Na2009 enus sql_06

Chapter 6: Maintenance

6-1

CHAPTER 6: MAINTENANCE Objectives

The objectives are:

• Evaluate how to optimize a Microsoft Dynamics® NAV database. • Set up a maintenance plan for a Microsoft Dynamics NAV database

to optimize indexes, update Microsoft® SQL Server® statistics and set index fill factors.

• Maintain an SQL Server by monitoring performance, database and transaction log growth.

Introduction Typically, in a database system there are several key items that affect performance. These items include the following:

• The database design • The code • Correct indexes • Current statistics • Defragmented indexes and data

In the previous chapters you have learned how to optimize the database design, the C/AL code, and the indexes. However, to ensure that SQL statements run as efficiently as possible, you need to run maintenance tasks periodically. The core maintenance tasks should include index rebuilds, statistics updates, and defragmenting indexes and data.

This chapter describes how to implement maintenance on your SQL Server by using maintenance plans. Next, it explains how to execute maintenance tasks manually (by using Transact-SQL script).

Microsoft Official Training Materials for Microsoft Dynamics ® Your use of this content is subject to your current services agreement

SQL Server Installation and Optimization for Microsoft Dynamics® NAV 2009

6-2

Optimizing a Microsoft Dynamics NAV Database The previous chapter explained that SIFT tables and indexes are the two main causes of performance issues in Microsoft Dynamics NAV 5.0 (and earlier). To maintain performance in a Microsoft Dynamics NAV 5.0 database, it is necessary to optimize the tables regularly.

The optimization process removes any entries that contain zero values in all numeric fields from each SIFT table. The removal of these redundant entries frees space and makes updating and summing SIFT information more efficient. At the same time, the optimization process rebuilds all indexes.

In Microsoft Dynamics NAV 5.0 SP1, SIFT tables have been replaced by indexed views that are maintained automatically. However, this does not mean that optimizing tables is no longer necessary in Microsoft Dynamics NAV 5.0 SP1 or Microsoft Dynamics NAV 2009 or later versions. Although the indexed views solve the zero SIFT record issue, indexes will become fragmented as data is entered in the database and they still need optimization to maintain performance.

In Microsoft Dynamics NAV 5.0 SP1 and later versions, table optimization still allows you to rebuild table indexes from the Microsoft Dynamics NAV client. Be aware that rebuilding indexes using the Microsoft Dynamics NAV client requires manual action and adversely affects performance (because indexes are dropped and rebuilt), so you do not want all users to be able to do this ad hoc.

SQL Server facilitates database maintenance by offering features that allow administrators to configure and schedule database maintenance tasks. These maintenance tasks are defined as maintenance plans and can be scheduled to run automatically at any time during the day.

Implementing Maintenance on SQL Server The SQL Server Database Engine is the core service for storing, processing, and securing data. You can use the Database Engine to create relational databases for online transaction processing (OLTP) or online analytical processing (OLAP) data. This includes creating tables for storing data, and database objects such as indexes, views, and stored procedures for viewing, managing, and securing data.

After you have designed the database, you can start feeding data to the Database Engine. But like the engine of a car, the Database Engine also needs maintenance to continue to run optimally. If the car is not maintained well, it will not do its job which is to bring you to your destination at the right time. The same applies to the SQL Server Database Engine. When you use SQL Server, there are several important maintenance tasks that need to be executed proactively regularly. The most important tasks, after making backups, are defragmenting indexes, updating SQL Server statistics, and managing the index fill factor.



6-3

SQL Server offers built-in features that allow administrators to configure and automatically execute maintenance activities by means of maintenance plans. You can set up a maintenance plan that includes several tasks, or you can schedule separate Transact-SQL scripts to perform maintenance tasks. Whatever method you choose is not important, as long as the necessary maintenance occurs.

In SQL Server certain maintenance tasks can be done automatically without any maintenance plan. For example, if you activate the Auto Update Statistics option on a database, SQL Server will automatically update statistics. However, before activating these options, consider when you want maintenance to run on the server. Be aware that automatic tasks that start during daily work can lead to unexpected behavior.

Creating and Using Maintenance Plans

Maintenance plans create a workflow of the tasks required to make sure that your database is optimized, is regularly backed up, and is free of inconsistencies. Maintenance plans can be created in two ways, either you use the Maintenance Plan Wizard or you can build your own maintenance plan from the design surface. Often, maintenance plans are created by using the wizard and then edited by using the design surfaces.

The Maintenance Plan Wizard is best for creating basic maintenance plans, whereas creating a plan by using the design surface allows you to utilize enhanced workflow and provides more flexibility. In SQL Server 2005 Database Engine, maintenance plans create a SQL Server Integration Services (SSIS) package, which is run by a SQL Server Agent job. These maintenance tasks can be run manually or automatically at scheduled intervals.

Maintenance plans only run against databases set to compatibility level 80 or higher. The maintenance plan designer in SQL Server Management Studio does not display databases set to compatibility level 70 or lower.

To create or manage maintenance plans, you must be a member of the sysadmin fixed server role. Note that Object Explorer only displays maintenance plans if the user is a member of the sysadmin fixed server role.

The Maintenance Plan Wizard

The Database Maintenance Plan Wizard can be used to help you set up the core maintenance tasks that are required to ensure that your database performs well, is regularly backed up if there is a system failure, and is checked for inconsistencies. The Database Maintenance Plan Wizard creates a Microsoft SQL Server job that performs these maintenance tasks automatically at scheduled intervals.



6-4

The following maintenance tasks can be scheduled to run automatically:

• Reorganizing the data on the data and index pages by rebuilding indexes with a new fill factor. This ensures that database pages contain an equally distributed amount of data and free space, which allows future growth to be faster.

• Compressing data files by removing empty database pages. • Updating index statistics to ensure the query optimizer has up-to-date

information about the distribution of data values in the tables. This allows the query optimizer to make better judgments about the best way to access data because it has more information about the data stored in the database. Although index statistics are automatically updated by SQL Server periodically, this option can force the statistics to be updated immediately.

• Performing internal consistency checks of the data and data pages within the database to ensure that a system or software problem has not damaged data.

• Backing up the database and transaction log files. Database and log backups can be retained for a specified period. This allows you to create a history of backups to be used in case you need to restore the database to a time earlier than the last database backup.

• Setting up log shipping. Log shipping allows the transaction logs from one database (the source) to be constantly fed to another database (the destination). Keeping the destination database synchronized with the source database allows you to have a standby server, and provides a way to offload query processing from the main computer (source server) to read-only destination servers.

The results generated by the maintenance tasks can be written as a report to a text file, HTML file, or the sysdbmaintplan_history tables in the msdb database. The report can also be e-mailed to an operator.

Scheduling a Maintenance Plan

Scheduling a maintenance plan is part of the maintenance plan creation. In the Maintenance Plan Wizard you can select a single schedule for all tasks or a separate schedule for each individual task. Depending on your selection, SQL Server will create one or more subplans that can be scheduled individually.

If you want to (re)schedule a maintenance plan that was initially created by using the wizard, you have to schedule it from the design surface.



6-5

Demonstration: Creating a Maintenance Plan

To optimize the Demo Database NAV (6-0) database, Tim, the IT manager, defines a maintenance plan for the database which performs the following tasks:

• Update Statistics • Rebuild Indexes

Tim wants to schedule the maintenance plan to run at night. However, he does not want the maintenance process to interfere with other scheduled tasks. Before he can define the schedule, he needs to determine when the other tasks are run. He decides to create the maintenance plan and schedule it later.

Perform the following steps when creating a Maintenance Plan:

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 Database Engine by using a login with

sysadmin credentials. 3. In Object Explorer, click Management. 4. Right-click Maintenance Plans. 5. Select Maintenance Plan Wizard to start the wizard. 6. On the SQL Server Maintenance Plan Wizard page, click Next. 7. On the Select Plan Properties page, in the Name field, enter a

meaningful name for the maintenance plan, such as the name of the server to which the plan applies or the execution interval of the maintenance plan (daily, weekly, and so on), or any combination. For example, enter NAV-SRV-01 - Daily MP. Optionally, in the Description field, you can enter a short description for the maintenance plan, describing the purpose or the subtasks of the maintenance plan.

8. At the bottom of the window, select the scheduling option for the maintenance plan. There are two options: Separate schedules for each task or Single schedule for the entire plan or no schedule. If you select Separate schedules for each task, you can define the schedule for each task later in the Wizard, when you configure the individual tasks. If you select Single schedule for the entire plan or no schedule, you have to define the schedule here (before you select and configure the individual tasks). To define the schedule, click the Change button. In this demonstration, select the second option. In the next demonstration, you will change the schedule.

9. Click the Next button.



6-6

10. On the Select Maintenance Tasks page, select the tasks to include in the maintenance plan. Select the tasks as shown in the following figure.

FIGURE 6.1 SELECT MAINTENANCE TASKS

11. Click the Next button. 12. On the Select Maintenance Task Order page, you can change the

order in which the tasks must be executed. You can use the Move Up and Move Down buttons to rearrange the tasks.

13. Click the Next button to start to configure the individual tasks. 14. On the Define Rebuild Index Task page, in the Database field,

select the database for which the task must be executed. To select one or more databases, click the drop-down list, select the These databases option, and select the databases to maintain. In this case, select the Demo Database NAV (6-0) database. Click OK.

15. In the Objects field, select the object type to maintain: Table, View or Tables and Views. To maintain all tables and views in the database, select Tables and Views. To reorganize only selected tables or views, select either the Table or View option and select the individual tables or views in the Selection field.



6-7

16. In the Free space options field, select how you want to rebuild the indexes. If you select Reorganize pages with the default amount of free space, SQL Server will drop the indexes and re-create them with the fill factor that was specified when the indexes were created. If you select Change free space per page percentage to, SQL Server drops the indexes in the database and re-creates them with a new, automatically calculated fill factor, thereby reserving the specified amount of free space on the index pages. The greater the percentage, the more free space is reserved on the index pages, and the larger the index grows. Valid values are from 0 through 100.

17. Select the Sort results in tempdb option. This option determines where the intermediate sort results, generated during index creation, are temporarily stored. If a sort operation is not required, or if the sort can be performed in memory, this option is ignored.

18. Select the Keep index online while reindexing option to allow users to access the underlying table or clustered index data and any associated nonclustered indexes during index operations.

NOTE: Online index operations are available only in SQL Server Developer, Evaluation, and Enterprise editions.

19. Click the Next button. 20. On the Define Update Statistics Task page, in the Database field,

select the database the task applies to. In this case, select the Demo Database NAV (6-0) database.

21. In the Objects field, select the object type to maintain (Table, View or Tables and Views) and select the corresponding views or tables in the Selection field.

22. In the Update field, select the statistics to update: All statistics, Column statistics or Index statistics. In this case, select All statistics.

23. In the Scan type field, select the type of scan used to collect updated statistics. If you select Full scan, SQL Server will read all rows in the table or view to collect the statistics. If you select Sample by, SQL Server will update statistics based on a sample of data. In this case, you must specify the percentage of the table or indexed view, or the number of rows to sample when collecting statistics for larger tables or views.

24. Click the Next button.



6-8

25. On the Select Report Options page, you can define a report of the task activity, and configure the task to notify people when the task is completed. The report contains details of the steps executed by the maintenance plan. This includes any error information. If you select Write a report to a text file (and specify a path for the text file in the Folder Location field), SQL Server saves the report to a text file. If you want an e-mail message to be sent when a task fails, you must select the E-mail report option. To use this task, you must have Database Mail enabled and configured correctly with MSDB as a Mail Host Database, and have a SQL Server Agent operator with a valid e-mail address. In this case, leave the default option Write a report to a text file. For more information about how to set up database mail, see Database Mail (http://msdn.microsoft.com/en-us/library/ms175887.aspx), Defining Operators (http://msdn.microsoft.com/en-us/library/ms179336.aspx) and How To: Create an Operator (SQL Server Management Studio) (http://msdn.microsoft.com/en-us/library/ms175962.aspx).

26. Click the Next button. 27. On the Complete the Wizard page, you can verify the choices made

in the wizard. 28. Click the Finish button.



6-9

As a final step, the SQL Server Maintenance Plan Wizard creates the necessary SSIS packages for the maintenance plan and shows the progress. When the Wizard finishes, the results are displayed:

FIGURE 6.2 RESULTS OF THE SQL SERVER MAINTENANCE PLAN WIZARD

29. Click Close to exit the wizard.

Demonstration: Scheduling a Maintenance Plan

Tim has found out that batch processes run between 11:00PM and 1:00AM. He can now schedule his maintenance plan to run once every night at 01:30AM, starting January 1, 2010. As he cannot use the wizard to reschedule the existing maintenance plan, he schedules it from the design surface. This is done by performing following steps:


sysadmin credentials. 3. In Object Explorer, click Management.



6-10

4. Click Maintenance Plans. 5. Double-click the NAV-SRV-01 - Daily MP plan or right-click it, and

then select Modify. The design surface opens.

FIGURE 6.3 SCHEDULE A MAINTENANCE PLAN FROM THE DESIGN SURFACE

The top of the design surface shows the name and the description for the maintenance plan. The middle pane shows a grid with all subplans that are part of the maintenance plan. The number of subplans created depends on the scheduling option selected in the wizard. If you select Separate schedules for each task, a separate subplan is created for task in the maintenance plan. If you select Single schedule for the entire plan or no schedule, only one subplan is created including all tasks. The bottom pane shows the different tasks in the selected subplan and the relation between these tasks.

6. In the grid, select Subplan_1. 7. In the toolbar, click the Subplan Schedule button or click the

Schedule icon next to the subplan in the grid. You can also double-click the subplan, and then click the Subplan Schedule icon in the Subplan Properties dialog box.



6-11

8. In the Job Schedule Properties window, you can define the schedule for the subplan. Define the schedule as shown in the following figure:

FIGURE 6.4 SCHEDULING A SUBPLAN

9. Click OK to close the Job Schedule Properties window and return to the design surface. Notice that the Schedule column for the subplan now contains schedule information.

10. In the toolbar, click the Save button to save the maintenance plan.

To remove the schedule for a specific subplan, select a subplan in the grid, click Remove Schedule in the toolbar or click the Remove Schedule icon next to the subplan in the grid. You can also double-click the subplan, and then click the Remove Schedule icon in the Subplan Properties dialog box.



6-12

Index Fragmentation

The SQL Server Database Engine automatically maintains indexes whenever insert, update, or delete operations are made to the underlying data. Over time these modifications can cause the information in the index to become scattered in the database (fragmented). Fragmentation exists when indexes have pages in which the logical ordering, based on the key value, does not match the physical ordering inside the data file. Heavily fragmented indexes can decrease query performance and cause your application to respond slowly.

In SQL Server 2005 you can correct index fragmentation by either reorganizing an index or by rebuilding an index. For partitioned indexes built on a partition scheme, you can use either of these methods on a complete index or on a single partition of an index.

Detecting Fragmentation

The first step in deciding which defragmentation method to use is to analyze the index to determine the degree of fragmentation. By using the system function sys.dm_db_index_physical_stats, you can detect fragmentation in a specific index, all indexes on a table or indexed view, all indexes in a database, or all indexes in all databases. For partitioned indexes, sys.dm_db_index_physical_stats also provides fragmentation information for each partition.

The algorithm for calculating fragmentation is more precise in SQL Server 2005 than in SQL Server 2000. As a result, the fragmentation values will appear higher. For example, in SQL Server 2000, a table is not considered fragmented if it has page 11 and page 13 in the same extent but not page 12. However, to access these two pages would require two physical I/O operations, so this is counted as fragmentation in SQL Server 2005.

The result set returned by the sys.dm_db_index_physical_stats function includes the following columns.

Column Description

avg_fragmentation_in_percent

The percent of logical fragmentation (out-of-order pages in the index).

fragment_count The number of fragments (physically consecutive leaf pages) in the index.

avg_fragment_size_in_pages

Average number of pages in one fragment in an index.



6-13

After the degree of fragmentation is known, use the following table to determine the best method to correct the fragmentation.

avg_fragmentation_in_percent value

Corrective statement

> 5% and < = 30% ALTER INDEX REORGANIZE

> 30% ALTER INDEX REBUILD WITH (ONLINE = ON)

Note that rebuilding an index can be executed online or offline. Reorganizing an index is always executed online. To achieve availability similar to the reorganize option, you should rebuild indexes online.

These values provide a rough guideline for determining the point at which you should switch between ALTER INDEX REORGANIZE and ALTER INDEX REBUILD. However, the actual values may vary from case to case. It is important that you experiment to determine the best threshold for your environment.

Be aware that recreating a heavily defragmented index can be faster than updating the existing index.

Very low levels of fragmentation (less than 5 percent) should not be addressed by either of these commands because the benefit of removing such a small amount of fragmentation is almost always significantly outweighed by the cost of reorganizing or rebuilding the index.

Reorganizing an Index

To reorganize one or more indexes, use the ALTER INDEX statement with the REORGANIZE clause. This statement replaces the DBCC INDEXDEFRAG statement. To reorganize a single partition of a partitioned index, use the PARTITION clause of ALTER INDEX.

Reorganizing an index defragments the leaf level of clustered and nonclustered indexes on tables and views by physically reordering the leaf-level pages to match the logical order (left to right) of the leaf nodes. Having the pages in order improves index-scanning performance. The index is reorganized within the existing pages allocated to it and no new pages are allocated. If an index spans more than one file, the files are reorganized one at a time. Pages do not migrate between files.

Reorganizing also compacts the index pages. Any empty pages created by this compaction are removed providing additional available disk space. Compaction is based on the fill factor value in the sys.indexes catalog view.

The reorganize process uses minimal system resources. Also, reorganizing is automatically performed online. The process does not hold long-term blocking locks. Therefore, it will not block running queries or updates.



6-14

Reorganize an index when the index is not heavily fragmented. See the previous table for fragmentation guidelines. However, if the index is heavily fragmented, you will achieve better results by rebuilding the index.

Rebuilding an Index

Rebuilding an index drops the index and creates a new one. In doing this, fragmentation is removed, disk space is reclaimed by compacting the pages using the specified or existing fill factor setting, and the index rows are reordered in contiguous pages (allocating new pages as needed). This can improve disk performance by reducing the number of page reads required to obtain the requested data.

The following methods can be used to rebuild clustered and nonclustered indexes:

• ALTER INDEX with the REBUILD clause. This statement replaces the DBCC DBREINDEX statement.

• CREATE INDEX with the DROP_EXISTING clause.

Each method performs the same function, but there are advantages and disadvantages to consider. For example, creating an index allows you to change the index definition by adding or removing key columns, changing column order, or changing the column sort order. You can also change filegroup or partition. However, creating multiple indexes is not possible within a single transaction.

You can also rebuild an index by first dropping the index with the DROP INDEX statement and re-creating it with a separate CREATE INDEX statement. Performing these operations as separate statements has several disadvantages, and it is not recommended.

The following sample code displays all indexes with an average fragmentation percentage bigger than 10.

SELECT vw.object_id AS objectid, object_name(vw.object_id) AS objectname, vw.index_id AS indexid, tbl.name, vw.partition_number AS partitionnum, vw.avg_fragmentation_in_percent AS frag FROM sys.dm_db_index_physical_stats ( DB_ID('Demo Database NAV (6-0)'), NULL, NULL, NULL, 'LIMITED') vw JOIN sys.indexes tbl ON vw.object_ID = tbl.object_id AND vw.index_id = tbl.index_id WHERE vw.avg_fragmentation_in_percent > 10.0 AND vw.index_id > 0 -- AND object_name(object_id) = -- 'CRONUS International Ltd_$Contact'



6-15

By enabling the last two lines in the script, you can limit the result set to the indexes for a specific table (in this case, the Contact table).

You can now reorganize or rebuild all or specific indexes based on the fragmentation values, as shown in the following code sample.

-- Rebuild Index $1 in the Contact Table ALTER INDEX [$1] ON dbo.[CRONUS International Ltd_$Contact] REBUILD -- Reorganize All Indexes in the Contact Table ALTER INDEX ALL ON dbo.[CRONUS International Ltd_$Contact] REORGANIZE

The following example automatically reorganizes or rebuilds all partitions in a database that have an average fragmentation over 10 percent. The decision point at which the switch is made between reorganize and rebuild has been defined in the script.

SET NOCOUNT ON; DECLARE @objectid int; DECLARE @indexid int; DECLARE @partitioncount bigint; DECLARE @schemaname nvarchar(130); DECLARE @objectname nvarchar(130); DECLARE @indexname nvarchar(130); DECLARE @partitionnum bigint; DECLARE @partitions bigint; DECLARE @frag float; DECLARE @command nvarchar(4000); -- Conditionally select tables and indexes from the -- sys.dm_db_index_physical_stats function and -- convert object and index IDs to names. SELECT object_id AS objectid, index_id AS indexid, partition_number AS partitionnum, avg_fragmentation_in_percent AS frag INTO #work_to_do FROM sys.dm_db_index_physical_stats ( DB_ID('Demo Database NAV (6-0)), NULL, NULL, NULL, 'LIMITED') WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0; -- Declare and open the cursor for the list of partitions -- to be processed. DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do; OPEN partitions; -- Loop through the partitions. WHILE (1=1) BEGIN; FETCH NEXT FROM partitions INTO @objectid, @indexid, @partitionnum, @frag; IF @@FETCH_STATUS < 0 BREAK;



6-16

SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name) FROM sys.objects AS o JOIN sys.schemas as s

ON s.schema_id = o.schema_id WHERE o.object_id = @objectid; SELECT @indexname = QUOTENAME(name) FROM sys.indexes WHERE object_id = @objectid AND index_id = @indexid; SELECT @partitioncount = count (*) FROM sys.partitions WHERE object_id = @objectid AND index_id = @indexid; -- 30 is an arbitrary decision point at which to -- switch between reorganizing and rebuilding. IF @frag < 30.0 SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE'; IF @frag >= 30.0 SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD'; IF @partitioncount > 1 SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10)); EXEC (@command); PRINT N'Executed: ' + @command; END; -- Close and deallocate the cursor. CLOSE partitions; DEALLOCATE partitions; -- Drop the temporary table. DROP TABLE #work_to_do;

Statistical Information

Microsoft SQL Server allows statistical information about the distribution of values in a column to be created. This statistical information can be used by the query processor to determine the optimal strategy for evaluating a query. When you create an index, SQL Server automatically stores statistical information about the distribution of values in the indexed column(s). The query optimizer in SQL Server uses these statistics to estimate the cost of using the index for a query. Additionally, when the AUTO_CREATE_STATISTICS database option is set to ON (default), SQL Server automatically creates statistics for columns without indexes that are used in a predicate.



6-17

As the data in a column changes, index and column statistics can become out-of-date and cause the query optimizer to make less-than-optimal decisions on how to process a query. For example, if you create a table with an indexed column and 1,000 rows of data, all with unique values in the indexed column, the query optimizer considers the indexed column a good way to collect the data for a query. If you update the data in the column so there are many duplicated values, the column is no longer an ideal candidate for use in a query. However, the query optimizer still considers it a good candidate based on the index's outdated distribution statistics, which are based on the data before the update.

Statistics that are maintained on each table in SQL Server to aid the optimizer in cost-based decision-making include the number of rows, the number of pages used by the table, and the number of modifications made to the keys of the table since the last statistics update. In addition to maintaining statistics on indexed columns, it is possible to maintain statistics on columns that are not indexed.

Therefore, SQL Server automatically updates this statistical information periodically as the data in the tables changes. The sampling is random across data pages, and taken from the table or the smallest nonclustered index on the columns needed by the statistics. After a data page has been read from disk, all the rows on the data page are used to update the statistical information. The frequency at which the statistical information is updated is determined by the volume of data in the column or index and the amount of changing data. For example, the statistics for a table that contains 10,000 rows may have to be updated when 1,000 index values have changed because 1,000 values may represent a significant percentage of the table. However, for a table that contains 10 million index entries, 1,000 changing index values is less significant, and so the statistics may not be automatically updated. SQL Server, however, always ensures that a minimum number of rows are sampled; tables that are smaller than 8 megabytes (MB) are always fully scanned to collect statistics.

The cost of this automatic statistical update is minimized by sampling the data, rather than analyzing all of it. Under certain circumstances, statistical sampling will not accurately characterize the data in a table. You can control the amount of data sampled during manual statistics updates on a table-by-table basis by using the SAMPLE and FULLSCAN clauses of the UPDATE STATISTICS statement. The FULLSCAN clause specifies that all of the data in the table is scanned to collect statistics, whereas the SAMPLE clause can be used to specify either the percentage of rows to sample or the number of rows to sample.

Out of date or missing statistics are indicated by warnings when the execution plan of a query is graphically displayed in SQL Query Analyzer. The table name is displayed in red text. Monitor the Missing Column Statistics event class by using SQL Profiler so that you know when statistics are missing. Use the UPDATE STATISTICS command or the sp_updatestats system stored procedure to manually update statistics after large changes in data, or daily, if there is a daily window available.

If you instruct SQL Server not to maintain statistics automatically, you must manually update the statistical information.



6-18

We recommend that you set the Auto Update Statistics and Auto Create Statistics database options to False and use a database maintenance plan to create and update statistics. As an alternative for the database maintenance plan, you can use the following Transact-SQL query to create statistics for all indexes in the database:

sp_createstats 'indexonly', 'fullscan'

Depending on the database size and the amount of data, this query can take some time. Therefore, we recommend that you schedule the index maintenance after working hours. Existing statistics will not be updated by sp_createstats. To update existing statistics, either drop all statistics before using sp_createstats (as shown in Lab 6.3), or execute sp_updatestats.

Demonstration: Activate Update Statistics

Perform the following steps to enable automatic statistics update for a database by using the Database Properties window.

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 server. 3. Select the database for which you want to update statistics. 4. Right-click the database and then select Properties. 5. On the Options page, set the Auto Update Statistics property to

True. 6. Click OK.

Demonstration: Activate Update Statistics Using T-SQL

Perform the following steps to enable automatic statistics update for a database by using a Transact-SQL query.

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 server. 3. Select the database for which you want to update statistics. 4. Click New Query to open a new query window. 5. In the New Query window, enter the following command:

ALTER DATABASE [Demo Database NAV (6-0)] SET AUTO_UPDATE_STATISTICS ON WITH NO_WAIT

6. Click Run to execute the query.

To update the statistics for all user-defined and internal tables in the current database, you can run the sp_updatestats system stored procedure.



6-19

Demonstration: Update Table Statistics Using T-SQL

Perform the following steps to update statistics for the Customer table based on 80 percent of the data.


UPDATE STATISTICS [CRONUS International Ltd_$Customer] WITH SAMPLE 80 PERCENT


Demonstration: Update Index Statistics Using T-SQL

Perform the following steps to update statistics for a specific index in the Customer table. SQL Server will use 80 percent of the data to update index statistics.


UPDATE STATISTICS [CRONUS International Ltd_$Customer] [$1] WITH SAMPLE 80 PERCENT


Index Fill Factor

When you create a clustered index, the data in the table is stored in the data pages of the database according to the order of the values in the indexed columns. When new rows of data are inserted into the table or the values in the indexed columns are changed, Microsoft SQL Server may have to reorganize the storage of the data in the table to make room for the new row and maintain the ordered storage of the data. This also applies to nonclustered indexes. When data is added or changed, SQL Server may have to reorganize the storage of the data in the nonclustered index pages. When a new row is added to a full index page, SQL Server moves approximately half the rows to a new page to make room for the new row. This reorganization is known as a page split. Page splitting can impair performance and fragment the storage of the data in a table.



6-20

When you create an index, you can specify a fill factor to leave additional gaps and reserve a percentage of free space on each leaf-level page of the index to accommodate future expansion in the storage of the table's data and reduce the potential for page splits. The fill factor value is a percentage from 0 to 100 that specifies how much to fill the data pages after the index is created. A value of 100 means the pages will be full and will take the least amount of storage space. This setting should be used only on a read-only table, to which additional data is never added. A lower value leaves more empty space on the data pages, which reduces the need to split data pages as indexes grow but requires more storage space. For example, a fill factor value of 80 means that 20 percent of each leaf-level page will be left empty providing space for index expansion as data is added to the underlying table. This setting is more appropriate when there will be changes to the data in the table.

The fill factor option is provided for fine-tuning performance. The fill factor value is a percentage from 1 to 100. The server-wide default of 0 is the optimal choice in most situations. When fill factor is set to 0, the leaf level is filled to capacity.

You can use the CREATE INDEX or ALTER INDEX statements to set the fill factor value for individual indexes. To modify the server-wide default value, use the sp_configure system stored procedure. To view the fill factor value of one or more indexes, use the sys.indexes catalog view.

NOTE: Even for an application oriented for many insert and update operations, the number of database reads typically outnumber database writes by a factor of 5 to 10. Therefore, specifying a fill factor other than the default can decrease database read performance by an amount inversely proportional to the fill factor setting. For example, a fill factor value of 50 percent can cause database read performance to decrease by two times.

It is useful to set the fill factor option to another value only in the following situations:

• When a new index is created on a table with existing data, • When future changes in that data can be accurately predicted.

The fill factor is implemented only when the index is created. It is not maintained after the index is created as data is added, deleted, or updated in the table. Trying to maintain the additional space on the data pages would defeat the purpose of originally using the fill factor because SQL Server would have to perform page splits to maintain the percentage of free space, specified by the fill factor, on each page as data is entered. Therefore, if the data in the table is significantly modified and new data added, the empty space in the data pages can fill. In this situation, the index can be re-created and the fill factor specified again to redistribute the data.



6-21

Page Splits and Performance Considerations

When a new row is added to a full index page, the Database Engine moves approximately half the rows to a new page to make room for the new row. This reorganization is known as a page split. A page split makes room for new records, but can take time to perform and is a resource intensive operation. Also, it can cause fragmentation that causes increased I/O operations. A correctly chosen fill factor value can reduce the potential for page splits by providing sufficient space for index expansion as data is added to the underlying table.

When frequent page splits occur, the index can be rebuilt by using a new or existing fill factor value to redistribute the data. For more information, see Reorganizing and Rebuilding Indexes.

Although a low fill factor value, other than 0, may reduce the requirement to split pages as the index grows, the index will require more storage space and can decrease read performance. Even for an application oriented for many insert and update operations, the number of database reads typically outnumber database writes by a factor of 5 to 10. Therefore, specifying a fill factor other than the default can decrease database read performance by an amount inversely proportional to the fill factor setting. For example, a fill factor value of 50 can cause database read performance to decrease by two times. Read performance is decreased because the index contains more pages, therefore increasing the disk IO operations required to retrieve the data.

Adding Data to the End of the Table

A nonzero fill factor other than 0 or 100 can be good for performance if the new data is evenly distributed throughout the table. However, if all the data is added to the end of the table, the empty space in the index pages will not be filled. For example, if the index key column is an IDENTITY column, the key for new rows is always increasing and the index rows are logically added to the end of the index. If existing rows will be updated with data that lengthens the size of the rows, use a fill factor of less than 100. The additional bytes on each page will help minimize page splits caused by additional length in the rows.

The following code sample rebuilds the index [$1] in the Contact table with a fill factor of 80.

ALTER INDEX [$1] ON dbo.[CRONUS International Ltd_$Contact] REBUILD WITH (FILLFACTOR= 80)

When adjusting the fill factor, you can add the SORT_IN_TEMPDB=ON parameter to have the intermediate sort results stored in the tempdb. If you set SORT_IN_TEMPDB to OFF, the sort results are stored in the filegroup or partition scheme in which the resulting index is stored.

You can add the STATISTICS_NORECOMPUTE parameter to specify whether out-of-date index statistics should be automatically recomputed.



6-22

Demonstration: Define Server-wide Fill Factor

Perform the following steps to change the server-wide default index fill factor.

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 server. 3. In Object Explorer, right-click the server node and select

Properties. The Server Properties window appears. 4. Click the Database Settings page. 5. Set the Default index fill factor to 80.

FIGURE 6.5 SERVER-WIDE DATABASE SETTINGS

6. Click OK to apply the new setting and to close the window.



6-23

Demonstration: Define Server-wide Fill Factor Using Code

The server-wide default fill factor can also be changed by using the sp_configure stored procedure.

Some options supported by sp_configure, such as Default index fill factor, are designated as Advanced. By default, these options are not available for viewing and changing. Setting the Show Advanced Options configuration option to 1 makes these options available.

Perform the following steps to set the default fill factor to 80.

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 server. 3. Click New Query to open a new query window. 4. In the New Query window, enter the following command:

sp_configure 'show advanced options', 1 RECONFIGURE WITH OVERRIDE; GO sp_configure 'fill factor (%)', 80 RECONFIGURE WITH OVERRIDE; GO sp_configure 'show advanced options', 0 RECONFIGURE WITH OVERRIDE;

5. Click Execute to run the query.

Demonstration: Define Index Fill Factor Using T-SQL

Perform the following steps to rebuild the indexes of the Contact table with a fill factor of 75.

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 server. 3. Select the database on which you want to update indexes. 4. Click New Query to open a new query window. 5. In the New Query window, enter the following command:

ALTER INDEX ALL ON dbo.[CRONUS International Ltd_$Contact] REBUILD WITH (FILLFACTOR= 75)




6-24

Note that FILLFACTOR can only be specified with REBUILD (not with REORGANIZE).

After all indexes have been rebuilt with the specified fill factor, you can use the following code to view the fill factor for all indexes in the table:

SELECT name, index_id, type, is_primary_key, type_desc, fill_factor FROM sys.indexes WHERE object_id = object_id('CRONUS International Ltd_$Contact')

The result will look as follows:

FIGURE 6.6 THE ADJUSTED FILL FACTOR

Monitoring Monitoring is an important aspect of database administration, because Microsoft SQL Server provides services in a dynamic environment. The data in the application changes, the type of access that users require changes, and the way that users connect changes. SQL Server automatically manages system-level resources such as memory and disk space, but monitoring lets administrators identify performance trends to determine whether changes are necessary.

Monitoring an instance of SQL Server requires analysis of some key aspects of the system. Eliminating the physical bottlenecks can immediately affect performance and further isolate the design issues in the database, Transact-SQL queries, or client applications.

It is important to monitor SQL Server performance so that you can identify bottlenecks (or the symptoms of upcoming bottlenecks) at an early stage, determine their cause, and eliminate them. Bottlenecks can be eliminated by upgrading hardware, by distributing server load among other instances of SQL Server, or by tuning SQL Server databases, indexes, and queries.

To determine performance trends, we recommend that you store historical monitoring information in a separate database. Keep in mind that the more monitoring data you keep, the bigger the load for the monitoring server.



6-25

Performance

The goal of monitoring databases is to assess how a server is performing. Effective monitoring involves taking periodic snapshots of current performance to isolate processes that are causing problems, and collecting data continuously over time to track performance trends. Microsoft SQL Server and the Microsoft Windows® operating system provide utilities that let you view the current condition of the database and to track performance as conditions change.

Monitoring SQL Server lets you do the following:

• Determine whether you can improve performance. For example, by monitoring the response times for frequently used queries, you can determine whether changes to the query or indexes on the tables are required.

• Evaluate user activity. For example, by monitoring users who are trying to connect to an instance of SQL Server, you can determine whether security is set up adequately and test applications or development systems. For example, by monitoring SQL queries as they are executed, you can determine whether they are written correctly and producing the expected results.

• Troubleshoot any problems or debug application components, such as stored procedures.

Monitoring is important because SQL Server provides a service in a dynamic environment. The data in the application changes, the type of access that users require changes, and the way that users connect changes. The types of applications accessing SQL Server may even change, but SQL Server automatically manages system-level resources such as memory and disk space so that the need for extensive system-level manual tuning is minimized. But monitoring lets administrators identify performance trends to determine whether changes are necessary.

Ongoing evaluation of the database performance helps you minimize response times and maximize throughput yielding optimal performance. Efficient network traffic, disk I/O, and CPU usage are key to peak performance. You need to thoroughly analyze the application requirements, understand the logical and physical structure of the data, assess database usage, and negotiate tradeoffs between conflicting uses such as online transaction processing (OLTP) versus decision support.



6-26

Changing conditions result in changing performance. In your evaluations, you can see performance changes as the number of users increases, user access and connection methods change, database contents grow, client applications change, data in the applications changes, queries become more complex, and network traffic increases. By using SQL Server tools to monitor performance, you can associate some changes in performance with changing conditions and complex queries. The following scenarios provide examples:

• By monitoring the response times for frequently used queries, you can determine whether changes to the query or indexes on the tables where the queries execute are required.

• By monitoring Transact-SQL queries as they are executed, you can determine whether the queries are written correctly and producing the expected results.

• By monitoring users who try to connect to an instance of SQL Server, you can determine whether security is set up adequately and test applications or development systems.

Response time is the length of time required for the first row of the result set to be returned to the user in the form of visual confirmation that a query is being processed. Throughput is the total number of queries handled by the server during a specified period of time.

As the number of users increases, so does the competition for a server's resources, which in turn increases response time and decreases overall throughput.

Database Growth

In addition to monitoring system resources and database activity, database growth, or free disk space should be monitored when using SQL Server.

Monitoring free disk space on the SQL Server is very important. If SQL Server runs out of disk space on a specific drive, it means that SQL Server has no space left to write transactions to the database, the transaction log or the tempdb database. As a consequence, SQL Server does the following:

• Reports error message 9002 or 1105 in the Microsoft SQL Server error log.

• Marks the database as suspect. • Takes the database offline.

A lack of disk space can cause serious disruptions in the SQL Server production environment and will prevent running applications from completing transactions. In either case, user action is required to make disk space available, as databases marked as suspect are inaccessible to the end-user.



6-27

For more information about how to troubleshoot any of these situations, see Troubleshooting a Full Transaction Log (Error 9002) (http://msdn.microsoft.com/en-us/library/ms175495.aspx), Troubleshooting Insufficient Data Disk Space (http://msdn.microsoft.com/en-us/library/ms366198.aspx), or Troubleshooting Insufficient Disk Space in tempdb (http://msdn.microsoft.com/en-us/library/ms176029.aspx).

How to Monitor Database Growth?

Monitoring database growth becomes more important as data is entered in the database and databases are added to the SQL Server. Instead of measuring growth of individual databases, you can measure the free space on the drives of the SQL Server.

Although Windows Script Host (WSH), Visual Basic Script (VBS) or Windows Management Instrumentation (WMI) offer better ways of collecting disk space information, it can also be done using Transact-SQL. To do this, use the xp_fixeddrives stored procedure, as shown in the following code:

xp_fixeddrives

The results of running this query will look as follows:

FIGURE 6.7 XP_FIXEDDRIVES RETURNS FREE DISK SPACE INFORMATION

To monitor disk space daily, you can schedule this query and store the results of the query (with a time stamp) in a separate table. This will allow you to analyze trends in disk space information and predict hardware bottlenecks (by using larger hard disks). This information will show you when the free disk space started decreasing significantly and allows you to calculate when you will run out of space.



6-28

The following script shows how to create a table DiskSpaceInfo in a monitoring database (Monitoring Database) and how to insert the xp_fixeddrives information into the table.

Use [MonitorDB]; -- Create Table (One Time Only) IF NOT EXISTS (SELECT * FROM sys.sysobjects WHERE id = object_id(N'[MonitorDB].dbo.[DiskSpaceInfo]')) CREATE TABLE [MonitorDB].dbo.DiskSpaceInfo (EntryNo int IDENTITY, MetricDate datetime default getdate(), DriveName varchar(2), FreeSpaceMB int ); -- Add Monitoring Data INSERT INTO [MonitorDB].dbo.DiskSpaceInfo (DriveName, FreeSpaceMB) EXEC xp_fixeddrives;

-- Show Records in Table -- SELECT * FROM [MonitorDB].dbo.DiskSpaceInfo;

This script can be scheduled on SQL Server to collect drive information at specific time intervals, for example every hour or every day at 12:00PM. The smaller the interval, the more accurate the data become and the bigger the monitoring database grows.

Database Mail Alerts

When measuring the disk space information, you can also setup alerts that will be triggered automatically when a specific limit is reached. You can set up alerts in Windows Performance Monitor or you can set them up in SQL Server. If you want to send alerts through e-mail, you must enable database mail in SQL Server.

To enable database mail in SQL Server 2008, use the following procedure:

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 Database Engine. 3. In Object Explorer, right-click the server name and select Facets.



6-29

4. In the View Facets window, in the Facet field, select Surface Area Configuration from the drop-down list.

5. Set the DatabaseMailEnabled property to True.

FIGURE 6.8 SURFACE AREA CONFIGURATION IN SQL SERVER 2008.

6. Click OK to close the View Facets window.

To enable database mail in SQL Server 2005, perform the following procedure:

1. In the Windows taskbar, click Start > All Programs > Microsoft SQL Server 2005 > Configuration Tools > SQL Server Surface Area Configuration.

2. Select Surface Area Configuration for Features. 3. In the Surface Area Configuration for Features window, select the

instance of SQL Server to configure. 4. Select Database Engine. 5. On the Database Mail page, check the Enable Database Mail

stored procedures field. 6. Click OK.

NOTE: Database Mail is a component for sending e-mail messages from the Database Engine with SMTP. Enable Database Mail stored procedures only if you plan to configure and use Database Mail.



6-30

For more information about how to set up database mail, see Database Mail How-to Topics (http://msdn.microsoft.com/en-us/library/ms188298.aspx).

Measuring Total Disk Capacity

The xp_fixeddrives extended stored procedure returns free disk space in megabytes, so you can set up alerts that trigger when the amount of free disk reaches or falls under a specific threshold value in megabytes. If you want to express the threshold value as a percentage of the total disk capacity, you have to use other methods outside SQL Server.

The following code shows you how to measure the total disk capacity and store it in a table DiskSpaceInfo2 in the MonitorDB database.

Use [MonitorDB];

SET NOCOUNT ON; DECLARE @hr int; DECLARE @fso int; DECLARE @drive char(1); DECLARE @odrive int; DECLARE @TotalSize varchar(20); DECLARE @MB bigint; SET @MB = 1048576;

-- Create Temporary Table CREATE TABLE #drives (ServerName varchar(15), drive char(1), FreeSpace int NULL, TotalSize int NULL, FreespaceTimestamp DATETIME NULL);

-- Create Table (One Time Only) IF NOT EXISTS (SELECT * FROM sys.sysobjects WHERE id = object_id(N'[MonitorDB].dbo.[DiskSpaceInfo2]')) create TABLE DiskSpaceInfo2 (EntryNo int identity, ServerName varchar(15), drive varchar(1),

FreeSpace int NULL, TotalSize int NULL, FreePct int, FreespaceTimestamp DATETIME NULL); INSERT #drives(drive,FreeSpace) EXEC master.dbo.xp_fixeddrives; EXEC @hr=sp_OACreate 'Scripting.FileSystemObject',@fso OUT; IF @hr <> 0 EXEC sp_OAGetErrorInfo @fso; DECLARE dcur CURSOR LOCAL FAST_FORWARD FOR



6-31

SELECT drive from #drives ORDER by drive; OPEN dcur; FETCH NEXT FROM dcur INTO @drive; WHILE @@FETCH_STATUS=0 BEGIN EXEC @hr = sp_OAMethod @fso,'GetDrive', @odrive OUT, @drive; IF @hr <> 0 EXEC sp_OAGetErrorInfo @fso; EXEC @hr = sp_OAGetProperty @odrive,'TotalSize', @TotalSize OUT; IF @hr <> 0 EXEC sp_OAGetErrorInfo @odrive; UPDATE #drives SET TotalSize=@TotalSize/@MB, ServerName = host_name(), FreespaceTimestamp = (GETDATE()) WHERE drive=@drive; FETCH NEXT FROM dcur INTO @drive; END; CLOSE dcur; DEALLOCATE dcur; EXEC @hr=sp_OADestroy @fso; IF @hr <> 0 EXEC sp_OAGetErrorInfo @fso;

INSERT INTO DiskSpaceInfo2 (ServerName,drive,TotalSize,FreeSpace,FreePct, FreespaceTimestamp) SELECT ServerName, drive, TotalSize as 'Total(MB)', FreeSpace as 'Free(MB)', CAST((FreeSpace/(TotalSize*1.0))*100.0 as int) as 'Free(%)', FreespaceTimestamp FROM #drives ORDER BY drive; DROP TABLE #drives; SELECT * FROM DiskSpaceInfo2

To use the File Script Object set the OleAutomationEnabled property to True. To do this follow the same procedure as for the DatabaseMailEnabled property.

NOTE: The OLE Automation extended stored procedures (XPs) allow Transact-SQL batches, stored procedures, and triggers to reference custom OLE Automation objects. Enable OLE Automation only if applications or Transact-SQL scripts use OLE Automation XPs.



6-32

Although it is not mandatory, we recommend to store the monitored data in a performance data warehouse. This is a (small) database that only contains performance data from one or more servers, collected by different monitoring tools. While data is collected and entered into the database, you can create views or Microsoft SQL Server Reporting Services reports to view the trends in time. Doing this, you can easily see when disk space starts changing considerably. When you see a significant change in database growth, you should closely follow-up the growth and evaluate whether you have to take some action. It is a good practice to find out what is causing the database growth. At the same time, you should plan for future changes. The information will serve as a historical system documentation that can be analyzed later.

Shrinking the Database

Shrinking the database file daily to recover disk space is not feasible. If you shrink the database file, you have the gain of the empty disk space, but keep in mind that expanding the database during daily work requires system resources.

You should only consider shrinking the database file when the database is significantly bigger than the amount of data in the database (for example, after you have archived or removed some of the data) and when the database is either read-only (archive purpose) or rather static (no or only a small amount of data is added). For example, if you have a 3GB database that contains only 1GB of data, you can shrink the database file.

If you need to shrink the database file, we recommend not to use a maintenance plan to do it. Instead, shrink the database manually by using the DBCC SHRINKDATABASE or DBCC SHRINKFILE statement. To shrink all data and log files for a specific database, execute the DBCC SHRINKDATABASE command. To shrink one data or log file at a time for a specific database, execute the DBCC SHRINKFILE command.

The following example reduces the size of the data and log files in the Demo Database NAV (6-0) database to allow for 10 percent free space in the database.

DBCC SHRINKDATABASE ('Demo Database NAV (6-0)', 10);

To view the current amount of free (unallocated) space in the database, run the sp_spaceused stored procedure.

Consider the following information when you plan to shrink a file:

• A shrink operation is most effective after an operation that creates a lot of unused space, such as a truncate table or a drop table operation.

• Most databases require some free space to be available for regular day-to-day operations. If you shrink a database repeatedly and notice that the database size grows again, this indicates that the space that was shrunk is required for regular operations. In these cases, repeatedly shrinking the database is a wasted operation.



6-33

• A shrink operation does not preserve the fragmentation state of indexes in the database, and generally increases fragmentation to a degree. This is another reason not to repeatedly shrink the database.

• Unless you have a specific requirement, do not set the AUTO_SHRINK database option to ON.

Troubleshooting File Shrinking

Note that, unlike DBCC SHRINKFILE, DBCC SHRINKDATABASE does not allow you to make a database smaller than the minimum size of the database. The minimum size is the size specified when the database is originally created, or the last size explicitly set by using a file size changing operation such as DBCC SHIRNKFILE or ALTER DATABASE. For example, if a database is originally created with a size of 10 MB and grows to 100 MB, the smallest the database can be reduced to is 10 MB, even if all the data in the database has been deleted.

Typically it is the log file that appears not to shrink. This is usually the result of a log file that has not been truncated. You can truncate the log by setting the database recovery model to SIMPLE, or by backing up the log and then running the DBCC SHRINKFILE operation again.

If insufficient free space is available, the shrink operation cannot reduce the file size any further. Run the DBCC SQLPERF command to return the space used in the transaction log, as shown in the following code.

DBCC SQLPERF(LOGSPACE)

For more information about shrinking databases and log files, see DBCC SHRINKFILE (http://msdn.microsoft.com/en-us/library/ms189493.aspx), DBCC SHRINKDATABASE (http://msdn.microsoft.com/en-us/library/ms190488.aspx), and Shrinking the Transaction Log (http://msdn.microsoft.com/en-us/library/ms178037.aspx).

Transaction Log Growth

The guidelines for monitoring database file growth also apply to transaction log files. If SQL Server runs out of space on the drive that contains the transaction log files, it cannot write data to the log files and errors will be raised.

To limit the growth of a transaction log file, you can set the database recovery model to Simple. However, most production environments require a different recovery model, which means that the transaction log files will grow. By implementing a decent backup strategy you can keep the transaction log growth under control, as the backup will shrink the transaction log files.

If you notice that transaction log files suddenly start growing significantly, check the database activity and make sure that you check your backup routines too. Very often, transaction logs start to grow because of a failing backup strategy.



6-34

To reduce the size of the transaction log, implement a sufficient backup strategy. If it is necessary, you can shrink the log files manually by using DBCC SHRINKFILE.

Database and transaction log backups can be included as a subtask in a maintenance plan. However, depending on your needs, backups will frequently be scheduled to run during the day (especially transaction log backups), so the need to include backups in a maintenance plan is low. In fact, for schedule maintenance reasons, it is more practical to keep the backup schedule separated from the maintenance plan.

Summary In this chapter you learn how to set up and schedule maintenance plans to perform important maintenance tasks on SQL Server. In addition, the chapter shows how to execute specific maintenance tasks by using Transact-SQL scripts.



6-35

Test Your Knowledge Test your knowledge with the following questions.

1. Which dynamic management view or function allows retrieving index fragmentation?

( ) sys.dm_db_index_operational_stats ( ) sys.dm_db_index_usage_stats ( ) sys.dm_db_index_physical_stats ( ) sys.dm_db_index_frag_stats

2. What does the ALTER INDEX [$1] ON [CRONUS International Ltd_$Contact] REBUILD statement do? (Select all that apply)

( ) Updates the [$1] index for the Contact table ( ) Rebuilds the [$1] index for the Contact table with the most recently

set FILLFACTOR value for that table. ( ) Rebuilds the [$1] index for the Contact table with a Fill Factor of 100. ( ) Drops the [$1] index for the Contact table

3. What does the ALTER INDEX ALL ON [CRONUS International Ltd_$Contact] REORGANIZE WITH (FILLFACTOR= 75) statement do?

( ) Updates all indexes for the Contact table ( ) Reorganizes all indexes for the Contact table with a FILLFACTOR

value of 75. ( ) Drops the all indexes for the Contact table ( ) This statement is not correct.

4. Which stored procedure runs the UPDATE STATISTICS against all user-defined and internal tables in the current database?

( ) sp_autostats ( ) sp_updatestats ( ) sp_createstats ( ) sp_updatestats ALL



6-36

5. Name two reasons why we recommend not to include database shrinking in a maintenance plan.

6. How can you control the growth of transaction log files for a specific database?



6-37

Lab 6.1 - Create a Maintenance Plan In this lab you set up a maintenance plan in SQL Server to optimize the maintenance for a Microsoft Dynamics NAV database.

Scenario

Tim, the IT manager, has run some tests on the Demo Database NAV (6-0) database. The tests have shown that the indexes for the following warehouse activity tables are fragmented:

• Warehouse Request • Warehouse Activity Header • Warehouse Activity Line • Registered Whse. Activity Header • Registered Whse. Activity Line • Warehouse Shipment Header • Warehouse Shipment Line • Posted Whse. Shipment Header • Posted Whse. Shipment Line

Tim creates a maintenance plan to defragment (reorganize) all indexes in the warehouse activity tables. He schedules the maintenance plan so that it is run automatically every night at 8:00 P.M. (except on weekends). Finally, he will test the maintenance plan.

Challenge Yourself!

Create a maintenance plan that reorganizes all indexes of the following warehouse activity tables:

• Warehouse Request • Warehouse Activity Header • Warehouse Activity Line • Registered Whse. Activity Header • Registered Whse. Activity Line • Warehouse Shipment Header • Warehouse Shipment Line • Posted Whse. Shipment Header • Posted Whse. Shipment Line

Schedule the maintenance plan to run every night at 8:00 P.M. (except on weekends). Test the plan.



6-38

Need a Little Help?

Perform the following steps to complete this lab:

1. Create and Schedule the Maintenance Plan. 2. Start SQL Server Agent. 3. Test the Maintenance Plan.

Step by Step

Perform the following steps to complete the lab:

Create and Schedule the Maintenance Plan


sysadmin credentials. 3. Expand the NAV-SRV-01 server. 4. Click Management. 5. Right-click Maintenance Plans and select Maintenance Plan

Wizard. 6. On the SQL Server Maintenance Plan Wizard page, click Next. 7. On the Select Plan Properties page, in the Name field, enter the

name for the maintenance plan: Lab 6_1. 8. In the Description field, enter the following description: Defragment

Indexes of Warehouse Activity tables. 9. Select the Single schedule for the entire plan or no plan option. 10. Click the Change button to define the schedule. 11. In the Job Schedule Properties window, verify that the Schedule

type is set to Recurring and that Enabled is selected. 12. Verify that the Frequency has been set to Weekly and that the

Recurs every week(s) on is set to 1.



6-39

13. Select the weekdays Monday to Friday. 14. Clear Saturday and Sunday.

FIGURE 6.9 JOB SCHEDULE PROPERTIES

15. Set the Occurs once at field to 8:00PM. 16. Set the Start Date to the current date and select the No end date

option. 17. Click OK to close the Job Schedule Properties window. 18. Click Next. 19. On the Select Maintenance Tasks page, select Reorganize Index. 20. Click Next. 21. On the Select Maintenance Task Order page, click Next. 22. On the Define Reorganize Index Task page, in the Database field,

select the Demo Database NAV (6-0) database. 23. In the Objects field, select Tables. 24. In the Selection field, select the following tables:

a. Warehouse Request b. Warehouse Activity Header c. Warehouse Activity Line d. Registered Whse. Activity Header e. Registered Whse. Activity Line



6-40

f. Warehouse Shipment Header g. Warehouse Shipment Line h. Posted Whse. Shipment Header i. Posted Whse. Shipment Line

25. Click Next. 26. On the Select Report Options page, verify that the Write a report

to a text file option is selected. Leave the default Folder Location. 27. Click Next. 28. On the Complete the Wizard page, verify the options selected for

the maintenance plan. 29. Click Finish to create the maintenance plan. 30. On the Maintenance Plan Wizard Progress page, click Close.

Start SQL Server Agent

1. In SQL Server Management Studio, expand Management. 2. Select SQL Server Agent. 3. Verify that SQL Server Agent is running.

If SQL Server Agent is not running, an icon with a small red square displays and no items are displayed under the SQL Server Agent node. If SQL Server Agent is running, an icon with a small green arrow displays and the SQL Server Agent node will contain items.

FIGURE 6.10 SQL SERVER AGENT NODE IN SSMS

To start SQL Server Agent, right-click SQL Server Agent and select Start. Click Yes to confirm starting the SQL Server Agent Service (SQLSERVERAGENT) on NAV-SRV-01.

NOTE: You can start and stop the SQL Server Agent service in SQL Server Management Studio. However, to configure the SQL Server Agent service, we recommend that you use the SQL Server Configuration Manager.



6-41

Test the Maintenance Plan

The maintenance plan can be run in two ways. Either you can run the maintenance plan from the Maintenance Plans node in SQL Server Management Studio, or you can run the SQL Server job that corresponds to the maintenance task in the SQL Server Agent node.

Method 1: Start the Maintenance Plan under Maintenance Plans.

1. In SQL Server Management Studio, select Maintenance Plans. 2. In the Object Explorer Details pane, right-click the Lab 6_1

maintenance plan and select Execute.

FIGURE 6.11 MAINTENANCE PLAN EXECUTION PROGRESS

The Execute Maintenance Plan dialog opens, showing the progress of the maintenance plan.

3. Click Close to exit the Execute Maintenance Plan dialog box.

Method 2: Start the Maintenance Plan under SQL Server Agent > Jobs.

1. In SQL Server Management Studio, select SQL Server Agent.



6-42

2. Select Jobs. 3. In the Object Explorer Details pane, right-click the Lab

6_1.Subplan_1 job and select Start Job at Step.

FIGURE 6.12 SQL SERVER AGENT JOB EXECUTION PROGRESS

The Start Jobs dialog opens, showing the progress of the job.

4. Click Close to exit the Start Jobs dialog box.



6-43

Lab 6.2 - Change the Fill Factor for Hot Tables In this lab you change the fill factor for the indexes of specific tables to reduce the number of page splits.

Scenario

While monitoring the SQL Server, Tim detects an increased number of page splits when users are querying the following tables:

• Sales Header • Sales Line • Purchase Header • Purchase Line • Document Dimension

To reduce the number of page splits, Tim decides to change the fill factor to 70% so that 30% of free space per page is available for data updates. While indexes are being re-created, the intermediate sort results must be stored in the tempdb and out-of-data statistics must be recomputed. Verify the index fill factor for the tables afterward.

Challenge Yourself!

Use a Transact-SQL script to change the fill factor of all indexes for the following tables to 70%:

• Sales Header • Sales Line • Purchase Header • Purchase Line • Document Dimension

Make sure that you use the tempdb to store the intermediate sort results and make sure that out-of-date statistics are automatically recomputed. Verify the index fill factor for the tables afterward.

Need a Little Help?


1. Open SQL Server Management Studio. 2. Run the Query. 3. Verify the index fill factor for the tables.



6-44

Step by Step


Open SQL Server Management Studio

1. In the Windows Taskbar, click Start > All Programs > Microsoft SQL Server 2008 > SQL Server Management Studio.

2. Connect to the NAV-SRV-01 Database Engine. 3. In the database drop-down list, select the Demo Database NAV (6-

0) database.

Run the Query

1. In SQL Server Management Studio, click the New Query button to open a new query window.

2. In the New Query window, enter the following command:

ALTER INDEX ALL ON [CRONUS International Ltd_$Sales Header] REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = ON); ALTER INDEX ALL ON [CRONUS International Ltd_$Sales Line] REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = ON); ALTER INDEX ALL ON [CRONUS International Ltd_$Purchase Header] REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = ON); ALTER INDEX ALL ON [CRONUS International Ltd_$Purchase Line] REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = ON); ALTER INDEX ALL ON [CRONUS International Ltd_$Document Dimension] REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = ON);


Verify the fill factor of the tables.

1. In SQL Server Management Studio, click the New Query button to open a new query window.



6-45

2. In the New Query window, enter the following command:

USE [Demo Database NAV (6-0)]; SELECT name, index_id, type, is_primary_key, type_desc, fill_factor FROM sys.indexes WHERE fill_factor = 70


The statement will list all indexes with a fill factor of 70.



6-46

Lab 6.3 - Compare Query Execution Before and After Deleting Statistics

In this lab you investigate the importance of SQL Server statistics for query execution.

Scenario

To reduce the overhead on the server, Mort, the IT systems developer, has disabled the Auto Update Statistics and Auto Create Statistics options on the Demo Database NAV (6-0) database. As a consequence, statistical information is not updated for the database.

Tim, the IT manager, explains that updated index statistics are really important for performance on SQL Server. As Mort is not convinced, Tim shows Mort how important statistics are, by running queries with and without SQL Server statistics. Afterward, he verifies that statistics exist for a specific table and compares the execution plans with and without statistics.

Challenge Yourself!

Prove the importance of SQL Server statistics for query execution. Use the following query as a base.

SELECT * FROM [CRONUS International Ltd_$Sales Line] WHERE ([Document Type]=1) AND ([Type]=2) AND ([No_]='1896-S') ORDER BY [Document Type],[Type],[No_],[Variant Code], [Drop Shipment],[Location Code],[Shipment Date]

This is the query that executes when you click Sales, Orders on the Item Card for item 1896-S.

Verify the presence of index statistics for the Sales Line table and compare the execution plans.

Need a Little Help?


1. Open SQL Server Management Studio. 2. Remove all Indexes. 3. Run the Sales Line Query. 4. Re-create Index Statistics. 5. Run the Sales Line Query Again.



6-47

6. Verify Statistics for the Sales Line Table. 7. Compare Execution Plans.

Step by Step


Open SQL Server Management Studio

1. In the Windows Taskbar, click Start > All Programs > Microsoft SQL Server 2008 > SQL Server Management Studio.

2. Connect to the NAV-SRV-01 Database Engine. 3. In the database drop-down list, select the Demo Database NAV (6-

0) database.

Remove All Statistics

1. Click the New Query button to open a new query window. 2. In the New Query window, enter the following query to remove

statistics for all tables and views in the database:

DECLARE @id int; DECLARE @name varchar(128); DECLARE @statement nvarchar(1000); DECLARE stat_cur CURSOR FAST_FORWARD FOR SELECT [id], [name] FROM sys.sysindexes WHERE ((indexproperty(id, name, N'IsStatistics')=1) OR (indexproperty(id, name, N'IsAutoStatistics')=1)) AND (isnull(objectproperty([id], N'IsUserTable'),0)=1); OPEN stat_cur; FETCH NEXT FROM stat_cur INTO @id, @name; WHILE @@fetch_status = 0 BEGIN SET @statement = 'DROP STATISTICS [' + object_name(@id) + '].[' + @name + ']'; BEGIN TRANSACTION; EXEC sp_executesql @statement; COMMIT TRANSACTION; FETCH NEXT FROM stat_cur INTO @id, @name; END; CLOSE stat_cur; DEALLOCATE stat_cur;

3. Click Execute to run the query. 4. Close the query window without saving the query.



6-48

Run the Sales Line Data Query

1. Click the New Query button to open a new query window. 2. In the New Query window, enter the following query:


3. Right-click the query window and select Display Estimated Execution Plan. SQL Server will now run the query and show the estimated execution plan.

FIGURE 6.13 EXECUTION PLAN WITHOUT STATISTICS

Re-create Index Statistics

1. Click the New Query button to open a new query window. 2. In the New Query window, enter the following query to create index

statistics:

sp_createstats 'indexonly';

3. Run the query. 4. Close the query window.



6-49

Run the Sales Line Data Query Again

1. Click the New Query button to open a new query window. 2. In the New Query window, enter the same query as before:


3. Right-click the query window and select Display Estimated Execution Plan. SQL Server will now run the query and show another execution plan.

FIGURE 6.14 EXECUTION PLAN WITH STATISTICS

Verify Statistics for the Sales Line Table

1. Click the New Query button to open a new query window. 2. In the New Query window, enter the following query to verify the

existing index statistics for the Sales Line table:

SELECT [id], object_name([id]) AS [tabname], [name], isnull(indexproperty(id, name, N'IsStatistics'),0) AS [stats], isnull(indexproperty(id, name, N'IsAutoStatistics'),0) AS [auto] FROM sys.sysindexes WHERE ((indexproperty(id, name, N'IsStatistics') = 1) OR (indexproperty(id, name, N'IsAutoStatistics') = 1)) AND (isnull(objectproperty([id], N'IsUserTable'),0) = 1) AND object_name([id]) LIKE '%Sales Line' ORDER BY tabname

3. Run the query. 4. Close the query window.



6-50

Compare Execution Plans

When comparing the execution plans, notice that in the second execution plan SQL Server spends more time executing index seeks and less time doing key lookups.

The use of a Key Lookup operator in a query plan indicates that the query might benefit from performance tuning. For example, query performance might be improved by adding a covering index. For more information about key lookups, see Key Lookup Showplan Operator (http://msdn.microsoft.com/en-us/library/bb326635.aspx).

Furthermore, if you hover the Index Seek icon on the first execution plan, you will notice a warning message stating that there are columns with no statistics. In

You can repeat this procedure for other queries in the Microsoft Dynamics NAV database and compare the execution plans with and without statistics. In general, you will notice better performance when statistics are available, especially when the amount of data grows.



6-51

Quick Interaction: Lessons Learned Take a moment and write down three Key Points you have learned from this chapter

1.

2.

3.



6-52

Solutions Test Your Knowledge

1. Which dynamic management view or function allows retrieving index fragmentation?

( ) sys.dm_db_index_operational_stats ( ) sys.dm_db_index_usage_stats (•) sys.dm_db_index_physical_stats ( ) sys.dm_db_index_frag_stats

2. What does the ALTER INDEX [$1] ON [CRONUS International Ltd_$Contact] REBUILD statement do? (Select all that apply)

( ) Updates the [$1] index for the Contact table (√) Rebuilds the [$1] index for the Contact table with the most recently

set FILLFACTOR value for that table. ( ) Rebuilds the [$1] index for the Contact table with a Fill Factor of 100. (√) Drops the [$1] index for the Contact table

3. What does the ALTER INDEX ALL ON [CRONUS International Ltd_$Contact] REORGANIZE WITH (FILLFACTOR= 75) statement do?

( ) Updates all indexes for the Contact table ( ) Reorganizes all indexes for the Contact table with a FILLFACTOR

value of 75. ( ) Drops the all indexes for the Contact table (•) This statement is not correct.

4. Which stored procedure runs the UPDATE STATISTICS against all user-defined and internal tables in the current database?

( ) sp_autostats (•) sp_updatestats ( ) sp_createstats ( ) sp_updatestats ALL



6-53

5. Name two reasons why we recommend not to include database shrinking in a maintenance plan.

MODEL ANSWER:

1. Most databases require some free space to be available for regular day-to-day operations. If you remove the free space from the database, SQL Server has to expand the database to execute its regular operations. In these cases, repeatedly shrinking the database is a wasted operation. 2. A shrink operation does not preserve the fragmentation state of indexes in the database, and generally increases fragmentation to a degree.

6. How can you control the growth of transaction log files for a specific database?

MODEL ANSWER:

You can set the recovery model of the database to SIMPLE. If you require a different recovery model, you have to implement a decent backup strategy (because making a backup reduces the size of the transaction log file). Occasionally, you can use the DBCC SHRINKFILE or DBCC SHRINKDATABASE statements to manually shrink the files.



6-54


Technology

Na2009 enus sql_06