ptg 714 CHAPTER 23 Creating and Managing Databases ( NAME = N’mydb_index1’, FILENAME = N’I:\mssql2008\data\mydb_index1.ndf’ , SIZE = 2048KB , FILEGROWTH = 1024KB ), FILEGROUP [UserData_FG] ( NAME = N’mydb_userdata1’, FILENAME = N’D:\mssql2008\data\mydb_userdata1.ndf’ , SIZE = 2048KB , FILEGROWTH = 1024KB ), ( NAME = N’mydb_userdata2’, FILENAME = N’E:\mssql2008\data\mydb_userdata2.ndf’ , SIZE = 2048KB , FILEGROWTH = 1024KB ), ( NAME = N’mydb_userdata3’, FILENAME = N’F:\mssql2008\data\mydb_userdata3.ndf’ , SIZE = 2048KB , FILEGROWTH = 1024KB ) LOG ON ( NAME = N’mydb_log’, FILENAME = N’L:\mssql2008\log\mydb_log.ldf’ , SIZE = 1024KB , FILEGROWTH = 10%) This example creates a database named mydb that has three filegroups. The first filegroup, PRIMARY, contains the .mdf file. Index_FG contains one file: I:\mssql2008\data\mydb_ index1.ndf. The third filegroup, UserData_FG, contains three data files located on the D:, E:, and F: drives. This example demonstrates the relationship between databases, file- groups, and the underlying operating system files. (The T-SQL for creating a database is discussed in detail later in this chapter.) After you create a database with multiple filegroups, you can then create a database object on a specific filegroup. In the preceding example, you could use the filegroup named UserData_FG to hold user-defined tables, and you could use the filegroup named Index_FG for the database indexes. You assign database objects at the time you create the object. The following example demonstrates the creation of a user-defined table on the UserData_FG filegroup and the creation of an index for that table on the Index_FG filegroup: CREATE TABLE dbo.Table1 (TableId int NULL, TableDesc varchar(50) NULL) ON [UserData_FG] CREATE CLUSTERED INDEX [CI_Table1_TableID] ON [dbo].[Table1] ( [TableId] ASC) ON [Index_FG] Any objects not explicitly created on a filegroup are created on the default filegroup. The PRIMARY filegroup is the default filegroup when a database is created. You can change the default filegroup, if necessary. If you want to change the default group to another group, you can use the ALTER DATABASE command. For example, the following command changes the default filegroup for the mydb database: ALTER DATABASE [mydb] MODIFY FILEGROUP [UserData_FG] DEFAULT Download from www.wowebook.com ptg 715 Database Files You can also change the default filegroup by right-clicking the database in the Object Explorer, choosing Properties, and selecting the Filegroups page. Then you select the check box labeled Default to make the given filegroup the default. Figure 23.1 shows the filegroups for the AdventureWorks2008 database, with the primary filegroup selected as the default. 23 When creating filegroups, you should keep in mind the following restrictions: . You can’t move a data file to another filegroup after it has been added to the database. . Filegroups apply only to data files and not to log files. . A data file can be part of only one filegroup and cannot be spread across multiple filegroups. . You can have a maximum of 32,767 filegroups for each database. NOTE Using SANs and RAID arrays for the database disk subsystem diminishes the need for filegroups. SAN and RAID systems typically have many disks mapped to a single data drive. This inherently allows for concurrent disk access without requiring the creation of a filegroup with multiple data files. FIGURE 23.1 Setting the default filegroup in SQL Server Management Studio (SSMS). Download from www.wowebook.com ptg 716 Using Partitions Partitioning in SQL Server 2008 allows for a single table or index to be aligned to more than one filegroup. This capability was introduced in SQL Server 2005. Prior to SQL Server 2005, you could use filegroups to isolate a table or an index to a single filegroup, but the table or index could not be spread across multiple filegroups or data files. The ability to spread a table or an index across multiple filegroups is particularly useful for large tables. You can partition a table across multiple filegroups and have data files live on separate disk drives to improve performance. Table partitioning is discussed in more detail in Chapter 24, “Creating and Managing Tables.” Transaction Log Files A transaction is a mechanism for grouping a series of database changes into one logical operation. SQL Server keeps track of each transaction in a file called the transaction log. This log file usually has the extension .ldf, but it can have a different extension. Typically, there is only one log file. You can specify multiple log files, but these files are accessed sequentially. If multiple files are used, SQL Server fills one file before moving to the next. You realize no performance benefit by using multiple files, but you can use them to extend the size of the log. NOTE The transaction log file is not a text file that can be read by opening the file in a text editor. The file is proprietary, and you cannot easily view the transactions or changes within it. However, you can use the undocumented DBCC LOG (database name) com- mand to list the log contents. The output is relatively cryptic, but it can give you some idea of the type of information that is stored in the log file. Because the transaction log file keeps track of all changes applied to a database, it is very important for database recovery. The transaction log is your friend: it can prevent signifi- cant data loss and provide recovery that is not possible without it. Consider, for example, a case in which a database is put in simple recovery mode. In short, this causes transac- tion detail to be automatically removed from the transaction log. This option is often selected because the transaction log is seen as taking too much disk space. The problem with simple mode is that it limits your ability to recover transactions. If a catastrophic failure occurs, you can restore your last database backup, but that may be it. If that backup was taken the night before, all the database work done that day is lost. If your database is not in simple mode (Full or Bulk-Logged), and the transaction log is intact, you have much better recovery options. For example, if you back up your transac- tion log periodically (for example, every hour) and a catastrophic error occurs, your data loss is limited. You still need to restore your last database backup, but you have the option of applying all the database changes stored in your transaction log. With hourly backups, you should lose no more than an hour’s worth of work. This topic is covered in detail in Chapter 14, “Database Backup and Restore.” CHAPTER 23 Creating and Managing Databases Download from www.wowebook.com ptg 717 Creating Databases 23 How the Transaction Log Works SQL Server utilizes a write-ahead log. As changes are made to data through transactions, those changes are written immediately to the transaction log when the transaction is complete. The write-ahead log guarantees that all data modifications are written to the log prior to being written to disk. By writing each change to the transaction log before it is written to the database, SQL Server can increase I/O efficiency to the data files and ensure data integrity in case of system failure. To fully understand the write-ahead log, you must first understand the role of SQL Server’s cache or memory as it relates to database updates. SQL Server does not write updates directly to the data page on disk. Instead, SQL Server writes a change to a copy of the data page that has been placed in memory. Pages changed in memory and not yet written to disk are called dirty pages. The same basic approach is used for transaction log updates. The update to the log is performed in the log cache first, and it is written to disk at a later time. The time when the updates are actually written from cache to disk is called a checkpoint. The checkpoint occurs periodically, and SQL Server ensures that dirty pages are not written to disk before the corresponding log entry is written to disk. The write-ahead log was designed for performance reasons, and it is critical for the recov- ery process after a system failure. If the system fails, an automatic recovery process is initi- ated when SQL Server restarts. This recovery process can use the checkpoint marker in the log file as a starting point for recovery. SQL Server examines all transactions after the checkpoint. If they are committed transactions, they are rolled forward; if they are incom- plete transactions, they are rolled back, or undone. NOTE Changes were made in SQL Server 2005 that improve the availability of the database during the recovery process. These changes have been carried forward to SQL Server 2008. In versions prior to SQL Server 2005, the database was not available until it was completely recovered and the roll-forward and roll-back processes were complete. In versions following SQL Server 2005, the database is made available right after the roll-forward process. The roll-back or undo process can occur while users are in the database. This feature, known as Fast Recovery, is available only with the Enterprise Edition of SQL Server 2008. For more detailed information on this topic, see Chapter 31, “Transaction Management and the Transaction Log.” Creating Databases Database creation is a relatively straightforward operation that you can perform by using T-SQL statements or SSMS. Because the data and log files are created at the time the data- base is created, the time it takes for the database to be created depends on the size and number of files you specify when you create the database. If there is not enough disk space to create any of the files specified, SQL Server returns an error, and none of the files are created. Download from www.wowebook.com ptg 718 FIGURE 23.2 Creating a database by using SSMS. NOTE Enhancements that were added in SQL Server 2005 and still exist in SQL Server 2008 have reduced the amount of time it takes to create a database. The reduction in cre- ation time is attributed to a change in the way the database files are initialized. The ini- tialization of the file with binary zeros is now deferred until the file is accessed via SQL queries. This results in much faster database creation and expansion. For example, we created a database with a 1GB data file on a machine running SQL Server 2008. The database was created in approximately 1 second. The same database was then creat- ed in SQL Server 2000, running on the same machine. The creation of the database on SQL Server 2000 took approximately 36 seconds. This new feature will make a lot of folks who create and support large databases very happy. Using SSMS to Create a Database The Object Explorer in SSMS makes creating a database simple. You right-click the Databases node and select New Database. The New Database dialog appears, as shown in Figure 23.2. The General page is selected by default. It allows you to select the essential information needed to create a database, including the database name, database owner, and location of the database files. CHAPTER 23 Creating and Managing Databases Some related information is populated when you enter the database name. For example, the logical name of the database files is populated using the database name. The data file Download from www.wowebook.com ptg 719 Creating Databases 23 (which is identified with the file type Data) is named the same as the database. The log file (file type Log) has a database name with the suffix _log. The logical filename can be changed, but it must be unique within the database. The location of the database files is an important decision. The location for each file is entered in the Path column in the Database Files grid. This column, located on the right side of the Database Files grid, includes an ellipsis that can help you navigate the directory structure on your server. When you select the location of these files, you should keep in mind the following: . Disk space—Databases, by nature, grow over time. You need to make sure the loca- tion where you place your database files has sufficient space for growth. . Performance—The location of your database files can affect performance. Generally, the data and log files should be placed on separate disk drives (with sepa- rate controllers) to maximize performance. . Organization—Choosing a common location or directory for your database files can help keep things organized. For example, you could choose to place your data files in directories named \mssql\data\ and \mssql\log instead of using the long pathname that SQL Server uses by default. There are several restrictions related to the database files specified. Each filename must be unique and cannot be used by another database. The files specified for a database must be located on a local drive of the machine where SQL Server is installed, a SAN drive, or an iSCSI-based network drive. Finally, you need to make sure the path specified exists on the drive prior to creating the database. NOTE The default path for the database files is populated based on database settings val- ues specified in the Server Properties dialog. To open this dialog, you right-click the server in the Object Explorer and choose Properties. When the Server Properties dia- log appears, you choose the Database Settings page, where you see the database default locations. If the database default locations for the log and data files are not specified, the paths to the master database files are used. You can determine the paths to the master database files by looking at the startup parameters for the SQL Server instance. You can view these startup parameters within the SQL Server Configuration Manager. After you open this application, you right-click the SQL Server service and select Properties. On the Advanced tab of the Properties dialog that appears, you find the setting named Startup Parameters. The –d parameter identifies the location of the data file for the master database. The –l parameter identifies the location of the log file for the master database. The remaining pages in the New Database dialog allow you to set database options, utilize filegroups, and set extended properties. The Options page contains many settings discussed in the “Setting Database Options” section later in this chapter. Three settings at the top of the Options page deserve special attention: Collation, Recovery Model, and Compatibility Level. Figure 23.3 shows the Options page. Download from www.wowebook.com ptg 720 CHAPTER 23 Creating and Managing Databases FIGURE 23.3 The Options page for creating a database. Collation specifies how strings are sorted and compared. The selection of collation is language dependent and addresses differences in the way characters are ordered. The default collation for a database is based on the server default, which is set during the installation of SQL Server. The server default for many U.S based installations is SQL_Latin1_General_CP1_CI_AS. The collation name provides some insight into how the collation will work. For example, CI is an acronym for Case Insensitive, and AS indicates that the collation will be Accent Sensitive. The following SELECT statement can be used to list all the available collations and relates details about how the collation behaves: SELECT * from ::fn_helpcollations() The Recovery Model setting is critical in determining how much data can be recovered in the event of a media failure. The default is Full, which provides the greatest level of recov- ery. With Full recovery, all changes to the database (inserts, updates, and deletions) are written to the transaction log, and so are any changes that may have occurred using BCP or BULK INSERT. If a failure occurs on one of the database files, you can restore the database by using the last full backup. All the changes captured in the transaction log since the last full backup can be reapplied to the database as well. The Bulk-Logged recovery setting is similar to Full recovery but has some differences in the way that operations (BCP or BULK INSERT) are logged. With Bulk-Logged recovery, you can still restore all the transaction log backups to recover your database to a point in time. Download from www.wowebook.com ptg 721 Creating Databases 23 NOTE When either Full recovery or Bulk-Logged settings is selected, it is important to set up a job or maintenance plan that performs periodic backups of the transaction log. A backup of the transaction log removes data from the log and keeps the size of the transaction log manageable. If regular backups of the transaction log are not made, the transaction log will continue to grow as every change in the database is written to it. Simple recovery mode offers the simplest backup/recovery model but the greatest possibil- ity of losing changes to the database. This is based on the fact that changes recorded in the transaction log are automatically truncated when the database is placed in Simple recovery mode. Recovery with Simple mode is limited to using full or differential database backups that have been taken. Simple recovery mode is a good option for read-only data- bases and for development databases that can afford the loss of changes since the last database backup. All the recovery models are discussed in detail in Chapter 14. The last setting on the Options page that deserves special attention is Compatibility Level. The Compatibility Level determines the level of backward compatibility the database engine uses. For many newly created databases in SQL Server 2008, the default of SQL Server 2008 (100) will suffice. With this setting, all the new features available with SQL Server 2008 are utilized. In some situations, however, you might want a SQL Server 2008 database to behave as though it were a SQL Server 2005 database or SQL Server 2000 data- base. You can accomplish this by setting Compatibility Level to SQL Server 2005 (90) or SQL Server 2000 (80). Generally, you select older compatibility levels to allow code that was developed for prior versions of SQL Server to work as it did with those versions. NOTE The Compatibility Level setting is intended to allow a database to behave as if it were running in a previous version of SQL Server by providing similar query behavior or by allowing deprecated features to still work as they did in the previous version. However, setting the Compatibility Level to a prior version does not prevent new SQL Server 2008 features from being implemented in the database. The intent of this functionality is to provide a means for moving a database and application developed for a previous release of SQL Server to SQL Server 2008 and allow it to work as it did while enabling you to start taking advantage of new features and capabilities as you migrate the sys- tem to SQL Server 2008. Using T-SQL to Create Databases Instead of using SSMS, you can use T-SQL to create a database. The T-SQL command to do this is CREATE DATABASE. The CREATE DATABASE syntax is extensive and is best illustrated with an example. Listing 23.1 shows a sample script to create a database called mydb. This script was generated using the Script option available on the New Database screen. Download from www.wowebook.com ptg 722 CHAPTER 23 Creating and Managing Databases LISTING 23.1 Using T-SQL to Create a Database CREATE DATABASE [mydb] ON PRIMARY ( NAME = N’mydb’, FILENAME = N’C:\mssql2008\data\mydb.mdf’ , SIZE = 2048KB , FILEGROWTH = 1024KB ) LOG ON ( NAME = N’mydb_log’, FILENAME = N’C:\mssql2008\log\mydb_log.ldf’, SIZE = 1024KB , FILEGROWTH = 10%) GO The database created in Listing 23.1 is relatively simple. It is named mydb and contains one data file and one log file. The data file is created on the PRIMARY filegroup; it is named mydb.mdf and is created in the C:\mssql2008\data folder. The mydb.mdf file is initially created with a size of 2048KB, or 2MB. If the database utilizes the entire 2MB, the file can be expanded by the amount specified in the FILEGROWTH parameter. In this case, the file can grow in 1MB increments. (Managing file growth is discussed in the section “Managing Databases,” later in this chapter.) The log file is defined using the LOG ON clause in the CREATE DATABASE command. The mydb database created in Listing 23.1 has a log file named mydb_log.ldf that is also created in the C:\mssql2008\data folder. The initial size of the file is 1MB, and it can expand by 10% of the current log file size. You need to use caution with large databases when using a percentage to define FILEGROWTH. For example, you may have problems if you have a large database that has a 30GB log file and a FILEGROWTH of 10%. If the data- base file is set to autogrow, and the 30GB log file is full, it attempts to expand the log file by 3GB. An expansion of this size could be detrimental to performance, and the disk drive where the log file is located might not have that much disk space remaining. You can specify many of the other options that define a database after the database is created by using the ALTER DATABASE statement. The T-SQL scripting option available on the CREATE DATABASE screen generates the basic CREATE DATABASE syntax shown in Listing 23.1, and then it generates a series of ALTER DATABASE commands that further define the database. These options are discussed in the next section. Setting Database Options You can use an abundance of database options to refine the behavior of a database. These options fall into the following categories, which are part of the option specification: Auto Options Cursor Options Database Availability Options Date Correlation Optimization Options External Access Options Parameterization Options Download from www.wowebook.com ptg 723 Setting Database Options 23 Recovery Options Service Broker Options Snapshot Isolation Options SQL Options For each category, you can set one or more options. You can find a full list of options for each category in the section “Setting Database Options” in SQL Server Books Online. Some of the options are discussed in further detail in the chapters of this book that relate to the database options. For example, the recovery options are discussed in detail in Chapter 14, the Service Broker options are discussed in Chapter 49, “SQL Server Service Broker” (on the CD), and database mirroring options are discussed in Chapter 20, “Database Mirroring.” The following section focuses on the database options displayed on the Options page in SSMS. The Database Options You can access many of the most common database options via the Options page of the Database Properties dialog. To get to this dialog, you right-click a database in the SSMS Object Explorer and select Properties. When the dialog appears, you select the Options page from the list on the left side of the Database Properties dialog. Figure 23.4 shows the Options page for the AdventureWorks2008 database. The options listed under Other Options can be listed alphabetically or by category. The default display mode is by category. The default settings for these options suffice for most installations. However, some options deserve special attention. The options listed under the Automatic category are among these options. The Auto Close option could cause problems in prior versions of SQL Server. This option is intended for desktop implementations in which the database does not need to be online all the time. When users are not accessing the database and this option is selected, the database files are closed. When the first user accesses the database, the database is brought back online. The problem in prior versions was that the synchro- nous operation of opening and closing the database files caused performance problems. This issue has been addressed in SQL Server 2008 because the operations are now performed asynchronously. The Auto Close option defaults to true only for SQL Server 2008 Express Edition and should generally be left set to false for all other versions. The Auto Create Statistics and Auto Update Statistics options also deserve special attention in situations in which the creation or updating of statistics is affecting performance. Generally, the creation or updating of statistics improves performance. These statistics enable the Query Optimizer to make the best decisions when determining the access path to the data. In some rare circumstances, there may be performance problems at the time statistics are created or updated automatically. When these situations arise, you can turn off the Auto Statistics options and schedule the statistics operations to occur during off-hours. Enabling the Auto Shrink option is a good idea for keeping a nonproduction database as small as possible. This option automatically performs a database shrink operation against the database files when more than 25% of a file contains unused space. The default setting Download from www.wowebook.com . newly created databases in SQL Server 2008, the default of SQL Server 2008 (100) will suffice. With this setting, all the new features available with SQL Server 2008 are utilized. In some situations,. might want a SQL Server 2008 database to behave as though it were a SQL Server 2005 database or SQL Server 2000 data- base. You can accomplish this by setting Compatibility Level to SQL Server 2005. release of SQL Server to SQL Server 2008 and allow it to work as it did while enabling you to start taking advantage of new features and capabilities as you migrate the sys- tem to SQL Server 2008. Using