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.

works only if tempdb is on a separate physical drive from your database file; otherwise, the change is<br />

only in name, and the competition for I/O is still a factor.<br />

ONLINE<br />

If you’re going to use SORT_IN_TEMPDB, make sure that there is enough space in tempdb for large<br />

files.<br />

Setting this to ON forces the table to remain available for general access, and does not create any locks<br />

that block users from the index and/or table. By default, the full index operation will grab the locks<br />

(eventually a table lock) needed for full and efficient access to the table. The side effect, however, is that<br />

your users are blocked out. (Yeah, it’s a paradox; you’re likely building an index to make the database<br />

more usable, but you essentially make the table unusable while you do it.)<br />

Now, you’re probably thinking something like: “Oh, that sounds like a good idea — I’ll do that every<br />

time so my users are unaffected.” Poor thinking. Keep in mind that any index construction like that is<br />

probably a very I/O-intensive operation, so it is affecting your users one way or the other. Now, add that<br />

there is a lot of additional overhead required in the index build for it to make sure that it doesn’t step on<br />

the toes of any of your users. If you let <strong>SQL</strong> <strong>Server</strong> have free reign over the table while it’s building the<br />

index, then the index will be built much faster, and the overall time that the build is affecting your system<br />

will be much smaller.<br />

ONLINE index operations are supported only in the Enterprise Edition of <strong>SQL</strong> <strong>Server</strong>. You can execute<br />

the index command with the ONLINE directive in other editions, but it will be ignored, so don’t be surprised<br />

if you use ONLINE and find your users still being blocked out by the index operation if you’re<br />

using a lesser edition of <strong>SQL</strong> <strong>Server</strong>.<br />

ALLOW ROW/PAGE LOCKS<br />

This is a longer term directive than ONLINE and is a very, very advanced topic. For purposes of this book<br />

and taking into consideration how much we’ve introduced so far on locking, let’s stick with a pretty simple<br />

explanation.<br />

Through much of the book thus far, we have repeatedly used the term “lock.” As explained early on,<br />

this is something of a placeholder to avoid conflicts in data integrity. The ALLOW settings we’re looking at<br />

here determine whether this index will allow row or page locks or not. This falls under the heading of<br />

extreme performance tweak.<br />

MAXDOP<br />

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

This is overriding the system setting for the maximum degree of parallelism for purposes of building<br />

this index. Parallelism is not something I talk about elsewhere in this book, so we’ll give you a mini-dose<br />

of it here.<br />

In short, the degree of parallelism is how many processes are put to use for one database operation (in<br />

this case, the construction of an index). There is a system setting called the max degree of parallelism<br />

that allows you to set a limit on how many processors per operation. The MAXDOP option in the index<br />

creation options allows you to set the degree of parallelism to be either higher or lower than the base<br />

system setting, as you deem appropriate.<br />

281

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

Saved successfully!

Ooh no, something went wrong!