Microsoft SQL Server 2008 R2 Unleashed- P86 pdf

ptg
794
CHAPTER 25 Creating and Managing Indexes
Dave
Bob
Amy
Zelda
Elizabeth
Elizabeth
George
George
Amy






Sam
Sam
Alexis, Amy,
Root Page
Intermediate
Page
Data Page
Amundsen, Fred,
Baker, Joe,
Best, Elizabeth,
Albert, John,
Masonelli, Irving,
Narin, Anabelle,

Naselle, Amy,
Neat, Juanita
Mason, Emma,
Zelda



Amy
Amy


Emma

Leaf Page
Anabelle

FIGURE 25.2 A simplified diagram of a nonclustered index.
A nonclustered index is also structured as a B-tree. Figure 25.2 shows a simplified diagram
of a nonclustered index defined on a first name column.
As with a clustered index, in a nonclustered index, all index key values are stored in the
nonclustered index levels in sorted order, based on the index key(s). This sort order is typi-
cally different from the sort order of the table itself. The main difference between a
nonclustered index and clustered index is that the leaf row of a nonclustered index is
independent of the data rows in the table. The leaf level of a nonclustered index contains
a row for every data row in the table, along with a pointer to locate the data row. This
pointer is either the clustered index key for the data row, if the table has a clustered index
on it, or the data page ID and row ID of the data row if the table is stored as a heap struc-
ture (that is, if the table has no clustered index defined on it).
To locate a data row via a nonclustered index, SQL Server starts at the root node and navi-
gates through the appropriate index pages in the intermediate levels of the index until it

reaches the leaf page, which should contain the index key for the desired data row. It then
scans the keys on the leaf page until it locates the desired index key value. SQL Server
then uses the pointer to the data row stored with the index key to retrieve the correspond-
ing data row.
Download from www.wowebook.com
ptg
795
Creating Indexes
25
NOTE
For a more detailed discussion of clustered tables versus heap tables (that is, tables
with no clustered indexes) and more detailed descriptions of clustered and nonclus-
tered index key structures and index key rows, as well as how SQL Server internally
maintains indexes, see Chapter 34.
The efficiency of the index lookup and the types of lookups should drive the selection of
nonclustered indexes. In the book index example, a single page reference is a very simple
lookup for the book reader and requires little work. If, however, many pages are referenced
in the index, and those pages are spread throughout the book, the lookup is no longer
simple, and much more work is required to get all the information.
You should choose your nonclustered indexes with the book index example in mind. You
should consider using nonclustered indexes for the following:
. Queries that do not return large result sets
. Columns that are frequently used in the WHERE clause that return exact matches
. Columns that have many distinct values (that is, high cardinality)
. All columns referenced in a critical query (a special nonclustered index called a
covering index that eliminates the need to go to the underlying data pages)
Having a good understanding of your data access is essential to creating nonclustered
indexes. Fortunately, SQL Server comes with tools such as the SQL Server Profiler and
Database Engine Tuning Advisor that can help you evaluate your data access paths and
determine which columns are the best candidates. SQL Profiler is discussed in more detail

in Chapter 6, “SQL Server Profiler.” In addition, Chapter 34 discusses the use of the SQL
Server Profiler and Database Engine Tuning Advisor to assist in developing an optimal
indexing strategy.
Creating Indexes
The following sections examine the most common means for creating indexes in SQL
Server. Microsoft provides several different methods for creating indexes, each of which
has advantages. The method used is often a matter of personal preference, but there are
situations in which a given method has distinct advantages.
Creating Indexes with T-SQL
Transact-SQL (T-SQL) is the most fundamental means for creating an index. This method
was available in all previous versions of SQL Server. It is a very powerful option for creat-
ing indexes because the T-SQL statements that create indexes can be stored in a file and
Download from www.wowebook.com
ptg
796
TABLE 25.1 Arguments for CREATE INDEX
Argument Explanation
UNIQUE
Indicates that no two rows in the index can have
the same index key values. Inserts into a table
with a UNIQUE index will fail if a row with the
same value already exists in the table.
CLUSTERED | NON-CLUSTERED
Defines the index as clustered or nonclustered.
NON-CLUSTERED is the default. Only one clus-
tered index is allowed per table.
index_name
Specifies the name of the index to be created.
object
Specifies the name of the table or view to be

indexed.
column_name
Specifies the column or columns that are to be
indexed.
ASC | DESC
Specifies the sort direction for the particular
index column. ASC creates an ascending sort
order and is the default. The DESC option
causes the index to be created in descending
order.
INCLUDE (column [ , n ] )
Allows a column to be added to the leaf level of
an index without being part of the index key.
This is a new argument.
run as part of a database installation or upgrade. In addition, T-SQL scripts that were used
in prior SQL Server versions to create indexes can be reused with very little change.
You can create indexes by using the T-SQL CREATE INDEX command. Listing 25.1 shows
the basic CREATE INDEX syntax. Refer to SQL Server 2008 Books Online for the full syntax.
LISTING 25.1 CREATE INDEX Syntax
CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
ON <object> ( column [ ASC | DESC ] [ , n ] )
[ INCLUDE ( column_name [ , n ] ) ]
[ WHERE <filter_predicate> ]
[ WITH ( <relational_index_option> [ , n ] ) ]
Table 25.1 lists the CREATE INDEX arguments.
CHAPTER 25 Creating and Managing Indexes
Download from www.wowebook.com
ptg
797
TABLE 25.1 Arguments for CREATE INDEX

Argument Explanation
WHERE <filter_predicate>
This argument, new to SQL Server 2008, is
used to create a filtered index. The
filter_predicate contains a WHERE clause
that limits the number of rows in the table that
are included in the index.
relational_index_option
Specifies the index option to use when creating
the index.
Creating Indexes
25
Following is a simple example using the basic syntax of the CREATE INDEX command:
CREATE NONCLUSTERED INDEX [NC_Person_LastName]
ON [Person].[Person]
(
[LastName] ASC
)
This example creates a nonclustered index on the person.person table, based on the
LastName column. The NONCLUSTERED and ASC keywords are not necessary because they
are the defaults. Because the UNIQUE keyword is not specified, duplicates are allowed in the
index (that is, multiple rows in the table can have the same LastName).
Unique indexes are more involved because they serve two roles: they provide fast access to
the data via the index’s columns, but they also serve as a constraint by allowing only one
row to exist on a table for the combination of column values in the index. They can be
clustered or nonclustered. Unique indexes are also defined on a table whenever you define
a unique or primary key constraint on a table. The following example shows the creation
of a nonclustered unique index:
CREATE UNIQUE NONCLUSTERED INDEX [AK_CreditCard_CardNumber]
ON [Sales].[CreditCard]

(
[CardNumber] ASC
)
This example creates a nonclustered index named AK_CreditCard_CardNumber on the
Sales.CreditCard table. This index is based on a single column in the table. When it is
created, this index prevents credit card rows with the same credit card number from being
inserted into the CreditCard table.
Download from www.wowebook.com
ptg
798
TABLE 25.2 Relational Index Options for CREATE INDEX
Argument Explanation
PAD_INDEX = {ON | OFF}
Determines whether free space is allocated to the
non-leaf-level pages of an index. The percentage of
free space is determined by FILLFACTOR.
FILLFACTOR = fillfactor
Determines the amount of free space left in the
leaf level of each index page. The fillfactor
values represent a percentage, from 0 to 100. The
default value is 0. If fillfactor is 0 or 100, the
index leaf-level pages are filled to capacity, leaving
only enough space for at least one more row to be
inserted.
SORT_IN_TEMPDB = {ON | OFF}
Specifies whether intermediate sort results that
are used to create the index are stored in tempdb.
Using them can speed up the creation of the index
(if tempdb is on a separate disk), but it requires
more disk space.

IGNORE_DUP_KEY = {ON | OFF}
Determines whether multirow inserts will fail when
duplicate rows in the insert violate a unique index.
When this option is set to ON, duplicate key values
are ignored, and the rest of the multirow insert
succeeds. When it is OFF (the default), the entire
multirow insertfails if a duplicate is encountered.
STATISTICS_NO_RECOMPUTE = {ON | OFF}
Determines whether distribution statistics used by
the Query Optimizer are recomputed. When ON, the
statistics are not automatically recomputed.
DROP_EXISTING = {ON | OFF}
Determines whether an index with the same name
is dropped prior to re-creation. This can provide
some performance benefits over dropping the exist-
ing index first and then creating. Clustered indexes
see the most benefit.
ONLINE = {ON | OFF}
Determines whether the index is built such that the
underlying table is still available for queries and
data modification during the index creation. This
new feature is discussed in more detail in the
“Online Indexing Operations” section, later in this
chapter.
The relational index options listed in Table 25.2 allow you to define more sophisticated
indexes or specify how an index is to be created.
CHAPTER 25 Creating and Managing Indexes
Download from www.wowebook.com
ptg
799

TABLE 25.2 Relational Index Options for CREATE INDEX
Argument Explanation
ALLOW_ROW_LOCKS = {ON | OFF}
Determines whether row locks are allowed when
accessing the index. The default for this new
feature is ON.
ALLOW_PAGE_LOCKS = {ON | OFF}
Determines whether page locks are allowed when
accessing the index. The default for this new
feature is ON.
MAXDOP = number of processors
Determines the number of processors that can be
used during index operations. The default for this
new feature is 0, which causes an index operation
to use the actual number of processors or fewer,
depending on the workload on the system. This
can be a useful option for index operations on
large tables that may impact performance during
the operation. For example, if you have four proces-
sors, you can specify MAXDOP = 2 to limit the index
operation to use only two of the four processors.
DATA_COMPRESSION = { NONE | ROW |
PAGE} [ ON PARTITIONS ( { <parti-
tion_number_expression> | <range> }
[ , n ] )
Determines whether data compression is used on
the specified index. The compression can be done
on the row or page level and specific index parti-
tions can be compressed if the index uses parti-
tioning.

Creating Indexes
25
The following example creates a more complex index that utilizes several of the index
options described in Table 25.2:
CREATE NONCLUSTERED INDEX [
IX_Person_LastName_FirstName_MiddleName] ON [Person].[Person]
(
[LastName] ASC,
[FirstName] ASC,
[MiddleName] ASC
)WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, FILLFAC-
TOR=80)
This example creates a nonclustered composite index on the person’s last name
(LastName), first name (FirstName), and middle name (MiddleName). It utilizes some of the
commonly used options and demonstrates how multiple options can be used in a single
CREATE statement.
Download from www.wowebook.com
ptg
800
TIP
SQL Server Management Studio (SSMS) has several methods for generating the T-SQL
code that creates indexes. You therefore rarely need to type index CREATE statements
from scratch. Instead, you can use the friendly GUI screens that enable you to specify
the common index options, and then you can generate the T-SQL script that can be
executed to create the index.
Additional syntax options (not listed here) relate to backward compatibility and the
creation of indexes on XML columns. Refer to Chapter 47, “Using XML in SQL Server
2008,” and the SQL Server Books Online documentation for further details.
Creating Indexes with SSMS
SQL Server 2008 has many options for creating indexes within SSMS. You can create

indexes within SSMS via the Database Engine Tuning Advisor, database diagrams, the
Table Designer, and several places within the Object Explorer. The means available from
the Object Explorer are the simplest to use and are the focus of this section. The other
options are discussed in more detail in related chapters of this book.
Index creation in the Object Explorer is facilitated by the New Index screen. You can
launch this screen from SMSS by expanding the database tree in the Object Explorer and
navigating to the Indexes node of the table that you want to add the index to. Then you
right-click the Indexes node and select New Index. A screen like the one shown in Figure
25.3 is displayed.
The name and options that are populated in Figure 25.3 are based on the person index
created in the previous T-SQL section. The LastName, FirstName, and MiddleName columns
were selected and added as part of this new index by clicking the Add button, which
displays a screen with all the columns in the table that are available for the index. You
simply select the column(s) you want to include on the index. This populates the Index
Key Columns grid on the default General page.
You can select other options for an index by changing the Select a Page options available
on the top-left side of the New Index screen. The Options, Included Columns, Storage,
Spatial, and Filter pages each provide a series of options that relate to the corresponding
category and are utilized when creating the index.
Of particular interest is the Included Columns page. This page allows you to select
columns that you want to include in the leaf-level pages of the index but don’t need as
part of the index key. For example, you could consider using included columns if you
have a critical query that often selects last name, first name, and address from a table but
uses only the last name and first name as search arguments in the
WHERE clause. This may
be a situation in which you would want to consider the use of a covering index that places
all the referenced columns from the query into a nonclustered index. In the case of our
critical query, the address column can be added to the index as an included column. It is
not included in the index key, but it is available in the leaf-level pages of the index so that
the additional overhead of going to the data pages to retrieve the address is not needed.

CHAPTER 25 Creating and Managing Indexes
Download from www.wowebook.com
ptg
801
FIGURE 25.3 Using Object Explorer to create indexes.
Creating Indexes
25
The Spatial and Filter option pages are new to SQL Server 2008. The Spatial page can be
used to create spatial indexes on a column that is defined as a spatial data type; that is
either type geometry or geography. If your table contains a column of this data type, you
can use the Index Type drop-down to change the index type to Spatial. After this is done,
you can add a column that is defined as a spatial data type to the index. Finally, you can
select the Spatial option page, as shown in Figure 25.4, that allows you to fully define a
spatial index. The meaning of the parameters on this page are beyond the scope of this
chapter and are discussed in more detail in Chapter 34.
The Filter option page allows you to define a filtering criterion to limit the rows that are
included in the index. The page, shown in Figure 25.5, is relatively simple with a single
input area that contains your filtering criterion. This criterion is basically the contents of a
WHERE clause that is similar to what you would use in a query window to filter the rows in
your result. The filter expression shown in Figure 25.5 was defined for an index on the
PersonType column, which is found in the Person.Person table of the
AdventureWorks2008 sample database. Many of the rows in this table have a PersonType
value equal to ’IN’ so a filtered index that does not include rows with this value will
dramatically reduce the size of the index and make searches on values other than ’IN’
relatively fast.
After selecting all the options you want for your index via the New Index screen, you have
several options for actually creating the index. You can script the index, schedule the
index creation for a later time, or simply click OK to allow the New Index screen to add
the index immediately. As mentioned earlier, it is a good idea to use this New Index
Download from www.wowebook.com

ptg
802
CHAPTER 25 Creating and Managing Indexes
FIGURE 25.4 Spatial Index options page.
FIGURE 25.5 Filter Index options page.
Download from www.wowebook.com
ptg
803
Managing Indexes
screen to specify the index options, and then you can click the Script button to generate
all the T-SQL statements needed to create the index. You can then save this script to a file
to be used for generating a database build script or for maintaining a record of the indexes
defined in a database.
Managing Indexes
There are two different aspects to index management. The first aspect is the management
of indexes by the SQL Server database engine. Fortunately, the engine does a good job of
managing the indexes internally so that limited manual intervention is required. This is
predicated on a well-designed database system and the use of SQL Server features, such as
automatic updates to distribution statistics.
The other aspect of index management typically comes into play when performance issues
arise. Index adjustments and maintenance of these indexes make up the bulk of this effort.
Managing Indexes with T-SQL
One of the T-SQL features available with SQL Server 2008 is the ALTER INDEX statement.
This statement simplifies many of the tasks associated with managing indexes. Index oper-
ations such as index rebuilds and changes to fill factor that were previously handled with
DBCC commands are now available via the ALTER INDEX statement. The basic syntax for
ALTER INDEX is as follows:
ALTER INDEX {index_name | ALL}
ON [{database_name.[schema_name]. | schema_name.}]
{table_or_view_name}

{ REBUILD [WITH(<rebuild_index_option>[, n])]
| REORGANIZE [ WITH( LOB_COMPACTION = {ON | OFF})]
| DISABLE
| SET (<set_index_option>[, n]) }
Let’s look at a few examples that demonstrate the power of the ALTER INDEX statement.
The first example simply rebuilds the primary key index on the Production.Product table:
ALTER INDEX [PK_Product_ProductID] ON [Production].[Product] REBUILD
This offline operation is equivalent to the DBCC DBREINDEX command. The specified index
is dropped and re-created, removing all fragmentation from the index pages. This is done
dynamically, without the need to drop and re-create constraints that reference any of the
affected indexes. If it is run on a clustered index, the data pages of the table are defrag-
mented as well. If you specify the ALL option for the ALTER INDEX command, all indexes
as well as the data pages of the table (if the table has a clustered index) are defragmented.
25
Download from www.wowebook.com