As Kimberly blogged about earlier this year<\/a>, SQLskills has an ongoing initiative to blog about basic topics, which we\u2019re calling SQL101. We\u2019re 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<\/strong> blog posts, check out SQLskills.com\/help\/SQL101<\/a>.<\/em><\/p>\n

One seemingly simple task that I very often see being done in a less than optimal way is creating a new database<\/a> in SQL Server. Whether it is done with the SQL Server Management Studio<\/a> (SSMS) GUI, or with a T-SQL CREATE DATABASE<\/a> 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.<\/p>\n

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.<\/p>\n

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).<\/p>\n

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. <\/p>\n

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!<\/p>\n

<\/a><\/p>\n

Figure 1: Server Properties: Database Settings Dialog<\/strong><\/p>\n

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<\/a> command.<\/p>\n

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.<\/p>\n

<\/a><\/p>\n

Figure 2: New Database: General Dialog with default values<\/strong><\/p>\n

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\u2019t click OK, because you are not done yet.<\/p>\n

 <\/p>\n

<\/a><\/p>\n

Figure 3: New Database: General Dialog with modified values<\/strong><\/p>\n

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<\/p>\n

 <\/p>\n

<\/a><\/p>\n

Figure 4: New Database: Options Dialog with default values<\/strong><\/p>\n

 <\/p>\n

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.<\/p>\n

<\/a><\/p>\n

Figure 5: New Database: Filegroups Dialog with modified values<\/strong><\/p>\n

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 \u201cScript Action to New Query Window\u201d, so you can review, edit, and save your database creation T-SQL script.<\/p>\n

 <\/p>\n

<\/a><\/p>\n

Figure 6: New Database: General Dialog with final values<\/strong><\/p>\n

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.<\/p>\n","protected":false},"excerpt":{"rendered":"

As Kimberly blogged about earlier this year, SQLskills has an ongoing initiative to blog about basic topics, which we\u2019re calling SQL101. We\u2019re 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 […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28,29,30,31,156,246,342,309],"tags":[312],"class_list":["post-1202","post","type-post","status-publish","format-standard","hentry","category-sql-server-2005","category-sql-server-2008","category-sql-server-2008-r2","category-sql-server-2012","category-sql-server-2014","category-sql-server-2016","category-sql-server-2017","category-sql101","tag-sql101"],"yoast_head":"\n