The Real MTCS SQL Server 2008 Exam 70/432 Prep Kit- P57 pptx

For partial indexes, the index structure is created only for a subset of data that is frequently searched for.. For example, if you store a decade’s worth of data in a table and only eve

The use of sparse columns is especially appropriate with filtered indexes Filtered indexes are indexes that are optimized for querying data based on certain criteria

A filtered index on a sparse column can index only the rows that have non-null values Filtered indexes created on sparse columns consume less disk space and improve performance

Maintaining Indexes

Index maintenance is an important part of looking after databases As you have

learned from earlier chapters, indexes are structures that speed up data retrieval signifi-cantly Indexes are stored on disk as physical structures Indexes are automatically updated when underlying table data is modified However, with time and data usage analysis, you may want to create new or drop existing indexes You may also need to defragment indexes on frequently modified tables as they can be highly fragmented

TEsT Day Tip

Sometimes very large indexes become difficult to maintain As an alter-native, consider partial indexes created with a filter (WHERE) clause For partial indexes, the index structure is created only for a subset of data that is frequently searched for For example, if you store a decade’s worth of data in a table and only ever query the last year’s worth of data frequently, there is no reason to maintain the index for the portion

of the data that is accessed infrequently An index with a WHERE clause helps overcome the situation by creating a small and efficient index structure that covers the current data only.

Dynamic Management Views (DMVs) is a feature introduced in SQL Server

2005 that allows you to view useful information about indexes The following DMVs are available for index maintenance:

sys.dm_db_missing_index_details Lists missing indexes

■

■

■

■ sys.dm_db_index_operational_stats Shows index usage statistics

■

■ sys.dm_db_index_physical_stats Shows fragmentation information on each

index

As shown in Example 7.12, when the sys.dm_db_missing_index_details includes equality_columns, the DMV lists potential index suggestions

Example 7.12 Finding Missing Indexes

SELECT DB_NAME(Database_id) AS DbName,

OBJECT_NAME(object_id, Database_id) AS ObjName, *

FROM sys.dm_db_missing_index_details

Results (no indexes are missing in this case):

DbName ObjName index_handle database_id object_id

equality_columns

inequality_columns

included_columns

statement

- - - - -

- (0 row(s) affected)

To identify any unused indexes that can be dropped, query the sys.dm_db_

index_usage_stats DMV This view explains when an index was last used, and how

it was used (the number of seeks, scans, and bookmark lookups) The dm_db_

index_usage_stats DMV is emptied every time the SQL Server service is restarted

In order to see the name of the index, you need to join the sys.dm_db_index_

usage_stats DMV to the sys.indexes table, as shown in Example 7.13

Example 7.13 Viewing Index Usage Statistics

SELECT indexes.name, IndexStats.*

FROM sys.dm_db_index_operational_stats

(DB_ID(N'AdventureWorks'),

OBJECT_ID(N'AdventureWorks.Person.Address'),

NULL,

NULL) AS IndexStats

INNER JOIN AdventureWorks.sys.indexes

ON IndexStats.object_id = indexes.object_id

AND IndexStats.index_id = indexes.index_id

Indexes become fragmented over time due to underlying data changes There

are two types of fragmentation: external and internal In order to understand the

difference, you must understand how SQL Server stores data Rows are stored

in 8KB pages, which are stored in extents An extent can contain up to 8 pages

SQL Server always accesses data by extent, not by page or row When a clustered

index exists on a table, the actual table data is stored in the order of the index

within each page When the clustered index was first created, SQL Server arranged

those pages so that contiguous pages were on the same extent

However, if there’s no room on the page to insert new rows, SQL Server splits the page, moving half of the data to a new page This creates space to keep rows in logical sequence If there is no space on the extent, SQL Server moves the new page to a different extent In order to read a sequence of rows covering these two pages, SQL Server must load the two extents, or 16 pages, into memory This can also occur when updating data, i.e., when the updated row no longer fits the page

on which it was originally stored In this case, the operation results in a split page When the logical order of pages becomes scattered across multiple extents, the situation is referred to as external fragmentation When a table has external frag-mentation, SQL Server spends more time accessing the drives This is a problem because disk activity is the most resource consuming task SQL Server performs Internal fragmentation refers to empty space within data pages Empty space within pages is created when data is deleted Empty space within tables and indexes improves write performance because SQL Server can insert new records into the empty space without rearranging page structure However, empty space decreases read performance, because SQL Server must load more extents into memory to read a data set Allocating intentional empty space within a clustered or nonclus-tered index is called fill factor The FILLFACTOR option can be used when creat-ing new or rebuildcreat-ing existcreat-ing indexes The FILLFACTOR option can be specified with the CREATE INDEX or ALTER INDEX WITH REBUILD statements (see Example 7.14) The FILLFACTOR is an integer between 0 and 100 For example,

a FILLFACTOR of 80 means that the index pages will be 80 percent full When values 0 or 100 are specified, no fill factor is used Regularly defragmenting indexes can maintain the fill factor and optimize performance

Example 7.14 Using the ALTER INDEX Statement with FILLFACTOR

USE AdventureWorks;

GO

ALTER INDEX IX_Contact_LastName ON Person.Contact.LastName

REBUILD WITH (FILLFACTOR = 80);

GO

Rebuilding an index is a resource intensive operation Users cannot access the index while it is being rebuilt, unless the ONLINE option is used with the ALTER INDEX statement As a best practice, you should rebuild all indexes that are report-ing over 30 percent fragmentation If the fragmentation reported is between 10 and

30 percent, it is recommended that you reorganize the index instead Reorganizing indexes is a less intensive operation than a rebuild (see Example 7.15) The table and

all of its indexes remain online and can be accessed by users while they are being

reorganized You can cancel reorganization without causing a rollback and without

losing any of the defragmentation that has already taken place However,

reorganiz-ing indexes takes longer and is not as thorough as rebuildreorganiz-ing them

Example 7.15 Reorganizing an Index

USE AdventureWorks;

GO

ALTER INDEX IX_Contact_LastName ON Person.Contact.LastName

REORGANIZE;

GO

TEsT Day Tip

Remember that you should rebuild an index when fragmentation is

reported at 30 percent or more and reorganize when fragmentation

is reported between 10 and 30 percent Less than 10 percent

fragmenta-tion is normal It would be counterproductive to try to defragment an

index with less than 10 percent fragmentation Also, ensure that you

understand the implications of FILLFACTOR on read and write

performance.

DBCC Explained

Database Console Commands, or DBCC, is a set of Transact SQL commands that

allow you to perform table, index, and database maintenance tasks DBCC can be

used to validate the integrity of a database or its individual tables, indexes, tables,

filegroups, or page allocation Useful fragmentation information for tables and

databases can be provided by DBCC Maintenance tasks like shrinking database files

or forcibly emptying caches can be performed by DBCC statements Table 7.1 lists

the options that can be used with DBCC

Informational Statements

INPUTBUFFER Shows the contents of the current input buffer

for a specific session.

OUTPUTBUFFER Shows the contents of the current output

buffer for a specific session.

OPENTRAN Shows information about the last open

transaction.

PROCCACHE Shows information held in procedure cache SHOW STATISTICS Shows query optimization statistics.

SHOWCONTIG Shows information about the fragmentation

of tables and indexes.

SQL PERF Shows transaction log statistics for all

databases.

TRACESTATUS Shows which diagnostic trace flags

have been set.

USEROPTIONS Shows the connection options.

Validation Statements

CHECKALLOC Checks the integrity of disk space allocation

for a database.

CHECKCATALOG Checks catalog integrity.

CHECKCONSTRAINTS Checks constraint integrity.

CHECKDB Checks database integrity.

CHECKFILEGROUP Checks the integrity of all tables and indexes

in a filegroup.

CHECKIDENT Shows the last identity value for a specified

table Can reseed the identity value.

CHECKTABLE Checks table integrity.

Maintenance Statements

CLEANTABLE Reclaims space in a table after a variable

length column has been dropped.

DROPCLEANBUFFER Removes clean buffers from the buffer pool.

Table 7.1 DBCC Options

Continued