SQL101: Avoiding Mistakes on a Production Database Server

As Kimberly blogged about earlier this year, SQLskills has an ongoing initiative to blog about basic topics, which we’re calling SQL101. We’re all blogging about things that we often see done incorrectly, technologies used the wrong way, or where there are many misunderstandings that lead to serious problems. If you want to find all of our SQLskills SQL101 blog posts, check out SQLskills.com/help/SQL101.

One reason that it is relatively difficult to get your first job as a DBA (compared to other positions, such as a developer) is that it is very easy for a DBA with Production access to cause an enormous amount of havoc with a single momentary mistake.

As a Developer, many of your most common mistakes are only seen by yourself. If you write some code with a syntax error that doesn’t compile, or you write some code that fails your unit tests, usually nobody sees those problems but you, and you have the opportunity to fix your mistakes before you check-in your code, with no one being any the wiser.

A DBA doing something like running an UPDATE or DELETE statement without a WHERE clause, running a query against a Production instance database when you thought you were running it against a Development instance database, or making a schema change in Production that is a size of data operation (that locks up a table for a long period) are just a few examples of common DBA mistakes that can have huge consequences for an organization.

A split-second, careless DBA mistake can cause a long outage that can be difficult or even impossible to recover from. In SQL Server, Cntl-Z (the undo action) does not work, so you need to be detail-oriented and careful as a good DBA. As the old saying goes: “measure twice and cut once”.

Here are a few basic tips that can help you avoid some of these common mistakes:

Using Color-Coded Connections in SSMS

SQL Server Management Studio (SSMS) has long had the ability to set a custom color as a connection property for individual connections to an instance of SQL Server. This option is available in legacy versions of SSMS and in the latest 17.4 version of SSMS. You can get even more robust connection coloring capability with third-party tools such as SSMS Tools Pack.

The idea here is to set specific colors, such as red, yellow, or green for specific types of database instances to help remind you when you are connected to a Production instance rather than a non-Production instance. It is fairly common to use red for a Production instance. This can be helpful if you don’t have red green color blindness, which affects about 7-10% of men, but is much less common among women.

Figure 1 shows how you can check the “Use custom color” checkbox, and then select the color you want to use for that connection. After that, as long as you use the exact same connection credentials for that instance from your copy of SSMS, you should get the color that you set when you open a connection to that instance.

I would not bet my job on the color always being accurate, because depending on exactly how you open a connection to the instance, you may not always get the custom color that you set for the connection. Still, it is an extra piece of added insurance.


Figure 1: Setting a custom color for a connection

Figure 2 shows a red bar at the bottom of the query window (which is the default position for the bar) after setting a custom connection color. This would help warn me that I was connected to a Production instance, so I need to be especially careful before doing anything.


Figure 2: Query window using red for the connection

Double-Checking Your Connection Information Before Running a Query

Something you should always do before running any query is to take a second to glance down to the bottom right of SSMS Query window to verify your current connection information. It will show the name of the instance you are connected to, your logon information (including the SPID number), and the name of the database you are connected to.

Taking the time to always verify that you are connected to the database and instance that you think you are BEFORE running a query will save you from making many common, costly mistakes.

Wrap Queries in an Explicit Transaction

One common safety measure is to wrap your queries (especially potentially dangerous ones that update or delete data) in an explicit transaction as you see in Figure 3. You open an explicit transaction with a BEGIN TRAN statement, then run just your query, without the COMMIT TRAN statement. If the query does what you expect (which the xx rows affected message can often quickly confirm), then you commit the explicit transaction by executing the COMMIT TRAN statement.

If it turns out that you just made a horrible mistake (like I did in the example in Figure 3) by omitting the WHERE clause, you would execute the ROLLBACK TRAN statement to rollback your explicit transaction (which could take a while to complete).


Figure 3: Using an explicit transaction as a safety measure

Test your Update/Delete Queries as Select Queries Before You Run Them

Another common safety measure is to write and run a test version of any query that is designed to change data, where you simply SELECT the rows that you are planning on changing before you actually try to change them with an UPDATE or DELETE statement. You can often just have the query count the number of rows that come back from your test SELECT statement, but you might need or want to to browse the data that comes back to be 100% sure that you don’t have a logic error in your query that would end up deleting or updating the wrong result set.

These are just a few of the most common measures for avoiding common DBA mistakes. The most important step is to always be detail-oriented and very careful when you are making potentially dangerous changes in Production, which is easier said than done. If you do make a big mistake, don’t panic, and don’t try to cover it up. Taking a little time to think about what you did, and the best way to quickly and correctly fix the problem is always the best course of action.

SQLskills SQL101: Azure SQL Database Monitoring

As Kimberly blogged about earlier this year, SQLskills has an ongoing initiative to blog about basic topics, which we’re calling SQL101. We’re all blogging about things that we often see done incorrectly, technologies used the wrong way, or where there are many misunderstandings that lead to serious problems. If you want to find all of our SQLskills SQL101 blog posts, check out SQLskills.com/help/SQL101.

If you are ready to start working with Azure SQL Database, which is Microsoft’s Platform as a Service (PaaS) offering for SQL Server, you will want some good diagnostic queries to use to help you better understand how your databases are performing and to give you more information than is exposed by the Azure Portal. After much delay and procrastination on my part, I have finally developed a version of my SQL Server Diagnostic Information Queries that are tailored for use with Azure SQL Database.

Azure SQL Database Diagnostic Information Queries

Azure SQL Database Blank Results Spreadsheet

The basic instructions for using these queries is that you should run each query in the set, one at a time (after reading the directions for that query). It is not really a good idea to simply run the entire batch in one shot, especially the first time you run these queries on a particular server, since some of these queries can take some time to run, depending on your workload and hardware. I also think it is very helpful to run each query, look at the results (and my comments on how to interpret the results) and think about the emerging picture of what is happening on your server as you go through the complete set. I have quite a few comments and links in the script on how to interpret the results after each query.

After running each query, you need to click on the top left square of the results grid in SQL Server Management Studio (SSMS) to select all of the results, and then right-click and select “Copy with Headers” to copy all of the results, including the column headers to the Windows clipboard. Then you paste the results into the matching tab in the blank results spreadsheet.

Please let me know what you think of these queries, and whether you have any suggestions for improvements. Thanks!

SQLskills SQL101: Creating SQL Server Databases

As Kimberly blogged about earlier this year, SQLskills has an ongoing initiative to blog about basic topics, which we’re calling SQL101. We’re all blogging about things that we often see done incorrectly, technologies used the wrong way, or where there are many misunderstandings that lead to serious problems. If you want to find all of our SQLskills SQL101 blog posts, check out SQLskills.com/help/SQL101.

One seemingly simple task that I very often see being done in a less than optimal way is creating a new database in SQL Server. Whether it is done with the SQL Server Management Studio (SSMS) GUI, or with a T-SQL CREATE DATABASE command, many people and organizations are creating new SQL Server databases without really thinking about what they are doing, and without taking advantage of a number of beneficial options and properties.

A SQL Server database requires one data file in the PRIMARY file group and one transaction log file. A very high percentage of SQL Server databases that I see in the wild only have these two required files, which can be problematic for a number of reasons related to both manageability and performance.

You should get in the habit of creating a new file group called MAIN, that is the default file group, that contains two or more data files that are the same size, with the same auto growth increment. If you do this, only the system objects will be in the required data file in the PRIMARY file group, while all of your user objects will be in the other data files in the MAIN file group. This will let you locate your data files across multiple LUNs (either now or in the future), which will make them easier to manage and potentially give you better I/O performance (if those LUNs actually map to separate underlying storage).

When you create a new SQL Server database, it inherits most of its properties from the model system database (unless you explicitly override those properties with ALTER DATABASE commands). By default, SQL Server creates the files for the database in the default location that was specified when SQL Server was installed, unless someone has changed those default locations using the Server Properties: Database Settings dialog shown in Figure 1.

If you do change these database default locations, you should make 100% sure that the new locations actually exist in your file system (since SQL Server does not validate them when you change them). If you change them to a non-existent location, and later try to install a SQL Server Service Pack or Cumulative Update, the Database Engine portion of the installation will fail at the end of the setup process, which could be an unpleasant surprise!


Figure 1: Server Properties: Database Settings Dialog

Another way to change the location and properties of your database files is by explicitly specifying what you want when you create the database, or afterwards, with an ALTER DATABASE command.

If you use the SSMS GUI to create a new database as shown in Figure 2, it only requires that you enter a name for the database, and then click the OK button. Even though this will work, it is not really the best method to create a new database. Instead, you should take the time to think about what you are doing and then change a few properties and settings from their default values.


Figure 2: New Database: General Dialog with default values

The first thing you should change is the Owner of the database. You should change it from <default> to sa, to ensure that your login is not the owner of the database. Next, you should change the initial size of the files to a more appropriate, larger value. You should also change the Autogrowth increment size for the files to a more appropriate, larger value that is a fixed size in megabytes rather than a percentage-based value. Finally, you may want to change the location where your initial database files will be located.  Your dialog should look something like what you see in Figure 3. After all of this, don’t click OK, because you are not done yet.



Figure 3: New Database: General Dialog with modified values

Next, you should go to the Options page, as shown in Figure 4, and think about whether you want to change any of your initial database property settings. For example, you might want to change the recovery model, the compatibility level, or possibly other settings depending on your workload or SLA requirements. The point here is to carefully consider your choices and make an explicit choice rather than just blindly accepting all of the default properties



Figure 4: New Database: Options Dialog with default values


Next, we want to go to the Filegroups page, and make some changes. You should add a MAIN file group, and make it the default file group, as you see in Figure 5.


Figure 5: New Database: Filegroups Dialog with modified values

The next step is to go back to the General page and add some data files to this new MAIN file group. In Figure 6, I have added two new data files to the MAIN file group, setting their properties to appropriate values. If desired, I could change their locations in the file system. After all of this work, do not click on the OK button! Instead, use the Script dropdown to select “Script Action to New Query Window”, so you can review, edit, and save your database creation T-SQL script.



Figure 6: New Database: General Dialog with final values

As appropriate for a SQL101-level post, this covers the basic options you should consider when creating a database, as opposed to just typing a database name and clicking OK. If you take the time to do this when you first create the database, you will have a lot more flexibility in the future as your database gets larger.