ptg 164 CHAPTER 6 SQL Server Profiler any other data columns that make sense for your specific trace. After this task is complete, you can launch the sample stored procedure from Listing 6.5 and get progress information via SQL Profiler as the procedure executes. You can accumulate execution statistics over time with this kind of trace and summarize the results. The execution command for the procedure follows: EXEC SampleApplicationProc @debug = 1 The resulting SQL Profiler results are shown in Figure 6.15. There are many other applications for User configurable events. How you use them depends on your specific need. As is the case with many Profiler scenarios, there are seem- ingly endless possibilities. Summary Whether you are a developer or database administrator, you should not ignore the power of the SQL Profiler. It is often one of the most underused applications in the SQL Server toolkit, yet it is one of the most versatile. Its auditing capabilities and ability to unravel complex server processes define its value. This chapter wraps up the introduction to the tools and utilities available with SQL Server. Now you should be equipped to start administering and working with SQL Server. The chapters in the next section focus on the overall administration of SQL, using some of the tools that you have been exposed to thus far. Chapter 7, “SQL Server System and Database Administration,” gives you some insight into the inner workings of SQL Server and what it takes to effectively administer a SQL Server instance. FIGURE 6.15 User configurable trace results. Download from www.wowebook.com ptg CHAPTER 7 SQL Server System and Database Administration IN THIS CHAPTER . What’s New in SQL Server System and Database Administration . System Administrator Responsibilities . System Databases . System Tables . System Views . System Stored Procedures This chapter outlines the role of a SQL Server system administrator and explores some of the methods that an administrator can use to query important system data. As with any other job, understanding the roles and responsibil- ities of the job is critical to doing the job well. The responsi- bilities of an administrator vary depending on the job, but there are some core responsibilities covered in this chapter. You also need the right tools and right information to do the job well and do it efficiently. The system data covered in this chapter provides some of the key information. The methods discussed to access this information are among the tools you will need. System data discloses information that can be invaluable when assessing your SQL Server environment and is an essential part of administering a SQL Server database. What’s New in SQL Server System and Database Administration The means for accessing system information has changed very little from SQL Server 2005 to SQL Server 2008. The new systems views that were introduced in SQL Server 2005 are still the preferred means for getting at that all-important system information. These views, which include catalog, compatibility, and dynamic views, are discussed in detail later in this chapter. What is new in SQL Server 2008 is an expanded set of system views. These new views are geared toward some of the new functionality offered with SQL Server 2008. For example, new catalog and dynamic management views that Download from www.wowebook.com ptg 166 CHAPTER 7 SQL Server System and Database Administration return information about Change Tracking and the Resource Governor have been added to cover these new features. System Administrator Responsibilities A system administrator is responsible for the integrity and availability of the data in a database. This is a simple concept, but it is a huge responsibility. Some large corporations place a valuation on their data as high as $1 million per 100MB. The investment in dollars is not the only issue; many companies that lose mission-critical data simply never recover. Job descriptions for system administrators vary widely. In small shops, the administrator might lay out the physical design, install SQL Server, implement the logical design, tune the installation, and then manage ongoing tasks, such as backups. At larger sites, tasks might be broken out into separate job functions. Managing users and backing up data are common examples. However, a lead administrator should still be in place to define policy and coordinate efforts. Whether performed by an individual or as a team, the core administration tasks are as follows: . Install and configure SQL Server. . Plan and create databases. . Manage data storage. . Control security. . Tune the database. . Perform backup and recovery. Another task sometimes handled by administrators is managing stored procedures. Because stored procedures for user applications often contain complex Transact-SQL (T- SQL) code, they tend to fall into the realm of the application developer. However, because stored procedures are stored as objects in the database, they are also the responsibility of the administrator. If an application calls custom stored procedures, the system administra- tor must be aware of this and coordinate with the application developers. The system administration job can be stressful, frustrating, and demanding, but it is a highly rewarding, interesting, and respected position. As a system administrator, you are expected to know all, see all, and predict all, but you should be well compensated for your efforts. System Databases SQL Server uses system databases to support different parts of the database management system (DBMS). Each database plays a specific role and stores information that SQL Server needs to do its job. The system databases are much like the user databases created in SQL Server. They store data in tables and contain the views, stored procedures, and other Download from www.wowebook.com ptg 167 System Databases TABLE 7.1 System Databases and Their Associated Database Files Database .mdf Filename .ldf Filename master master.mdf mastlog.ldf resource mssqlsystemresource.mdf mssqlsystemresource.ldf model model.mdf modellog.ldf msdb msdbdata.mdf msdblog.ldf distribution distmdl.ldf distmdl.mdf tempdb tempdb.mdf templog.ldf database objects that you also see in user databases. They also have associated database files (that is, .mdf and .ldf files) that are physically located on the SQL Server machine. Table 7.1 lists system databases and their related database filenames. 7 TIP You can use the sys.master_files catalog view to list the physical locations of the system database files as well as the user database files. This catalog view contains a myriad of information, including the logical name, current state, and size of each database file. The folder where each of these database files is located depends on the SQL Server installa- tion. By default, the installation process places these files in a folder named <drive>:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\. You can move these files after the installation by using special procedures that are documented in the SQL Server Books Online topic “Moving System Databases.” The following sections describe the function of each system database. The master Database The master database contains server-wide information about the SQL Server system. This server-wide information includes logins, linked server information, configuration information for the server, and information about user databases created in the SQL Server instance. The actual locations of the database files and key properties that relate to each user database are stored in the master database. SQL Server cannot start without a master database. This is not surprising, given the type of information that it contains. Without the master database, SQL Server does not know Download from www.wowebook.com ptg 168 the location of the databases that it services and does not know how the server is config- ured to run. The resource Database The resource database contains all the system objects deployed with SQL Server 2008. These system objects include the system stored procedures and system views that logically appear in each database but are physically stored in the resource database. Microsoft moved all the system objects to the resource database to simplify the upgrade process. When a new release of the software is made available, upgrading the system objects is accomplished by simply copying the single resource database file to the local server. Similarly, rolling back an upgrade only requires overwriting the current version of the resource database with the older version. You do not see the resource database in the list of system databases shown in SQL Server Management Studio (SSMS). You also cannot add user objects to the resource database. For the most part, you should not be aware of the existence of the resource database. It has database files named mssqlsystemresources.mdf and mssqlsystemresources.ldf that are located in the Binn folder, but you cannot access the database directly. In addition, you do not see the database listed when selecting databases using system views or with system procedures, such as sp_helpdb. The model Database The model database is a template on which all user-created databases are based. All data- bases must contain a base set of objects known as the database catalog. When a new data- base is created, the model is copied to create the requisite objects. Conveniently, objects can be added to the model database. For example, if you want a certain table created in all your databases, you can create the table in the model database, and it is then propagated to all subsequently created databases. The msdb Database The msdb database is used to store information for the SQL Server Agent, the Service Broker, Database Mail, log shipping, and more. When you create and schedule a SQL Server Agent job, the job’s parameters and execution history are stored in msdb. Backups and maintenance plan information are stored in msdb as well. If log shipping is imple- mented, critical information about the servers and tables involved in this process is stored in msdb. The distribution Database The distribution database, utilized during replication, stores metadata and history infor- mation for all types of replication. It is also used to store transactions when transactional replication is utilized. By default, replication is not set up, and you do not see the distribution database listed in SSMS. However, the actual data files for the distribution database are installed by default. CHAPTER 7 SQL Server System and Database Administration Download from www.wowebook.com ptg 169 System Databases 7 Refer to Chapter 19, “Replication,” for a more detailed discussion of the intricacies of replication. The tempdb Database The tempdb database stores temporary data and data objects. The temporary data objects include temporary tables, temporary stored procedures, and any other objects you want to create temporarily. The longevity of data objects in the temporary database depends on the type of object created. Ultimately, all temporary database objects are removed when the SQL Server service is restarted. The tempdb database is re-created, and all objects and data added since the last restart of SQL Server are lost. tempdb can also be used for some of SQL Server’s internal operations. Large sort operations are performed in tempdb before the result set is returned to the client. Certain index opera- tions can be performed in tempdb to offload some of the space requirements or to spread I/O. SQL Server also uses tempdb to store row versions that are generated from database modifications in databases that use row versioning or snapshot isolation transactions. Refer to Chapter 37 “Locking and Performance,” for a more detailed discussion of transac- tion isolation levels and row versioning. Maintaining System Databases You should give system databases the same attention that you give your user databases. These databases should be backed up on a regular basis and secured in the event that one of them needs to be restored. All the system databases, with the exception of tempdb and resource, can be backed up. These same databases can also be restored to bring them back to a previous state. NOTE Although you cannot back up the resource database using SQL Server’s BACKUP and RESTORE commands, you can make a backup copy of it by performing a file-based or disk-based backup of the mssqlsystemresource.mdf file (SQL Server must not be run- ning at the time). Likewise, you can manually restore a backup copy of the mssqlsystemresource.mdf file only when SQL Server is not running. You must be careful not to overwrite the current resource database with a version for a different release level of SQL Server. It’s important that you monitor the size of your system databases. The amount of data that accumulates in these databases can be significant. This is particularly true for the tempdb, msdb, and distribution databases. Large sort or index operations can increase the size of your tempdb database in a short period of time. The msdb and distribution data- bases contain a great deal of historical information. Consider, for example, a server with hundreds of databases that have log backups occurring every 15 minutes. The information captured for each individual backup is not significant, but the total number of databases Download from www.wowebook.com ptg 170 FIGURE 7.1 System tables listed in Object Explorer. and frequency of the backups cause many rows to be stored in the msdb database. Cleanup tasks and similar activities that remove older historical data can help keep the database size manageable. System Tables System tables contain data about objects in the SQL Server databases (that is, metadata) as well as information that SQL Server components use to do their job. Many of the system tables are now hidden (in the resource database) and are no longer available for direct access by end users. In SQL Server 2008, compatibility views, which are discussed later in this chapter, have the same names as the system tables available in SQL Server 2000. For example, if you had a query in SQL Server 2000 that selected from syscolumns, this query continues to work in SQL Server 2008, but the results come from a view instead of a system table. The system tables that you can view are now found in some of the system databases, such as msdb or master. You can use the Object Explorer in SSMS to view the system tables in these databases. Figure 7.1 shows the system tables listed for the master database in the Object Explorer. CHAPTER 7 SQL Server System and Database Administration The most significant number of viewable system tables is found in the msdb system data- base. The system tables there support backup and restore, log shipping, maintenance plans, Notification Services, the SQL Server Agent, and more. You can retrieve a tremen- dous amount of information from these system tables if you know what you are looking Download from www.wowebook.com ptg 171 System Tables 7 for. The following query selects from the system tables in msdb to report on recent restores for the AdventureWorks2008R2 database: select destination_database_name ‘database’, h.restore_date, restore_type, cast((backup_size/1024)/1024 as numeric(8,0)) ‘backup_size MB’, f.physical_device_name from msdb restorehistory h (NOLOCK) LEFT JOIN msdb backupset b (NOLOCK) ON h.backup_set_id = b.backup_set_id LEFT JOIN msdb backupmediafamily f (NOLOCK) ON b.media_set_id = f.media_set_id where h.restore_date > getdate() - 5 and UPPER(h.destination_database_name) = ‘AdventureWorks2008R2’ order by UPPER(h.destination_database_name), h.restore_date desc One of the challenges with using system tables is determining the relationships between them. Some vendors offer diagrams of these tables, and you can also determine the rela- tionships by reviewing the foreign keys on these tables and by referring to SQL Server 2008 Books Online, which describes the use for each column in the system table. CAUTION Microsoft does not recommend querying system tables directly. It does not guarantee the consistency of system tables across versions and warns that queries that may have worked against system tables in past versions may no longer work. Catalog views or information schema views should be used instead, especially in production code. Queries against system tables are best used for ad hoc queries. The values in system tables should never be updated, and an object’s structure should not be altered, either. Making changes to the data or structure could cause problems and cause SQL Server or one of its components to fail. System Views System views are virtual tables that expose metadata that relates to many different aspects of SQL Server. Several different types of views target different data needs. SQL Server 2008 offers an extended number of system views and view types that should meet most, if not all, your metadata needs. The available system views can be shown in the Object Explorer in SSMS. Figure 7.2 shows the Object Explorer with the System Views node highlighted. There are far too many views to cover in detail in this chapter, but we cover each type of view and provide an example of each to give you some insight into their value. Each system view is covered in Download from www.wowebook.com ptg 172 CHAPTER 7 SQL Server System and Database Administration FIGURE 7.2 System views listed in Object Explorer. detail in SQL Server Books Online, which includes descriptions of each column in the view. Compatibility Views Compatibility views were retained in SQL Server 2008 for backward compatibility. Many of the system tables available in SQL Server 2000 and prior versions of SQL Server are now implemented as compatibility views. These views have the same name as the system tables from prior versions and return the same metadata available in SQL Server 2000. They do not contain information that was added after SQL Server 2000. You can find most of the compatibility views in the Object Explorer by looking for system views that have names starting with sys.sys. For example, sys.syscolumns, sys.syscomments, and sys.sysobjects are all compatibility views. The first part of the name indicates the schema that the object belongs to (in this case, sys). All system objects are part of this sys schema or the INFORMATION_SCHEMA schema. The second part of the name is the view name, which corresponds to the name of a system table in SQL Server 2000. Download from www.wowebook.com ptg 173 System Views 7 TIP To see a list of compatibility views, use the inde x lookup in SQL Ser ver 2008 Bo oks Online and look for sys.sys. The index is placed at the beginning of a list of compatibility views, starting with sys.sysaltfiles. Objects in the list that are compatibility views have the text compatibility view following the object name, so you can easily identify them and get help. You also can u se the new IntelliSense feature available with SQL Ser ver 2008 to obtain information about the compatibility views and other system views. Simply open a query window in SSMS and start typing a SELECT statement. When you start typing the name of the view that you want to select from (for example, sys.) the IntelliSense drop-down appears listing the views that start with the letters sys. You can also deter- mine the columns available from the view by referencing the view or alias for the view in the column selection list. When you enter the period following the view or alias, the IntelliSense drop-down shows you the available columns. You should transition from the use of compatibility views to the use of other system views, such as catalog views. The scripts that were created in SQL Server 2000 and refer- ence SQL Server 2000 system tables should continue to function in SQL Server 2008, but this capability is strictly for backward compatibility. Table 7.2 provides a list of SQL Server 2000 system tables and alternative SQL Server 2008 system views you can use instead. TABLE 7.2 SQL Server 2008 Alternatives for SQL Server 2000 System Tables SQL Server 2000 System Table SQL Server 2008 System View View Type sysaltfiles sys.master_files Catalog view syscacheobjects sys.dm_exec_cached_plans DMV sys.dm_exec_plan_attributes DMV sys.dm_exec_sql_text DMV syscharsets sys.syscharsets Compatibility view syscolumns sys.columns Catalog view syscomments sys.sql_modules Catalog view sysconfigures sys.configurations Catalog view sysconstraints sys.check_constraints Catalog view sys.default_constraints Catalog view sys.key_constraints Catalog view Download from www.wowebook.com . list of SQL Server 2000 system tables and alternative SQL Server 2008 system views you can use instead. TABLE 7.2 SQL Server 2008 Alternatives for SQL Server 2000 System Tables SQL Server 2000 System. depends on the SQL Server installa- tion. By default, the installation process places these files in a folder named <drive>:Program Files Microsoft SQL Server MSSQL.1MSSQLData. You. Views Compatibility views were retained in SQL Server 2008 for backward compatibility. Many of the system tables available in SQL Server 2000 and prior versions of SQL Server are now implemented as compatibility