Browsing: SQL DBA tips

Database could not be exclusively locked Error 5030

Hi there! In this article we are going to discuss how to resolve the error “The database could not be exclusively locked to perform the operation. (Microsoft SQL Server, Error: 5030)”

The Complete error message while rename fails for exclusive lock looks like below: Refer How To Rename SQL Server Database

Database could not be exclusively locked

Why the Error Message:

You need to have exclusive lock on the database to rename the db. Exclusive lock means there are no other database connections open/using the database. SQL Engine is smart enough not to allow database name change while other users are accessing the database.

Query to Resolve Database could not be exclusively locked:

Following query will switch the database from Multi User mode to Single User mode, then rename the database and then set it back to Multi User mode.

USE master
GO
ALTER DATABASE [DatabaseName]  --Change The Database Name
SET SINGLE_USER  WITH  ROLLBACK  IMMEDIATE
GO
ALTER DATABASE [DatabaseName] MODIFY NAME = [NewDatabaseName]
GO
ALTER DATABASE [NewDatabaseName]  --Put the new database name
SET MULTI_USER WITH ROLLBACK IMMEDIATE

Point often overlooked in the above query is the final statement, where you need to put the new database name.

To demonstrate please find the following Example for database named “SQLGeeksPro” renaming to “SQLGeeksPro_NewName”

Database Could not be exclusively locked

{ Add a Comment }

Rename SQL Database Logical and Physical File Names

<<Previous

This article is in continuation of How To Rename SQL Server Database and here we are going show how to Rename SQL Database Logical and Physical File Names.

I am sure you have already got the idea from the previous article on what is logical and physical file name. The query we used to check the database file details is as follows: We are going to use this multiple times to verify the file details.

USE SQLGeeksPro_NewName -- Change the db Name
GO
SELECT DB_NAME() AS DatabaseName, file_id, name AS logical_name, physical_name
FROM sys.database_files
GO 

Now we are going to rename SQL Database logical and physical file name.

Query to Rename SQL Database Logical File Name:
USE master
GO
ALTER DATABASE [SQLGeeksPro_NewName] MODIFY FILE (NAME = SQLGeeksPro, NEWNAME = SQLGeeksPro_NewName_Data);
GO
ALTER DATABASE [SQLGeeksPro_NewName] MODIFY FILE (NAME = SQLGeeksPro_log, NEWNAME = SQLGeeksPro_NewName_log);
GO

Rename SQL Database Logical and Physical File NameNow let’s check the database file details again by executing the first query.

Example result set:

Rename SQL Database Logical and Physical File Name

 

As can be seen till now we are able to rename the database name and logical file name. Next and final step is to rename the physical file name.

Things become a bit tricky here as you can’t rename physical files while the database is online. Therefore I had mentioned in the first article that you need downtime.

Steps To Rename SQL Database Physical File Name:

To rename physical file name we have to take the database offline and for that we need exclusive access to the database and hence we’ll first put the database in Single User mode.  If there are any transactions running from application, it’s recommended to let them complete first.

In the below query, first statement will rollback any open transactions and set the database in single user mode. The second statement will put the database into offline state.

Step1: Put the database in Offline State
USE master
GO
ALTER DATABASE [SQLGeeksPro_NewName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE [SQLGeeksPro_NewName] SET OFFLINE

Rename Logical and Physical File Name

In SSMS the database status will look like below:

Rename Logical and Physical File Name

 

Step2: Rename the Physical Files

Go to the physical locations of data and log file and rename them. Below screen shot shows example for primary data file. You have to rename all the data and log files in respective physical locations.

 

Rename Logical and Physical File Name

Rename Logical And Physical File Name

 Step3:Update System Catalog

You have to inform SQL Server Engine that physical file name have been changed for the data and log files so that when you bring up the database it can refer the metadata and identify the new names. Otherwise it will try to look for the the old physical file names and will fail to bring the database online.

USE master
GO
ALTER DATABASE [SQLGeeksPro_NewName] MODIFY FILE (NAME ='SQLGeeksPro_NewName_Data', FILENAME ='F:\DATA\SQLGeeksPro_NewName_Data.mdf')
GO
ALTER DATABASE [SQLGeeksPro_NewName] MODIFY FILE (NAME ='SQLGeeksPro_NewName_Log', FILENAME ='F:\DATA\SQLGeeksPro_NewName_Log.ldf')
GO

The message shows that the system catalogs have been updated and new path will be used after the database is started.

Rename Logical and Physical File Name

Step4: Bring up the database using the below query
USE master
GO
ALTER DATABASE [SQLGeeksPro_NewName] SET ONLINE
GO
ALTER DATABASE [SQLGeeksPro_NewName] SET MULTI_USER

Rename Logical and Physical File name

Final step is to verify if all files have been renamed successfully as desired/as per organization standards.

You can execute the very first query provided in this article again:

Rename Logical and Physical File Name

Conclusion:

As can be seen above, renaming a SQL Server database can be done easily with a few steps. Rename not only SQL Server database alone but also logical and physical file names.

Feel free to leave your thoughts below in comment sections.

{ Add a Comment }

How To Rename SQL Server Database

Hi There! Today we are going to discuss How To Rename SQL Server Database the best way. Renaming a SQL Server database can be a straightforward process, but it is essential to follow the right steps to ensure data integrity and avoid disruptions. Trust me most of the DBAs think it is too easy to perform and end up missing an essential step which is discussed here.

Why Rename SQL Server Database?

Before jumping into the steps, it’s important to understand why you might need to rename a database. Common reasons are as follows:

  • Rebranding: Aligning the database name with a new organizational structure or branding.
  • Clarity: Improving the descriptiveness of the database name for better understanding among team members.
  • Organization: Consolidating database names for better management in multi-database environments.
  • Version Control: Adding version numbers or dates for better tracking.

Regardless of the reason, there may come a time when you want to or need to rename a database. In this tip we’ll look at the best option.

Prerequisites to Rename SQL Server Database:

First ensure the following:

  • Backups: Always have a recent backup of your database. This provides a safety net in case something goes wrong during the renaming process.
  • Permissions: Verify that you have the necessary permissions to rename the database. Typically, you need to be a member of the db_owner role or have ALTER permission
  • Downtime: The process needs downtime and hence always secure downtime approval/inform stake holders as per your organization process.
Two Different Methods can be used to Rename SQL Server Database:
  • Using SSMS (SQL Server Management Studio)
  • Using T-SQL

First of all let’s check and note the database details by running the following query:

USE SQLGeeksPro -- Change the db Name
GO
SELECT DB_NAME() AS DatabaseName, file_id, name AS logical_name, physical_name
FROM sys.database_files
GO 

The Results will be as shown below:

Rename SQL Database

Make a note of the highlighted details in the above example.

Rename SQL Database using SSMS:
Step 1: Connect to SQL Server

Open SQL Server Management Studio (SSMS) and connect to the SQL Server instance that contains the database you want to rename.

Step 2: Right click on the database and select the Rename option

Rename SQL Database

 

Step 3: Type in the new name you want for the database

Rename SQL Database

Now if you are not able to rename it because of the error message “The database could not be exclusively locked to perform the operation. (Microsoft SQL Server, Error: 5030)” then refer Database could not be exclusively locked

Rename SQL Database using T-SQL:
Step1: In SSMS open a new Query Window 
Step2: Execute the below Query:
USE master
GO
ALTER DATABASE [CurrentDatabaseName] MODIFY NAME = [NewDatabaseName] -- Change the CurrentDatabaseName and NewDatabaseName as required

For Example:
Rename SQL Database

This command works for SQL Server 2005, 2008, 2008R2, 2012, 2014, 2016, 2017, 2019 and 2022. Alternatively you can use sp_renamedb as well.

USE master
GO
EXEC sp_renamedb 'CurrentDatabaseName','NewDatabaseName'

Most of us think that in this way we have completed the database renaming. In other words you’ll be able to see the new name in SSMS. Important to realize and point often overlooked is we have not changed the logical and physical file name. To be sure execute the very first query provided above to check the file names:

Result will be as shown below:

Rename SQL Database

As can be seen in the highlighted portion in green, only the database name got changed and there is no change for logical and physical file names. This may cause confusion in future even if we keep the technical issues aside. We can discuss it in another blog post.

Therefore you need to change the logical and physical file names as well. >>Continue Reading

{ Add a Comment }

Fix Incorrect Mexico Time in SQL Server sys.time_zone_info

In this article we are going to discuss how to fix incorrect Mexico Time in SQL Server sys.time_zone_info system catalog.

Problem:

One of our customer informed that Mexico changed their DST . In UAT, application is showing correct time which is UTC -6 however in Production the mexico time zone is showing as UTC – 5. The application is referring the sys.time_zone_info system catalog in SQL Server.

Troubleshooting:

In the first place you should understand what is the actual problem. In other words what the customer is talking about. The problem statement it is not very clear if it is SQL Server issue or OS issue or it is something to do with application code.

After a short call with the customer we got to know that as per Mexican Government order published in October 26th, 2022, that Daylight Saving Time (DST) in the United Mexican States will not be observed in 2023 calendar year.

Second is to compare the UAT and Production environment.

  • No change in code at application end.
  • There is no difference in OS time zone settings in application and database server.
  • The result of Mexico Time Zone in sys.time_zone_info were different.

Query to check the Mexico Time Zone information:

SELECT * FROM sys.time_zone_info
WHERE name LIKE '%Mexico%'

Result:

Mexico Time

The above result was from UAT where the output is showing correct. Likewise we checked it in Production environment and result is as follows:

Mexico Time Zone

Certainly we could see the difference as mentioned by the customer. What next?

  • Checked the SQL Server patch and both UAT and Production Instance were in the same patch level
  • Compared the OS patch level on both the servers and we could find the difference in patches installed

Being DBA you need to know how to verify these stuffs to be able to quickly identify the issue. Below screen shot will help you with the path:

Mexico Time Zone

The highlighted patch was not installed in Prod because it was scheduled for next month patching cycle.

A quick read about the patch in the KB article  KB5023702 clarifies the issue:

Mexico Time Zone

Resolution & Conclusion:

The resolution is a no brainer once you find the issue. You have to follow the process as per your organization and get the patch installed in the server.

To conclude incorrect time zone in sys.time_zone_info is not a SQL Server issue. However being DBA you should be able to troubleshoot, find the root cause and suggest the solution. If customer complains about one server shows correct time zone while the other is incorrect without doing any changes in the application end, you should perform a thorough check at server end. The issue occurred because of not having latest OS patch and you can resolve it by going through the relevant article of the OS patch and get it installed.

{ Add a Comment }

Error 15141: The Server Principal Owns One or More Server Roles

Today we are going to discuss about how to resolve the “Error 15141: The Server Principal Owns One or More Server Roles and cannot be dropped”

Introduction

If you are a SQL Server DBA, you may encounter the Error 15141 when trying to delete a login id. First of all let me show you how the error message looks like in SSMS when you try to delete/drop a login.

The Server Principal Owns One or More Server Roles

In the above example screen shot we are trying to delete the login id ‘Admin’. I have observed that some DBA(s) do not read the error message carefully and starts beating about the bush.

There are very similar error messages while dropping logins as you can refer the following links:

Error 15141: The Server Principal Owns One or More Availability Groups

Error 15141: The Server Principal Owns One or More Endpoints

Error 15434: Could not drop login as the user is currently logged in

To emphasize if you observe the above error message clearly reads that the principal (or login) owns one or more server roles, which prevents you from dropping it.

Cause Of the Error 15141: The Server Principal Owns One or More Server Roles

When a server principal or login owns a server role, you cannot drop the login unless you first transfer ownership of the server role to another login. As a matter of fact SQL Server never allows you to drop a login if it owns any object. Hence it throws the error preventing you to drop the server principal or login.

Resolution

To resolve the error, you first need to identify the Server Roles owned by the login or server principal. Then you need to transfer the ownership for each of the server roles to ‘sa’ or any other login as per your organization standard.

1. Query to Identify the Server Roles the Login owns

SELECT sp1.name AS ServerRoleName, 
       sp2.name AS RoleOwnerName
       FROM sys.server_principals AS sp1
       JOIN sys.server_principals As sp2
       ON sp1.owning_principal_id=sp2.principal_id
       WHERE sp2.name='Admin' --Change the login name

Sample Output:

The Server Principal Owns One or More Server Roles

Here in the above example it shows that the login id ‘Admin’ owns two Server roles. On the contrary if the login would have own one or more database role(s), it would allow to delete the login but not the user. Now we’ll change the ownership.

2. Query to Change the Server Role Owner:

USE [master]
GO
ALTER AUTHORIZATION ON SERVER ROLE :: [ServerRole-Test] TO [sa] --Change The ServerRole Name and login Name
GO
ALTER AUTHORIZATION ON SERVER ROLE :: [AnotherServerRole-Test] TO [sa] --Change The ServerRole Name and login Name
GO

3. Drop the Login:

USE [master]
GO
DROP Login [Admin] --change the login Name

Query Result:

The Server Principal Owns One or More Server Roles

As can be seen now the the drop command completed successfully.

Conclusion:

To summarize the error Error 15141: The Server Principal Owns One or More Server Roles and cannot be dropped occurs when the login or server principal owns one or more Server Roles and you are trying to drop the login. Obviously you should not take any knee jerk reaction. After all you are trying to resolve the issue. Hence you should first list out the Server Roles which the login owns. Then change the ownership to [sa] or any other login as per your organization standards. Finally delete or drop the login. Definitely this should resolve the issue. Important to realize that this method will allow you to delete the login even if the login owns and database roles. Hence to repeat you need to be very careful while working in production systems.

{ Add a Comment }

Error 15141: The Server Principal Owns One or More Availability Groups

Hey there, this article is about understanding and resolving the error message  “Error 15141: The Server Principal Owns One or More Availability Groups and cannot be dropped”.

Introduction

First of all let me tell you that the above mentioned error occurs when you try to delete a login in a SQL Server Always On Instance. The error message clearly says that the Login Owns an Availability Group(s). In SSMS the error message looks like as shown in the below screen shot.

Error 15141: The Server Principal Owns One or More Availability Groups

Why does the Error 15141: The Server Principal Owns One or More Availability Groups occur in SQL Server?

SQL Server does not allow you to drop any login or Server principal which owns any objects. In this case the server principal is owning an Availability Group. If it allows to drop the login then the Availability Group will become orphaned and that is why SQL Server does not allow to do so.

Now the next question is how come the login has become the owner of the Availability Group.  This is because the login had created the Availability Group while configuring Always On. Does it create any issues as far Always On functionality is concerned? NO, it does not. Then why you need to drop the login?

This is mostly because of the Organization standards. No individual login id should own any Availability Groups. Imagine if the the user leaves the organization and the Id has been removed from Active Directory.

Resolution:

To resolve the error first thing the DBA should do is to identify the list of Availability Groups owned by the login or server principal. Once you have the list, you need to change the ownership to ‘sa’ or any other login as per your Organization Standards. I always say don’t panic and never try to delete the Availability Group itself.

1.Query to Identify the Availability Groups the login Owns:

SELECT ag.[name]  AS availability_groups_name
    ,sp.[name] AS owner_name
    ,ag.group_id
    ,ar.replica_id
    ,ar.owner_sid
FROM  sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.server_principals sp ON ar.owner_sid = sp.[sid]
WHERE sp.[name]= 'GLOBAL\Dev' -- Change the login name

Sample Output:

Error 15141: The Server Principal Owns One or More Availability Groups

Notably the above output shows that the login ‘GlOBAL\Dev’ owns the Availability Group “DEV-AVG01′. Now we’ll change the owner.

2. Query to Change the Availability Group Owner:

 USE [master]
 GO
 ALTER AUTHORIZATION ON AVAILABILITY GROUP::[DEV-AVG01] TO [sa];
 GO

Now again run the Select query to check the Ownership. Once confirmed you can try dropping the login id.

3. Drop the Login:

 USE [master]
 GO
 DROP LOGIN [GLOBAL\Dev]  --Change the login 
 GO

Summary

To conclude, the Error 15141: The Server Principal Owns One or More Availability Groups occur in SQL Server is one of the common errors DBAs encounter while working on SQL Server Always On Instances. Specifically the error occurs when you try to delete a login or server principal which owns one or more availability Groups. While troubleshooting, first thing to remember is not to take any hasty decision. Particularly in Production. The DBA must first list out the Availability Groups owned by the login and then change the ownership to a different login id as per Organization standards which will resolve the issue.

You can also refer the following articles if you are facing Error 15141: The Server Principal Owns One or More Endpoints 

Or Error 15434: Could not drop login as the user is currently logged in

{ Add a Comment }

Error 15434: Could not drop login as the user is currently logged in

Hey there, the other day I got a call from a DBA saying he is not able to drop a login from a SQL Instance and getting the following error:
“Error 15434: Could not drop login as the user is currently logged in.”

In this blog post, we will discuss what this error message means, why it occurs and how to resolve it. First of all let’s see how the error message looks like SSMS.

Error 15434: Could not drop login as the user is currently logged in

 

This error message says database administrator tries to drop a login who is doing some work/running transactions in the SQL Server. First thought came to the DBA’s mind is to wait until the login/user disconnects to the database before they can drop it.

Why does Error 15434 occur in SQL Server?

The error occurs because you are trying to delete/drop a login which has a session (Active/Inactive) in the SQL Instance. The SQL server does not allow to drop the login because it would terminate the session. This can cause business impact.

Resolution:

To resolve Error 15434, the database administrator must first identify the connected session and then either wait for the session to be disconnected or manually disconnect the session. Always check with the user if possible. If it is more or like a generic ID like the above example (‘Admin’), it becomes little tricky.

When I got the call, first thing I checked with the DBA if he is trying to delete his own id. This situation may also occur when you Installed SQL Server and added your individual id and as part of the cleaning process you want to delete your id.

Point often overlooked is that you can not delete your own id. In that case you need to connect either using “sa” account or another “security admin” and “processadmin” (to be able to kill the process) or sysadmin account. If you don’t have another such account then ask your fellow DBA(s) to follow the below steps. Obviously SQL Server does not allow to kill your own session.

1. Identify the connected sessions:

 
USE master
GO 
SELECT spid, blocked  AS BlockedBy, loginame  AS LogInName, login_time,
last_batch, status
FROM   sys.sysprocesses
WHERE loginame = 'Admin'   --Change the loginID you are trying to delete

Sample Output:
Error 15434: Could not drop login as the user is currently logged in

Now few points to observe from the sample output. You got few sessions which for the login and they are in sleeping status. You need to to also observe the login_time and the last_batch which is basically the last activity time completed with the connection. If both of them are old, you can decide on killing the sessions. Again be very careful while you do this in production environment.

2. Disconnect or Kill the Sessions:

KILL spid

Screen Shot with above example Spids:
Error 15434: Could not drop login as the user is currently logged in

3. Delete the Login:

DROP Login [loginame]

Error 15434: Could not drop login as the user is currently logged in

As you can see from the above screen shot the login is dropped without any issue/errors.

Summary:

To conclude, the error “Error 15434: Could not drop login as the user is currently logged in” occurs when you try to delete a login having active/inactive connections to the SQL Instance. The database administrator must first identify and disconnect the connected session, and then drop the login.

You can also refer the below articles related to login drop issues:

Error 15141:The Server Principal Owns One or More Endpoints and cannot be Dropped

Error 15141: The Server Principal Owns One or More Availability Groups

{ Add a Comment }

Error 15141: The Server Principal Owns One or More Endpoints and Cannot be Dropped

Problem:

As a DBA you may encounter the following error message “The Server Principal Owns One or More Endpoints and Cannot be Dropped. (Microsoft SQL Server Error:15141)” while deleting a login id in Always On SQL server.

This happens because the user (DBA) configured the Always on and configured it. As security best practice we should not keep any individual login id in SQL Instances. All domain logins should be part of the Active Directory group.

The error message:

The Server Principal Owns One or More Endpoints and Cannot be Dropped

What is Endpoint in SQL Server:

SQL Server Endpoint is a communication channel that enables clients to connect to the server and access data. It is a database object that defines the ways and means  in which SQL Server may communicate over the network. In SQL Server Always on this endpoint is a special-purpose endpoint that is used exclusively to receive connections from other server instances.

SQL Server will not allow you to drop a user that owns an endpoint because it would disrupt communication for the clients that use the endpoint.

Resolution:

As shown above, the error clearly says that the login owns one or more endpoints. First thing is NOT to have a knee jerk reaction to delete the endpoint itself.

First you need to check the endpoints and their ownership. Second you can change the ownership to “sa” or the domain account as per your organization standards.

Query to to check the Endpoint Ownership:

USE master
GO 
SELECT e.name as  EndpointName,
sp.name AS  EndpointOwner,e.type_desc AS Endpint_Type, e.state_desc  AS Endpoint_Status
FROM  sys.endpoints e
INNER JOIN  sys.server_principalssp
 ON e.principal_id = sp.principal_id

Output Showing  individual login ID owning the Endpoint “Hadr_endpoint”:

Error 15141: The Server Principal Owns One or More Endpoints and Cannot be Dropped

Furthermore the endpoint’s name is “Hadr_endpoint” which is the default name of the Availability Group (AG) endpoint. Hence this confirms the individual loginID is part of Always On setup .

Next step is to change the ownership of the endpoint to the login id as per your organization’s standards. In this example I am changing it to “sa”

Here we are using ALTER Authorization statement to transfer ownership. We can not set the ownership to database level users. ALTER AUTHORIZATION is the statement to change the ownership of any entity that has an owner.

Command to change the Endpoint Ownership:

--Replace the login id [sa] with your login.
ALTER Authorization on endpoint ::Hadr_endpoint to [sa]
GO

Now again run the Select query to check the Ownership. Once confirmed you can try dropping the loginid.

Drop LoginID:

DROP Login  [GlOBAL\Tridib.Dev] --Change the loginID you want to delete 

Error 15141: The Server Principal Owns One or More Endpoints and Cannot be Dropped

Conclusion:

In summary, By understanding endpoint and why dropping a user with an endpoint is prohibited, you can quickly resolve this issue by transferring the ownership to a standard account and continue with your database administration tasks.

You can refer Error 154934: Could not drop login as the user is currently logged in

Error 15141: The Server Principal Owns One or More Availability Groups

{ Add a Comment }

SQL Server Orphaned Files: Causes and Consequences

SQL Server orphaned files are a common issue faced by database administrators. These files are no longer in use by the SQL Server database but still exist on the file system. In this blog post, we will discuss the causes of SQL Server orphaned files and the problems they can cause.

Causes of Orphaned Files

There are several reasons why orphaned files can occur in a SQL Server environment. Some of the common causes include:

  • Detached databases: When a database is detached from the SQL Server, the files are not automatically removed, leaving behind orphaned files. For example, if a database is detached and the files are not deleted, they will be considered as orphaned files.
  • Improperly deleted Databases: This is often overlooked. Whenever you do database decommission, as per best practice first you keep it  offline for a week or so. Once you do not hear anything you go ahead and delete it.

Here is the catch. If you delete the database files while the database is offline, SQL Server do not remove the files automatically.

Let me give you a demo. In the below example I have created a database “AA_Decom”.

Offline Database deletion keeps the physical files

SQL Server Orphaned Files

Now let me take the database offline and then delete it.

SQL Server Orphaned Files

 

Right Click on the database and Delete:

SQL Server Orphaned Files

Let’s Verify if the database and Files are visible to SQL Server. The below screen shot shows they are no longer available.

SQL Server Orphaned Files

However the below screen shot shows the physical files still exists in the data and log file path. This is one of the main reasons of having SQL Server Orphaned files.

SQL Server Orphaned Files

SQL Server Orphaned Files

  • Upgrading or Migration: During the process of upgrading or migrating to a new version of SQL Server, if the files are not properly transferred or handled, it can lead to orphaned files.

Consequences of Orphaned Files

Orphaned files in SQL Server can lead to a number of negative consequences. Some examples of the consequences of orphaned files include:

  • Lack of Disk Space: Orphaned files can take up valuable disk space on the server, which can lead to disk space issues. For example, if the disk space is full and the SQL Server cannot write to the transaction log, it can cause the database to become unavailable.
  • Difficulty in Identifying and Removing Unnecessary Files: These files can also cause confusion when trying to identify which files are in use and which are not, making it difficult to properly manage and maintain the database. For example, if the DBA has to go through hundreds of files to identify which are in use and which are not, it can take a lot of time and resources.
  • Security Risks: Orphaned files can also pose a security risk. For example, if an orphaned file contains sensitive information, it could be accessed by unauthorized users.

It’s important to keep an eye on the orphaned files and take necessary actions to remove them, in order to avoid these consequences. Let me know if you have observed any other scenarios by putting your comments below.

You may also like to go through below articles:

Top 5 Tips for Speeding Up SQL Server Backups

Tips to Improve SQL Database Restore Performance

How to Force Manual Failover AlwaysOn Group

 

{ Add a Comment }

What and How to Enable 3GB Switch

Hello there! In this article we are going to learn what is /3GB switch, enabling 3GB switch and verifying 3GB switch. First of all let me tell you in brief why you need to know about 32 bit application configurations.

Sooner or later you will encounter one of the legacy systems (e.g. SQL Server 2005 32 bit on Window Server 2003) having some weird issues or someone may reach out to you for help. Recently I got a question from one of the DBAs on how to enable 3GB switch as he/she never worked on such environment.

What is 3GB Switch

/3GB switch changes the first 4 gigs allocation. To put it differently,  without the switch, 2 gigs are allocated to the OS, and 2 gigs are allocated to applications. With the /3GB switch, application can utilize 3GB memory while the OS can use only the remaining 1 gig. This switch only affects the first 4 gigs of RAM. The switch is there or need to be added in boot.ini file.

How to Enable 3GB Switch

The below screen shots are from Window Server 2003 Standard Edition.
Right click on “My Computer” > Properties

Enabling 3GB Switch

Click on Advanced

Enabling 3GB Switch

Under “Startup and Recovery” click the “Settings” button.

Enabling 3GB Switch

Click On “Edit”

Enabling 3GB Switch

This will open the boot.ini file in notepad. Add /3GB in the last line as shown in the following screen shot and save the file.

Enabling 3gb switch

Not to mention, If the switch is enabled, you will find it (/3GB) already in the boot.ini file. This is how you can verify /3GB switch.

Hope it helps. Please let me know by putting your comments below. You may be interested in the below articles as well:

SQL Agent Job Schedule changed automatically

How to handle OS Patching In SQL Server Always On

Database restore stuck at 100 Percent

{ Add a Comment }