17.06.2013 Views

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 9: <strong>SQL</strong> <strong>Server</strong> Storage and Index Structures<br />

That being said, database fragmentation does have its good side — OLTP systems positively love fragmentation.<br />

Any guesses as to why? Page splits. Pages that don’t have much data in them can have data<br />

inserted with little or no risk of page splits.<br />

So, high fragmentation equates to poor read performance, but it also equates to excellent insert performance.<br />

As you might expect, this also means that OLAP systems really don’t like fragmentation.<br />

Identifying Fragmentation vs. Likelihood of Page Splits<br />

292<br />

<strong>SQL</strong> <strong>Server</strong> provides a special metadata function called sys.dm_db_index_physical_stats that is<br />

particularly useful in helping us identify just how full the pages and extents in our database are. We can<br />

then use that information to make some decisions about what we want to do to maintain our database.<br />

sys.dm_db_index_physical_stats is what is called a table valued function (we’ll learn more about<br />

these in Chapter 13). In short, this means that while it’s a function, you can use it much as you would a<br />

table, which means that you can actually stick WHERE conditions on it and other similar constructs. The<br />

syntax for the function itself is pretty simple:<br />

sys.dm_db_index_physical_stats (<br />

{ | NULL | 0 | DEFAULT }<br />

, { | NULL | 0 | DEFAULT }<br />

, { | NULL | 0 | -1 | DEFAULT }<br />

, { | NULL | 0 | DEFAULT }<br />

, { | NULL | DEFAULT }<br />

)<br />

Note that it is demanding the rather non-intuitive ids as input values rather than the logical names that<br />

you might be more used to. Fortunately, <strong>SQL</strong> <strong>Server</strong> gives us a number of functions that work on returning<br />

the proper id for a given object on the server or in the database.<br />

As an example of how to use this, let’s get the all information index information from the Sales<br />

.SalesOrderDetail table. Since we’ve said we want all the indexes in the table, we just need the id for<br />

the table — not any individual indexes. Since the function is table valued, we need to write a query to<br />

return the results from the function. For example:<br />

DECLARE @db_id SMALLINT;<br />

DECLARE @object_id INT;<br />

SET @db_id = DB_ID(N'AdventureWorks<strong>2008</strong>');<br />

SET @object_id = OBJECT_ID(N'AdventureWorks<strong>2008</strong>.Sales.SalesOrderDetail');<br />

SELECT database_id, object_id, index_id, index_depth, avg_fragmentation_in_percent,<br />

page_count<br />

FROM sys.dm_db_index_physical_stats(@db_id,@object_id,NULL,NULL,NULL);

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!