<html>਍㰀戀漀搀礀㸀ഀഀ
਍㰀栀㄀㸀匀漀洀攀 匀儀䰀 匀攀爀瘀攀爀 ㈀　　㔀 ⼀ ㈀　　㠀 瀀攀爀昀漀爀洀愀渀挀攀 挀漀渀猀椀搀攀爀愀琀椀漀渀猀⸀㰀⼀栀㄀㸀ഀഀ
਍㰀䈀㸀嘀攀爀猀椀漀渀㰀⼀䈀㸀ऀ    㨀 ㈀⸀㤀㰀戀爀㸀ഀഀ
<B>Date</B>		: 17/08/2010<br>਍㰀䈀㸀䈀礀㰀⼀䈀㸀ऀऀ    㨀 䄀氀戀攀爀琀 瘀愀渀 搀攀爀 匀攀氀㰀戀爀㸀ഀഀ
<B>Type of doc</B>	: It's just a few notes on SQL Server performance in simple words. It's no more than just "entry level".<br>਍㰀䈀㸀䘀漀爀 眀栀漀㰀⼀䈀㸀                㨀 䘀漀爀 愀渀礀漀渀攀 眀栀漀 氀椀欀攀猀 愀 猀栀漀爀琀 漀爀椀攀渀琀愀琀椀漀渀 漀渀 琀栀攀 猀甀戀樀攀挀琀⸀ 䈀甀琀 昀漀爀 攀砀瀀攀爀椀攀渀挀攀搀 䐀䈀䄀✀猀Ⰰ 椀琀✀猀 琀漀漀 猀椀洀瀀氀攀⸀㰀戀爀㸀ഀഀ
਍㰀栀爀⼀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍㰀䈀㸀䌀漀渀琀攀渀琀猀㨀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀　⸀ 倀爀攀昀愀挀攀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<B>Chapter 1. How to "quickly" determine if you have Disk I/O problems.</B><br> ਍ⴀ ㄀⸀㄀ 唀猀攀 漀昀 琀栀攀 ∀昀渀开瘀椀爀琀甀愀氀昀椀氀攀猀琀愀琀∀ 昀甀渀挀琀椀漀渀㰀戀爀㸀ഀഀ
- 1.2 Using "System Monitor"/"Performance Monitor" Disk counters with respect to Disk IO<br>਍ⴀ ㄀⸀㌀ 䤀渀昀漀爀洀愀琀椀漀渀 昀爀漀洀 琀栀攀 ∀猀礀猀⸀搀洀开漀猀开眀愀椀琀开猀琀愀琀猀∀ 瘀椀攀眀Ⰰ 眀椀琀栀 爀攀猀瀀攀挀琀 琀漀 䤀伀 愀渀搀 䐀椀猀欀 䤀伀㰀戀爀㸀ഀഀ
<B>Chapter 2. Some remarks on Virtual Machines and a large, active, SQL Server environment.</B><br>਍㰀䈀㸀䌀栀愀瀀琀攀爀 ㌀⸀ 匀漀洀攀 爀攀洀愀爀欀猀 愀戀漀甀琀 愀 㘀㐀 戀椀琀 伀匀 愀渀搀 㘀㐀 戀椀琀 匀儀䰀 匀攀爀瘀攀爀 攀搀椀琀椀漀渀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<B>Chapter 4. Indexes and Index tuning.</B><br>਍ⴀ 㐀⸀㄀ 匀栀漀爀琀 爀攀挀愀瀀 漀渀 椀渀搀攀砀攀猀 㰀戀爀㸀ഀഀ
- 4.2 Dynamic management views and functions<br>਍ⴀ 㐀⸀㌀ 䴀漀瘀攀 愀 栀漀琀猀瀀漀琀 椀渀搀攀砀 琀漀 愀渀漀琀栀攀爀 䘀椀氀攀最爀漀甀瀀㰀戀爀㸀ഀഀ
- 4.4 Quick check on the effectiveness of your indexes<br>਍ⴀ 㐀⸀㔀 䠀漀眀 琀漀 刀攀漀爀最愀渀椀稀攀 愀渀搀 刀攀戀甀椀氀搀 䤀渀搀攀砀攀猀㰀戀爀㸀ഀഀ
- 4.6 Remarks on Statistics<br>਍㰀䈀㸀䌀栀愀瀀琀攀爀 㔀⸀ 䠀漀眀 琀漀 搀攀琀攀爀洀椀渀攀 椀昀 礀漀甀 栀愀瘀攀 愀 䌀倀唀 瀀爀漀戀氀攀洀 ⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
- 5.1 Using "System Monitor"/"Performance Monitor" <br>਍ⴀ 㔀⸀㈀ 唀猀椀渀最 琀栀攀 䐀礀渀愀洀椀挀 䴀愀渀愀最攀洀攀渀琀 嘀椀攀眀猀 愀渀搀 䘀甀渀挀琀椀漀渀猀㰀戀爀㸀ഀഀ
<B>Chapter 6. Allocation Unit and Partition Alignment.</B><br>਍㰀䈀㸀䌀栀愀瀀琀攀爀 㜀⸀ 倀氀愀挀攀洀攀渀琀 漀昀 漀戀樀攀挀琀猀 漀渀 䘀椀氀攀最爀漀甀瀀猀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
- 7.1 The "traditional" non-partitioning approach<br>਍ⴀ 㜀⸀㈀ 倀愀爀琀椀琀椀漀渀椀渀最 琀愀戀氀攀猀 愀渀搀 椀渀搀攀砀攀猀㰀戀爀㸀ഀഀ
<B>Chapter 8. Other remarks on several subjects (like tempdb, datatypes etc..)</B><br>਍㰀䈀㸀䌀栀愀瀀琀攀爀 㤀⸀ 匀漀洀攀 爀攀愀氀 眀漀爀氀搀 挀愀猀攀猀Ⰰ 搀攀猀挀爀椀戀椀渀最 猀漀洀攀眀栀愀琀 洀漀爀攀 挀漀洀瀀氀攀砀 瀀攀爀昀漀爀洀愀渀挀攀 瀀爀漀戀氀攀洀猀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<B>Chapter 10. A few links to recommended technical articles</B><br>਍㰀戀爀㸀ഀഀ
<br>਍㰀栀㈀㸀　⸀ 倀爀攀昀愀挀攀㰀⼀栀㈀㸀ഀഀ
਍吀栀椀猀 椀猀 愀 猀栀漀爀琀 渀漀琀攀Ⰰ 椀渀琀爀漀搀甀挀椀渀最 猀漀洀攀 戀愀猀椀挀 挀漀渀猀椀搀攀爀愀琀椀漀渀猀 漀渀 匀儀䰀 匀攀爀瘀攀爀 瀀攀爀昀漀爀洀愀渀挀攀⸀㰀戀爀㸀ഀഀ
<br>਍䤀昀 礀漀甀 愀爀攀 愀渀 攀砀瀀攀爀椀攀渀挀攀搀 匀儀䰀 匀攀爀瘀攀爀 䐀䈀䄀Ⰰ 琀栀椀猀 渀漀琀攀 椀猀 瀀爀漀戀愀戀氀礀 渀漀琀 昀漀爀 礀漀甀 ⠀戀甀琀 礀漀甀 愀爀攀 挀攀爀琀愀椀渀氀礀 椀渀瘀椀琀攀搀 琀漀 爀攀愀搀 漀渀℀⤀⸀㰀戀爀㸀ഀഀ
<br>਍䤀渀猀琀攀愀搀Ⰰ 椀昀 礀漀甀 㰀䤀㸀樀甀猀琀 欀渀漀眀 礀漀甀 眀愀礀 愀爀漀甀渀搀 椀渀 匀儀䰀 匀攀爀瘀攀爀㰀⼀䤀㸀Ⰰ 愀渀搀 礀漀甀 㰀䤀㸀樀甀猀琀㰀⼀䤀㸀 眀愀渀琀 琀漀 欀渀漀眀 猀漀洀攀 漀昀 琀栀攀 洀漀爀攀 椀洀瀀漀爀琀愀渀琀㰀戀爀㸀ഀഀ
stuff on performance, then you are at the right place.<br>਍䈀甀琀⸀⸀Ⰰ 爀攀洀攀洀戀攀爀Ⰰ 琀栀椀猀 渀漀琀攀 椀猀 猀甀爀攀氀礀 渀漀 洀漀爀攀 琀栀愀渀 愀 氀椀最栀琀眀攀椀最栀琀 搀椀猀挀甀猀猀椀漀渀⸀㰀戀爀㸀ഀഀ
<br>਍ഀഀ
<B>And a very important remark should be made right at the start: <I>we are not going to discuss "Query Design and Tuning"</I></B><br>਍㰀戀爀㸀ഀഀ
There are many things which are very important to improve SQL server performance. Like for example, to place<br>਍吀愀戀氀攀 搀愀琀愀 愀渀搀 䤀渀搀攀砀攀猀 漀渀 搀椀昀昀攀爀攀渀琀 䐀椀猀欀 嘀漀氀甀洀攀猀 ⠀搀椀昀昀攀爀攀渀琀 ∀猀瀀椀渀搀氀攀猀∀⤀Ⰰ 琀栀攀爀攀 愀爀攀 洀攀洀漀爀礀 挀漀渀猀椀搀攀爀愀琀椀漀渀猀Ⰰ㰀戀爀㸀ഀഀ
there are "smart" choiches on the datatypes, considerations if you need partitioning etc.. etc..<br>਍伀渀攀 瘀攀爀礀 瀀愀爀愀洀漀甀渀琀 猀甀戀樀攀挀琀 椀渀 瀀攀爀昀漀爀洀愀渀挀攀 挀漀渀猀椀搀攀爀愀琀椀漀渀猀 ⠀愀琀 愀氀氀 䐀愀琀愀戀愀猀攀 䔀渀最椀渀攀猀 氀椀欀攀 伀爀愀挀氀攀Ⰰ 匀儀䰀 匀攀爀瘀攀爀 攀琀挀⸀⸀⤀Ⰰ 㰀戀爀㸀ഀഀ
is "Query Design & Tuning". Now, this note will not address that subject.<br> ਍㰀戀爀㸀ഀഀ
What is meant by Query Design and Tuning ? <br>਍㰀戀爀㸀ഀഀ
Ultimately, Users or applications, send SQL Statements to the database engine.<br>਍㰀戀爀㸀ഀഀ
For the sake of argument, let's consider some complex SQL statement. It could consist of, say,<br> ਍㰀䈀㸀㈀　 漀爀 猀漀 渀攀猀琀攀搀 樀漀椀渀猀㰀⼀䈀㸀 漀昀 瀀漀猀猀椀戀氀礀 愀 洀椀砀 漀昀 猀洀愀氀氀 琀愀戀氀攀猀Ⰰ 氀愀爀最攀 琀愀戀氀攀猀Ⰰ 愀渀搀 瀀漀猀猀椀戀氀礀 㰀䤀㸀瘀攀爀礀㰀⼀䤀㸀 氀愀爀最攀 琀愀戀氀攀猀⸀㰀戀爀㸀ഀഀ
<br>਍一漀眀Ⰰ 琀栀攀爀攀 愀爀攀 洀愀渀礀 爀漀愀搀猀 琀栀愀琀 氀攀愀搀 琀漀 琀栀攀 挀椀琀礀 漀昀 刀漀洀攀Ⰰ 愀渀搀 猀漀洀攀 漀昀 琀栀攀洀 愀爀攀 攀愀猀礀 琀漀 琀爀愀瘀攀氀Ⰰ㰀戀爀㸀ഀഀ
while others are difficult and lengthy. The same is true for how someone designs a query and how it will be executed.<br> ਍䤀琀 挀漀甀氀搀 戀攀 愀 瘀攀爀礀 猀洀愀爀琀 漀渀攀Ⰰ 甀猀椀渀最 琀栀攀 戀攀猀琀 愀渀搀 昀愀猀琀攀猀琀 愀挀挀攀猀猀瀀愀琀栀猀Ⰰ 漀爀 椀琀 洀椀最栀琀 戀攀 猀漀 琀攀爀爀椀戀氀礀 椀氀氀ⴀ搀攀猀椀最渀攀搀Ⰰ 㰀戀爀㸀ഀഀ
that the database Server just whished someone pressed the shutdown button.<br>਍㰀戀爀㸀ഀഀ
So, query design and tuning, is extremely important ! Yet, we don't mentioned it in this note.<br>਍伀昀挀漀甀爀猀攀Ⰰ 㰀䈀㸀漀渀攀 攀氀攀洀攀渀琀㰀⼀䈀㸀 椀渀 儀甀攀爀礀 吀甀渀椀渀最 㰀䈀㸀眀椀氀氀㰀⼀䈀㸀 戀攀 愀搀搀爀攀猀猀攀搀Ⰰ 愀渀搀 琀栀愀琀 椀猀 搀攀琀攀爀洀椀渀椀渀最 琀栀攀 戀攀猀琀 甀猀攀 漀昀 椀渀搀攀砀攀猀⸀㰀戀爀㸀ഀഀ
But, the subject on how <I>to best actually write Queries, is not.</I>਍䄀渀搀 戀攀氀椀攀瘀攀 洀攀Ⰰ 椀琀 椀猀 愀 瘀攀爀礀 椀洀瀀漀爀琀愀渀琀 猀甀戀樀攀挀琀⸀㰀戀爀㸀 ഀഀ
If some application uses horribly bad designed SQL Statements, it's really very hard to fight that.<br>਍㰀戀爀㸀ഀഀ
Note: you might not even be in control on Query Design at all. Suppose you use a "third-party" application (which is very likely).<br> ਍吀栀攀渀 椀琀 樀甀猀琀 眀漀爀欀猀 琀栀攀 眀愀礀 琀栀漀猀攀 搀攀瘀攀氀漀瀀攀爀猀 挀爀攀愀琀攀搀 椀琀⸀ 䈀甀琀 攀瘀攀渀 琀栀攀渀 礀漀甀 挀愀渀 ∀挀愀瀀琀甀爀攀∀ 琀栀攀 匀儀䰀 猀琀愀琀攀洀攀渀琀猀Ⰰ 昀漀爀 攀砀愀洀瀀氀攀 甀猀椀渀最㰀戀爀㸀ഀഀ
a 'tracing tool' (the profiler), or by using some smart queries on the <B>Dynamic Management views and functions</B>.<br>਍吀栀攀渀Ⰰ 椀渀 瀀爀椀渀挀椀瀀氀攀Ⰰ 礀漀甀 挀愀渀 栀漀氀搀 琀栀攀 爀攀猀甀氀琀猀 琀漀 琀栀漀猀攀 搀攀瘀攀氀漀瀀攀爀猀Ⰰ 愀氀漀渀最 眀椀琀栀 爀攀挀漀洀洀攀渀搀愀琀椀漀渀猀⸀㰀戀爀㸀ഀഀ
But, yes, that might be a bit of an "optimistic" view on matters.<br>਍伀渀 琀栀攀 漀琀栀攀爀 栀愀渀搀Ⰰ 椀昀 礀漀甀 栀愀瘀攀 ∀椀渀琀攀爀渀愀氀∀ 搀攀瘀攀氀漀瀀攀爀猀Ⰰ 礀漀甀 挀漀甀氀搀 挀爀攀愀琀攀 挀漀搀攀 昀漀爀 琀栀攀洀 椀渀 ∀猀琀漀爀攀搀 瀀爀漀挀攀搀甀爀攀猀∀ ⠀眀漀爀欀猀 昀愀猀琀⤀Ⰰ㰀戀爀㸀ഀഀ
or make recommendations for their query design<br>਍㰀戀爀㸀ഀഀ
Could this note then <I>has something to say at all?</I><br>਍䐀攀昀椀渀椀琀攀氀礀℀ 吀栀攀爀攀 愀爀攀 猀漀 洀愀渀礀 挀漀渀猀椀搀攀爀愀琀椀漀渀猀 漀渀 匀儀䰀 匀攀爀瘀攀爀 瀀攀昀漀爀洀愀渀挀攀⸀㰀戀爀㸀ഀഀ
<br>਍㰀䤀㸀䈀攀氀漀眀Ⰰ 礀漀甀 眀椀氀氀 昀椀渀搀 愀戀漀甀琀 㠀 挀漀渀猀椀搀攀爀愀琀椀漀渀猀Ⰰ 椀渀 㠀 挀栀愀瀀琀攀爀猀Ⰰ 眀栀椀挀栀 愀爀攀 最攀渀攀爀愀氀氀礀 瘀椀攀眀攀搀 琀漀 戀攀 ∀爀攀氀攀瘀愀渀琀∀⸀⸀⸀⸀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍㰀栀㈀㸀䌀栀愀瀀琀攀爀 ㄀⸀ 䠀漀眀 琀漀 ∀焀甀椀挀欀氀礀∀ 搀攀琀攀爀洀椀渀攀 椀昀 礀漀甀 栀愀瘀攀 䐀椀猀欀 䤀⼀伀 瀀爀漀戀氀攀洀猀⸀㰀⼀栀㈀㸀ഀഀ
਍䴀愀渀礀 氀攀愀爀渀攀搀 瀀攀漀瀀氀攀 眀椀氀氀 琀攀氀氀 甀猀Ⰰ 琀栀愀琀 愀 㰀䤀㸀最漀漀搀 瀀攀爀昀漀爀洀愀渀挀攀 洀攀愀猀甀爀攀洀攀渀琀㰀⼀䤀㸀Ⰰ 猀栀漀甀氀搀 愀氀眀愀礀猀 挀漀渀猀椀搀攀爀 挀瀀甀Ⰰ 琀栀攀 搀椀猀欀猀甀戀猀礀猀琀攀洀猀Ⰰ㰀戀爀㸀ഀഀ
memory, the network subsystem, and all relevant specific SQL server counters.<br>਍吀栀愀琀 椀猀 琀爀甀攀⸀ 䈀甀琀 椀琀 搀漀攀猀 渀漀琀 洀攀愀渀 琀栀愀琀 礀漀甀 挀愀渀✀琀 昀漀挀甀猀 昀漀爀 愀 眀栀椀氀攀 漀渀 樀甀猀琀 漀渀攀 瀀愀爀琀椀挀甀氀愀爀 猀甀戀猀礀猀琀攀洀 漀渀氀礀⸀㰀戀爀㸀ഀഀ
If we do that, the only thing we should beware of, is that we should not jump to conclusions right away. Ok, that's fair enough.<br>਍㰀戀爀㸀ഀഀ
Still, the following gives us very important clues on the status/statistics of Disk IO.<br>਍㰀漀氀㸀ഀഀ
<li> A few "dynamic management views and functions" in SQL Server, can show you quickly whether Disk IO is good or bad, or਍猀漀洀攀琀栀椀渀最 椀渀 戀攀琀眀攀攀渀⸀ 㰀戀爀㸀ഀഀ
The <B>cause</B> of poor Disk IO, could originate from a Database design which is not OK (like not having seperated tables and indexes),<br>਍㰀䤀㸀㰀唀㸀漀爀㰀⼀䤀㸀㰀⼀唀㸀Ⰰ 椀渀搀攀攀搀 琀栀攀 搀椀猀欀猀甀戀猀礀猀琀攀洀 挀愀渀渀漀琀 欀攀攀瀀 甀瀀 眀椀琀栀 琀栀攀 搀攀洀愀渀搀猀⸀㰀戀爀㸀㰀⼀氀椀㸀ഀഀ
<li> Also, a number of counters of "System Monitor" (or Performance Monitor) in NT, will show you quickly the same thing.</li>਍㰀⼀漀氀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
<h3>1.1 The "remarkable" <B>fn_virtualfilestats</B> function </h3>਍ഀഀ
One remarkable function, is the <B>fn_virtualfilestats</B> function. You can use it from the "Query Window" (or Query Analyzer)<br>਍眀栀椀挀栀 礀漀甀 挀愀渀 猀琀愀爀琀 昀爀漀洀 ∀匀儀䰀 匀攀爀瘀攀爀 䴀愀渀愀最攀洀攀渀琀 匀琀甀搀椀漀∀⸀㰀戀爀㸀ഀഀ
It returns I/O statistics for database files, including log files. To use it, it can be as easy as this statement:<br>਍㰀戀爀㸀ഀഀ
<B>SELECT * FROM fn_virtualfilestats(null, null)</B><br>਍㰀戀爀㸀ഀഀ
<br>਍吀栀攀 昀甀渀挀琀椀漀渀 琀愀欀攀猀 琀眀漀 瀀愀爀愀洀攀琀攀爀猀⸀ 䤀昀 礀漀甀 氀攀愀瘀攀 琀栀攀洀 愀猀 ∀渀甀氀氀∀Ⰰ 礀漀甀 眀椀氀氀 猀攀攀 䤀伀 猀琀愀琀椀猀琀椀挀猀 漀渀 愀氀氀 昀椀氀攀猀 昀爀漀洀 愀氀氀 搀愀琀愀戀愀猀攀猀⸀㰀戀爀㸀ഀഀ
That ofcourse, could already be good enough. Below, you see an example of the output.<br>਍㰀戀爀㸀ഀഀ
<img src="sql1.jpg" align="left"/>਍㰀戀爀㸀ഀഀ
Before we discuss this very interresting output, here is some more info on the function itself.਍䤀昀 礀漀甀 眀愀渀琀 琀漀 甀猀攀 瀀愀爀愀洀攀琀攀爀猀 ⠀昀漀爀 愀 猀栀漀爀琀攀爀 氀椀猀琀⤀Ⰰ 琀栀攀渀 礀漀甀 猀栀漀甀氀搀 欀渀漀眀 琀栀愀琀ഀഀ
the first parameter is the "database id" (dbid), and the second one is the "file id" (fileId).<br>਍吀栀椀猀 眀愀礀Ⰰ 礀漀甀 挀愀渀 ∀昀漀挀甀猀 椀渀∀ 琀漀 愀 瀀愀爀琀椀挀甀氀愀爀 搀愀琀愀戀愀猀攀 愀渀搀⼀漀爀 瀀愀爀琀椀挀甀氀愀爀 昀椀氀攀⸀㰀戀爀㸀ഀഀ
<br>਍䤀琀✀猀 攀愀猀礀 琀漀 最攀琀 愀 氀椀猀琀 漀昀 搀愀琀愀戀愀猀攀 渀愀洀攀猀 愀渀搀 搀愀琀愀戀愀猀攀 椀搀✀猀 甀猀椀渀最㨀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀猀攀氀攀挀琀 ⨀ 昀爀漀洀 猀礀猀⸀搀愀琀愀戀愀猀攀猀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍䰀椀欀攀眀椀猀攀Ⰰ 椀琀✀猀 攀愀猀礀 琀漀 最攀琀 愀 氀椀猀琀 漀昀 昀椀氀攀渀愀洀攀猀 愀渀搀 昀椀氀攀 椀搀✀猀 昀漀爀 愀 瀀愀爀琀椀挀甀氀愀爀 搀愀琀愀戀愀猀攀Ⰰ 甀猀椀渀最㨀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀甀猀攀 搀愀琀愀戀愀猀攀开渀愀洀攀开漀昀开礀漀甀爀开椀渀琀攀爀攀猀琀㰀戀爀㸀ഀഀ
select * from sys.database_files</B><br>਍㰀戀爀㸀ഀഀ
Now let's turn our attention to the output. As you can see, you find a number of very interesting columns in the resultset.<br>਍䠀攀爀攀 愀爀攀 愀 昀攀眀 椀洀瀀漀爀琀愀渀琀 漀渀攀猀㨀㰀戀爀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
<B>BytesRead: Number of bytes read issued on the file.<br>਍䈀礀琀攀猀圀爀椀琀琀攀渀㨀 一甀洀戀攀爀 漀昀 戀礀琀攀猀 眀爀椀琀琀攀渀 洀愀搀攀 漀渀 琀栀攀 昀椀氀攀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍㰀䤀㸀一漀琀攀 琀栀愀琀 礀漀甀 挀愀渀 攀愀猀椀氀礀 椀搀攀渀琀椀昀礀 ∀栀漀琀猀瀀漀琀 昀椀氀攀猀∀ 昀爀漀洀 琀栀漀猀攀 瘀愀氀甀攀猀⸀⸀⸀⠀℀⤀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀䤀漀匀琀愀氀氀刀攀愀搀䴀匀㨀 吀漀琀愀氀 愀洀漀甀渀琀 漀昀 琀椀洀攀Ⰰ 椀渀 洀椀氀氀椀猀攀挀漀渀搀猀Ⰰ 琀栀愀琀 甀猀攀爀猀 眀愀椀琀攀搀 昀漀爀 琀栀攀 爀攀愀搀 䤀⼀伀猀 琀漀 挀漀洀瀀氀攀琀攀 漀渀 琀栀攀 昀椀氀攀⸀㰀戀爀㸀ഀഀ
IoStallWriteMS: Total time, in milliseconds, that users waited for the write I/Os to complete on the file.</B><br>਍㰀戀爀㸀ഀഀ
The last two values, thus represent the "stalls" on reads and writes. Obviously, they should take on small values.<br>਍䤀昀 礀漀甀 猀攀攀 栀椀最栀 瘀愀氀甀攀猀Ⰰ 䤀琀 搀漀攀猀 渀漀琀 愀甀琀漀洀愀琀椀挀愀氀氀礀 洀攀愀渀猀 琀栀愀琀 礀漀甀 栀愀瘀攀 愀 ∀戀愀搀∀ 䐀椀猀欀猀甀戀猀礀猀琀攀洀 搀攀猀椀最渀⸀㰀戀爀㸀ഀഀ
Ofcourse, that could be true, but also other configurations can contribute to the effect.<br>਍䘀漀爀 琀栀攀 氀愀琀琀攀爀Ⰰ 礀漀甀 洀椀最栀琀 琀栀椀渀欀 漀昀 氀愀爀最攀 琀愀戀氀攀猀 愀渀搀 氀愀爀最攀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀 眀栀椀挀栀 愀爀攀 猀琀漀爀攀搀 椀渀 琀栀攀 㰀䤀㸀猀愀洀攀㰀⼀䤀㸀 昀椀氀攀Ⰰ㰀戀爀㸀ഀഀ
and thus a lot of <I>contention</I> takes place, which can result in the "stalls" observed.<br>਍㰀戀爀㸀ഀഀ
So, the output of the "fn_virtualfilestats" function, cannot lead to exact conclusions right away.<br>਍䈀甀琀㨀㰀戀爀㸀ഀഀ
<ol>਍㰀氀椀㸀夀漀甀 挀愀渀 椀搀攀渀琀椀昀礀 昀椀氀攀猀 眀栀椀挀栀 愀爀攀 ∀栀漀琀猀瀀漀琀猀∀Ⰰ 琀栀甀猀 眀栀椀挀栀 栀愀瘀攀 愀 氀愀爀最攀 渀甀洀戀攀爀 漀昀 爀攀愀搀猀 愀渀搀⼀漀爀 眀爀椀琀攀猀⸀㰀戀爀㸀ഀഀ
This could mean that you must move a (few) "active" table(s) or index(es) to a new file on another disk.</li>਍㰀氀椀㸀夀漀甀 椀搀攀渀琀椀昀礀 昀椀氀攀猀 眀栀攀爀攀 ∀猀琀愀氀氀猀∀ 琀愀欀攀猀 瀀氀愀挀攀⸀ 吀栀椀猀 挀漀甀氀搀 洀攀愀渀 琀栀愀琀 琀栀攀 䐀椀猀欀 䤀伀 搀攀猀椀最渀 椀猀 渀漀琀 最漀漀搀 攀渀漀甀最栀Ⰰ㰀戀爀㸀ഀഀ
but that fact is not proven yet. Just as above, here too it could could mean that you must move a (few) "active" table(s) or index(es)<br>਍琀漀 愀 渀攀眀 昀椀氀攀 漀渀 愀渀漀琀栀攀爀 搀椀猀欀⸀㰀⼀氀椀㸀ഀഀ
</ol>਍ഀഀ
But if you have neatly seperated active indexes and tables, and <I>there still are many stalls</I>,<br>਍琀栀攀渀Ⰰ 椀琀 洀椀最栀琀 戀攀 愀 挀氀甀攀 琀栀愀琀 䐀椀猀欀 䤀伀 椀猀 渀漀琀 漀瀀琀椀洀愀氀氀礀 猀攀琀甀瀀⸀ 䈀甀琀Ⰰ 眀攀 搀漀 渀漀琀 樀甀洀瀀 琀漀 挀漀渀挀氀甀猀椀漀渀猀 礀攀琀℀㰀戀爀㸀ഀഀ
<br>਍䤀渀 漀甀爀 攀砀愀洀瀀氀攀Ⰰ 眀攀 栀愀瘀攀 猀攀攀渀 愀 䐀椀猀欀 䤀伀 瀀爀漀戀氀攀洀⸀ 䈀甀琀 椀琀 挀漀甀氀搀 攀椀琀栀攀爀 戀攀 挀愀甀猀攀搀 戀礀 愀 戀愀搀 搀愀琀愀戀愀猀攀 搀攀猀椀最渀Ⰰ 漀爀 瀀漀猀猀椀戀氀礀 戀礀 渀漀琀 漀瀀琀椀洀愀氀氀礀㰀戀爀㸀ഀഀ
configured disks.<br>਍㰀戀爀㸀ഀഀ
You see? We already have learned a lot. But we need more information, so let's see what the next section brings us.<br>਍㰀戀爀㸀ഀഀ
<h3>1.2 Using "System Monitor"/"Performance Monitor" Disk counters with respect to Disk IO</h3>਍ഀഀ
System Monitor (or Performance Monitor as many people still call it), is a well-know NT performance measurement utility.<br>਍夀漀甀 挀愀渀 搀漀 ∀爀攀愀氀ⴀ琀椀洀攀∀ 洀攀愀猀甀爀攀洀攀渀琀猀 ⠀瘀椀攀眀椀渀最 爀攀愀氀ⴀ琀椀洀攀 最爀愀瀀栀猀⤀Ⰰ 漀爀 礀漀甀 挀愀渀 氀漀最 琀栀攀 昀椀渀搀椀渀最猀 琀漀 愀 昀椀氀攀⸀㰀戀爀㸀ഀഀ
If you want to start it, just open a command window and enter the <B>perfmon</B>command.<br>਍㰀戀爀㸀ഀഀ
With NT system monitoring tools, you will encounter the following naming structure;<br>਍ⴀ ∀漀戀樀攀挀琀猀∀ 愀爀攀 爀攀瀀爀攀猀攀渀琀愀琀椀漀渀猀 漀昀 ⠀爀攀愀氀⤀ 挀漀洀瀀漀渀攀渀琀猀 氀椀欀攀 瀀爀漀挀攀猀猀漀爀Ⰰ 瀀栀礀猀椀挀愀氀䐀椀猀欀 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
- a "counter", of an object, is a measurable metric that is exposed by that object. An object usually has many counters.<br>਍ⴀ ∀椀渀猀琀愀渀挀攀∀Ⰰ 昀漀爀 攀砀愀洀瀀氀攀Ⰰ 礀漀甀 洀椀最栀琀 栀愀瘀攀 愀渀 漀戀樀攀挀琀 氀椀欀攀 愀 ∀倀栀礀猀椀挀愀氀䐀椀猀欀∀Ⰰ 戀甀琀⸀⸀ 礀漀甀 洀椀最栀琀 栀愀瘀攀 洀甀氀琀椀瀀氀攀 搀椀猀欀猀 漀渀 礀漀甀爀 猀礀猀琀攀洀℀㰀戀爀㸀ഀഀ
So, in this example, you might pick a particular disk (like E:), or choose all of them (mostly designated by "_Total")<br>਍㰀戀爀㸀ഀഀ
So you might have as an object, a "processor", which exposes several counters like "%User Time", "%Priviledge Time", or<br>਍∀─倀爀漀挀攀猀猀漀爀 吀椀洀攀∀ ⠀眀栀椀挀栀 椀猀 唀猀攀爀 ⬀ 倀爀椀瘀椀氀攀搀最攀⤀⸀㰀戀爀㸀ഀഀ
<br>਍唀猀椀渀最 琀栀椀猀 最爀愀瀀栀椀挀愀氀 琀漀漀氀 ⠀瀀攀爀昀漀爀洀愀渀挀攀 洀漀渀椀琀漀爀⼀猀礀猀琀攀洀 洀漀渀椀琀漀爀⤀Ⰰ 椀琀✀猀 焀甀椀琀攀 攀愀猀礀 琀漀 猀攀氀攀挀琀 洀甀氀琀椀瀀氀攀 漀戀樀攀挀琀猀Ⰰ 愀渀搀 瀀攀爀 漀戀樀攀挀琀Ⰰ㰀戀爀㸀ഀഀ
select the counters that you are interrested in.<br>਍吀栀椀猀 挀栀愀瀀琀攀爀 搀攀愀氀猀 眀椀琀栀 琀栀攀 猀甀戀樀攀挀琀 漀渀 栀漀眀 礀漀甀 挀愀渀 搀椀猀挀漀瘀攀爀 䐀椀猀欀 䤀⼀伀 瀀爀漀戀氀攀洀猀Ⰰ 猀漀 眀攀 眀椀氀氀 昀漀挀甀猀 漀甀爀 愀琀琀攀渀琀椀漀渀 琀漀 琀栀愀琀 猀甀戀樀攀挀琀⸀㰀戀爀㸀ഀഀ
<br>਍䤀昀 礀漀甀 眀愀渀琀 琀漀 愀搀搀 挀漀甀渀琀攀爀猀Ⰰ 樀甀猀琀 渀愀瘀椀最愀琀攀 琀漀 琀栀攀 ∀最爀愀瀀栀∀ 猀攀挀琀椀漀渀 愀渀搀 爀椀最栀琀ⴀ挀氀椀挀欀⸀ 吀栀攀渀 礀漀甀 眀椀氀氀 猀攀攀 愀 洀攀渀甀 琀漀 愀搀搀 挀漀甀渀琀攀爀猀⸀㰀戀爀㸀ഀഀ
There objects (each with many counters) which describe your system and OS, like processor, memory etc..<br>਍䄀渀搀Ⰰ 椀昀 礀漀甀爀 匀攀爀瘀攀爀 栀愀猀 匀儀䰀 匀攀爀瘀攀爀 椀渀猀琀愀氀氀攀搀Ⰰ 琀栀攀爀攀 愀爀攀 洀愀渀礀 漀戀樀攀挀琀猀 昀爀漀洀 匀儀䰀 匀攀爀瘀攀爀 愀猀 眀攀氀氀⸀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀匀琀愀渀搀愀爀搀 猀礀猀琀攀洀 䐀椀猀欀 挀漀甀渀琀攀爀猀㨀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍䘀椀爀猀琀 氀攀琀✀猀 琀愀欀攀 愀 氀漀漀欀 愀琀 琀栀攀 猀琀愀渀搀愀爀搀 猀礀猀琀攀洀 挀漀甀渀琀攀爀猀Ⰰ 爀攀氀愀琀攀搀 琀漀 琀栀攀 䐀椀猀欀 猀甀戀猀礀猀琀攀洀⸀㰀戀爀㸀ഀഀ
Note: maybe you want to check with your sysadmin whether disk counters are "activated" (it's very likely that it is).<br>਍㰀戀爀㸀ഀഀ
As objects, you can choose "PhysicalDisk" and "LogicalDisk". Logical Disks are structures like "partitions", like an E: drive.<br>਍䤀渀 琀栀椀猀 搀椀猀挀甀猀猀椀漀渀Ⰰ 椀琀 搀漀攀猀 渀漀琀 洀愀琀琀攀爀 眀栀椀挀栀 漀渀攀 礀漀甀 挀栀漀漀猀攀Ⰰ 㰀䤀㸀愀猀 氀漀渀最 愀猀 椀琀 椀猀 琀栀攀 搀椀猀欀⼀瀀愀爀琀椀琀椀漀渀 礀漀甀 眀愀渀琀 氀漀最Ⰰ 琀栀愀琀 椀猀Ⰰ㰀戀爀㸀ഀഀ
it should contain databasefile(s), or the transactionlog file(s).</I><br>਍匀漀Ⰰ 昀漀爀 攀砀愀洀瀀氀攀 礀漀甀 洀椀最栀琀 挀栀漀漀猀攀 ∀䜀㨀∀Ⰰ 戀攀挀愀甀猀攀 琀栀椀猀 ∀搀椀猀欀∀ 挀漀渀琀愀椀渀猀 愀渀 愀挀琀椀瘀攀 䤀渀搀攀砀 昀椀氀攀⸀㰀戀爀㸀ഀഀ
Or, you might choose the "_Total" object of the LogicalDisk object, which means you measure all disks at the same time.<br>਍䄀渀搀 椀昀 礀漀甀 栀愀瘀攀 愀 搀攀搀椀挀愀琀攀搀 匀儀䰀 匀攀爀瘀攀爀 洀愀挀栀椀渀攀Ⰰ 琀栀攀渀 琀栀愀琀✀猀 渀漀琀 愀 戀愀搀 挀栀漀椀挀栀攀⸀㰀戀爀㸀ഀഀ
<br>਍一漀眀Ⰰ 瀀愀礀 猀瀀攀挀椀愀氀 愀琀琀攀渀琀椀漀渀 琀漀 琀栀攀 昀漀氀氀漀眀椀渀最 挀漀甀渀琀攀爀猀 ⠀昀爀漀洀 琀栀攀 倀栀礀猀椀挀愀氀䐀椀猀欀 漀戀樀攀挀琀⤀㨀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀 ─ 䐀椀猀欀 吀椀洀攀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<B> Avg. Disk Queue Length</B><br>਍㰀戀爀㸀ഀഀ
<img src="sql4.jpg" align="center"/>਍㰀戀爀㸀ഀഀ
In the figure on the left, you see a very "exaggerated" example of a perfmon graph.਍一漀琀攀 琀栀攀 瘀愀爀椀漀甀猀 挀漀甀渀琀攀爀猀 搀椀瀀氀愀礀攀搀⸀ 吀栀攀 ∀礀攀氀氀漀眀∀ 氀椀渀攀 椀猀 ∀─䐀椀猀欀 吀椀洀攀∀Ⰰ 眀栀椀氀攀 琀栀攀ഀഀ
"green" line represents the "Avg. Disk Queue Length".<br>਍㰀戀爀㸀ഀഀ
The values shown here, are a bit high. Who cares, it's just an example.<br>਍㰀戀爀㸀ഀഀ
The "PhysicalDisk: % Disk Time" counter monitors the percentage of time that the disk is busy with read/write activity.<br>਍㰀戀爀㸀ഀഀ
If the "PhysicalDisk: % Disk Time" counter is constantly high, (more than 80,90 percent), we might see a problem.<br>਍㰀戀爀㸀ഀഀ
<br>਍䔀瘀攀渀 漀昀 洀漀爀攀 椀渀琀攀爀爀攀猀琀Ⰰ 椀猀 琀栀攀 ∀倀栀礀猀椀挀愀氀䐀椀猀欀㨀 䄀瘀最⸀ 䐀椀猀欀 儀甀攀甀攀 䰀攀渀最琀栀∀ 挀漀甀渀琀攀爀Ⰰ 琀漀 猀攀攀 栀漀眀 洀愀渀礀 猀礀猀琀攀洀 爀攀焀甀攀猀琀猀 愀爀攀 㰀唀㸀眀愀椀琀椀渀最㰀⼀唀㸀㰀戀爀㸀ഀഀ
for disk access. If you see that taking values like 2, 5, 3, 4, 10, 1 etc.., there is likely no Disk IO problem.<br>਍㰀戀爀㸀ഀഀ
<br>਍䤀昀 礀漀甀 眀愀渀琀 琀漀 猀攀攀 琀栀愀琀 攀砀瀀爀攀猀猀攀搀 椀渀 愀 爀甀氀攀㨀 琀栀攀 渀甀洀戀攀爀 漀昀 漀甀猀琀愀渀搀椀渀最 爀攀焀甀攀猀琀 猀栀漀甀氀搀 戀攀 渀漀 洀漀爀攀 琀栀愀渀 ㈀ 砀 ⠀琀栀攀 渀甀洀戀攀爀 漀昀 猀瀀椀渀搀氀攀猀⤀⸀㰀戀爀㸀ഀഀ
So, suppose you see constantly high values like 20, 30 or higher, you might agree we probably have a serious  Disk IO problem.<br>਍㰀戀爀㸀ഀഀ
Also note from the above figure, that I took the counters of the "PhysicalDisk" object, over all "disk instances" (shown as "_Total").<br>਍㰀戀爀㸀ഀഀ
As always, however compelling the "evidence" seems to be, never jump to conclusions right away. We still need more information.<br>਍㰀戀爀㸀ഀഀ
Now, what about the specific SQL Server counters? Sure, and we will see them in Chapter 6!<br>਍㰀戀爀㸀ഀഀ
<br>਍㰀栀㌀㸀㄀⸀㌀ 䤀渀昀漀爀洀愀琀椀漀渀 昀爀漀洀 琀栀攀 ∀猀礀猀⸀搀洀开漀猀开眀愀椀琀开猀琀愀琀猀∀ 瘀椀攀眀Ⰰ 眀椀琀栀 爀攀猀瀀攀挀琀 琀漀 䤀伀 愀渀搀 䐀椀猀欀 䤀伀㰀⼀栀㌀㸀ഀഀ
਍匀椀渀挀攀 瘀攀爀猀椀漀渀 ㈀　　㔀Ⰰ 匀儀䰀 匀攀爀瘀攀爀 栀愀猀 愀 瘀攀爀礀 攀砀琀攀渀搀攀搀 搀椀挀琀椀漀渀愀爀礀 眀椀琀栀 ∀猀礀猀琀攀洀 瘀椀攀眀猀∀ 愀渀搀 ∀猀礀猀琀攀洀 昀甀渀挀琀椀漀渀猀∀Ⰰ 昀漀爀 甀猀攀 昀漀爀 琀栀攀 䐀䈀䄀⸀㰀戀爀㸀ഀഀ
The views contains a wealth of statistics on sessions, locks, transactions, system metrics like latches, Disk statistics etc.. etc..<br>਍䄀琀 氀愀猀琀Ⰰ 眀攀 栀愀瘀攀 爀攀愀挀栀攀搀 琀栀攀 氀攀瘀攀氀 漀昀 伀爀愀挀氀攀 䐀䈀䄀✀猀Ⰰ 眀栀椀挀栀 昀漀爀 洀愀渀礀 洀愀渀礀 礀攀愀爀猀 焀甀攀爀椀攀搀 琀栀攀椀爀 栀甀渀搀爀攀搀猀 漀昀 瘀␀ 愀渀搀 䐀䈀䄀开 瘀椀攀眀猀⸀㰀戀爀㸀ഀഀ
<br>਍吀栀攀爀攀 愀爀攀 猀漀 洀愀渀礀 椀渀琀攀爀爀攀猀琀椀渀最 猀礀猀琀攀洀 瘀椀攀眀猀 椀渀 匀儀䰀 匀攀爀瘀攀爀Ⰰ 琀栀愀琀 眀攀 眀愀渀琀 琀漀 瘀椀攀眀 琀栀攀洀 愀氀氀 爀椀最栀琀 渀漀眀℀ 䈀甀琀Ⰰ 琀栀椀猀 挀栀愀瀀琀攀爀 椀猀㰀戀爀㸀ഀഀ
dealing on Disk IO, so one Dynamic Management view stands out: "sys.dm_os_wait_stats".<br>਍吀栀椀猀 瘀椀攀眀 椀猀 猀瀀攀挀椀昀椀挀愀氀氀礀 昀漀爀 最愀琀栀攀爀椀渀最 ∀眀愀椀琀猀∀ 漀渀 愀 氀愀爀最攀 渀甀洀戀攀爀 漀昀 攀瘀攀渀琀猀⸀㰀戀爀㸀ഀഀ
(Note: even the function of section 1.1 uses it)<br>਍䈀甀琀 眀攀 洀甀猀琀 爀攀洀攀洀戀攀爀 琀栀愀琀 琀栀攀 瘀愀氀甀攀猀 椀渀 ∀猀礀猀⸀搀洀开漀猀开眀愀椀琀开猀琀愀琀猀∀Ⰰ 愀爀攀 ∀挀甀洀甀氀愀琀椀瘀攀∀Ⰰ 琀栀愀琀 椀猀Ⰰ 椀渀昀漀爀洀愀琀椀漀渀 椀猀 愀搀搀攀搀 愀氀氀 琀栀攀 琀椀洀攀⸀㰀戀爀㸀ഀഀ
The counters can be reset using the SQL statement DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR).<br>਍㰀戀爀㸀ഀഀ
You could already use "select * from sys.dm_os_wait_stats", but that query gives use too much (unfocused) information.<br>਍ഀഀ
<br> ਍㰀椀洀最 猀爀挀㴀∀猀焀氀㈀⸀樀瀀最∀ 愀氀椀最渀㴀∀氀攀昀琀∀⼀㸀ഀഀ
<br>਍䤀渀 琀栀攀 昀椀最甀爀攀 漀渀 琀栀攀 氀攀昀琀Ⰰ 礀漀甀 猀攀攀 愀 戀攀琀琀攀爀 焀甀攀爀礀 瘀愀爀椀愀渀琀 漀渀 猀礀猀⸀搀洀开漀猀开眀愀椀琀开猀琀愀琀⸀ 圀攀 猀瀀攀挀椀昀椀挀愀氀氀礀 氀攀愀瘀攀 漀甀琀 昀椀攀氀搀猀ഀഀ
which we are not interrested in (at the moment) because we want to focus on events related to Disk IO.<br>਍吀栀愀琀✀猀 眀栀礀 眀攀 甀猀攀 琀栀攀 挀氀愀甀猀攀 ∀眀栀攀爀攀 眀愀椀琀琀礀瀀攀 渀漀琀 椀渀 ⠀⸀⸀⤀∀⸀㰀戀爀㸀ഀഀ
<br>਍䄀渀搀Ⰰ 眀攀 甀猀攀 琀栀攀 挀氀愀甀猀攀 ∀琀漀瀀 ㄀　 ⨀∀ 戀攀挀愀甀猀攀 眀攀 愀爀攀 椀渀琀攀爀爀攀猀琀攀搀 椀渀 琀栀攀 ∀琀漀瀀 ㄀　 䤀伀 洀攀琀爀椀挀猀∀⸀㰀戀爀㸀ഀഀ
<br>਍一漀琀攀㨀 戀攀氀漀眀 礀漀甀 眀椀氀氀 昀椀渀搀 琀栀攀 焀甀攀爀礀 椀渀 挀氀攀愀爀 琀攀砀琀⤀⸀㰀戀爀㸀ഀഀ
<br>਍䄀氀猀漀 渀漀琀攀 琀栀愀琀 礀漀甀 挀愀渀 眀爀椀琀攀 渀甀洀洀攀爀漀甀猀 椀渀琀攀爀爀攀猀琀椀渀最 焀甀攀爀礀 瘀愀爀椀愀渀琀猀 漀渀 猀礀猀⸀搀洀开漀猀开眀愀椀琀开猀琀愀琀猀⸀㰀戀爀㸀ഀഀ
<br>਍䰀攀琀✀猀 渀漀眀 昀漀挀甀猀 漀渀 琀栀攀 漀甀琀瀀甀琀 漀昀 琀栀椀猀 猀瀀攀挀椀昀椀挀 焀甀攀爀礀⸀ 䤀渀 琀栀椀猀 猀瀀攀挀椀昀椀挀 攀砀愀洀瀀氀攀Ⰰ 琀栀攀 焀甀攀爀礀 眀愀猀 爀甀渀 漀渀 愀 猀礀猀琀攀洀 ഀഀ
which has quite a Disk IO problem. A very important column to pay attention to is "wait_time_ms", which shows us the time਍椀渀 洀猀Ⰰ 眀栀椀挀栀 瀀爀漀挀攀猀猀攀猀 栀愀搀 琀漀 眀愀椀琀 昀漀爀Ⰰ 昀漀爀 琀栀愀琀 猀瀀攀挀椀昀椀挀 ∀眀愀椀琀开琀礀瀀攀∀ ⠀猀栀漀眀渀 椀渀 琀栀攀 昀椀爀猀琀 挀漀氀甀洀渀⤀⸀㰀戀爀㸀ഀഀ
<br>਍圀栀愀琀 挀漀甀氀搀 猀攀琀 甀猀 漀渀 琀栀攀 琀爀愀挀欀 漀昀 瀀漀猀猀椀戀氀攀 䐀椀猀欀 䤀伀 瀀爀漀戀氀攀洀猀Ⰰ 椀猀 琀栀攀 ∀眀愀椀琀开琀椀洀攀开洀猀∀ 爀攀氀愀琀攀搀 琀漀 琀栀攀㰀戀爀㸀ഀഀ
"Pageiolatch_%" wait_types.<br>਍∀倀愀最攀椀漀氀愀琀挀栀开猀栀 洀攀愀渀猀 琀栀愀琀 愀 猀攀猀猀椀漀渀 椀猀 眀愀椀琀椀渀最 昀漀爀 猀漀洀攀 瀀愀最攀 琀漀 戀攀 戀爀漀甀最栀琀 椀渀琀漀 洀攀洀漀爀礀Ⰰ 昀爀漀洀 搀愀琀愀戀愀猀攀 昀椀氀攀猀 漀渀 搀椀猀欀⸀㰀戀爀㸀ഀഀ
That a small wait is involved is understandable. However, if the Pageiolatch_% waittimes are too high, it could be an indicator਍漀昀 愀 䐀椀猀欀 䤀伀 瀀爀漀戀氀攀洀⸀㰀戀爀㸀ഀഀ
More generally, this wait_type, represent all sorts of memory-to-disk transfers, so it could also be an indication that you are low<br>਍漀渀 挀愀挀栀攀 戀甀昀昀攀爀 洀攀洀漀爀礀⸀㰀戀爀㸀ഀഀ
<br>਍䤀伀 瀀爀漀戀氀攀洀猀 挀愀渀 愀氀猀漀 戀攀 戀攀 愀 挀漀渀猀椀搀攀爀愀戀氀攀 昀愀挀琀漀爀Ⰰ 椀昀 䄀匀夀一䌀开䤀伀开䌀伀䴀倀䰀䔀吀䤀伀一 愀渀搀 䤀伀开䌀伀䴀倀䰀䔀吀䤀伀一 猀栀漀眀 栀椀最栀 眀愀椀琀 琀椀洀攀猀⸀㰀戀爀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
The values are cumulative ofcourse, and you might consider the above DBCC command, to start over.<br>਍圀栀愀琀 愀爀攀 爀攀愀猀漀渀愀戀氀攀 瘀愀氀甀攀猀 漀昀 琀栀攀 倀愀最攀椀漀氀愀琀挀栀开─ 瘀愀氀甀攀猀㼀㰀戀爀㸀ഀഀ
The query that is shown in the figure, <I>actually tells you</I>. If it's listed high in the top 10, we have an indicator of a Disk IO problem.<br>਍㰀戀爀㸀ഀഀ
Again, don't jump to conclusions from this information alone. However, if we take all the information from<br>਍猀攀挀琀椀漀渀猀 ㄀⸀㄀Ⰰ ㄀⸀㈀ 愀渀搀 ㄀⸀㌀ 琀漀最攀琀栀攀爀Ⰰ 愀渀搀 琀栀攀礀 瀀爀漀瘀椀搀攀 愀 挀漀渀猀椀猀琀攀渀琀 瘀椀攀眀Ⰰ 琀栀攀渀 椀琀 椀猀 爀攀愀猀漀渀愀戀氀攀 琀漀 愀猀猀甀洀攀 琀栀愀琀 䐀椀猀欀 䤀伀㰀戀爀㸀ഀഀ
is indeed a problem.<br>਍匀漀Ⰰ 眀攀 搀椀搀 眀栀愀琀 眀愀猀 瀀爀漀洀椀猀攀搀 椀渀 琀栀攀 琀椀琀氀攀 漀昀 琀栀椀猀 挀栀愀瀀琀攀爀㨀 㰀䤀㸀䠀漀眀 琀漀 ∀焀甀椀挀欀氀礀∀ 搀攀琀攀爀洀椀渀攀 椀昀 礀漀甀 栀愀瘀攀 䐀椀猀欀 䤀⼀伀 瀀爀漀戀氀攀洀猀⸀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍䠀漀眀攀瘀攀爀Ⰰ 㰀䈀㸀眀攀 搀椀搀 渀漀琀 洀愀欀攀 挀氀攀愀爀㰀⼀䈀㸀 眀栀攀琀栀攀爀 琀栀攀 䤀伀 瀀爀漀戀氀攀洀 愀爀漀猀攀 昀爀漀洀 愀 戀愀搀 搀愀琀愀戀愀猀攀 搀攀猀椀最渀 ⠀猀攀瀀攀爀愀琀椀漀渀 琀愀戀氀攀猀 愀渀搀 椀渀搀攀砀攀猀 攀琀挀⸀⸀⤀Ⰰ㰀戀爀㸀ഀഀ
or that indeed the disksubsystem is not good enough for the SQL Server environment.<br>਍㰀戀爀㸀ഀഀ
As another example to be carefull before "you blame something", consider this:<br>਍䴀愀礀戀攀 琀栀攀爀攀 愀爀攀 猀漀 洀愀渀礀 甀猀攀爀猀 愀挀琀椀瘀攀Ⰰ 眀栀椀挀栀 眀愀猀 渀漀琀 愀渀琀椀挀椀瀀愀琀攀搀 戀攀昀漀爀攀Ⰰ 猀漀 琀栀愀琀 琀栀攀 猀礀猀琀攀洀 椀猀 渀漀琀㰀戀爀㸀ഀഀ
scaled properly. There are just so many competing sessions, that everything "overloads".<br>਍伀昀挀漀甀爀猀攀 眀攀 挀愀渀 椀渀瘀攀猀琀椀最愀琀攀 琀栀愀琀 琀漀漀⸀㰀戀爀㸀ഀഀ
It's just a remark "to be carefull" with conclusions.<br>਍㰀戀爀㸀ഀഀ
Note: here is the query (for easy copy/paste purposes)<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍猀攀氀攀挀琀 琀漀瀀 ㄀　 ⨀㰀戀爀㸀ഀഀ
from sys.dm_os_wait_stats<br>਍眀栀攀爀攀 眀愀椀琀开琀礀瀀攀 渀漀琀 椀渀㰀戀爀㸀ഀഀ
( <br>਍✀䬀匀伀唀刀䌀䔀开圀䄀䬀䔀唀倀✀Ⰰ ✀匀䰀䔀䔀倀开䈀倀伀伀䰀开䘀䰀唀匀䠀✀Ⰰ ✀䈀刀伀䬀䔀刀开吀䄀匀䬀开匀吀伀倀✀Ⰰ㰀戀爀㸀ഀഀ
'XE_TIMER_EVENT', 'XE_DISPATCHER_WAIT', 'FT_IFTS_SCHEDULER_IDLE_WAIT',<br>   ਍✀匀儀䰀吀刀䄀䌀䔀开䈀唀䘀䘀䔀刀开䘀䰀唀匀䠀✀Ⰰ ✀䌀䰀刀开䄀唀吀伀开䔀嘀䔀一吀✀Ⰰ ✀䈀刀伀䬀䔀刀开䔀嘀䔀一吀䠀䄀一䐀䰀䔀刀✀Ⰰ㰀戀爀㸀ഀഀ
'LAZYWRITER_SLEEP', 'BAD_PAGE_PROCESS', 'BROKER_TRANSMITTER', <br>਍✀䌀䠀䔀䌀䬀倀伀䤀一吀开儀唀䔀唀䔀✀Ⰰ ✀䐀䈀䴀䤀刀刀伀刀开䔀嘀䔀一吀匀开儀唀䔀唀䔀✀Ⰰ ✀䰀䄀娀夀圀刀䤀吀䔀刀开匀䰀䔀䔀倀✀Ⰰ 㰀戀爀㸀ഀഀ
'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'LOGMGR_QUEUE',<br> ਍✀匀䰀䔀䔀倀开吀䄀匀䬀✀Ⰰ ✀匀儀䰀吀刀䄀䌀䔀开䈀唀䘀䘀䔀刀开䘀䰀唀匀䠀✀Ⰰ ✀䌀䰀刀开䴀䄀一唀䄀䰀开䔀嘀䔀一吀✀Ⰰ㰀戀爀㸀 ഀഀ
'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS', <br> ਍✀倀刀䔀䔀䴀倀吀䤀嘀䔀开伀匀开䄀唀吀䠀䔀一吀䤀䌀䄀吀䤀伀一伀倀匀✀Ⰰ ✀䈀刀伀䬀䔀刀开吀伀开䘀䰀唀匀䠀✀㰀戀爀㸀 ഀഀ
) <br> ਍漀爀搀攀爀 戀礀 眀愀椀琀开琀椀洀攀开洀猀 搀攀猀挀 㰀戀爀㸀 ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀  ഀഀ
<br>਍㰀栀㈀㸀䌀栀愀瀀琀攀爀 ㈀⸀ 匀漀洀攀 爀攀洀愀爀欀猀 漀渀 嘀椀爀琀甀愀氀 䴀愀挀栀椀渀攀猀 愀渀搀 愀 氀愀爀最攀Ⰰ 愀挀琀椀瘀攀Ⰰ 匀儀䰀 匀攀爀瘀攀爀 攀渀瘀椀爀漀渀洀攀渀琀⸀㰀⼀栀㈀㸀ഀഀ
਍䤀渀 挀愀猀攀 漀昀 愀 瘀攀爀礀 氀愀爀最攀Ⰰ 瘀攀爀礀 ∀愀挀琀椀瘀攀∀ 搀愀琀愀戀愀猀攀Ⰰ 戀攀琀琀攀爀 渀漀琀 瘀椀爀琀甀愀氀椀稀攀 礀漀甀爀 匀儀䰀 攀渀瘀椀爀漀渀洀攀渀琀⸀ 圀攀氀氀Ⰰ 琀栀愀琀✀猀 洀礀 漀瀀椀渀椀漀渀⸀㰀戀爀㸀ഀഀ
<br>਍㰀䤀㸀倀氀攀愀猀攀 爀攀愀搀 琀栀攀 昀漀氀氀漀眀椀渀最 眀椀琀栀 愀 栀攀愀氀琀栀礀 搀漀猀椀猀 漀昀 猀欀攀瀀琀椀猀洀⸀ 䤀琀✀猀 樀甀猀琀 琀栀愀琀 漀渀 琀栀椀猀 猀甀戀樀攀挀琀Ⰰ 渀漀戀漀搀礀 挀愀渀 琀攀氀氀㰀戀爀㸀ഀഀ
you "the absolute truth".</I><br>਍㰀戀爀㸀ഀഀ
In today's Datacentres, many physical Servers are present, where <U>each</U> physical machine is running <U>many</U> "Virtual Machines (VM)".<br>਍䄀氀洀漀猀琀 愀氀眀愀礀猀Ⰰ 猀漀洀攀 ∀瘀椀爀琀甀愀氀椀稀愀琀椀漀渀∀ 瀀爀漀搀甀挀琀 椀猀 甀猀攀搀 戀礀 眀栀椀挀栀 琀栀攀 䄀搀洀椀渀 椀猀 愀戀氀攀 琀漀 挀爀攀愀琀攀 嘀䴀✀猀 漀渀 琀栀愀琀 䠀漀猀琀⸀㰀戀爀㸀ഀഀ
Those VM's, each get their share of memory, virtual cpu's, network access, and disk access.<br>਍䘀漀爀 攀砀愀洀瀀氀攀Ⰰ ∀嘀䴀眀愀爀攀 䔀匀堀∀ 椀猀 瘀攀爀礀 瀀漀瀀甀氀愀爀⸀ 伀渀攀 瀀栀礀猀椀挀愀氀 匀攀爀瘀攀爀Ⰰ 椀渀猀琀愀氀氀攀搀 眀椀琀栀 䔀匀堀Ⰰ 挀愀渀 爀甀渀 愀 洀椀砀 漀昀 愀氀氀 猀漀爀琀猀 漀昀 䰀椀渀甀砀 愀渀搀 圀椀渀搀漀眀猀 嘀䴀✀猀㰀戀爀㸀ഀഀ
<br>਍䤀琀 搀漀攀猀 渀漀琀 栀愀瘀攀 琀漀 戀攀 愀 瀀爀漀戀氀攀洀⸀ 䈀甀琀 昀愀挀琀 椀猀Ⰰ 琀栀愀琀 洀愀渀礀 瀀栀礀猀椀挀愀氀 䠀漀猀琀猀 最攀琀猀 ∀挀爀漀眀搀攀搀∀ 眀椀琀栀 挀漀洀瀀攀琀椀渀最 嘀䴀✀猀 昀漀爀 爀攀猀漀甀爀挀攀猀⸀㰀戀爀㸀ഀഀ
This is the way many "businesses" work: new projects get alive, which all need their own test- development- and production machines.<br>਍䤀渀 洀愀渀礀 挀愀猀攀猀Ⰰ 椀琀✀猀 栀愀爀搀 昀漀爀 愀 猀礀猀愀搀洀椀渀 琀漀 欀攀攀瀀 愀氀氀 琀栀攀 搀攀洀愀渀搀猀 愀渀搀 爀攀猀漀甀爀挀攀猀 椀渀 戀愀氀愀渀挀攀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
Secondly, when the sysadmins and SAN administrators create the infrastructure, they may be unaware of the specific purposes<br>਍漀昀 琀栀攀 椀渀搀椀瘀椀搀甀愀氀 嘀䴀✀猀 琀栀愀琀 眀椀氀氀 戀攀 椀渀猀琀愀氀氀攀搀⸀ 匀漀洀攀 嘀䴀✀猀 眀椀氀氀 眀漀爀欀 愀猀 䘀椀氀攀 匀攀爀瘀攀爀猀Ⰰ 䴀愀椀氀 匀攀爀瘀攀爀猀Ⰰ 䐀漀洀愀椀渀 䌀漀渀琀爀漀氀氀攀爀猀Ⰰ 䄀瀀瀀氀椀挀愀琀椀漀渀 匀攀爀瘀攀爀猀Ⰰ㰀戀爀㸀ഀഀ
and.... SQL Server machines.<br>਍㰀戀爀㸀ഀഀ
Now, you might end up with a Win2K3 Server, with just a C:, D: and E: "drive", and you might know nothing<br>਍漀昀 琀栀攀 猀瀀攀挀椀昀椀挀猀 漀昀 猀琀漀爀愀最攀⸀㰀戀爀㸀ഀഀ
This is not the way that you will have fun with large, and/or active, databases.<br>਍䈀攀挀愀甀猀攀Ⰰ 愀氀眀愀礀猀 琀爀礀 琀漀 猀瀀攀爀愀琀攀 琀愀戀氀攀搀愀琀愀Ⰰ 椀渀搀攀砀攀猀Ⰰ 琀爀愀渀猀愀挀琀椀漀渀 氀漀最昀椀氀攀猀Ⰰ ⠀愀渀搀 琀攀洀瀀搀戀⤀ 漀渀 琀栀攀椀爀 漀眀渀 搀椀猀欀瘀漀氀甀洀攀猀Ⰰ㰀戀爀㸀ഀഀ
that is, seperate "spindels".<br> ਍伀琀栀攀爀眀椀猀攀 礀漀甀 洀椀最栀琀 攀渀挀漀甀渀琀攀爀 瘀攀爀礀 猀攀爀椀漀甀猀 䐀椀猀欀 䤀伀 瀀爀漀戀氀攀洀猀⸀㰀戀爀㸀ഀഀ
<br>਍圀栀椀氀攀 椀琀 椀猀 焀甀椀琀攀 攀愀猀礀 ∀琀漀 最攀琀 琀栀攀 攀瘀椀搀攀渀挀攀∀ 漀昀 䤀伀 瀀爀漀戀氀攀洀猀 ⠀猀攀攀 昀漀爀 攀砀愀洀瀀氀攀 猀攀挀琀椀漀渀 ㄀⤀Ⰰ 琀漀 ∀爀攀瀀愀椀爀∀ 琀栀攀 猀椀琀甀愀琀椀漀渀㰀戀爀㸀ഀഀ
often is quite difficult.<br>਍㰀戀爀㸀ഀഀ
Don't get me wrong: for smaller SQL Server database, you probably will not have any difficulties at all.<br>਍䄀渀搀 戀攀猀椀搀攀猀Ⰰ 䔀匀堀 栀愀猀 愀氀氀 猀漀爀琀猀 漀昀 瘀攀爀礀 渀攀愀琀 琀爀椀挀欀猀Ⰰ 氀椀欀攀 漀渀氀椀渀攀 洀漀瘀椀渀最 愀 嘀䴀 琀漀 愀渀漀琀栀攀爀 栀漀猀琀Ⰰ 愀渀搀 洀甀挀栀 洀漀爀攀⸀㰀戀爀㸀ഀഀ
<br>਍䈀甀琀 昀漀爀 愀 瘀攀爀礀 氀愀爀最攀Ⰰ 瘀攀爀礀 愀挀琀椀瘀攀 搀愀琀愀戀愀猀攀Ⰰ 琀愀欀攀 挀愀爀攀⸀ 夀漀甀 洀椀最栀琀 挀漀渀猀椀搀攀爀 愀 搀攀搀椀挀愀琀攀搀 瀀栀礀猀椀挀愀氀 洀愀挀栀椀渀攀⸀㰀戀爀㸀ഀഀ
<br>਍䈀礀 琀栀攀 眀愀礀Ⰰ 琀栀攀 最攀渀攀爀愀氀 挀漀渀猀攀渀猀甀猀 ∀椀渀 琀栀攀 䤀吀 挀漀洀洀甀渀椀琀礀∀ 樀甀猀琀 㰀唀㸀猀攀攀洀㰀⼀唀㸀 琀漀 猀甀瀀瀀漀爀琀 琀栀攀 愀戀漀瘀攀 瘀椀攀眀⸀㰀戀爀㸀ഀഀ
(please note the word "seem" here).<br>਍䄀渀礀眀愀礀Ⰰ 愀琀 漀挀挀愀猀椀漀渀猀 琀栀愀琀 䤀 琀愀氀欀 眀椀琀栀 䴀椀挀爀漀猀漀昀琀 攀渀最椀渀攀攀爀猀 漀渀 琀栀椀猀 猀甀戀樀攀挀琀Ⰰ 琀栀攀礀 愀氀眀愀礀猀 猀愀礀 琀栀愀琀 椀琀✀猀 椀渀搀攀攀搀 㰀䤀㸀∀一漀琀 䐀漀渀攀∀㰀⼀䤀㸀⸀㰀戀爀㸀ഀഀ
<br>਍一漀琀攀㨀 䤀 挀攀爀琀愀椀渀氀礀 氀椀欀攀 瘀椀爀琀甀愀氀椀稀愀琀椀漀渀⸀ 䤀昀 礀漀甀 愀爀攀 漀渀 最漀漀搀 琀攀爀洀猀 眀椀琀栀 琀栀攀 猀礀猀愀搀洀椀渀猀 攀渀 猀琀漀爀愀最攀 瀀攀漀瀀氀攀Ⰰ 洀漀猀琀 漀昀 琀栀攀 琀椀洀攀㰀戀爀㸀ഀഀ
things will work out OK. For example, Oracle on AIX lpars, or HPUX vpars, or DB2 on Z lpars etc... etc..,<br>਍眀漀爀欀猀 ⠀椀渀 最攀渀攀爀愀氀⤀ 伀䬀⸀㰀戀爀㸀ഀഀ
I must say that I am a bit dissapointed by a couple of bad experiences with really large SQL Server environments<br>਍漀渀 嘀䴀圀愀爀攀⸀ 䤀 愀氀眀愀礀猀 猀攀攀洀 琀漀 栀愀瘀攀 瀀爀漀戀氀攀洀猀 眀椀琀栀 圀椀渀搀漀眀猀 嘀椀爀琀甀愀氀椀稀愀琀椀漀渀 愀渀搀 氀愀爀最攀 搀愀琀愀戀愀猀攀猀⸀ 䘀漀爀 洀攀Ⰰ 椀琀 搀漀攀猀 渀漀琀 眀漀爀欀 眀攀氀氀⸀㰀戀爀㸀ഀഀ
I always have Disk IO problems and/or cpu utilizaton problems and/or Memory problems and/or network problems,<br>਍眀栀攀爀攀 䐀椀猀欀 䤀伀 椀猀 愀 瀀爀漀洀椀渀攀渀琀氀礀 渀甀洀戀攀爀 ∀㄀∀ 挀愀甀猀攀 漀昀 氀漀眀 瀀攀爀昀漀爀洀愀渀挀攀⸀㰀戀爀㸀 ഀഀ
So, it's certainly not an "absolute truth". I only tell you to be carefull, and try to create good test scenario's.<br>਍㰀戀爀㸀ഀഀ
If you must use a VM (for example, because of a <I>very</I> strict company policy), sit down with the sysadmin<br>਍愀渀搀 猀琀漀爀愀最攀 愀搀洀椀渀Ⰰ 愀渀搀 洀愀欀攀 礀漀甀爀 爀攀猀漀甀爀挀攀 爀攀焀甀椀爀攀洀攀渀琀猀 瘀攀爀礀 挀氀攀愀爀 ⠀愀渀搀 洀愀欀攀 琀栀攀洀 礀漀甀爀 昀爀椀攀渀搀猀 愀猀 眀攀氀氀⤀⸀㰀戀爀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
<h2>Chapter 3. In case of a large, very "active" database, always choose a 64 bit OS and 64 bit SQL Server edition.</h2>਍ഀഀ
This is ofcourse quite obvious. Even if we just <I>only</I> consider the memory that a 64 bit<br>਍匀儀䰀 匀攀爀瘀攀爀 挀愀渀 甀猀攀Ⰰ 挀漀洀瀀愀爀攀搀 琀漀 愀 ㌀㈀ 戀椀琀 攀搀椀琀椀漀渀Ⰰ 琀栀攀 搀椀昀昀攀爀攀渀挀攀 椀猀 愀猀琀漀渀椀猀栀椀渀最⸀㰀戀爀㸀ഀഀ
<br>਍伀渀 ㌀㈀ 戀椀琀 猀礀猀琀攀洀猀Ⰰ 礀漀甀 愀爀攀 氀椀洀椀琀攀搀 琀漀 㐀䜀䈀 漀昀 洀攀洀漀爀礀⸀ 夀漀甀 㰀䤀㸀挀漀甀氀搀㰀⼀䤀㸀 瀀甀琀 琀栀攀 猀漀挀愀氀氀攀搀 䄀圀䔀 昀攀愀琀甀爀攀 愀琀 眀漀爀欀Ⰰ 眀椀氀氀 眀漀甀氀搀 愀氀氀漀眀㰀戀爀㸀ഀഀ
for a maximum of 64GB cache. But that is not computational memory, it's just for caching.<br>਍㰀戀爀㸀ഀഀ
A 64 bit SQL Server, on the other hand, can directly address 1,024 gigabytes of physical memory, <br>਍猀漀 琀栀攀 愀洀漀甀渀琀 漀昀 搀愀琀愀 匀儀䰀 匀攀爀瘀攀爀 挀愀渀 愀挀挀攀猀猀 昀漀爀 挀愀挀栀攀 愀渀搀 挀漀洀瀀甀琀愀琀椀漀渀愀氀 洀攀洀漀爀礀Ⰰ 椀猀 琀栀甀猀 洀甀挀栀Ⰰ 洀甀挀栀 氀愀爀最攀爀⸀㰀戀爀㸀ഀഀ
It will pay off in almost all actions that SQL Server perfoms.<br>਍㰀戀爀㸀ഀഀ
Ofcourse, you need 64bit hardware to implement the 64 bit OS and 64 bit SQL Server editions.<br>਍㰀戀爀㸀ഀഀ
So, unless you are restricted by hardware or licensing issues, you cannot really speak of a choice here:<br>਍䘀漀爀 氀愀爀最攀爀 愀渀搀⼀漀爀 瘀攀爀礀 愀挀琀椀瘀攀 搀愀琀愀戀愀猀攀猀Ⰰ 礀漀甀 㰀䤀㸀猀栀漀甀氀搀 愀氀眀愀礀猀㰀⼀䤀㸀 最漀 昀漀爀 琀栀攀 㘀㐀 戀椀琀 攀渀瘀椀爀漀渀洀攀渀琀⸀㰀戀爀㸀ഀഀ
<br>਍吀爀甀攀Ⰰ 琀栀椀猀 椀猀 愀氀氀 瘀攀爀礀 琀爀椀瘀椀愀氀 愀渀搀 漀戀瘀椀漀甀猀⸀ 匀漀爀爀礀 昀漀爀 琀栀愀琀⸀㰀戀爀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
<h2>Chapter 4. Indexes and Index tuning.</h2>਍ഀഀ
You surely know what indexes are, and why they need to exist, certainly for larger tables.<br>਍㰀戀爀㸀ഀഀ
<h3>4.1 Short recap on indexes </h3>਍ഀഀ
Here are a few facts (just take them for granted), which will be explained later in more depth.<br>਍䘀漀爀 琀栀攀 ∀琀爀愀搀椀琀椀漀渀愀氀∀ 爀攀氀愀琀椀漀渀愀氀 匀儀䰀 匀攀爀瘀攀爀 琀愀戀氀攀猀Ⰰ 琀眀漀 琀礀瀀攀猀 漀昀 椀渀搀攀砀攀猀 攀砀椀猀琀㨀  㰀䈀㸀挀氀甀猀琀攀爀攀搀 椀渀搀攀砀㰀⼀䈀㸀 愀渀搀 㰀䈀㸀渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀㰀⼀䈀㸀⸀㰀戀爀㸀ഀഀ
<br>਍㰀漀氀㸀ഀഀ
<li>A table without a "clustered" index, is called a "heap". Essentially, the table rows are then not ordered by some "key"<br>਍⠀琀栀椀猀 欀攀礀 椀猀 漀渀攀 漀爀 洀漀爀攀 挀漀氀甀洀渀猀 漀昀 琀栀攀 琀愀戀氀攀⤀⸀㰀戀爀㸀ഀഀ
Now, this table could have one or more "non-clustered indexes", but it's still a heap.<br>਍㰀戀爀㸀㰀⼀氀椀㸀ഀഀ
<li>If a table has a clustered index, ONLY THEN the rows of the table are ordered by the key of that clustered index. So, actually really<br>਍琀栀攀 爀漀眀猀 椀渀 琀栀攀 瀀愀最攀猀 愀爀攀 猀漀爀琀攀搀 戀礀 琀栀愀琀 欀攀礀⸀ 吀栀甀猀Ⰰ 愀 琀愀戀氀攀 挀愀渀 漀渀氀礀 栀愀瘀攀 伀一䔀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀Ⰰ 戀攀挀愀甀猀攀 礀漀甀 挀愀渀 瀀栀礀猀椀挀愀氀氀礀 ∀猀漀爀琀∀㰀戀爀㸀ഀഀ
the table rows <B>in one way only</B> (and not by another key at the same time: that's not possible).<br>਍倀爀攀昀攀爀爀愀戀氀礀Ⰰ 琀栀攀 欀攀礀 漀昀 琀栀攀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 椀猀 愀 琀愀戀氀攀 挀漀氀甀洀渀 漀昀 愀 渀甀洀洀攀爀椀挀 搀愀琀愀琀礀瀀攀Ⰰ 琀栀愀琀 椀渀挀爀攀愀猀攀猀 眀椀琀栀 攀愀挀栀 爀漀眀 愀搀搀攀搀⸀㰀戀爀㸀ഀഀ
But, a character based dataype is often used too, like for example a "social security number".<br>਍㰀戀爀㸀㰀⼀氀椀㸀ഀഀ
<li>A table may have one or more "non clustered" indexes. A non clustered index, will not order the physical rows<br>਍漀昀 愀 琀愀戀氀攀 ⠀氀椀欀攀 愀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 搀漀攀猀⤀⸀ 匀漀Ⰰ 愀 琀愀戀氀攀 洀椀最栀琀 栀愀瘀攀 漀渀攀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 ⠀漀渀氀礀 漀渀攀⤀Ⰰ 愀渀搀 洀甀氀琀瀀氀攀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀⸀㰀戀爀㸀ഀഀ
<br></li>਍㰀氀椀㸀䄀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 椀猀 樀甀猀琀 愀渀 攀砀琀攀爀渀愀氀 漀戀樀攀挀琀Ⰰ 氀漀漀欀椀渀最 氀椀欀攀 愀 ∀洀椀渀椀 爀攀瀀爀攀猀攀渀琀愀琀椀漀渀∀ 漀昀 琀栀攀 琀愀戀氀攀⸀ 䤀琀 栀愀猀 ⠀氀攀愀昀⤀瀀愀最攀猀 挀漀渀琀愀椀渀椀渀最 爀漀眀猀Ⰰ㰀戀爀㸀ഀഀ
each of which has the choosen key of the table (one or more columns of that table), and a pointer to the corresponding<br>਍琀愀戀氀攀瀀愀最攀 眀栀椀挀栀 漀昀挀漀甀爀猀攀 挀漀渀琀愀椀渀 愀氀氀 琀栀攀 搀愀琀愀⸀ 吀栀愀琀 椀猀 漀渀攀 爀攀愀猀漀渀 眀栀礀 愀渀 椀渀搀攀砀 猀瀀攀攀搀猀 甀瀀 猀攀愀爀挀栀攀猀 椀渀 琀愀戀氀攀猀⸀㰀戀爀㸀ഀഀ
Such an index looks logically like a tree: it has a root page containing pointers to an intermediate level with pages,<br>਍眀栀攀爀攀 琀栀漀猀攀 瀀愀最攀猀 瀀漀椀渀琀 琀漀 琀栀攀 氀攀愀昀 氀攀瘀攀氀 漀昀 瀀愀最攀猀⸀ 吀栀漀猀攀 瀀愀最攀猀 琀栀攀渀Ⰰ 挀漀渀琀愀椀渀猀 琀栀攀 愀挀琀甀愀氀 欀攀礀猀 愀渀搀 瀀漀椀渀琀攀爀猀 琀漀 琀栀攀 㰀䈀㸀琀愀戀氀攀㰀⼀戀㸀 瀀愀最攀猀⸀㰀戀爀㸀ഀഀ
When a query uses such an index, the <I>tree is traversed</I>, and the table row is then quicly found.<br>਍㰀戀爀㸀㰀⼀氀椀㸀ഀഀ
<li>When a table has no indexes, a <I>full table scan</I> is done, meaning starting at the first page, all the way down,<br>਍甀渀椀琀氀 琀栀攀 猀漀甀最栀琀 愀昀琀攀爀 爀漀眀 椀猀 昀漀甀渀搀⸀ 吀栀愀琀✀猀 眀栀礀Ⰰ 眀椀琀栀 氀愀爀最攀爀 琀愀戀氀攀猀Ⰰ 椀渀搀攀砀攀猀 愀爀攀 椀渀搀椀猀瀀攀渀猀椀戀氀攀⸀㰀戀爀㸀ഀഀ
<br></li>਍㰀氀椀㸀䄀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 椀猀 猀漀洀攀眀栀愀琀 ∀猀瀀攀挀椀愀氀∀ ⠀椀昀 礀漀甀 栀愀瀀瀀攀渀 琀漀 戀攀 昀愀洀椀氀椀愀爀 眀椀琀栀 伀爀愀挀氀攀Ⰰ 椀琀 氀漀漀欀猀 氀椀欀攀 愀 䤀伀吀⤀⸀㰀戀爀㸀ഀഀ
What we have said in point 4, largely applies to a clustered index as well.<br>਍䔀砀挀攀瀀琀 琀栀愀琀 椀渀 琀栀椀猀 挀愀猀攀Ⰰ 㰀䤀㸀琀栀攀 氀攀愀昀 氀攀瘀攀氀 愀爀攀 琀栀攀 琀愀戀氀攀 瀀愀最攀猀 琀栀攀洀猀攀氀瘀攀猀 ⠀℀⤀㰀⼀䤀㸀⸀㰀戀爀㸀ഀഀ
<br>਍䄀琀 琀栀攀 洀漀洀攀渀琀 愀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 漀渀 愀 琀愀戀氀攀 椀猀 挀爀攀愀琀攀搀Ⰰ 琀栀攀 琀愀戀氀攀 爀漀眀猀 最攀琀 猀漀爀琀攀搀 ⠀漀渀 琀栀攀 挀栀漀漀猀攀渀 欀攀礀 漀昀 琀栀攀 椀渀搀攀砀⤀⸀㰀戀爀㸀ഀഀ
When that's done, the index leaf level, just is the same as the <B>table pages.</B><br>਍㰀戀爀㸀ഀഀ
To put it in simple words: A clustered Index is the ordered table itself.<br>਍㰀䤀㸀一漀琀攀㨀 椀琀✀猀 愀氀洀漀猀琀 琀爀甀攀Ⰰ 攀砀挀攀瀀琀 昀漀爀 琀栀攀 爀漀漀琀氀攀瘀攀氀 愀渀搀 愀渀礀 漀瀀琀椀漀渀愀氀 椀渀琀攀爀洀攀搀椀愀琀攀 氀攀瘀攀氀⸀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍㰀氀椀㸀伀渀氀礀 眀栀攀渀 愀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 椀猀 搀攀昀椀渀攀搀 昀漀爀 愀 琀愀戀氀攀Ⰰ 琀栀攀 琀愀戀氀攀 椀猀 渀漀琀 愀 ∀栀攀愀瀀∀ 愀渀礀洀漀爀攀⸀ 吀栀攀 琀愀戀氀攀爀漀眀猀 最攀琀 猀漀爀琀攀搀㰀戀爀㸀ഀഀ
on the choosen key.<br>਍䈀礀 琀栀攀 眀愀礀Ⰰ 椀昀 愀 ∀倀爀椀洀愀爀礀 䬀攀礀∀ 椀猀 搀攀昀椀渀攀搀 昀漀爀 愀 琀愀戀氀攀Ⰰ 匀儀䰀 匀攀爀瘀攀爀 眀椀氀氀 瀀攀爀 搀攀昀愀甀氀琀 挀爀攀愀琀攀 愀渀 愀猀猀漀挀椀愀琀攀搀㰀戀爀㸀ഀഀ
unique (clustered) index. You know probably that a Primary Key column in a table, must have all unique values.<br>਍匀漀Ⰰ 攀愀挀栀 爀漀眀 椀渀 琀栀攀 琀愀戀氀攀 㰀䈀㸀椀猀 甀渀椀焀甀攀㰀⼀䈀㸀 眀椀琀栀 爀攀猀瀀攀挀琀 琀漀 琀栀愀琀 瀀愀爀琀椀挀甀氀愀爀 挀漀氀甀洀渀 ⠀漀爀 猀攀琀 漀昀 挀漀氀甀洀渀猀⤀⸀㰀戀爀㸀ഀഀ
The above rule, is actually enforced by the unique index. A few lines above, I told you that a clustered index<br>਍眀椀氀氀 戀攀 挀爀攀愀琀攀搀⸀ 䤀渀 瀀爀愀挀琀椀挀攀Ⰰ 礀漀甀 愀氀洀漀猀琀 愀氀眀愀礀猀 眀椀氀氀 搀漀 琀栀愀琀⸀ 䈀甀琀 愀挀琀甀愀氀氀礀Ⰰ 愀 ∀甀渀椀焀甀攀∀ 椀渀搀攀砀 椀猀 愀氀爀攀愀搀礀 猀甀昀昀椀挀椀攀渀琀⸀㰀戀爀㸀ഀഀ
<br>਍䐀漀渀✀琀 眀漀爀爀礀 渀漀眀⸀ 吀栀攀爀攀 愀爀攀 樀甀猀琀 琀眀漀 椀渀搀攀砀 琀礀瀀攀猀 ⠀挀氀甀猀琀攀爀攀搀 愀渀搀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀⤀⸀ 䈀甀琀 愀渀 椀渀搀攀砀 挀愀渀 戀攀 搀攀昀椀渀攀搀 愀猀 甀渀椀焀甀攀Ⰰ 椀昀 琀栀攀ഀഀ
choosen key, only takes on unique values. So, even a non-clustered index can be defined as unique.<br>਍㰀戀爀㸀㰀⼀氀椀㸀ഀഀ
<li>If a primary key is defined for a table, then you automatically have your (one and only) clustered index as well.<br>਍䈀甀琀 礀漀甀 洀愀礀 愀搀搀 愀搀椀琀椀漀渀愀氀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀⸀ 䤀昀 礀漀甀 愀爀攀 挀攀爀琀愀椀渀Ⰰ 琀栀愀琀 愀 爀攀氀攀瘀愀渀琀 渀甀洀戀攀爀 漀昀 焀甀攀爀椀攀猀㰀戀爀㸀ഀഀ
have in the "where clause", colums that are not in the clustered index key, you probably consider creating<br>਍漀渀攀 漀爀 洀漀爀攀 ⠀愀 眀攀氀氀 戀愀氀愀渀挀攀搀 渀甀洀戀攀爀⤀ 漀昀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀⠀攀猀⤀⸀㰀戀爀㸀ഀഀ
It's a bit of an art. You surely can have a situation where the addition of a non-clustered index helps tremendously.<br>਍䈀甀琀 椀昀 礀漀甀 栀愀瘀攀 琀漀漀 洀愀渀礀 ⠀甀猀攀氀攀猀猀⤀ 椀渀搀攀砀攀猀Ⰰ 椀琀 眀漀爀欀猀 挀漀甀渀琀攀爀 瀀爀漀搀甀挀琀椀瘀攀⸀㰀戀爀㸀ഀഀ
You know, any Insert, Delete, and Update SQL statement, alters a row (or more rows) in the table, and all associated<br>਍椀渀搀攀砀攀猀 洀甀猀琀 戀攀 甀瀀搀愀琀攀搀 愀猀 眀攀氀氀Ⰰ 琀漀 爀攀昀氀攀挀琀 琀栀攀 渀攀眀 猀椀琀甀愀琀椀漀渀⸀ ഀഀ
਍㰀⼀漀氀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
All objects in SQL Server have an "Object ID" (object_id). This holds for tables, indexes and other objects.<br>਍㰀戀爀㸀ഀഀ
Once indexes are defined on a table, those indexes have an "index id" (index_id or ind_id) as well.<br>਍㰀戀爀㸀ഀഀ
You know about the "close" relationship between tables and indexes. For example, the leaflevel of pages of a<br>਍挀氀甀猀琀攀爀攀搀 椀渀搀攀砀Ⰰ 樀甀猀琀 愀爀攀 琀栀攀 琀愀戀氀攀 瀀愀最攀猀⸀㰀戀爀㸀ഀഀ
There are a quite a few dynamic management views and functions that show the properties of indexes and tables.<br>਍䤀昀 愀 琀愀戀氀攀 栀愀猀 椀渀搀攀砀攀猀Ⰰ 琀栀攀 昀漀氀氀漀眀椀渀最 椀渀搀攀砀开椀搀✀猀 栀漀氀搀 昀漀爀 琀栀攀 琀愀戀氀攀 愀渀搀 椀琀✀猀 椀渀搀攀砀攀猀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀䄀㨀 琀愀戀氀攀 栀愀猀 渀漀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍椀渀搀攀砀开椀搀㴀　 㨀椀渀搀攀砀 椀搀 漀昀 琀栀攀 栀攀愀瀀 ⠀琀栀攀 琀愀戀氀攀 椀琀猀攀氀昀⤀㰀戀爀㸀ഀഀ
index_id>1 :index id's of the non-clustered indexes (like 1, 2, 3 etc..)<br>਍㰀戀爀㸀ഀഀ
<B>A: table has a clustered index</B><br>਍㰀戀爀㸀ഀഀ
index_id=1 :index id of the clustered index (the table itself)<br>਍椀渀搀攀砀开椀搀㸀㄀ 㨀椀渀搀攀砀 椀搀✀猀 漀昀 琀栀攀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀㰀戀爀㸀ഀഀ
<br>਍㰀䤀㸀一漀琀攀㨀 椀渀 猀漀洀攀 漀氀搀攀爀 瘀椀攀眀猀 ⠀昀爀漀洀 昀漀爀洀攀爀 瘀攀爀猀椀漀渀猀⤀ 琀栀攀 ∀椀渀搀攀砀开椀搀∀ 椀猀 氀椀猀琀攀搀 愀猀 ∀椀渀搀椀搀∀⸀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍㰀栀㌀㸀㐀⸀㈀ 䐀礀渀愀洀椀挀 洀愀渀愀最攀洀攀渀琀 瘀椀攀眀猀 愀渀搀 昀甀渀挀琀椀漀渀猀㨀 㰀⼀栀㌀㸀ഀഀ
਍吀栀攀 昀漀氀氀漀眀椀渀最 瘀椀攀眀猀 愀渀搀 昀甀渀挀琀椀漀渀猀 眀椀氀氀 栀攀氀瀀 甀猀 愀 氀漀琀 椀渀 搀攀琀攀爀洀椀渀椀渀最 洀愀渀礀 瀀爀漀瀀攀爀琀椀攀猀 漀昀 椀渀搀攀砀攀猀Ⰰ 氀椀欀攀 琀栀攀 渀甀洀戀攀爀 漀昀 爀漀眀猀 椀渀 琀栀攀 椀渀搀攀砀Ⰰ㰀戀爀㸀ഀഀ
the number of pages, fragmentation level, if it might be a hotspot, or contrary, is not uses much etc.. etc..<br>਍㰀戀爀㸀ഀഀ
<I>This is what you likely want to know in a quick and easy manner:</I><br>਍㰀戀爀㸀ഀഀ
=> If an index is a "hotspot", then that's good because it's evidently used much.<br>਍䈀甀琀Ⰰ 椀昀 礀漀甀 栀愀瘀攀 洀甀氀琀椀瀀氀攀 ∀栀漀琀猀瀀漀琀猀∀ 㰀䈀㸀椀渀 琀栀攀 猀愀洀攀 昀椀氀攀㰀⼀䈀㸀Ⰰ 琀栀攀渀 礀漀甀 洀椀最栀琀 挀漀渀猀椀搀攀爀 洀漀瘀椀渀最 愀渀 栀漀琀猀瀀漀琀 琀漀 愀渀漀琀栀攀爀 昀椀氀攀⸀㰀戀爀㸀ഀഀ
<br>਍㴀㸀 䄀氀猀漀Ⰰ 猀椀渀挀攀 椀渀搀攀砀攀猀 ∀洀甀琀愀琀攀∀ 愀猀 眀攀氀氀Ⰰ 礀漀甀 眀愀渀琀 琀漀 欀渀漀眀 栀漀眀 昀爀愀最洀攀渀琀攀搀 琀栀攀礀 愀爀攀Ⰰ 愀渀搀 琀栀愀琀 洀椀最栀琀 琀爀椀最最攀爀 礀漀甀 琀漀㰀戀爀㸀ഀഀ
reorganize or even rebuild an index (maintenance of an index).<br>਍㰀戀爀㸀ഀഀ
=> If an index <I>is (almost) not used at all</I>, you might want to remove it.<br>਍㰀戀爀㸀ഀഀ
=>You also want to easily see how many rows an index has. The larger indexes are probably the more important ones,<br>਍愀渀搀 椀昀 琀栀攀礀 愀爀攀 昀爀愀最洀攀渀琀攀搀Ⰰ 礀漀甀 挀愀渀 挀爀攀愀琀攀 氀椀猀琀猀 漀昀 椀渀搀攀砀攀猀 漀渀 眀栀椀挀栀 礀漀甀 眀愀渀琀 琀漀 搀漀 洀愀椀渀琀攀渀愀渀挀攀⸀㰀戀爀㸀ഀഀ
Besides, then you also know which rebuilds of which indexes will hit performance most during a rebuild.<br>਍㰀戀爀㸀ഀഀ
<B>The following views an functions are important:</B><br>਍㰀戀爀㸀ഀഀ
<ol>਍㰀氀椀㸀㰀䈀㸀猀礀猀椀渀搀攀砀攀猀 ⠀瘀椀攀眀⤀㨀㰀⼀䈀㸀 䄀渀 漀氀搀 昀爀椀攀渀搀 昀爀漀洀 昀漀爀洀攀爀 匀儀䰀 猀攀爀瘀攀爀 瘀攀爀猀椀漀渀猀⸀ 䤀琀✀猀 猀琀椀氀氀 愀瘀愀椀氀愀戀氀攀 椀渀 ㈀　　㔀⼀㈀　　㠀⸀㰀戀爀㸀ഀഀ
Contains one row for each index (or heap) with many important properties. Often it is joined with "sysobjects", in order<br>਍琀漀 最攀琀 琀栀攀 愀猀猀漀挀椀愀琀攀搀 琀愀戀氀攀渀愀洀攀猀 愀猀 眀攀氀氀⸀㰀戀爀㸀ഀഀ
<br></li>਍ഀഀ
<li><B>sys.dm_db_index_operational_stats (function):</B> Since 2005 and up. Contains one row for each index,<br>਍愀渀搀 愀最最爀攀最愀琀攀猀 琀栀攀 渀甀洀戀攀爀 漀昀 氀攀愀昀 愀渀搀 渀漀渀ⴀ氀攀愀昀 椀渀猀攀爀琀猀Ⰰ 甀瀀搀愀琀攀猀Ⰰ 搀攀氀攀琀攀猀 愀氀漀渀最 眀椀琀栀 瀀愀最攀 氀愀琀挀栀 猀琀愀琀椀猀琀椀挀猀⸀㰀戀爀㸀ഀഀ
<br></li>਍ഀഀ
<li><B>sys.dm_db_index_physical_stats (function):</B> Shows per index the fragmentation and allocation information.<br>਍㰀戀爀㸀㰀⼀氀椀㸀ഀഀ
਍㰀氀椀㸀㰀䈀㸀猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开甀猀愀最攀开猀琀愀琀猀 ⠀瘀椀攀眀⤀㨀㰀⼀䈀㸀 匀栀漀眀猀 瀀攀爀 椀渀搀攀砀Ⰰ 猀琀愀琀椀猀琀椀挀猀 漀昀 栀漀眀 昀爀攀焀甀攀渀琀氀礀 愀渀 椀渀搀攀砀 椀猀 愀挀挀攀猀猀攀搀Ⰰ㰀戀爀㸀ഀഀ
as well as how many times it is accessed.<br>਍㰀戀爀㸀㰀⼀氀椀㸀ഀഀ
਍㰀氀椀㸀㰀䈀㸀猀礀猀⸀搀洀开搀戀开洀椀猀猀椀渀最开椀渀搀攀砀开搀攀琀愀椀氀猀 ⠀瘀椀攀眀⤀㰀⼀䈀㸀 挀漀渀琀愀椀渀猀 爀攀挀漀爀搀猀 漀昀 瀀漀猀猀椀戀氀攀 椀渀搀攀砀攀猀 琀栀愀琀 琀栀攀 漀瀀琀椀洀椀稀攀爀 洀椀最栀琀 㰀戀爀㸀ഀഀ
be able to take advantage of, but that not exist within the database. So, they might be candidates to create.<br>਍㰀戀爀㸀㰀⼀氀椀㸀 ഀഀ
</ol>਍㰀戀爀㸀ഀഀ
<B><U>4.2.1 The "sysindexes" VIEW:</U></B>:<br>਍㰀戀爀㸀ഀഀ
Let's take a look to a usefull query, using this "old" systemview.<br>਍䰀攀琀✀猀 琀爀礀 琀栀攀 昀漀氀氀漀眀椀渀最⸀ 䤀琀 猀栀漀眀猀 愀氀氀 琀愀戀氀攀猀 眀椀琀栀 愀氀氀 琀栀攀椀爀 椀渀搀攀砀攀猀Ⰰ 眀椀琀栀 琀栀攀椀爀 椀渀搀攀砀开椀搀✀猀 愀渀搀 渀甀洀戀攀爀 漀昀 爀漀眀猀⸀㰀戀爀㸀ഀഀ
The list is sorted by the number of rows, listing the largest first.<br>਍㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
USE YOUR_DATABASE_NAME   -- for example: USE SALES<br>਍䜀伀㰀戀爀㸀ഀഀ
<br>਍匀䔀䰀䔀䌀吀㰀戀爀㸀 ഀഀ
substring(sysobjects.name,1,40) AS TABLENAME, <br>਍猀甀戀猀琀爀椀渀最⠀猀礀猀椀渀搀攀砀攀猀⸀渀愀洀攀Ⰰ㄀Ⰰ㐀　⤀ 䄀匀 䤀一䐀䔀堀一䄀䴀䔀Ⰰ 㰀戀爀㸀ഀഀ
sysobjects.id, sysindexes.indid, sysindexes.groupid,sysindexes.rows<br>਍䘀刀伀䴀     猀礀猀漀戀樀攀挀琀猀Ⰰ 猀礀猀椀渀搀攀砀攀猀㰀戀爀㸀ഀഀ
WHERE    sysobjects.id=sysindexes.id<br>਍伀刀䐀䔀刀 䈀夀 猀礀猀椀渀搀攀砀攀猀⸀爀漀眀猀 搀攀猀挀㰀戀爀㸀ഀഀ
GO<br>਍㰀戀爀㸀ഀഀ
In the figure below, you can see some example output:<br>਍㰀戀爀㸀ഀഀ
<img src="sql7.jpg" align="center"/>਍㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<I>Note: In the actual real output, you will see the systemviews as well.</I><br>਍㰀戀爀㸀ഀഀ
Actually, it's a neat list. You can see all tables with their associated indexes.<br>਍吀栀攀 椀渀搀攀砀攀猀 眀栀椀挀栀 愀爀攀 愀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀Ⰰ 栀愀瘀攀 愀渀 ∀椀渀搀椀搀∀ 漀昀 ∀㄀∀Ⰰ 氀椀欀攀 ∀瀀欀戀漀戀开瀀爀椀挀攀∀㰀戀爀㸀ഀഀ
Remember that the (leafpages of) clustered indexes are actually the tablepages themselves.<br>਍㰀戀爀㸀ഀഀ
Also note that the table called "VALUE" is a "heap", with an indid of "0". It does not have a clustered index.<br>਍䈀攀挀愀甀猀攀 琀栀椀猀 琀愀戀氀攀 椀猀 愀 栀攀愀瀀Ⰰ 椀琀 椀猀 氀椀猀琀攀搀 愀猀 ∀渀甀氀氀∀ 愀琀 琀栀攀 椀渀搀攀砀渀愀洀攀 挀漀氀甀洀渀⸀ 䈀甀琀 琀栀攀 琀愀戀氀攀 栀愀猀 㔀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀Ⰰ㰀戀爀㸀ഀഀ
and thats why you see the tablename repeated.<br>਍㰀戀爀㸀ഀഀ
It's also nice to have a list of the number of rows of the indexes.<br>਍㰀戀爀㸀ഀഀ
So, this query shows you the tablename, with all index names associated with that table,<br>਍愀猀 眀攀氀氀 愀猀 琀栀攀 漀戀樀攀挀琀开椀搀 漀昀 琀栀攀 琀愀戀氀攀Ⰰ 琀栀攀 椀渀搀攀砀开椀搀 漀昀 琀栀漀猀攀 椀渀搀攀砀攀猀Ⰰ 愀渀搀 琀栀攀 渀甀洀戀攀爀 漀昀 爀漀眀猀 椀渀 愀氀氀 栀攀愀瀀猀Ⰰ㰀戀爀㸀ഀഀ
clustered indexes and non-clustered indexes.<br>਍㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀㰀唀㸀㐀⸀㈀⸀㈀ 吀栀攀 ∀猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开漀瀀攀爀愀琀椀漀渀愀氀开猀琀愀琀猀∀ 䘀唀一䌀吀䤀伀一㨀㰀⼀唀㸀㰀⼀䈀㸀㨀㰀戀爀㸀ഀഀ
<br>਍䄀 昀甀渀挀琀椀漀渀 椀猀 渀漀琀 琀栀攀 猀愀洀攀 愀猀 愀 瘀椀攀眀Ⰰ 漀昀挀漀甀爀猀攀⸀ 䈀甀琀Ⰰ 礀漀甀 甀猀攀 琀栀攀洀 渀漀琀 椀渀 愀 洀甀挀栀 搀椀昀昀攀爀攀渀琀 眀愀礀 愀猀 愀 瘀椀攀眀⸀㰀戀爀㸀ഀഀ
In both case you make statements like <B>"SELECT .. FROM [view|function ].</B><br>਍伀渀氀礀Ⰰ 愀 昀甀渀挀琀椀漀渀 漀昀琀攀渀 攀砀瀀攀挀琀猀 ∀瀀愀爀愀洀攀琀攀爀猀∀ 氀椀欀攀 椀渀 ∀昀甀渀挀琀椀漀渀渀愀洀攀⠀瀀愀爀愀洀攀琀攀爀猀⤀Ⰰ 眀栀攀爀攀 琀栀攀 瀀愀爀愀洀攀琀攀爀猀 洀椀最栀琀 戀攀㰀戀爀㸀ഀഀ
an "object_id", "index_id", or a "database_id" etc..<br>਍㰀戀爀㸀ഀഀ
- If you specify all parameters, it usually means you need information of one object only.<br>਍ⴀ 䤀渀 洀愀渀礀 挀愀猀攀猀Ⰰ 瀀愀爀愀洀攀琀攀爀猀 洀愀礀 琀愀欀攀 漀渀 ∀一唀䰀䰀∀Ⰰ 眀栀椀挀栀 洀攀愀渀猀 礀漀甀 最攀琀 椀渀昀漀爀洀愀琀椀漀渀 漀昀 洀漀爀攀 漀戀樀攀挀琀猀Ⰰ 漀爀 攀瘀攀渀 愀氀氀 漀戀樀攀挀琀猀⸀㰀戀爀㸀 ഀഀ
<br>਍䰀攀琀✀猀 猀攀攀 栀漀眀 眀攀 挀愀渀 甀猀攀 琀栀攀 ∀猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开漀瀀攀爀愀琀椀漀渀愀氀开猀琀愀琀猀∀ 昀甀渀挀琀椀漀渀⸀㰀戀爀㸀ഀഀ
A short description of this function is: <I>Contains one row for each index,<br>਍愀渀搀 愀最最爀攀最愀琀攀猀 琀栀攀 渀甀洀戀攀爀 漀昀 氀攀愀昀 愀渀搀 渀漀渀ⴀ氀攀愀昀 椀渀猀攀爀琀猀Ⰰ 甀瀀搀愀琀攀猀Ⰰ 搀攀氀攀琀攀猀Ⰰ 愀氀漀渀最 眀椀琀栀 瀀愀最攀 氀愀琀挀栀 猀琀愀琀椀猀琀椀挀猀⸀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍吀栀愀琀✀猀 瘀攀爀礀 椀渀琀攀爀攀猀琀椀渀最Ⰰ 戀攀挀愀甀猀攀 栀攀爀攀 礀漀甀 愀爀攀 愀戀氀攀 琀漀 攀砀琀爀愀挀琀 椀渀昀漀爀洀愀琀椀漀渀 眀栀攀琀栀攀爀 愀渀 椀渀搀攀砀 椀猀 洀甀挀栀 甀猀攀搀 漀爀 渀漀琀⸀㰀戀爀㸀ഀഀ
Syntax of the function:<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开漀瀀攀爀愀琀椀漀渀愀氀开猀琀愀琀猀 ⠀㰀戀爀㸀ഀഀ
    { database_id | NULL | 0 | DEFAULT }<br>਍    Ⰰ 笀 漀戀樀攀挀琀开椀搀 簀 一唀䰀䰀 簀 　 簀 䐀䔀䘀䄀唀䰀吀 紀㰀戀爀㸀ഀഀ
    , { index_id | 0 | NULL | -1 | DEFAULT }<br>਍    Ⰰ 笀 瀀愀爀琀椀琀椀漀渀开渀甀洀戀攀爀 簀 一唀䰀䰀 簀 　 簀 䐀䔀䘀䄀唀䰀吀 紀㰀戀爀㸀ഀഀ
)<br>਍㰀戀爀㸀ഀഀ
਍䠀攀爀攀 椀猀 愀渀 攀砀愀洀瀀氀攀 焀甀攀爀礀㨀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀ഀഀ
SELECT database_id, object_name(object_id), index_id, leaf_insert_count, leaf_delete_count,<br>਍渀漀渀氀攀愀昀开搀攀氀攀琀攀开挀漀甀渀琀Ⰰ 渀漀渀氀攀愀昀开甀瀀搀愀琀攀开挀漀甀渀琀 䘀刀伀䴀 㰀䤀㸀ⴀⴀ 洀愀渀礀 洀漀爀攀 挀漀氀甀洀渀猀 挀漀甀氀搀 栀愀瘀攀 戀攀攀渀 挀栀漀猀攀渀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
sys.dm_db_index_operational_stats(DB_ID('eximius_production_data'), OBJECT_iD('VALUE'),NULL,NULL)</B><br>਍㰀戀爀㸀ഀഀ
<I>Meaning that from the 'eximius_production_data' database, you want operational stats of all indexes<br>਍愀猀猀漀挀椀愀琀攀搀 琀漀 琀栀攀 ✀嘀䄀䰀唀䔀✀ 琀愀戀氀攀⸀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
<font face="arial" size=2 color="black">਍ഀഀ
<img src="sql9.jpg" align="center"/>਍㰀戀爀㸀ഀഀ
<br>਍一漀眀Ⰰ 猀甀瀀瀀漀猀攀 礀漀甀爀 瀀爀漀搀甀挀琀椀漀渀 搀愀琀愀戀愀猀攀 栀愀猀 愀 搀愀琀愀戀愀猀攀开椀搀 漀昀 ✀㔀✀ ⠀攀愀猀礀 琀漀 昀椀渀搀 眀椀琀栀 ∀猀攀氀攀挀琀 搀愀琀愀戀愀猀攀开椀搀Ⰰ 渀愀洀攀 昀爀漀洀 猀礀猀⸀搀愀琀愀戀愀猀攀猀∀⤀㰀戀爀㸀ഀഀ
Now suppose you want operational stats of all indexes of all tables, then use this <B>really nice query</B>:<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍㰀䈀㸀匀䔀䰀䔀䌀吀 搀愀琀愀戀愀猀攀开椀搀Ⰰ 漀戀樀攀挀琀开渀愀洀攀⠀漀戀樀攀挀琀开椀搀⤀Ⰰ 椀渀搀攀砀开椀搀Ⰰ 氀攀愀昀开椀渀猀攀爀琀开挀漀甀渀琀Ⰰ 氀攀愀昀开搀攀氀攀琀攀开挀漀甀渀琀Ⰰ㰀戀爀㸀ഀഀ
nonleaf_delete_count, nonleaf_update_count FROM <br>਍猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开漀瀀攀爀愀琀椀漀渀愀氀开猀琀愀琀猀⠀㔀Ⰰ 一唀䰀䰀Ⰰ一唀䰀䰀Ⰰ一唀䰀䰀⤀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
Notes:<br>਍ⴀ 伀昀挀漀甀爀猀攀Ⰰ 礀漀甀 挀愀渀 攀砀琀攀渀搀 琀栀攀 焀甀攀爀礀 眀椀琀栀 愀 挀氀愀甀猀攀 氀椀欀攀 ∀伀刀䐀䔀刀 䈀夀 氀攀愀昀开椀渀猀攀爀琀开挀漀甀渀琀∀ 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
- Also make sure you try <B>"SELECT * FROM sys.dm_db_index_operational_stats(5, NULL,NULL,NULL)"</B>, just to see what<br>਍漀琀栀攀爀 挀漀氀甀洀渀猀 漀昀 椀渀昀漀爀洀愀琀椀漀渀 挀愀渀 戀攀 攀砀琀爀愀挀琀攀搀⸀㰀戀爀㸀ഀഀ
<br>਍䤀渀 琀栀攀 愀戀漀瘀攀 琀眀漀 攀砀愀洀瀀氀攀 焀甀攀爀椀攀猀Ⰰ 眀攀 昀漀挀甀猀攀搀 漀渀 氀攀愀昀开椀渀猀攀爀琀开挀漀甀渀琀Ⰰ 氀攀愀昀开搀攀氀攀琀攀开挀漀甀渀琀 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
But this function will show you much information on "locks" and "contention" as well !<br>਍吀漀 昀椀渀搀 漀甀琀 椀昀 愀 挀攀爀琀愀椀渀 椀渀搀攀砀 椀猀 ∀甀猀攀搀 洀甀挀栀Ⰰ 漀爀 渀漀琀∀Ⰰ 礀漀甀 挀愀渀 挀漀洀瀀愀爀攀 琀栀攀 ∀挀漀甀渀琀∀ 挀漀氀甀洀渀猀 漀昀 琀栀攀 椀渀搀攀砀攀猀⸀㰀戀爀㸀ഀഀ
But there are many "wait" columns too, giving clues to if a certain index is a "hotspot".<br>਍䘀漀爀 礀漀甀爀 搀愀琀愀戀愀猀攀Ⰰ 琀爀礀 琀栀攀 昀甀渀挀琀椀漀渀 愀最愀椀渀Ⰰ 戀甀琀 琀栀椀猀 琀椀洀攀 愀氀猀漀 椀渀挀氀甀搀攀 琀栀攀 昀漀氀氀漀眀椀渀最 挀漀氀甀洀渀猀㨀㰀戀爀㸀ഀഀ
<br>਍㰀漀氀㸀ഀഀ
<li><B>row_lock_count:</B> Cumulative number of row locks requested.</li>਍㰀氀椀㸀㰀䈀㸀爀漀眀开氀漀挀欀开眀愀椀琀开挀漀甀渀琀㨀㰀⼀䈀㸀 䌀甀洀甀氀愀琀椀瘀攀 渀甀洀戀攀爀 漀昀 琀椀洀攀猀 琀栀攀 䐀愀琀愀戀愀猀攀 䔀渀最椀渀攀 眀愀椀琀攀搀 漀渀 愀 爀漀眀 氀漀挀欀⸀㰀⼀氀椀㸀ഀഀ
<li><B>row_lock_wait_in_ms:</B> Total number of milliseconds the Database Engine waited on a row lock. </li>਍㰀氀椀㸀㰀䈀㸀瀀愀最攀开氀漀挀欀开眀愀椀琀开椀渀开洀猀㨀㰀⼀䈀㸀 吀漀琀愀氀 渀甀洀戀攀爀 漀昀 洀椀氀氀椀猀攀挀漀渀搀猀 琀栀攀 䐀愀琀愀戀愀猀攀 䔀渀最椀渀攀 眀愀椀琀攀搀 漀渀 愀 瀀愀最攀 氀漀挀欀⸀ 㰀⼀氀椀㸀ഀഀ
</ol>਍㰀戀爀㸀ഀഀ
Then make lists of of all indexes, and compare the values among those indexes. This <I>will</I> give<br>਍礀漀甀 愀 最漀漀搀 椀搀攀愀 愀戀漀甀琀 栀漀琀猀瀀漀琀猀⸀ 䤀昀 礀漀甀 猀攀攀 洀甀氀琀椀瀀氀攀 椀渀搀攀砀攀猀 眀椀琀栀 氀漀渀最攀爀 眀愀椀琀猀Ⰰ 椀琀 洀椀最栀琀 戀攀 愀渀 椀渀搀椀挀愀琀椀漀渀㰀戀爀㸀ഀഀ
to move one or two to another filegroup.<br>.਍㰀戀爀㸀ഀഀ
਍㰀䈀㸀㰀唀㸀㐀⸀㈀⸀㌀ 吀栀攀 ∀猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开甀猀愀最攀开猀琀愀琀猀∀ 嘀䤀䔀圀㨀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍夀漀甀 猀栀漀甀氀搀 甀猀攀 琀栀椀猀 瘀椀攀眀 挀漀洀瀀氀攀洀攀渀琀愀爀礀 琀漀 琀栀攀 昀甀渀挀琀椀漀渀 椀渀 㐀⸀㈀⸀㈀⸀㰀戀爀㸀ഀഀ
The function from 4.2.2, shows you "waits" and leaf_insert_count, leaf_delete_count etc..<br>਍䈀甀琀 眀椀琀栀 琀栀椀猀 瘀椀攀眀Ⰰ 眀椀氀氀 猀攀攀 搀椀昀昀攀爀攀渀琀愀琀椀漀渀 戀攀琀眀攀攀渀 㰀䈀㸀甀猀攀爀开猀挀愀渀猀Ⰰ 甀猀攀爀开氀漀漀欀甀瀀猀Ⰰ 甀猀攀爀开甀瀀搀愀琀攀猀Ⰰ 氀愀猀琀开甀猀攀爀开猀攀攀欀Ⰰ氀愀猀琀开甀猀攀爀开猀挀愀渀Ⰰ氀愀猀琀开甀猀攀爀开氀漀漀欀甀瀀Ⰰ氀愀猀琀开甀猀攀爀开甀瀀搀愀琀攀 攀琀挀⸀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
So, it's really easy to find out if an index is usefull or not. If the "last_" columns only show old date/times,<br>਍琀栀攀渀 漀戀瘀椀漀甀猀氀礀Ⰰ 琀栀攀 椀渀搀攀砀 椀猀 渀漀琀 甀猀攀搀⸀ 㰀䈀㸀䤀琀 洀愀礀 攀瘀攀渀 戀攀 愀 挀愀渀搀椀搀愀琀攀 琀漀 搀攀氀攀琀攀 椀琀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
਍䈀甀琀 渀漀琀 猀漀 昀愀猀琀⸀ 䴀愀礀戀攀 琀栀攀 ∀猀琀愀琀椀猀琀椀挀猀∀ 愀爀攀 猀漀 氀漀甀猀礀Ⰰ 琀栀愀琀 琀栀攀 漀瀀琀椀洀椀稀攀爀 搀漀攀猀 渀漀琀 挀漀渀猀椀搀攀爀 椀琀⸀㰀戀爀㸀ഀഀ
But if you are sure the "statistics" are up to date, and the "user_" and "last_" show small or old values,<br>਍琀栀攀渀 挀漀渀猀椀搀攀爀 搀攀氀攀琀椀漀渀 漀昀 琀栀愀琀 椀渀搀攀砀⸀㰀戀爀㸀ഀഀ
<br>਍一漀琀攀 琀栀愀琀 琀栀椀猀 瘀椀攀眀 爀攀最椀猀琀攀爀猀 猀琀愀琀椀猀琀椀挀猀 漀昀 愀氀氀 椀渀搀攀砀攀猀 漀昀 愀氀氀 搀愀琀愀戀愀猀攀猀⸀ 匀漀Ⰰ 瀀爀漀戀愀戀氀礀 礀漀甀 眀愀渀琀 琀漀 甀猀攀㰀戀爀㸀ഀഀ
a "WHERE" clause that specifies your database (id) of interest.<br>਍䄀氀猀漀Ⰰ 琀栀攀 焀甀攀爀礀 洀椀最栀琀 琀愀欀攀 猀漀 琀椀洀攀 琀漀 爀甀渀 椀渀 愀 瘀攀爀礀 氀愀爀最攀 搀愀琀愀戀愀猀攀Ⰰ 猀漀 昀椀爀猀琀 攀砀瀀攀爀椀洀攀渀琀 愀 戀椀琀 漀渀 琀攀猀琀猀礀猀琀攀洀猀⸀㰀戀爀㸀ഀഀ
<br>਍匀椀渀挀攀 椀琀猀 愀 瘀椀攀眀Ⰰ 甀猀攀 ∀匀䔀䰀䔀䌀吀 ⨀ 䘀刀伀䴀 猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开甀猀愀最攀开猀琀愀琀猀 圀䠀䔀刀䔀 搀愀琀愀戀愀猀攀开椀搀㴀㰀琀栀攀开搀愀琀愀戀愀猀攀开椀搀㸀∀⸀㰀戀爀㸀ഀഀ
From that, browse the columns that are interesting, and adjust your query accordingly, possibly with clauses like<br>਍∀甀猀攀爀开甀瀀搀愀琀攀猀㸀渀∀Ⰰ 漀爀 ∀伀刀䐀䔀刀 䈀夀 甀猀攀爀开甀瀀搀愀琀攀猀∀ 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
<br>਍夀漀甀 爀攀愀氀氀礀  渀攀攀搀 琀漀 瀀氀愀礀 眀椀琀栀 琀栀椀猀 瘀椀攀眀 愀 戀椀琀Ⰰ 琀漀 愀瀀瀀爀攀挀椀愀琀攀 琀栀攀 椀渀昀漀爀洀愀琀椀漀渀 礀漀甀 挀愀渀 最攀琀⸀㰀戀爀㸀ഀഀ
<br>਍ഀഀ
<br>਍㰀䈀㸀㰀唀㸀㐀⸀㈀⸀㐀 吀栀攀 ∀猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开瀀栀礀猀椀挀愀氀开猀琀愀琀猀∀ 䘀唀一䌀吀䤀伀一㨀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍夀漀甀 渀漀琀椀挀攀 琀栀攀 ∀瀀栀礀猀椀挀愀氀开猀琀愀琀猀∀ 椀渀 琀栀攀 渀愀洀攀 漀昀 琀栀椀猀 昀甀渀挀琀椀漀渀㼀 䤀渀搀攀攀搀Ⰰ 琀栀椀猀 昀甀渀挀琀椀漀渀 眀椀氀氀 爀攀瘀攀愀氀 琀漀 甀猀㰀戀爀㸀ഀഀ
how index pages are filled with rows, and what their average fragmentation level is.<br>਍㰀戀爀㸀ഀഀ
<img src="sql10.jpg" align="center"/>਍㰀戀爀㸀ഀഀ
<h3>4.3 How to move a hotspot index to another Filegroup: </h3>਍ഀഀ
Important:<br>਍㰀漀氀㸀ഀഀ
<li>Make sure you have scripted your objects, that is, have the create scripts of all objects.</li><br>਍㰀氀椀㸀䴀漀瘀椀渀最 氀愀爀最攀 椀渀搀攀砀攀猀Ⰰ 挀漀猀琀 愀 氀漀琀 漀昀 瀀攀爀昀漀爀洀愀渀挀攀 愀渀搀 眀椀氀氀 琀愀欀攀 琀椀洀攀⸀ 圀椀琀栀 琀栀攀 䔀渀琀攀爀瀀爀椀猀攀 䔀搀椀琀椀漀渀Ⰰ 琀栀攀漀爀攀琀椀挀愀氀氀礀㰀戀爀㸀ഀഀ
you can do it "ONLINE", but, for example, you don't want to move a 700 million row index while the users are busy.</li><br>਍㰀⼀漀氀㸀 ഀഀ
<br>਍倀攀爀猀漀渀愀氀氀礀Ⰰ 䤀 琀栀椀渀欀 琀栀愀琀 洀漀瘀椀渀最 漀戀樀攀挀琀猀 氀椀欀攀 琀愀戀氀攀猀 愀渀搀 椀渀搀攀砀攀猀 琀漀 漀琀栀攀爀 琀愀戀氀攀猀瀀愀挀攀猀Ⰰ 椀猀 焀甀椀琀攀 攀愀猀礀 椀渀 伀爀愀挀氀攀⸀㰀戀爀㸀ഀഀ
Ofcouse, the methods exist in SQL Server too, but here it's somewhat more elaborate.<br>਍㰀戀爀㸀ഀഀ
Anyway, if you move an index from one filegroup to another filegroup, there might be a mean rattlesnake in the grass.<br>਍䔀猀猀攀渀琀椀愀氀氀礀Ⰰ 洀漀瘀椀渀最 愀渀 攀砀椀猀琀椀渀最 椀渀搀攀砀Ⰰ 洀攀愀渀猀 搀爀漀瀀瀀椀渀最 椀琀 愀渀搀 琀栀攀渀 爀攀挀爀攀愀琀椀渀最 椀琀⸀㰀戀爀㸀ഀഀ
Now, if this index supports some Constraint, like a Primary key, or PK-FK relations, you must enable them again!<br>਍䤀琀 椀猀 攀愀猀礀 琀漀 昀漀爀最攀琀 琀栀椀猀Ⰰ 戀攀挀愀甀猀攀 洀漀瘀椀渀最 愀渀 椀渀搀攀砀 ∀氀漀漀欀猀∀ 氀椀欀攀 愀 猀椀渀最氀攀 愀挀琀椀漀渀⸀ 䤀琀 椀猀Ⰰ 愀猀 氀漀渀最 琀栀攀爀攀 愀爀攀 渀漀㰀戀爀㸀ഀഀ
constraints involved.<br>਍䄀氀琀栀漀甀最栀Ⰰ 琀爀礀椀渀最 琀漀 攀砀瀀氀椀挀椀琀氀礀 搀爀漀瀀瀀椀渀最 愀渀 椀渀搀攀砀 ⠀眀椀琀栀 琀栀攀 䐀刀伀倀 䤀一䐀䔀堀 猀琀愀琀攀洀攀渀琀⤀ 琀栀愀琀 猀甀瀀瀀漀爀琀猀 愀 倀爀椀洀愀爀礀 欀攀礀Ⰰ 眀椀氀氀 戀攀 搀攀渀椀攀搀㰀戀爀㸀ഀഀ
by the Database Engine. But, other statements (like ALTER INDEX) will work.<br>਍㰀戀爀㸀ഀഀ
In reality, before you do anything, make sure you script the database. That means that SQL Server will script<br>਍愀氀氀 挀爀攀愀琀攀 猀琀愀琀攀洀攀渀琀猀 眀椀琀栀 爀攀猀瀀攀挀琀 琀漀 琀愀戀氀攀猀Ⰰ 椀渀搀攀砀攀猀Ⰰ 挀漀渀猀琀爀愀椀渀琀猀Ⰰ 琀爀椀最最攀爀猀Ⰰ 攀琀挀⸀⸀ 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
This way, you just have an ascii file with all create statements, and if you need it, you can easily retrieve<br>਍昀漀爀 攀砀愀洀瀀氀攀Ⰰ 愀渀 椀渀搀攀砀 挀爀攀愀琀攀 猀琀愀琀攀洀攀渀琀 攀琀挀⸀⸀ 眀椀琀栀漀甀琀 琀栀愀琀 礀漀甀 渀攀攀搀 琀漀 ∀爀攀洀攀洀戀攀爀∀ 眀栀椀挀栀 挀漀氀甀洀渀猀 眀攀爀攀 椀渀瘀漀氀瘀攀搀⸀ഀഀ
It's easy to do that: just browse around a bit in SQL Server Management Studio (SSMS).<br>਍⠀䨀甀猀琀 爀椀最栀琀挀氀椀挀欀 礀漀甀爀 搀愀琀愀戀愀猀攀 ⴀ㸀 挀栀漀漀猀攀 吀愀猀欀猀 ⴀ㸀 挀栀漀漀猀攀 䜀攀渀攀爀愀琀攀 匀挀爀椀瀀琀猀⤀㰀戀爀㸀ഀഀ
<br>਍一漀琀攀㨀 䴀愀渀礀 瀀爀漀昀攀猀猀椀漀渀愀氀 猀礀猀琀攀洀猀Ⰰ 栀愀瘀攀 猀漀洀攀 猀漀爀琀 漀昀 爀攀瀀漀猀椀琀漀爀礀Ⰰ 搀攀猀挀爀椀戀椀渀最 愀氀氀 漀戀樀攀挀琀猀Ⰰ 椀渀挀氀甀搀椀渀最 琀栀攀 吀匀儀䰀 挀爀攀愀琀攀 猀琀愀琀攀洀攀渀琀猀⸀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀一漀眀Ⰰ 栀漀眀 琀漀 洀漀瘀攀 愀渀 琀愀戀氀攀 愀渀搀 漀爀 愀渀 椀渀搀攀砀 琀漀 愀渀漀琀栀攀爀 昀椀氀攀最爀漀甀瀀㼀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍䰀攀琀✀猀 爀攀瘀椀攀眀 椀渀 愀 昀攀眀 猀椀洀瀀氀攀 攀砀愀洀瀀氀攀猀Ⰰ 栀漀眀 椀渀搀攀砀攀猀 愀爀攀 挀爀攀愀琀攀搀 漀渀 愀渀 攀砀椀猀琀椀渀最 琀愀戀氀攀⸀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
Lets make a simple example table:<br>਍㰀戀爀㸀ഀഀ
CREATE TABLE dbo.Customers<br>਍⠀㰀戀爀㸀ഀഀ
Cust_id     int         NOT NULL,<br>਍䌀甀猀琀开渀愀洀攀   瘀愀爀挀栀愀爀⠀㈀　⤀ 一伀吀 一唀䰀䰀Ⰰ㰀戀爀㸀ഀഀ
Address     varchar(30),<br>਍䌀椀琀礀        瘀愀爀挀栀愀爀⠀㈀　⤀Ⰰ㰀戀爀㸀ഀഀ
Country     varchar(20)<br>਍⤀ 㰀戀爀㸀ഀഀ
ON FG_DATA                            -- The filegroup FG_DATA for storage of tables<br>਍䜀伀㰀戀爀㸀ഀഀ
<br>਍ⴀ 䌀氀甀猀琀攀爀攀搀㨀㰀戀爀㸀ഀഀ
<br>਍䌀刀䔀䄀吀䔀 䌀䰀唀匀吀䔀刀䔀䐀 䤀一䐀䔀堀 椀渀搀砀开攀洀瀀氀漀礀攀攀开攀洀瀀开椀搀 伀一 䔀䴀倀䰀伀夀䔀䔀⠀䔀䴀倀开䤀䐀⤀㰀戀爀㸀ഀഀ
<br>  ਍㰀戀爀㸀ഀഀ
- non-clustered:<br>਍㰀戀爀㸀ഀഀ
CREATE NONCLUSTERED INDEX indx_employee_empname ON EMPLOYEE(EMP_NAME)<br>਍伀一 䘀䜀开䤀一䐀䔀堀 ⴀⴀ 吀栀攀 昀椀氀攀最爀漀甀瀀 䘀䜀开䤀一䐀䔀堀 昀漀爀 猀琀漀爀愀最攀 漀昀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀㰀戀爀㸀ഀഀ
<br>਍伀爀 琀栀攀 䤀渀搀攀砀 䌀爀攀愀琀攀 猀琀愀琀攀洀攀渀琀 椀渀 愀 猀氀椀最栀琀氀礀 最攀渀攀爀愀氀椀稀攀搀 昀漀爀洀㨀㰀戀爀㸀ഀഀ
<br>਍䌀刀䔀䄀吀䔀 嬀䌀䰀唀匀吀䔀刀䔀䐀 簀 一伀一䌀䰀唀匀吀䔀刀䔀䐀崀 䤀一䐀䔀堀 㰀椀渀搀攀砀开渀愀洀攀㸀 伀一 吀䄀䈀䰀䔀一䄀䴀䔀⠀挀漀氀甀洀渀㄀Ⰰ 挀漀氀甀洀渀㈀Ⰰ⸀⸀⸀⤀ 嬀伀一 昀椀氀攀最爀漀甀瀀开渀愀洀攀崀㰀戀爀㸀ഀഀ
<font face="arial" size=2 color="black">਍㰀戀爀㸀ഀഀ
Note that I did not use the "ON FG_INDEX" clause with the clustered index create statement.<br>਍䤀 㰀䤀㸀挀漀甀氀搀㰀⼀䤀㸀 栀愀瘀攀 搀漀渀攀 琀栀愀琀Ⰰ 戀甀琀 琀栀愀琀 眀漀甀氀搀 椀洀瀀氀礀 琀栀愀琀 䤀 ∀洀漀瘀攀搀∀ 琀栀攀 琀愀戀氀攀 琀漀 琀栀愀琀 昀椀氀攀最爀漀甀瀀⸀㰀戀爀㸀ഀഀ
Again, the table (in simple words) is actually the same as the clustered index.<br>਍㰀戀爀㸀ഀഀ
So, we can immediately conclude the following:<br>਍㰀戀爀㸀ഀഀ
<B>1. How to "move" a table with a clustered index to another filegroup:</B><br>਍㰀戀爀㸀ഀഀ
DROP the clustered index. Create the Clustered Index again with Filegroup clause pointing to the right filegroup.<br>਍㰀戀爀㸀ഀഀ
<B>2. How to "move" a clustered index to another filegroup:</B><br>਍㰀戀爀㸀ഀഀ
Ofcourse, it's the same as above.<br>਍㰀戀爀㸀ഀഀ
You cannot move indexes supporting a unique or primary key constraint, using a DROP statement.<br> ਍䄀猀 眀攀 眀椀氀氀 猀攀攀 氀愀琀攀爀 漀渀Ⰰ 琀漀 洀漀瘀攀 琀栀攀猀攀 椀渀搀攀砀攀猀Ⰰ 眀攀 洀甀猀琀 甀猀攀 琀栀攀 䌀刀䔀䄀吀䔀 䤀一䐀䔀堀 猀琀愀琀攀洀攀渀琀 眀椀琀栀 琀栀攀 ⠀䐀刀伀倀开䔀堀䤀匀吀䤀一䜀㴀伀一⤀ 漀瀀琀椀漀渀⸀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀㌀⸀ 䠀漀眀 琀漀 ∀洀漀瘀攀∀ 愀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 琀漀 愀渀漀琀栀攀爀 昀椀氀攀最爀漀甀瀀㨀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍䐀刀伀倀 琀栀攀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀⸀ 䌀爀攀愀琀攀 琀栀攀 渀漀渀ⴀ䌀氀甀猀琀攀爀攀搀 䤀渀搀攀砀 愀最愀椀渀 眀椀琀栀 䘀椀氀攀最爀漀甀瀀 挀氀愀甀猀攀 瀀漀椀渀琀椀渀最 琀漀 琀栀攀 爀椀最栀琀 昀椀氀攀最爀漀甀瀀⸀㰀戀爀㸀ഀഀ
<br>਍吀栀攀 瀀漀椀渀琀猀 ㈀ 愀渀搀 ㌀ 愀爀攀 最爀攀愀琀Ⰰ 椀昀 礀漀甀 眀漀甀氀搀 栀愀瘀攀 琀栀攀 漀爀椀最椀渀愀氀 䌀刀䔀䄀吀䔀 猀琀愀琀攀洀攀渀琀猀 漀昀 琀栀漀猀攀 椀渀搀攀砀攀猀⸀㰀戀爀㸀ഀഀ
But there exists another method too. This is by using the "CREATE INDEX .. (DROP_EXISTING=ON).. ON [filegroup_name]" statement  <br>਍㰀戀爀㸀ഀഀ
<B>4. Alternative method for "moving" a clustered or non-clustered index to another filegroup:</B><br>਍㰀戀爀㸀ഀഀ
As a generic example for using the CREATE INDEX .. (DROP_EXISTING=ON) statement, take a look at the following syntax:<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍䌀刀䔀䄀吀䔀 嬀一伀一崀䌀䰀唀匀吀䔀刀䔀䐀 䤀一䐀䔀堀 䤀一䐀䔀堀开一䄀䴀䔀㰀戀爀㸀ഀഀ
ON TABLE_NAME(column1, column2,...)<br> ਍圀䤀吀䠀 䐀刀伀倀开䔀堀䤀匀吀䤀一䜀 㰀戀爀㸀ഀഀ
ON [filegroup_name] <br>਍㰀戀爀㸀ഀഀ
<font face="arial" size=2 color="black">਍䤀昀 琀栀攀 椀渀搀攀砀 攀渀昀漀爀挀攀猀 愀 倀刀䤀䴀䄀刀夀 䬀䔀夀 漀爀 唀一䤀儀唀䔀 挀漀渀猀琀爀愀椀渀琀 愀渀搀 琀栀攀 椀渀搀攀砀 搀攀昀椀渀椀琀椀漀渀 ⠀眀栀椀挀栀 挀漀氀甀洀渀猀⤀ 椀猀 渀漀琀 愀氀琀攀爀攀搀 椀渀 愀渀礀 眀愀礀Ⰰ㰀戀爀㸀ഀഀ
the index is dropped and re-created, and will preserve the existing constraint.਍㰀戀爀㸀ഀഀ
If you want a list of Primary, Unique, and Foreign key constraints, you might want to play with the following queries:<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍ഀഀ
select * FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS<br>਍猀攀氀攀挀琀 ⨀ 䘀刀伀䴀 䤀一䘀伀刀䴀䄀吀䤀伀一开匀䌀䠀䔀䴀䄀⸀䌀伀一匀吀刀䄀䤀一吀开吀䄀䈀䰀䔀开唀匀䄀䜀䔀㰀戀爀㸀ഀഀ
select * FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS<br>਍㰀戀爀㸀ഀഀ
਍匀䔀䰀䔀䌀吀 猀甀戀猀琀爀椀渀最⠀漀戀樀攀挀琀开渀愀洀攀⠀挀漀渀猀琀椀搀⤀Ⰰ ㄀Ⰰ 㐀　⤀ 䄀匀 䘀䬀Ⰰ㰀戀爀㸀ഀഀ
       substring(object_name(fkeyid), 1, 40)  AS "Referencing Table",<br>਍       猀甀戀猀琀爀椀渀最⠀漀戀樀攀挀琀开渀愀洀攀⠀爀欀攀礀椀搀⤀Ⰰ ㄀Ⰰ 㐀　⤀  䄀匀 ∀刀攀昀攀爀攀渀挀攀搀 吀愀戀氀攀∀㰀戀爀㸀ഀഀ
FROM   sysreferences<br>਍伀刀䐀䔀刀 䈀夀 漀戀樀攀挀琀开渀愀洀攀⠀爀欀攀礀椀搀⤀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍ഀഀ
<br>਍㰀戀爀㸀ഀഀ
<h3>4.4 Quick check on the effectiveness of your indexes: </h3>਍ഀഀ
In section 4.2.3, we have touched the "sys.dm_db_index_usage_stats" Dynamic Management View.<br>਍吀栀椀猀 瘀椀攀眀 猀栀漀眀猀 甀猀 洀愀渀礀 椀渀琀攀爀爀攀猀琀椀渀最 昀愀挀琀猀 氀椀欀攀 ∀甀猀攀爀开猀挀愀渀猀∀Ⰰ ∀甀猀攀爀开氀漀漀欀甀瀀猀∀ 攀琀挀⸀⸀Ⰰ 猀漀 椀琀 最椀瘀攀猀 甀猀 愀 最漀漀搀 椀搀攀愀㰀戀爀㸀ഀഀ
on the usage, or the effectivity, of an index.<br>਍㰀戀爀㸀ഀഀ
- In general, if an index has a relatively high number of "reads", compared to the "writes", that is a clue<br>਍琀栀愀琀 琀栀攀 椀渀搀攀砀 椀猀 甀猀攀搀 洀甀挀栀⸀  匀漀Ⰰ 椀琀✀猀 瀀爀漀戀愀戀礀 愀渀 攀昀昀攀挀琀椀瘀攀 椀渀搀攀砀⸀㰀戀爀㸀ഀഀ
So, if the "total Reads" > "total Writes", it's a good index.<br>਍㰀戀爀㸀ഀഀ
- Also, if an index has a relatively high number of "writes", compared to the "reads", that is a clue<br>਍琀栀愀琀 琀栀攀 椀渀搀攀砀 椀猀 一伀吀 甀猀攀搀 洀甀挀栀⸀  匀漀Ⰰ 椀琀✀猀 瀀爀漀戀愀戀氀礀 愀渀 椀渀攀昀昀攀挀琀椀瘀攀 椀渀搀攀砀⸀㰀戀爀㸀ഀഀ
If there are little reads, but many writes, the system is busy updating the index, without that users are using it.<br>਍夀漀甀 欀渀漀眀 琀栀愀琀 眀爀椀琀攀猀 琀漀 愀渀 椀渀搀攀砀 洀攀愀渀猀 甀瀀搀愀琀椀渀最 椀琀⸀ 刀攀愀搀椀渀最 愀渀 椀渀搀攀砀 洀攀愀渀猀 琀栀愀琀 愀 焀甀攀爀礀 椀猀 甀猀椀渀最 椀琀⸀㰀戀爀㸀ഀഀ
So, if the "total Writes" > "total Reads", the index only spills performance, and it's not a good index.<br>਍㰀戀爀㸀ഀഀ
Here is a handy query that produces a list of the indexes in a Database, including the <B>Reads from</B>, and <B>writes to</B>, the indexes.<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍ഀഀ
SELECT OBJECT_NAME(s.[object_id]) AS [Table Name], i.name AS [Index Name], i.index_id,<br>਍        甀猀攀爀开甀瀀搀愀琀攀猀 䄀匀 嬀吀漀琀愀氀 圀爀椀琀攀猀崀Ⰰ 甀猀攀爀开猀攀攀欀猀 ⬀ 甀猀攀爀开猀挀愀渀猀 ⬀ 甀猀攀爀开氀漀漀欀甀瀀猀 䄀匀 嬀吀漀琀愀氀 刀攀愀搀猀崀Ⰰ㰀戀爀㸀ഀഀ
        user_updates - (user_seeks + user_scans + user_lookups) AS [Difference]<br>਍䘀刀伀䴀 㰀䈀㸀猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开甀猀愀最攀开猀琀愀琀猀㰀⼀䈀㸀 䄀匀 猀 圀䤀吀䠀 ⠀一伀䰀伀䌀䬀⤀㰀戀爀㸀ഀഀ
INNER JOIN sys.indexes AS i WITH (NOLOCK)<br>਍伀一 猀⸀嬀漀戀樀攀挀琀开椀搀崀 㴀 椀⸀嬀漀戀樀攀挀琀开椀搀崀㰀戀爀㸀ഀഀ
AND i.index_id = s.index_id<br>਍圀䠀䔀刀䔀 伀䈀䨀䔀䌀吀倀刀伀倀䔀刀吀夀⠀猀⸀嬀漀戀樀攀挀琀开椀搀崀Ⰰ✀䤀猀唀猀攀爀吀愀戀氀攀✀⤀ 㴀 ㄀㰀戀爀㸀ഀഀ
AND s.database_id = DB_ID()<br>਍䄀一䐀 甀猀攀爀开甀瀀搀愀琀攀猀 㸀 ⠀甀猀攀爀开猀攀攀欀猀 ⬀ 甀猀攀爀开猀挀愀渀猀 ⬀ 甀猀攀爀开氀漀漀欀甀瀀猀⤀㰀戀爀㸀ഀഀ
AND i.index_id > 1 -- not the heap or clustered indexes<br>਍伀刀䐀䔀刀 䈀夀 嬀䐀椀昀昀攀爀攀渀挀攀崀 䐀䔀匀䌀Ⰰ 嬀吀漀琀愀氀 圀爀椀琀攀猀崀 䐀䔀匀䌀Ⰰ 嬀吀漀琀愀氀 刀攀愀搀猀崀 䄀匀䌀㬀㰀戀爀㸀ഀഀ
਍ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍一漀琀攀 栀漀眀 琀栀椀猀 焀甀攀爀礀 漀渀氀礀 甀猀攀猀 琀栀攀 ∀猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开甀猀愀最攀开猀琀愀琀猀∀ 䐀礀渀愀洀椀挀 䴀愀渀愀最攀洀攀渀琀 嘀椀攀眀⸀ഀഀ
<br>਍ഀഀ
<h3>4.5 How to Reorganize and Rebuild Indexes: </h3>਍ഀഀ
<B>4.5.1 How to detect Index Fragmentation:</B><br>਍㰀戀爀㸀ഀഀ
਍䔀猀瀀攀挀椀愀氀氀礀Ⰰ 琀栀攀 搀礀渀愀洀椀挀 洀愀渀愀最攀洀攀渀琀 昀甀渀挀琀椀漀渀 ∀猀礀猀⸀搀洀开搀戀开椀渀搀攀砀开瀀栀礀猀椀挀愀氀开猀琀愀琀猀∀ 挀愀渀 戀攀 漀昀 栀攀氀瀀 椀渀 搀攀琀攀爀洀椀渀椀渀最㰀戀爀㸀ഀഀ
if an index is too much fragmented or not.<br>਍㰀戀爀㸀ഀഀ
The function need a number of parameters, which might be left as "null".<br>਍吀栀攀 洀漀爀攀 瀀愀爀愀洀攀琀攀爀猀 礀漀甀 猀瀀攀挀椀昀礀 ⠀愀猀 渀漀琀 戀攀椀渀最 ∀渀甀氀氀∀⤀Ⰰ 琀栀攀 洀漀爀攀 猀瀀攀挀椀昀椀挀 琀栀攀 漀甀琀瀀甀琀 眀椀氀氀 戀攀⸀㰀戀爀㸀ഀഀ
<br>਍䤀渀 瀀愀爀琀椀挀甀氀愀爀Ⰰ 琀栀攀爀攀 愀爀攀 琀栀爀攀攀 瘀攀爀礀 甀猀攀昀甀氀氀 眀愀礀猀 琀漀 甀猀攀 琀栀攀 昀甀渀挀琀椀漀渀㨀㰀戀爀㸀 ഀഀ
<br>਍⠀㄀⤀ 䜀攀琀 琀栀攀 搀攀琀愀椀氀猀 ⠀愀 氀椀猀琀⤀ 漀昀 琀栀攀 昀爀愀最洀攀渀琀愀琀椀漀渀 氀攀瘀攀氀猀 漀昀 愀氀氀 椀渀搀攀砀攀猀 椀渀 愀 挀攀爀琀愀椀渀 䐀愀琀愀戀愀猀攀⸀㰀戀爀㸀ഀഀ
(2) Get the details of the fragmentation levels of all indexes of just one specific Table.<br>਍⠀㌀⤀ 䜀攀琀 琀栀攀 搀攀琀愀椀氀猀 漀昀 琀栀攀 昀爀愀最洀攀渀琀愀琀椀漀渀 氀攀瘀攀氀 漀昀 樀甀猀琀 漀渀攀 猀瀀攀挀椀昀椀挀 椀渀搀攀砀 漀昀 樀甀猀琀 漀渀攀 猀瀀攀挀椀昀椀挀 吀愀戀氀攀⸀㰀戀爀㸀ഀഀ
<br>਍䠀攀爀攀 愀爀攀 愀 昀攀眀 攀砀愀洀瀀氀攀猀㨀㰀戀爀㸀ഀഀ
਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍匀䔀䰀䔀䌀吀 椀渀搀攀砀开椀搀Ⰰ 愀瘀最开昀爀愀最洀攀渀琀愀琀椀漀渀开椀渀开瀀攀爀挀攀渀琀Ⰰ 愀瘀最开瀀愀最攀开猀瀀愀挀攀开甀猀攀搀开椀渀开瀀攀爀挀攀渀琀㰀戀爀㸀ഀഀ
FROM  sys.dm_db_index_physical_stats<B>(DB_ID('SALES'), OBJECT_ID('dbo.EMPLOYEE'),null,null,'DETAILED')</B><br>਍㰀戀爀㸀ഀഀ
SELECT SUBSTRING(OBJECT_NAME(object_id),1,30) AS NAME, index_id, SUBSTRING(index_type_desc,1,20) AS TYPE,<br>਍愀瘀最开昀爀愀最洀攀渀琀愀琀椀漀渀开椀渀开瀀攀爀挀攀渀琀Ⰰ 愀瘀最开昀爀愀最洀攀渀琀开猀椀稀攀开椀渀开瀀愀最攀猀 瀀愀最攀开挀漀甀渀琀㰀戀爀㸀 ഀഀ
FROM sys.dm_db_index_physical_stats<B>(DB_ID(N'SALES'), NULL, NULL, NULL , 'DETAILED')</B><br>਍㰀戀爀㸀ഀഀ
<font face="arial" size=2 color="black">਍ഀഀ
The first query, shows the fragmentation (column "avg_fragmentation_in_percent") of the indexes of the EMPLOYEE table only.<br> ਍㰀戀爀㸀ഀഀ
The second query, shows fragmentation information of all indexes (of all Tables) that exist in the SALES database.<br>਍㰀戀爀㸀ഀഀ
Note that the column "avg_fragmentation_in_percent" in the output, shows you the relevant information.<br>਍䤀渀 猀攀挀琀椀漀渀 㐀⸀㈀⸀㐀Ⰰ 礀漀甀 挀愀渀 昀椀渀搀 愀 爀攀愀氀 攀砀愀洀瀀氀攀Ⰰ 眀椀琀栀 攀砀愀洀瀀氀攀 漀甀琀瀀甀琀Ⰰ 漀昀 甀猀椀渀最 琀栀椀猀 昀甀渀挀琀椀漀渀⸀㰀戀爀㸀ഀഀ
<br>਍䄀挀挀漀爀搀椀渀最 琀漀 䴀椀挀爀漀猀漀昀琀 搀漀挀甀洀攀渀琀猀Ⰰ 礀漀甀 猀栀漀甀氀搀 刀攀戀甀椀氀搀 椀渀搀攀砀攀猀 眀栀攀渀 琀栀攀 愀瘀攀爀愀最攀 昀爀愀最洀攀渀琀愀琀椀漀渀 椀猀 栀椀最栀攀爀 琀栀愀渀Ⰰ 猀愀礀Ⰰ ㈀㔀 琀漀 ㌀　─⸀㰀戀爀㸀ഀഀ
You might consider Reorganizing indexes when the average fragmentation is between, say, 15 to 25%.<br>਍㰀戀爀㸀ഀഀ
For the smaller indexes, don't expect high improvements from rebuilding or reorganizing indexes.<br>਍䘀漀爀 氀愀爀最攀爀 椀渀搀攀砀攀猀Ⰰ 琀栀攀 椀洀瀀爀漀瘀攀洀攀渀琀 挀愀渀 戀攀 瘀攀爀礀 猀椀最渀椀昀椀挀愀渀琀⸀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀㐀⸀㔀⸀㈀ 䠀漀眀 琀漀 刀攀漀爀最愀渀椀稀攀 愀渀搀 刀攀戀甀椀氀搀 䤀渀搀攀砀攀猀㨀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br> ਍ⴀ 刀攀漀爀最愀渀椀稀椀渀最Ⰰ 搀攀昀爀愀最洀攀渀琀猀 漀渀氀礀 琀栀攀 氀攀愀昀 氀攀瘀攀氀 漀昀 挀氀甀猀琀攀爀攀搀 愀渀搀 渀漀渀挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀 漀渀 琀愀戀氀攀猀⸀ 吀栀攀 猀愀洀攀 瀀愀最攀猀 愀爀攀 甀猀攀搀 愀最愀椀渀⸀㰀戀爀㸀ഀഀ
Since a fill factor can be specified, it's likely that empty pages will result by this "compaction".਍吀栀攀猀攀 愀爀攀 爀攀洀漀瘀攀搀Ⰰ 愀渀搀 琀栀甀猀 瀀爀漀瘀椀搀椀渀最 愀搀搀椀琀椀漀渀愀氀 愀瘀愀椀氀愀戀氀攀 搀椀猀欀 猀瀀愀挀攀⸀㰀戀爀㸀ഀഀ
The fill factor, as the name already implies, specifies "how full" a page should be filled, like for example "70" (70%) or "80" (80%).<br>਍㰀戀爀㸀 ഀഀ
- Rebuilding an index actually drops the index and re-creates a new one. Since this action means <I>completely rebuilding</I> a new index,<br>਍愀氀氀 氀攀瘀攀氀猀 ⠀氀攀愀昀 氀攀瘀攀氀Ⰰ 椀渀琀攀爀洀攀搀椀愀琀攀 氀攀瘀攀氀猀Ⰰ 爀漀漀琀 氀攀瘀攀氀⤀ 愀爀攀 爀攀挀爀攀愀琀攀搀 愀最愀椀渀Ⰰ 愀渀搀 愀氀氀 昀爀愀最洀攀渀琀愀琀椀漀渀 椀猀 爀攀洀漀瘀攀搀⸀㰀戀爀㸀ഀഀ
In this process, you reclaim disk space, since all pages are build again using the specified "fill factor" setting.<br>਍㰀戀爀㸀 ഀഀ
Usually, rebuilding an index is more resource intensive than reorganizing an index.<br>਍刀攀漀爀最愀渀椀稀椀渀最 椀猀 愀甀琀漀洀愀琀椀挀愀氀氀礀 搀漀渀攀 ∀漀渀氀椀渀攀∀Ⰰ 琀栀甀猀 眀栀椀氀攀 猀攀猀猀椀漀渀猀 洀愀礀 愀挀挀攀猀猀 琀栀攀 琀愀戀氀攀 愀渀搀 椀渀搀攀砀⸀㰀戀爀㸀ഀഀ
Rebuilding can be done online or offline. If done offline, locks will block sessions for the time the index is rebuild.<br>਍圀椀琀栀 琀栀攀 䔀渀琀攀爀瀀爀椀猀攀 䔀搀椀琀椀漀渀Ⰰ 甀猀椀渀最 琀栀攀 ∀伀一䰀䤀一䔀㴀伀一∀ 挀氀愀甀猀攀Ⰰ 礀漀甀 挀愀渀 爀攀戀甀椀氀搀 椀渀搀攀砀攀猀 漀渀氀椀渀攀⸀㰀戀爀㸀ഀഀ
Still, with very large indexes, it's really best to rebuild them during the times of least activity in the Database.<br> ਍㰀戀爀㸀ഀഀ
Here are a few examples on how to rebuild or reorganize indexes:<br>਍㰀戀爀㸀ഀഀ
First a warning. You can explicitly DROP an index, and CREATE it again, assuming you had the original CREATE statement.<br>਍䤀渀 洀漀猀琀 挀愀猀攀猀Ⰰ 琀栀攀 䐀愀琀愀戀愀猀攀 眀椀氀氀 渀漀琀 攀砀攀挀甀琀攀 琀栀攀 猀琀愀琀攀洀攀渀琀 椀昀 琀栀攀 椀渀搀攀砀 猀甀瀀瀀漀爀琀猀 ⠀漀爀 ∀椀猀∀⤀ 愀 倀爀椀洀愀爀礀 䬀攀礀 漀爀 唀渀椀焀甀攀 挀漀渀猀琀爀愀椀渀琀⸀㰀戀爀㸀ഀഀ
But you still must be carefull, in how far the index supports any constraint at all. You have to investigate that first.<br>਍匀漀Ⰰ 椀琀✀猀 戀攀猀琀 琀漀 一伀吀 琀漀 ∀䐀刀伀倀∀ 愀渀搀 ∀䌀刀䔀䄀吀䔀∀ 愀渀 椀渀搀攀砀Ⰰ 甀渀氀攀猀猀 礀漀甀 欀渀漀眀 琀栀攀 搀攀琀愀椀氀猀 漀昀 礀漀甀爀 挀漀渀猀琀爀愀椀渀琀猀⸀㰀戀爀㸀ഀഀ
<br>਍䈀甀琀Ⰰ 眀栀攀渀 甀猀椀渀最 琀栀攀 ∀䄀䰀吀䔀刀 䤀一䐀䔀堀 ⸀⸀ 刀䔀䈀唀䤀䰀䐀∀ 愀渀搀 ∀䐀䈀䌀䌀 䐀䈀刀䔀䤀一䐀䔀堀⠀⤀∀ 挀漀洀洀愀渀搀猀Ⰰ 礀漀甀 愀爀攀 瀀爀攀琀琀礀 猀愀瘀攀⸀㰀戀爀㸀ഀഀ
<br>਍吀栀甀猀Ⰰ 礀漀甀 挀愀渀 甀猀攀 琀眀漀 琀礀瀀攀猀 漀昀 挀漀洀洀愀渀搀猀 琀漀 刀攀戀甀椀氀搀 愀渀 䤀渀搀攀砀㨀 琀栀攀 ∀䄀䰀吀䔀刀 䤀一䐀䔀堀∀ 猀琀愀琀攀洀攀渀琀 愀渀搀 琀栀攀 ∀䐀䈀䌀䌀 䐀䈀刀䔀䤀一䐀䔀堀⠀⤀∀ 猀琀愀琀攀洀攀渀琀⸀㰀戀爀㸀ഀഀ
The DBCC command is more SQL Server 7/2000 "style", but it's still valid in 2005 and 2008.<br>਍䨀甀猀琀 琀愀欀攀 愀 氀漀漀欀 愀琀 琀栀攀 昀漀氀氀漀眀椀渀最 攀砀愀洀瀀氀攀猀⸀ 䠀漀眀 琀漀 搀攀愀氀 眀椀琀栀 㰀䈀㸀愀氀氀㰀⼀䈀㸀 椀渀搀攀砀攀猀 漀昀 㰀䈀㸀愀氀氀㰀⼀䈀㸀 琀愀戀氀攀猀 椀渀 愀 搀愀琀愀戀愀猀攀Ⰰ 椀猀 琀栀攀 猀甀戀樀攀挀琀 漀昀 琀栀攀 渀攀砀琀 猀攀挀琀椀漀渀⸀㰀戀爀㸀ഀഀ
<br>਍吀栀攀 攀砀愀洀瀀氀攀猀 戀攀氀漀眀 愀爀攀 㰀䤀㸀瘀攀爀礀 猀椀洀瀀氀椀猀琀椀挀㰀⼀䤀㸀⸀ 夀漀甀 渀攀攀搀 琀漀 爀攀愀搀 䈀漀漀欀猀 伀渀氀椀渀攀 ⠀䈀伀䰀⤀Ⰰ 漀爀 猀攀愀爀挀栀 琀栀攀 椀渀琀攀爀渀攀琀Ⰰ 琀漀 昀椀渀搀 愀氀氀 挀氀愀甀猀攀猀 愀渀搀 漀瀀琀椀漀渀猀㰀戀爀㸀ഀഀ
that you can use with the ALTER INDEX and DBCC REINDEX commands.<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍䄀䰀吀䔀刀 䤀一䐀䔀堀 䤀䐀堀开䔀洀瀀氀漀礀攀攀开䔀䴀倀䤀䐀 伀一 䔀洀瀀氀漀礀攀攀 刀䔀䈀唀䤀䰀䐀 㰀䤀㸀ⴀⴀ 漀渀氀礀 爀攀戀甀椀氀搀 琀栀攀 椀渀搀攀砀 ∀䤀䐀堀开䔀洀瀀氀漀礀攀攀开䔀䴀倀䤀䐀∀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍䄀䰀吀䔀刀 䤀一䐀䔀堀 䄀䰀䰀 伀一 䔀洀瀀氀漀礀攀攀 刀䔀䈀唀䤀䰀䐀 㰀䤀㸀ⴀⴀ 爀攀戀甀椀氀搀 愀氀氀 椀渀搀攀砀攀猀 漀昀 琀栀攀 䔀䴀倀䰀伀夀䔀䔀 琀愀戀氀攀㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍䄀䰀吀䔀刀 䤀一䐀䔀堀 䤀䐀堀开䔀洀瀀氀漀礀攀攀开䔀䴀倀䤀䐀 伀一 䔀洀瀀氀漀礀攀攀 刀䔀䈀唀䤀䰀䐀 圀䤀吀䠀 ⠀䘀䤀䰀䰀䘀䄀䌀吀伀刀 㴀 㠀　⤀ 㰀䤀㸀ⴀⴀ 漀渀氀礀 爀攀戀甀椀氀搀 琀栀攀 椀渀搀攀砀 ∀䤀䐀堀开䔀洀瀀氀漀礀攀攀开䔀䴀倀䤀䐀∀ 眀椀琀栀 䘀䤀䰀䰀䘀䄀䌀吀伀刀㴀㠀　㰀⼀䤀㸀㰀戀爀㸀㰀戀爀㸀ഀഀ
<br>਍匀漀Ⰰ ∀䄀䰀吀䔀刀 䤀一䐀䔀堀 䄀䰀䰀 吀愀戀氀攀开一愀洀攀 刀䔀䈀唀䤀䰀䐀 圀䤀吀䠀 ⠀䘀䤀䰀䰀䘀䄀䌀吀伀刀 㴀 渀⤀∀ 琀愀欀攀猀 挀愀爀攀 漀昀 愀氀氀 椀渀搀攀砀攀猀 漀昀 愀 挀攀爀琀愀椀渀 琀愀戀氀攀⸀㰀戀爀㸀ഀഀ
<br>਍䐀䈀䌀䌀 䐀䈀刀䔀䤀一䐀䔀堀⠀䔀䴀倀䰀伀夀䔀䔀Ⰰ✀✀Ⰰ㠀　⤀ 㰀䤀㸀ⴀⴀ 爀攀戀甀椀氀搀 愀氀氀 椀渀搀攀砀攀猀 漀昀 琀栀攀 䔀䴀倀䰀伀夀䔀䔀 琀愀戀氀攀 眀椀琀栀 愀 䘀䤀䰀䰀䘀䄀䌀吀伀刀㴀㠀　㰀⼀䤀㸀㰀戀爀㸀ഀഀ
<br>਍匀漀Ⰰ ∀䐀䈀䌀䌀 䐀䈀刀䔀䤀一䐀䔀堀⠀吀愀戀氀攀开一愀洀攀Ⰰ✀✀Ⰰ䘀椀氀氀昀愀挀琀漀爀⤀∀Ⰰ 琀愀欀攀猀 挀愀爀攀 漀昀 愀氀氀 椀渀搀攀砀攀猀 漀昀 愀 挀攀爀琀愀椀渀 琀愀戀氀攀⸀㰀戀爀㸀ഀഀ
<br>਍ഀഀ
<font face="arial" size=2 color="black">਍儀甀攀猀琀椀漀渀㨀㰀戀爀㸀ഀഀ
<br>਍䴀愀礀戀攀 琀栀椀猀 椀猀 愀 搀椀昀昀椀挀甀氀琀 焀甀攀猀琀椀漀渀⸀ 䤀琀✀猀 挀攀爀琀愀椀渀氀礀 愀 瘀攀爀礀 椀渀琀攀爀爀攀猀琀椀渀最 焀甀攀猀琀椀漀渀⸀㰀戀爀㸀 ഀഀ
If needed, search Books Online (BOL) and/or the Internet for answers.<br>਍㰀戀爀㸀ഀഀ
Suppose a table has a clustered index, and several non-clustered indexes.<br>਍圀栀愀琀 栀愀瀀瀀攀渀猀 琀漀 琀栀攀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀Ⰰ 椀昀 礀漀甀 爀攀戀甀椀氀搀 琀栀攀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀㼀㰀戀爀㸀ഀഀ
<br>਍ഀഀ
<B>4.5.3 How to "dynamically" generate index rebuild statements of all indexes in a Database:</B><br>਍㰀戀爀㸀ഀഀ
If you want to "dynamically" generate the rebuild statements for all usertables in a Database,<br>਍眀攀 挀愀渀 甀猀攀 愀 氀漀漀瀀椀渀最 挀漀渀猀琀爀甀挀琀Ⰰ 挀愀氀氀攀搀 愀 挀甀爀猀漀爀⸀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍ഀഀ
-- A loop generating DBCC statements:<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍ഀഀ
set nocount on<br>਍䐀䔀䌀䰀䄀刀䔀 䀀吀愀戀氀攀一愀洀攀 瘀愀爀挀栀愀爀⠀㈀㔀㔀⤀㰀戀爀㸀 ഀഀ
<br>਍䐀䔀䌀䰀䄀刀䔀 吀愀戀氀攀䌀甀爀猀漀爀 䌀唀刀匀伀刀 䘀伀刀 㰀戀爀㸀ഀഀ
SELECT table_name FROM information_schema.tables <br>਍圀䠀䔀刀䔀 琀愀戀氀攀开琀礀瀀攀 㴀 ✀戀愀猀攀 琀愀戀氀攀✀ 㰀戀爀㸀ഀഀ
<br>਍伀倀䔀一 吀愀戀氀攀䌀甀爀猀漀爀 㰀戀爀㸀ഀഀ
<br>਍䘀䔀吀䌀䠀 一䔀堀吀 䘀刀伀䴀 吀愀戀氀攀䌀甀爀猀漀爀 䤀一吀伀 䀀吀愀戀氀攀一愀洀攀 㰀戀爀㸀ഀഀ
WHILE @@FETCH_STATUS = 0 <br>਍ 䈀䔀䜀䤀一 㰀戀爀㸀ഀഀ
 SELECT 'DBCC DBREINDEX('+@TableName+','+''''',80)' -- asssuming a fill factor of 80<br>਍ 䘀䔀吀䌀䠀 一䔀堀吀 䘀刀伀䴀 吀愀戀氀攀䌀甀爀猀漀爀 䤀一吀伀 䀀吀愀戀氀攀一愀洀攀 㰀戀爀㸀ഀഀ
 END <br>਍㰀戀爀㸀ഀഀ
CLOSE TableCursor <br>਍㰀戀爀㸀ഀഀ
DEALLOCATE TableCursor<br>਍㰀戀爀㸀ഀഀ
-- A loop generating ALTER INDEX statements:<br>਍㰀戀爀㸀ഀഀ
set nocount on<br>਍䐀䔀䌀䰀䄀刀䔀 䀀吀愀戀氀攀一愀洀攀 瘀愀爀挀栀愀爀⠀㈀㔀㔀⤀ 㰀戀爀㸀ഀഀ
<br>਍䐀䔀䌀䰀䄀刀䔀 吀愀戀氀攀䌀甀爀猀漀爀 䌀唀刀匀伀刀 䘀伀刀 㰀戀爀㸀ഀഀ
SELECT table_name FROM information_schema.tables <br>਍圀䠀䔀刀䔀 琀愀戀氀攀开琀礀瀀攀 㴀 ✀戀愀猀攀 琀愀戀氀攀✀ 㰀戀爀㸀ഀഀ
<br>਍伀倀䔀一 吀愀戀氀攀䌀甀爀猀漀爀 㰀戀爀㸀ഀഀ
<br>਍䘀䔀吀䌀䠀 一䔀堀吀 䘀刀伀䴀 吀愀戀氀攀䌀甀爀猀漀爀 䤀一吀伀 䀀吀愀戀氀攀一愀洀攀 㰀戀爀㸀ഀഀ
WHILE @@FETCH_STATUS = 0 <br>਍䈀䔀䜀䤀一 㰀戀爀㸀ഀഀ
SELECT 'ALTER INDEX ALL ON '+@TableName+' REBUILD WITH (FILLFACTOR=80)'<br>਍䘀䔀吀䌀䠀 一䔀堀吀 䘀刀伀䴀 吀愀戀氀攀䌀甀爀猀漀爀 䤀一吀伀 䀀吀愀戀氀攀一愀洀攀 㰀戀爀㸀ഀഀ
END <br>਍㰀戀爀㸀ഀഀ
CLOSE TableCursor <br>਍㰀戀爀㸀ഀഀ
DEALLOCATE TableCursor<br>਍ഀഀ
<font face="arial" size=2 color="black">਍ഀഀ
<br> ਍㰀戀爀㸀 ഀഀ
<h2>Chapter 5. How to determine if you have too low CPU power.</h2>਍ഀഀ
Again, just like in chapter 1, <B>System Monitor</B> (or Performance Monitor), and the <B>dynamic management views</B> (dmv's) can learn us a lot.<br>਍㰀戀爀㸀ഀഀ
It's important to differentiate here, between a <I>"real cpu problem"</I>, meaning that for the workload,<br>਍礀漀甀 樀甀猀琀 栀愀瘀攀 琀漀漀 氀椀琀琀氀攀 䌀倀唀 瀀漀眀攀爀⸀ 䈀甀琀 椀琀 挀愀渀 戀攀 愀 戀椀琀 挀漀渀昀甀猀椀渀最Ⰰ 戀攀挀愀甀猀攀 椀琀 挀愀渀 愀氀猀漀 戀攀 琀栀愀琀 礀漀甀 漀渀氀礀 栀愀瘀攀 愀渀 ∀愀瀀瀀愀爀攀渀琀 挀瀀甀 瀀爀漀戀氀攀洀∀Ⰰ㰀戀爀㸀ഀഀ
because of <B>waits</B> of some sort.<br>਍㰀戀爀㸀ഀഀ
Let's first take a look at what we can discover using Performance Monitor (perfmon).<br>਍㰀戀爀㸀ഀഀ
<h3>5.1 Taking a quick look Using Perfmon:</h3>਍ഀഀ
This is going to be a bit of a trivial section, I am afraid.<br>਍㰀戀爀⸀ഀഀ
As you can see in the example below, you can add counters from the "processor" object.<br>਍匀漀洀攀 漀戀瘀椀漀甀猀 挀漀甀渀琀攀爀猀 愀爀攀 㰀䈀㸀∀倀爀漀挀攀猀猀漀爀尀─倀爀椀瘀椀氀攀搀最攀 吀椀洀攀⠀开吀漀琀愀氀⤀∀Ⰰ  ∀倀爀漀挀攀猀猀漀爀尀─唀猀攀爀 吀椀洀攀⠀开吀漀琀愀氀⤀∀Ⰰ 愀渀搀 ∀倀爀漀挀攀猀猀漀爀尀─䤀搀氀攀 吀椀洀攀⠀开吀漀琀愀氀⤀∀㰀⼀䈀㸀⸀㰀戀爀㸀ഀഀ
<br>਍伀渀攀 漀琀栀攀爀 瘀攀爀礀 椀洀瀀漀爀琀愀渀琀 挀漀甀渀琀攀爀Ⰰ 椀猀 㰀䈀㸀渀漀琀 昀漀甀渀搀㰀⼀䈀㸀 甀渀搀攀爀 琀栀攀 ∀倀爀漀挀攀猀猀漀爀∀ 漀戀樀攀挀琀⸀ 䤀渀猀琀攀愀搀Ⰰ 猀攀氀攀挀琀 琀栀攀 ∀匀礀猀琀攀洀∀ 漀戀樀攀挀琀Ⰰ 愀渀搀 猀攀氀攀挀琀㰀戀爀㸀ഀഀ
the <B>"System\Processor Queue Length" </B> counter.<br>਍㰀戀爀㸀ഀഀ
Please see section 1.2 for a short explanation on "objects", "counters", and "instances".<br>਍吀栀攀爀攀 愀爀攀 漀昀挀漀甀爀猀攀 洀愀渀礀 漀琀栀攀爀 椀渀琀攀爀爀攀猀琀椀渀最 挀漀甀渀琀攀爀猀 氀椀欀攀 ∀─䐀倀䌀 吀椀洀攀∀ 攀琀挀⸀⸀Ⰰ 戀甀琀 琀栀攀猀攀 愀爀攀 渀漀琀 㰀䤀㸀琀栀愀琀㰀⼀䤀㸀 ∀爀攀氀攀瘀愀渀琀∀ 昀漀爀 ∀漀甀爀 焀甀椀挀欀 氀漀漀欀∀⸀㰀戀爀㸀ഀഀ
<br>਍䄀 猀栀漀爀琀 搀攀猀挀爀椀瀀琀椀漀渀 漀昀 琀栀攀 愀戀漀瘀攀 挀漀甀渀琀攀爀猀 椀猀㨀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀ⴀ ─䤀搀氀攀 吀椀洀攀㨀㰀⼀䈀㸀 匀栀漀眀猀 琀栀攀 ─琀椀洀攀 琀栀愀琀 琀栀攀 瀀爀漀挀攀猀猀漀爀⠀猀⤀ 眀愀猀 椀搀氀攀 搀甀爀椀渀最 琀栀攀 猀愀洀瀀氀攀 椀渀琀攀爀瘀愀氀⸀㰀戀爀㸀ഀഀ
<B>- %Priviledge Time:</B> Shows the %time that the processor(s) was running Kernel Mode code during the sample interval.<br>਍㰀䈀㸀ⴀ ─唀猀攀爀 吀椀洀攀㨀㰀⼀䈀㸀 匀栀漀眀猀 琀栀攀 ─琀椀洀攀 琀栀愀琀 琀栀攀 瀀爀漀挀攀猀猀漀爀⠀猀⤀ 眀愀猀 爀甀渀渀椀渀最 唀猀攀爀 䴀漀搀攀 挀漀搀攀 ⠀渀漀渀 欀攀爀渀攀氀⤀ 搀甀爀椀渀最 琀栀攀 猀愀洀瀀氀攀 椀渀琀攀爀瘀愀氀⸀㰀戀爀㸀ഀഀ
<B>- %Processor Time:</B> Is almost the same as (%Priviledge Time + %User Time).<br>਍㰀䈀㸀ⴀ 倀爀漀挀攀猀猀漀爀 儀甀攀甀攀 䰀攀渀最琀栀㨀㰀⼀䈀㸀 吀栀椀猀 椀渀搀椀挀愀琀攀猀 琀栀攀 渀甀洀戀攀爀 漀昀 琀栀爀攀愀搀猀 椀渀 琀栀攀 瀀爀漀挀攀猀猀漀爀 焀甀攀甀攀⸀ 䤀琀 洀愀礀 戀攀 挀漀渀猀椀搀攀爀攀搀 琀漀 戀攀 ∀栀椀最栀∀Ⰰ㰀戀爀㸀ഀഀ
if on average it's much more than 2 x #cpu's in your system.<br>਍㰀戀爀㸀ഀഀ
With all those counters, some occasional "spikes" are no big deal. Only if you see structural high values (except for "Idle Time"),<br>਍漀渀 愀瘀攀爀愀最攀Ⰰ 漀爀 昀漀爀 愀 挀漀渀猀椀搀攀爀愀戀氀攀 愀洀漀甀渀琀 漀昀 琀椀洀攀 ⠀猀愀礀Ⰰ 搀甀爀椀渀最 愀 ∀戀愀琀挀栀∀⤀Ⰰ 礀漀甀 洀椀最栀琀 栀愀瘀攀 愀 挀瀀甀 戀漀琀氀氀攀渀攀挀欀⸀㰀戀爀㸀ഀഀ
<br>਍㄀⸀ 伀渀攀 瘀攀爀礀 琀爀椀瘀椀愀氀 爀攀洀愀爀欀 椀猀 琀栀椀猀㨀 椀昀 琀栀攀 ∀倀爀漀挀攀猀猀漀爀㨀䤀搀氀攀 吀椀洀攀⠀开吀漀琀愀氀⤀∀ 椀猀 瘀攀爀礀 栀椀最栀 㰀䤀㸀洀漀猀琀 漀昀 琀栀攀 琀椀洀攀㰀⼀䤀㸀Ⰰ 礀漀甀 搀漀 渀漀琀 栀愀瘀攀㰀戀爀㸀ഀഀ
a CPU pressure at all on your system. Or, what is the same, if %Processor Time is low <I>most of the time</I>,<br>਍礀漀甀 搀漀 渀漀琀 栀愀瘀攀 愀 䌀倀唀 瀀爀攀猀猀甀爀攀 漀渀 礀漀甀爀 猀礀猀琀攀洀⸀㰀戀爀㸀ഀഀ
<br>਍㈀⸀ 䤀昀 㰀䈀㸀漀渀 愀瘀攀爀愀最攀㰀⼀䈀㸀Ⰰ 礀漀甀 猀礀猀琀攀洀 猀栀漀眀猀 愀戀漀甀琀 㐀　Ⰰ 㔀　Ⰰ 㘀　 ─倀爀漀挀攀猀猀漀爀 琀椀洀攀Ⰰ 䤀 眀漀甀氀搀 猀愀礀 椀琀✀猀 渀椀挀攀氀礀 愀琀 眀漀爀欀⸀㰀戀爀㸀ഀഀ
Because, suppose that the cpu's were idle <I>all the time</I>, then that's not good either. It would be a waste of cpu power.<br>਍㰀戀爀㸀ഀഀ
3. Now, what if the cpu's show a %Processor time which hovers around 90% <I>most of the time</I>? That should certainly get our attention.<br>਍㰀戀爀㸀ഀഀ
One of the most important questions following point 3) is, is it really a CPU bottleneck, or are those observations<br>਍愀氀猀漀 挀愀甀猀攀搀 戀礀 ∀猀漀洀攀 搀攀攀瀀攀爀 琀攀挀栀渀椀挀愀氀 爀攀愀猀漀渀∀㼀㰀戀爀㸀ഀഀ
<br>਍㐀⸀ 䤀昀 琀栀攀 挀瀀甀✀猀 猀栀漀眀 愀 ∀─倀爀漀挀攀猀猀漀爀 琀椀洀攀∀ 眀栀椀挀栀 椀猀 栀椀最栀 㰀䤀㸀洀漀猀琀 漀昀 琀栀攀 琀椀洀攀㰀⼀䤀㸀 愀渀搀 ∀倀爀漀挀攀猀猀漀爀 儀甀攀甀攀 䰀攀渀最琀栀∀ 椀猀 挀漀渀猀椀搀攀爀愀戀氀礀 氀愀爀最攀 琀漀漀Ⰰ㰀戀爀㸀ഀഀ
then you have a strong indication of a structural CPU pressure.<br>਍㰀戀爀㸀ഀഀ
Although it all seems "obvious", do no jump to conclusions yet.<br>਍䤀 琀栀椀渀欀 琀栀愀琀 愀昀琀攀爀 爀攀愀搀椀渀最 琀栀攀 洀愀琀攀爀椀愀氀 椀渀 挀栀愀瀀琀攀爀 㤀Ⰰ 眀攀 眀椀氀氀 愀瀀瀀爀攀挀椀愀琀攀 琀栀愀琀 猀琀愀琀攀洀攀渀琀 猀漀洀攀眀栀愀琀 洀漀爀攀⸀㰀戀爀㸀ഀഀ
<br> ਍㰀椀洀最 猀爀挀㴀∀猀焀氀㄀㔀⸀樀瀀最∀ 愀氀椀最渀㴀∀挀攀渀琀攀爀∀⼀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
If you use perfmon and measure the above metrics for a representable amount of time, and you <I>indeed</I> find<br>਍栀椀最栀 瘀愀氀甀攀猀 漀渀 愀瘀攀爀愀最攀Ⰰ 椀琀✀猀 㰀䤀㸀焀甀椀琀攀 氀椀欀攀氀礀㰀⼀䤀㸀 礀漀甀 栀愀瘀攀 愀 戀漀琀琀氀攀渀攀挀欀 ∀猀漀洀攀眀栀攀爀攀∀⸀ 䄀渀搀 椀渀搀攀攀搀Ⰰ 椀琀✀猀 氀椀欀攀氀礀 琀漀 戀攀 琀栀攀 挀瀀甀✀猀⸀㰀戀爀㸀ഀഀ
But what to think of this example. Suppose you have a Database Server, and a number of application Servers.<br>਍圀栀攀渀 猀漀洀攀 氀愀爀最攀 戀愀琀挀栀 猀琀愀爀琀猀Ⰰ 洀愀渀礀 愀瀀瀀氀椀挀愀琀椀漀渀 挀漀洀瀀漀渀攀渀琀猀 漀渀 琀栀攀 䄀瀀瀀氀椀挀愀琀椀漀渀 匀攀爀瘀攀爀猀Ⰰ 愀氀氀 猀琀愀爀琀猀 琀愀猀欀猀 漀渀 琀栀攀㰀戀爀㸀ഀഀ
Database Server at the same time, and all keeps running until the batch finishes. Maybe thats why we see such a high cpu pressure.<br>਍䤀琀 挀漀甀氀搀 戀攀 琀爀甀攀 琀栀愀琀 琀栀椀猀 椀猀 ∀愀猀 搀攀猀椀最渀攀搀∀Ⰰ 愀渀搀 眀攀 愀爀攀 琀漀漀 氀漀眀 漀渀 挀瀀甀 瀀漀眀攀爀⸀ 伀爀 猀漀洀攀琀栀椀渀最 攀氀猀攀 椀猀 渀漀琀 爀椀最栀琀⸀㰀戀爀㸀 ഀഀ
We always need a helicopter view so to speak, on the system as a whole.<br>਍㰀戀爀㸀ഀഀ
So, it's often too difficult to reach well founded conclusions, using Performance Monitor alone.<br>਍㰀戀爀㸀ഀഀ
That's why you also need other information, and at least take a look at the dynamic management views as well.<br>਍ഀഀ
<br>਍㰀栀㌀㸀㔀⸀㈀ 唀猀椀渀最 猀漀洀攀 搀礀渀愀洀椀挀 洀愀渀愀最攀洀攀渀琀 瘀椀攀眀猀㨀㰀⼀栀㌀㸀ഀഀ
਍䄀最愀椀渀Ⰰ 琀栀攀 䐀䴀嘀 ∀猀礀猀⸀搀洀开漀猀开眀愀椀琀开猀琀愀琀猀∀ 挀愀渀 最椀瘀攀 甀猀 瘀愀氀甀愀戀氀攀 瀀漀椀渀琀攀爀猀 琀漀 攀砀椀猀琀攀渀挀攀 漀昀 瀀漀猀猀椀戀氀攀 ∀䌀倀唀 瀀爀攀猀猀甀爀攀∀⸀㰀戀爀㸀ഀഀ
When a session is "ready for some work", it will first enter the "runnable queue". The longer this queue is,<br>਍琀栀攀 洀漀爀攀 眀攀 洀愀礀 瀀爀攀猀甀洀攀 琀栀愀琀 挀瀀甀 瀀爀攀猀猀甀爀攀 椀猀 愀挀琀甀愀氀氀礀 爀攀愀氀氀礀 琀爀甀攀Ⰰ 猀椀渀挀攀 愀 氀漀渀最攀爀 焀甀攀甀攀 氀攀渀最琀栀 椀洀瀀氀椀攀猀 琀栀愀琀㰀戀爀㸀ഀഀ
the cpu cannot keep up sufficiently with the demands.<br>਍䄀猀 愀 猀攀猀猀椀漀渀 搀漀攀猀 眀漀爀欀Ⰰ 戀甀琀 琀栀攀渀 栀愀瘀攀 琀漀 眀愀椀琀 漀渀 猀漀洀攀 ∀爀攀猀漀甀爀挀攀∀ ⠀氀椀欀攀 瀀愀最攀猀 琀栀愀琀 洀甀猀琀 戀攀 昀攀琀挀栀攀搀 昀爀漀洀 搀椀猀欀⤀Ⰰ㰀戀爀㸀ഀഀ
it will be put in a "waiters queue", until conditions have arived that makes it runnable again (put in the runnable queue).<br>਍㰀戀爀㸀ഀഀ
਍吀栀攀 琀椀洀攀 眀愀椀琀椀渀最 椀渀 琀栀攀 爀甀渀渀愀戀氀攀 焀甀攀甀攀 昀漀爀 䌀倀唀Ⰰ 椀猀 猀栀漀眀渀 愀猀 ∀匀椀最渀愀氀 圀愀椀琀猀∀⸀㰀戀爀㸀ഀഀ
The time waiting for a resource is shown as "Resource Waits".<br>਍㰀戀爀㸀ഀഀ
The following query will show you a grand total of the percentage of Signal Waits and Resource waits,<br>਍愀渀搀 琀栀甀猀 愀氀氀漀眀猀 甀猀 琀漀 挀漀洀瀀愀爀攀 琀栀攀 琀眀漀⸀㰀戀爀㸀ഀഀ
<br>਍䤀昀 琀栀攀 琀漀琀愀氀 漀昀 ∀─猀椀最渀愀氀 眀愀椀琀猀∀ 椀猀 栀椀最栀攀猀琀Ⰰ 椀琀✀猀 愀 爀攀愀猀漀渀愀戀氀攀 瀀漀椀渀琀攀爀 琀漀 猀甀猀瀀攀挀琀 䌀倀唀 瀀爀攀猀猀甀爀攀⸀㰀戀爀㸀ഀഀ
If the total of "%Resource waits is highest, it's a reasonable pointer to suspect overall poor IO, or excessive locking behaviour.<br>਍㰀戀爀㸀ഀഀ
Again, to draw conclusions on this alone, is not a good idea ! Also take a look at section 5.1.<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍匀攀氀攀挀琀 猀椀最渀愀氀开眀愀椀琀开琀椀洀攀开洀猀㴀猀甀洀⠀猀椀最渀愀氀开眀愀椀琀开琀椀洀攀开洀猀⤀㰀戀爀㸀 Ⰰ✀─猀椀最渀愀氀 ⠀挀瀀甀⤀ 眀愀椀琀猀✀ 㴀 挀愀猀琀⠀㄀　　⸀　 ⨀ 猀甀洀⠀猀椀最渀愀氀开眀愀椀琀开琀椀洀攀开洀猀⤀ ⼀ 猀甀洀 ⠀眀愀椀琀开琀椀洀攀开洀猀⤀ 愀猀 渀甀洀攀爀椀挀⠀㈀　Ⰰ㈀⤀⤀㰀戀爀㸀ഀഀ
          ,resource_wait_time_ms=sum(wait_time_ms - signal_wait_time_ms)<br>਍          Ⰰ✀─爀攀猀漀甀爀挀攀 眀愀椀琀猀✀㴀 挀愀猀琀⠀㄀　　⸀　 ⨀ 猀甀洀⠀眀愀椀琀开琀椀洀攀开洀猀 ⴀ 猀椀最渀愀氀开眀愀椀琀开琀椀洀攀开洀猀⤀ ⼀ 猀甀洀 ⠀眀愀椀琀开琀椀洀攀开洀猀⤀ 愀猀 渀甀洀攀爀椀挀⠀㈀　Ⰰ㈀⤀⤀㰀戀爀㸀ഀഀ
From sys.dm_os_wait_stats<br>਍㰀戀爀㸀ഀഀ
select top 20 <br>਍猀琀⸀漀戀樀攀挀琀椀搀Ⰰ 猀琀⸀搀戀椀搀Ⰰ㰀戀爀㸀ഀഀ
total_worker_time/execution_count AS AverageCPUTime,<br>਍    䌀䄀匀䔀 猀琀愀琀攀洀攀渀琀开攀渀搀开漀昀昀猀攀琀 㰀戀爀㸀ഀഀ
         WHEN -1 THEN st.text<br>਍         䔀䰀匀䔀 匀唀䈀匀吀刀䤀一䜀⠀猀琀⸀琀攀砀琀Ⰰ猀琀愀琀攀洀攀渀琀开猀琀愀爀琀开漀昀昀猀攀琀⼀㈀Ⰰ猀琀愀琀攀洀攀渀琀开攀渀搀开漀昀昀猀攀琀⼀㈀⤀㰀戀爀㸀ഀഀ
     END AS StatementText<br>਍昀爀漀洀 㰀戀爀㸀ഀഀ
        sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st<br>਍伀刀䐀䔀刀 䈀夀 䄀瘀攀爀愀最攀䌀倀唀吀椀洀攀 䐀䔀匀䌀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
This section is not ready yet. I am thinking on what to present in chapter 9, probably finish that first,<br>਍愀渀搀 琀栀攀渀 爀攀琀甀爀渀 琀漀 琀栀椀猀 猀攀挀琀椀漀渀⸀㰀戀爀㸀ഀഀ
So please continue with the other chapters. Thanks !<br>਍㰀戀爀㸀ഀഀ
਍㰀栀㈀㸀䌀栀愀瀀琀攀爀 㘀⸀ 䄀氀氀漀挀愀琀椀漀渀 唀渀椀琀 愀渀搀 倀愀爀琀椀琀椀漀渀 䄀氀椀最渀洀攀渀琀⸀㰀⼀栀㈀㸀ഀഀ
਍䤀昀 礀漀甀 愀爀攀 椀渀瘀漀氀瘀攀搀 椀渀 愀 渀攀眀 瀀爀漀樀攀挀琀Ⰰ 搀攀猀椀最渀椀渀最 愀渀 愀爀挀栀椀琀攀挀琀甀爀攀 昀漀爀 愀 氀愀爀最攀 愀渀搀⼀漀爀 瘀攀爀礀 愀挀琀椀瘀攀 搀愀琀愀戀愀猀攀Ⰰ㰀戀爀㸀ഀഀ
the design/implementation of storage for your database is very important.<br>਍㰀戀爀㸀ഀഀ
You always should seperate tabledata (or clustered indexes), and non-clustered indexes,<br>਍愀渀搀 琀栀攀 昀椀氀攀猀 漀昀 琀栀攀 琀爀愀渀猀愀挀琀椀漀渀氀漀最 ⠀愀渀搀 琀攀洀瀀搀戀 愀氀猀漀⤀Ⰰ 漀渀 搀椀昀昀攀爀攀渀琀 昀椀氀攀猀礀猀琀攀洀猀 ⠀䔀㨀Ⰰ 䘀㨀Ⰰ 䜀㨀 攀琀挀⸀⸀⤀ 漀渀 搀椀昀昀攀爀攀渀琀㰀戀爀㸀ഀഀ
diskvolumes (actually, different independent spindels).<br>਍吀栀椀猀 椀猀 琀漀 攀渀猀甀爀攀 瀀攀爀昀漀爀洀愀渀挀攀⸀ 䄀琀 琀栀攀 猀愀洀攀 琀椀洀攀Ⰰ 礀漀甀 渀攀攀搀 愀 䠀椀最栀 䄀瘀愀椀氀愀戀椀氀礀 猀漀氀甀琀椀漀渀 昀漀爀 礀漀甀爀 搀愀琀愀戀愀猀攀 昀椀氀攀猀Ⰰ㰀戀爀㸀ഀഀ
like some RAID implementations.<br>਍䤀 瀀爀攀猀甀洀攀 琀栀愀琀 琀栀攀 甀瀀瀀攀爀 椀猀 欀渀漀眀 琀漀 礀漀甀⸀ 䤀渀 挀栀愀瀀琀攀爀 㜀Ⰰ 眀攀 愀爀攀 最漀椀渀最 琀漀 搀攀愀氀 眀椀琀栀 琀栀愀琀 猀甀戀樀攀挀琀⸀㰀戀爀㸀ഀഀ
<br>਍䤀渀 琀栀椀猀 挀栀愀瀀琀攀爀 栀漀眀攀瘀攀爀Ⰰ 眀攀 洀攀愀渀 猀漀洀攀琀栀椀渀最 搀椀昀昀攀爀攀渀琀㨀 栀攀爀攀 眀攀 愀爀攀 最漀椀渀最 琀漀 猀瀀攀渀搀 愀 昀攀眀 眀漀爀搀猀 漀渀 琀栀攀 ∀愀氀氀漀挀愀琀椀漀渀 甀渀椀琀∀㰀戀爀㸀ഀഀ
and "partition alignment". This subject is not too exiting, and don't expect miracles from it.<br>਍㰀戀爀㸀ഀഀ
In the following, we will make a certain abstraction. Be warned though: for your specific types of storage, the following<br>਍洀愀礀戀攀 㰀䈀㸀搀漀攀猀 渀漀琀 愀瀀瀀氀礀 愀琀 愀氀氀℀㰀⼀䈀㸀 吀栀愀琀✀猀 眀栀礀 礀漀甀 渀攀攀搀 琀漀 琀愀氀欀 眀椀琀栀 瀀攀漀瀀氀攀 眀栀漀 甀渀搀攀爀猀琀愀渀搀 礀漀甀爀 琀礀瀀攀 漀昀 猀琀漀爀愀最攀⸀㰀戀爀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
<B><U>Allocation Unit:</B></U><br>਍㰀戀爀㸀ഀഀ
Disk sectors are almost always 512 bytes in size. The <B>allocation unit</B>, or blocksize on disk (not the SQL server blocksize!)<br>਍椀猀 搀攀琀攀爀洀椀渀攀搀 眀栀攀渀 礀漀甀 昀漀爀洀愀琀 琀栀攀 搀椀猀欀⸀ 䠀攀爀攀Ⰰ 礀漀甀 漀昀琀攀渀 挀愀渀 挀栀漀漀猀攀 瘀愀氀甀攀猀 氀椀欀攀 ㈀䬀Ⰰ 㐀䬀Ⰰ ㄀㘀䬀Ⰰ ㌀㈀䬀Ⰰ 㘀㐀䬀Ⰰ 愀渀搀 猀漀洀攀琀椀洀攀猀 攀瘀攀渀 氀愀爀最攀爀⸀㰀戀爀㸀ഀഀ
Now, the question may arise: is there an optimal allocation unit for SQL Server?<br>਍吀栀攀 昀甀渀搀愀洀攀渀琀愀氀 瀀愀最攀猀椀稀攀 椀渀 匀儀䰀 猀攀爀瘀攀爀 椀猀 㠀䬀⸀ 匀攀挀漀渀搀氀礀Ⰰ 匀儀䰀 匀攀爀瘀攀爀 漀昀琀攀渀 ✀爀攀愀搀 愀栀攀愀搀✀ 椀渀 㘀㐀䬀 ✀挀栀甀渀欀猀✀ ⠀攀砀琀攀渀搀猀⤀⸀㰀戀爀㸀ഀഀ
<br>਍吀眀漀 琀栀椀渀最猀 栀攀爀攀㨀㰀戀爀㸀ഀഀ
This question relates to the RAID implementation you have choosen, like RAID5 or RAID10.<br>਍䤀渀 琀栀椀猀 挀愀猀攀Ⰰ 甀渀搀攀爀 琀栀攀 栀漀漀搀Ⰰ 琀栀攀 挀栀漀猀攀渀 猀琀爀椀瀀攀猀椀稀攀 椀猀 漀昀 椀洀瀀漀爀琀愀渀挀攀Ⰰ 愀渀搀 搀攀琀攀爀洀椀渀攀猀 眀栀愀琀 礀漀甀 猀栀漀甀氀搀㰀戀爀㸀ഀഀ
should take as a suitable allocation unit.<br>਍㰀戀爀㸀ഀഀ
1. If you use such a RAID implementation, first the choosen "stripe size" is important. Many articles suggest you should<br>਍甀猀攀 愀 ∀渀 砀 㘀㐀䬀∀ 猀琀爀椀瀀攀 猀椀稀攀 ⠀氀椀欀攀 㘀㐀䬀Ⰰ ㄀㈀㠀䬀Ⰰ ㈀㔀㘀䬀⤀⸀㰀戀爀㸀ഀഀ
<br>਍㈀⸀ 䄀昀琀攀爀 琀栀攀 刀䄀䤀䐀渀 甀渀椀琀 椀猀 愀瘀愀椀氀愀戀氀攀 愀渀搀 瘀椀攀眀愀戀氀攀 愀猀 ∀愀 搀椀猀欀∀ 椀渀 圀椀渀搀漀眀猀Ⰰ 礀漀甀 瀀愀爀琀椀琀椀漀渀 愀渀搀 昀漀爀洀愀琀 椀琀⸀ ഀഀ
Now, what allocation unit should you choose? This is very a hard question to answer.<br>਍㰀戀爀㸀ഀഀ
So?<br>਍㰀戀爀㸀ഀഀ
Microsoft articles seem to suggest that it's always best to choose an 64K allocation unit.<br>਍吀栀愀琀 洀椀最栀琀 戀攀 琀爀甀攀⸀ 匀甀爀攀氀礀Ⰰ 匀儀䰀 猀攀爀瘀攀爀 椀猀 琀栀攀椀爀 瀀爀漀搀甀挀琀Ⰰ 猀漀 琀栀攀礀 猀栀漀甀氀搀 欀渀漀眀⸀㰀戀爀㸀ഀഀ
<br>਍匀攀瘀攀爀愀氀 漀琀栀攀爀 愀爀琀椀挀氀攀猀 猀琀甀搀椀攀搀 琀栀攀 瀀攀爀昀漀爀洀愀渀挀攀 ⠀椀渀 最攀渀攀爀愀氀⤀ 甀猀椀渀最 㘀㐀䬀 愀渀搀 ㄀㈀㠀䬀 猀琀爀椀瀀攀 猀攀琀猀Ⰰ 椀渀 挀漀洀戀椀渀愀琀椀漀渀㰀戀爀㸀ഀഀ
with 4K, 8K and 64K allocation units. The results varies a lot, so IMHO, we cannot easily answer the question!<br>਍䤀琀 愀氀氀 搀攀瀀攀渀搀猀 漀渀 猀琀漀爀愀最攀Ⰰ 琀礀瀀攀 漀昀 刀䄀䤀䐀Ⰰ 猀琀爀椀瀀攀猀攀琀 挀栀漀漀猀攀渀Ⰰ 琀礀瀀攀 漀昀 搀愀琀愀戀愀猀攀 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
In most cases, if we are talking about a very ordered Dataware House, with almost only reads and<br>਍瘀攀爀礀 渀攀愀琀 爀攀戀甀椀氀搀 琀愀戀氀攀猀⼀椀渀搀攀砀攀猀Ⰰ 䤀 眀漀甀氀搀 愀氀猀漀 挀栀漀漀猀攀 㘀㐀䬀 愀氀氀漀挀愀琀椀漀渀 甀渀椀琀⸀㰀戀爀㸀ഀഀ
<br>਍匀漀㼀 䤀 愀洀 愀昀爀愀椀搀 䤀 眀愀猀 渀漀琀 愀戀氀攀 琀漀 昀甀氀氀礀 愀渀猀眀攀爀 琀栀攀 焀甀攀猀琀椀漀渀 漀昀 琀栀攀 ∀戀攀猀琀 愀氀氀漀挀愀琀椀漀渀 甀渀椀琀∀⸀㰀戀爀㸀ഀഀ
Hopefully you agree that's simply not easy to answer unless you know a lot of details.<br>਍䈀甀琀 最攀渀攀爀愀氀氀礀 猀瀀攀愀欀椀渀最Ⰰ 䤀 眀漀甀氀搀 愀氀猀漀 猀愀礀 琀栀愀琀 愀渀 愀氀氀漀挀愀琀椀漀渀 甀渀椀琀 漀昀 㘀㐀䬀 㰀䈀㸀猀攀攀洀㰀⼀䈀㸀 爀椀最栀琀Ⰰ 猀椀渀挀攀 匀儀䰀 猀攀爀瘀攀爀㰀戀爀㸀ഀഀ
for table and index data 'thinks' in 64K chunks (extents) anyway.<br>਍㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀㰀唀㸀倀愀爀琀椀琀椀漀渀 䄀氀椀最渀洀攀渀琀㨀㰀⼀䈀㸀㰀⼀唀㸀㰀戀爀㸀ഀഀ
<br>਍䴀愀渀礀 愀爀琀椀挀氀攀猀 眀栀椀挀栀 搀椀猀挀甀猀猀 ∀瀀愀爀琀椀琀椀漀渀 愀氀椀最渀洀攀渀琀∀Ⰰ 猀瀀攀愀欀 漀昀 愀 瀀漀猀猀椀戀氀攀 ∀漀瘀攀爀愀氀氀∀ 瀀攀爀昀漀爀洀愀渀挀攀 椀渀挀爀攀愀猀攀 漀昀 愀戀漀甀琀 ㄀㔀─ⴀ㌀　─⸀㰀戀爀㸀ഀഀ
So, if you do this "right", it could have a significant effect.<br>਍㰀戀爀㸀ഀഀ
This work is or should typically be done by a storage admin, or sysadmin, who installs a Server and implements the disksubsystem.<br>਍㰀戀爀㸀ഀഀ
Maybe first you should check with those people, to get the facts (for your specific storage) straight.<br>਍䤀渀 琀栀攀 甀渀氀椀欀攀氀礀 挀愀猀攀 琀栀攀礀 愀渀猀眀攀爀 眀椀琀栀 ∀栀甀栀⸀⸀㼀∀Ⰰ 琀栀攀渀 㰀䤀㸀礀漀甀㰀⼀䤀㸀 栀愀瘀攀 琀漀 瀀爀漀瘀椀搀攀 琀栀攀 渀攀挀挀攀猀猀愀爀礀 椀渀瀀甀琀⸀㰀戀爀㸀ഀഀ
<br>਍倀愀爀琀椀琀椀漀渀 愀氀椀最渀洀攀渀琀Ⰰ ⠀漀爀 瘀漀氀甀洀攀 愀氀椀最渀洀攀渀琀Ⰰ 漀爀 猀攀挀琀漀爀 愀氀椀最渀洀攀渀琀 愀猀 椀琀 椀猀 挀愀氀氀攀搀 漀挀挀愀猀椀漀渀愀氀氀礀⤀ 栀愀猀 ∀猀漀洀攀琀栀椀渀最 琀漀 搀漀∀㰀戀爀㸀ഀഀ
that the offset of the start of the partition, from the very beginning of the disk, should align with the stripset<br>਍琀栀愀琀 椀猀 椀渀 攀昀昀攀挀琀 漀渀 礀漀甀爀 刀䄀䤀䐀 猀礀猀琀攀洀⸀㰀戀爀㸀ഀഀ
If this not the case, more IO is done than is strictly neccessary.<br>਍一漀眀Ⰰ 琀栀攀 瀀漀椀渀琀 椀猀Ⰰ 琀栀攀 嘀攀渀搀漀爀 漀昀 礀漀甀爀 搀椀猀欀愀爀爀礀Ⰰ 漀爀 琀栀攀 瀀攀爀猀漀渀 眀栀漀 椀渀猀琀愀氀氀猀 椀琀Ⰰ 猀栀漀甀氀搀 欀渀漀眀 琀栀攀猀攀 ∀洀愀最椀挀∀ 渀甀洀戀攀爀猀⸀㰀戀爀㸀ഀഀ
In practice however, if the information is not available, there are generic setups that seem to work.<br>਍㰀戀爀㸀ഀഀ
If you setup partitions under Win2K8, you will not be "bothered" by the misaligned offset. This system will take care of it.<br>਍䈀甀琀Ⰰ 漀渀 圀椀渀㈀䬀㌀Ⰰ 椀琀 挀漀甀氀搀 戀攀 愀渀 椀猀猀甀攀⸀㰀戀爀㸀ഀഀ
<br>਍䄀渀礀眀愀礀Ⰰ 椀昀 漀渀 圀椀渀㈀䬀㌀Ⰰ 愀 㘀㐀䬀 漀昀昀猀攀琀 ⠀㄀㈀㠀 猀攀挀琀漀爀猀⤀ 椀猀 愀 挀漀洀洀漀渀 瘀愀氀甀攀 琀栀愀琀 眀漀爀欀猀 漀渀 洀愀渀礀 猀琀漀爀愀最攀 愀爀爀愀礀猀⸀㰀戀爀㸀ഀഀ
Win2K8 uses a 1024K offset, which should work even better.<br>਍匀漀Ⰰ 眀攀 眀椀氀氀 琀愀欀攀 琀栀愀琀 愀猀 漀甀爀 瀀爀攀昀昀攀爀攀搀 漀昀昀猀攀琀⸀㰀戀爀㸀ഀഀ
<br>਍䠀漀眀 琀漀 搀漀 椀琀 礀漀甀爀猀攀氀昀㼀 吀栀攀 琀漀漀氀猀 礀漀甀 挀漀甀氀搀 甀猀攀 愀爀攀 ∀搀椀猀欀瀀愀爀∀ 漀爀 ∀搀椀猀欀瀀愀爀琀∀⸀㰀戀爀㸀ഀഀ
However, DiskPart.exe is the preferred method since it's newer and is included as of Win2K3 sp1.<br> ਍ഀഀ
<font face="courier" size=2 color="black">਍㰀戀爀㸀ഀഀ
DISKPART> list disk<br>਍㰀戀爀㸀ഀഀ
<I> shows a list of your disks... </I><br>਍㰀戀爀㸀ഀഀ
Now, suppose you want to align and then format disk 3:਍㰀戀爀㸀ഀഀ
DISKPART> select disk 3<br>਍䐀椀猀欀 ㌀ 椀猀 渀漀眀 琀栀攀 猀攀氀攀挀琀攀搀 搀椀猀欀⸀㰀戀爀㸀ഀഀ
DISKPART> create partition primary align=1024<br>਍䐀椀猀欀倀愀爀琀 猀甀挀挀攀攀搀攀搀 椀渀 挀爀攀愀琀椀渀最 琀栀攀 猀瀀攀挀椀昀椀攀搀 瀀愀爀琀椀琀椀漀渀⸀㰀戀爀㸀ഀഀ
DISKPART> assign letter=F<br>਍䐀椀猀欀倀愀爀琀 猀甀挀挀攀猀猀昀甀氀氀礀 愀猀猀椀最渀攀搀 琀栀攀 搀爀椀瘀攀 氀攀琀琀攀爀 漀爀 洀漀甀渀琀 瀀漀椀渀琀⸀㰀戀爀㸀ഀഀ
DISKPART> format fs=ntfs unit=64K label="SQLINDEX"<br>਍㰀戀爀㸀ഀഀ
Note that in the above example, I choose for align=1024, which is 1MB or 2048 sectors.<br>਍䤀琀✀猀 瘀攀爀礀 氀椀欀攀氀礀 琀栀愀琀 琀栀椀猀 戀漀甀渀搀愀爀礀 眀椀氀氀 洀愀琀挀栀 洀漀猀琀 猀琀爀椀瀀攀 甀渀椀琀猀⸀㰀戀爀㸀ഀഀ
<br>਍䄀昀琀攀爀 琀栀攀 昀漀爀洀愀琀琀椀渀最 椀猀 搀漀渀攀Ⰰ 礀漀甀 挀愀渀 挀栀攀挀欀 琀栀攀 漀昀昀猀攀琀 甀猀椀渀最 琀栀攀 ∀眀洀椀挀∀ 挀漀洀洀愀渀搀Ⰰ 氀椀欀攀 猀漀㨀㰀戀爀㸀ഀഀ
<br>਍䌀㨀尀㸀 眀洀椀挀 瀀愀爀琀椀琀椀漀渀 最攀琀 䈀氀漀挀欀匀椀稀攀Ⰰ 匀琀愀爀琀椀渀最伀昀昀猀攀琀Ⰰ 一愀洀攀Ⰰ 䤀渀搀攀砀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍吀栀攀爀攀 愀爀攀 猀漀 洀愀渀礀 洀漀爀攀 挀漀渀猀椀搀攀爀愀琀椀漀渀猀 漀渀 猀琀漀爀愀最攀⸀ 䘀漀爀 攀砀愀洀瀀氀攀Ⰰ 愀 昀攀愀琀甀爀攀 氀椀欀攀 ∀䠀䈀䄀 焀甀攀甀攀 氀攀渀最琀栀∀ 椀猀 椀洀瀀漀爀琀愀渀琀 愀猀 眀攀氀氀⸀㰀戀爀㸀ഀഀ
So, in general, I would say that DBA's just need storage specialists for large projects.<br>਍㰀戀爀㸀ഀഀ
But at least it's good to know that the right choices on "allocation unit" and "partition alignment" could play<br>਍∀猀漀洀攀∀ 爀漀氀攀 愀猀 眀攀氀氀 椀渀 ∀漀瘀攀爀愀氀氀∀ 瀀攀爀昀漀爀洀愀渀挀攀⸀㰀戀爀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
<h2>Chapter 7. Placement of objects on Filegroups.</h2><br>਍ഀഀ
<h3>7.1 The "traditional" non-partitioning approach:</h3>਍ഀഀ
If you are not too familiar with the concept of "filegroups", here is a small demo.<br>਍䤀渀 琀栀攀 攀砀愀洀瀀氀攀 戀攀氀漀眀Ⰰ 眀攀 愀爀攀 最漀椀渀最 琀漀 挀爀攀愀琀攀 琀栀攀 搀愀琀愀戀愀猀攀 ∀匀䄀䰀䔀匀∀Ⰰ 愀渀搀 椀渀猀琀攀愀搀 漀昀 㰀䤀㸀 樀甀猀琀 栀愀瘀椀渀最㰀戀爀㸀ഀഀ
only the PRIMARY filegroup (the default)</I>, we make two additional "logical containers": SALESDATA01 and SALESINDEX01.<br>਍㰀戀爀㸀ഀഀ
A filegroup can contain one or more files (usually more than one, if we have a large database).<br>਍吀栀攀 ∀琀爀椀挀欀∀ 椀猀Ⰰ 琀漀 氀攀琀 琀栀攀 昀椀氀攀猀 漀昀 愀 挀攀爀琀愀椀渀 昀椀氀攀最爀漀甀瀀Ⰰ 爀攀猀椀搀攀 漀渀 㰀䈀㸀愀渀漀琀栀攀爀 昀椀氀攀猀礀猀琀攀洀㰀⼀䈀㸀Ⰰ㰀戀爀㸀ഀഀ
than the files of the other filegroups.<br>਍㰀戀爀㸀ഀഀ
If those filesystems correspond to really different diskvolumes, we can achieve parallel IO.<br>਍吀栀椀猀 椀猀 猀漀Ⰰ 戀攀挀愀甀猀攀 眀栀攀渀 礀漀甀 挀爀攀愀琀攀 愀 吀愀戀氀攀 漀爀 愀渀 䤀渀搀攀砀Ⰰ 礀漀甀 挀愀渀 猀瀀攀挀椀昀礀 ⠀愀猀 愀 挀氀愀甀猀攀⤀Ⰰ 漀渀 眀栀椀挀栀㰀戀爀㸀ഀഀ
filegroup it is supposed to live.<br>਍伀爀Ⰰ 眀椀琀栀 攀砀椀猀琀椀渀最 琀愀戀氀攀猀 愀渀搀 椀渀搀攀砀攀猀Ⰰ 椀琀✀猀 瀀漀猀猀椀戀氀攀 琀漀 洀漀瘀攀 琀愀戀氀攀猀Ⰰ 愀渀搀 渀漀渀ⴀ挀氀甀猀琀攀爀攀爀搀 椀渀搀攀砀攀猀Ⰰ 琀漀 琀栀攀椀爀 漀眀渀 昀椀氀攀最爀漀甀瀀猀⸀㰀戀爀㸀ഀഀ
<br>਍匀漀Ⰰ 昀椀氀攀最爀漀甀瀀猀 洀愀欀攀 椀琀 瀀漀猀猀椀戀氀攀 琀漀 猀攀瀀攀爀愀琀攀 琀愀戀氀攀猀 愀渀搀 椀渀搀攀砀攀猀Ⰰ 愀渀搀 渀漀琀栀椀渀最 瀀爀攀瘀攀渀琀猀 礀漀甀 昀爀漀洀 昀甀爀琀栀攀爀㰀戀爀㸀ഀഀ
seperate large tables (or indexes) on their own filegroups (just create the appropriate number of filegroups).<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍ഀഀ
create database SALES<br>਍漀渀 倀刀䤀䴀䄀刀夀㰀戀爀㸀ഀഀ
(<br>਍渀愀洀攀㴀✀匀䄀䰀䔀匀✀Ⰰ㰀戀爀㸀ഀഀ
filename='f:\mssql\dATA\SALES.mdf'<br>,਍猀椀稀攀㴀㐀　　䴀䈀Ⰰ㰀戀爀㸀ഀഀ
filegrowth= 0MB,<br>਍洀愀砀猀椀稀攀㴀 㐀　　䴀䈀㰀戀爀㸀ഀഀ
),<br>਍䘀䤀䰀䔀䜀刀伀唀倀 匀䄀䰀䔀匀䐀䄀吀䄀　㄀㰀戀爀㸀ഀഀ
(<br>਍渀愀洀攀㴀✀匀䄀䰀䔀匀开䐀䄀吀䄀开　㄀✀Ⰰ㰀戀爀㸀ഀഀ
filename='g:\mssql\data\SALES_DATA_01.ndf',<br>਍猀椀稀攀㴀 㐀　　　䴀䈀Ⰰ㰀戀爀㸀ഀഀ
filegrowth= 100MB,<br>਍洀愀砀猀椀稀攀㴀 㠀　　　䴀䈀㰀戀爀㸀ഀഀ
),<br>਍䘀䤀䰀䔀䜀刀伀唀倀 匀䄀䰀䔀匀䤀一䐀䔀堀　㄀㰀戀爀㸀ഀഀ
(<br>਍渀愀洀攀㴀✀匀䄀䰀䔀匀开䤀一䐀䔀堀开　㄀✀Ⰰ㰀戀爀㸀ഀഀ
filename='h:\mssql\data\SALES_INDEX_01.ndf',<br>਍猀椀稀攀㴀 㐀　　　䴀䈀Ⰰ㰀戀爀㸀ഀഀ
filegrowth= 100MB,<br>਍洀愀砀猀椀稀攀㴀 㠀　　　䴀䈀㰀戀爀㸀ഀഀ
)<br>਍䰀伀䜀 伀一㰀戀爀㸀ഀഀ
(<br>਍渀愀洀攀㴀✀匀䄀䰀䔀匀开䰀伀䜀开　　㄀✀Ⰰ㰀戀爀㸀ഀഀ
filename='i:\mssql\log\SALES_LOG_001.ldf',<br>਍猀椀稀攀㴀 ㌀　　　䴀䈀Ⰰ㰀戀爀㸀ഀഀ
filegrowth= 100MB,<br>਍洀愀砀猀椀稀攀㴀 㠀　　　䴀䈀㰀戀爀㸀ഀഀ
)<br>਍㰀戀爀㸀ഀഀ
਍䄀䰀吀䔀刀 䐀䄀吀䄀䈀䄀匀䔀 匀䄀䰀䔀匀㰀戀爀㸀ഀഀ
MODIFY FILEGROUP SALESDATA01 DEFAULT<br>਍䜀伀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
In the above example, you see that I only have F:, G:, and H: for filegroups for tables and indexes.<br>਍䤀琀✀猀 瘀攀爀礀 椀洀瀀漀爀琀愀渀琀 琀漀 瀀甀琀 琀栀攀 ∀琀爀愀渀猀愀挀琀椀漀渀氀漀最 昀椀氀攀⠀猀⤀∀ 猀攀瀀攀爀愀琀攀 昀爀漀洀 琀栀攀 愀戀漀瘀攀 昀椀氀攀猀礀猀琀攀洀猀 昀漀爀 琀愀戀氀攀猀 愀渀搀 椀渀搀攀砀攀猀⸀㰀戀爀㸀ഀഀ
In the above example, the transactionlog resides on I:<br>਍㰀戀爀㸀ഀഀ
<B>Approach 1:</B><br>਍㰀戀爀㸀ഀഀ
As you have seen from chapter 4, if a table has a clustered index, in effect, the leafpages of that clustered index<br>਍愀爀攀 琀栀攀 琀愀戀氀攀瀀愀最攀猀 琀栀攀猀攀氀瘀攀猀⸀㰀戀爀㸀ഀഀ
So, if all (or most) of your tables have a Primary Key (and are enforced by the unique clustered index), then you could follow this approach:<br>਍㰀戀爀㸀ഀഀ
<B>Create nonclustered indexes on a filegroup other than the filegroup of the table (= clustered index).</B><br>਍㰀戀爀㸀ഀഀ
And repeat that approach for all other relevant large and/or active tables.<br>਍伀昀挀漀甀爀猀攀Ⰰ 礀漀甀 挀愀渀渀漀琀 最椀瘀攀 攀瘀攀爀礀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀 椀琀✀猀 漀眀渀 昀椀氀攀最爀漀甀瀀Ⰰ 猀漀 瀀爀漀戀愀戀氀礀 礀漀甀 眀椀氀氀 瀀甀琀 愀 昀愀椀爀氀礀 氀愀爀最攀 渀甀洀戀攀爀㰀戀爀㸀ഀഀ
of indexes on "filegroupA", and possibly another fairly large number of indexes on "filegroupB".<br> ਍㰀戀爀㸀ഀഀ
This is all actually no more than "common sense".<br>਍㰀戀爀㸀ഀഀ
You can even apply this approach for the largest and most active tables. Even if your database has hundreds, or even thousents<br>਍漀昀 琀愀戀氀攀猀Ⰰ 䤀 愀洀 猀甀爀攀Ⰰ 琀栀愀琀 甀猀椀渀最 琀栀攀 焀甀攀爀椀攀猀 昀爀漀洀 挀栀愀瀀琀攀爀 㐀Ⰰ 礀漀甀 眀椀氀氀 搀椀猀挀漀瘀攀爀 琀栀愀琀 漀渀氀礀 ㄀　Ⰰ 漀爀 ㈀　 漀爀 洀愀礀戀攀 ㌀　Ⰰ 爀攀愀氀氀礀 氀愀爀最攀㰀戀爀㸀ഀഀ
and/or active tables are present. Suppose you have found tables A,B,C,D,E,F,G,H to be very large.<br>਍一漀眀Ⰰ 渀漀琀栀椀渀最 瀀爀攀瘀攀渀琀猀 礀漀甀 昀爀漀洀 瀀氀愀挀椀渀最 吀愀戀氀攀猀 䄀Ⰰ 䈀Ⰰ 䌀Ⰰ 䐀 漀渀 昀椀氀攀最爀漀甀瀀 ∀䘀䜀开䄀䈀䌀䐀∀Ⰰ 愀渀搀 瀀氀愀挀攀 琀栀攀 琀愀戀氀攀猀 䔀Ⰰ 䘀Ⰰ 䜀Ⰰ 䠀 漀渀 昀椀氀攀最爀漀甀瀀 ∀䘀䜀开䔀䘀䜀䠀∀⸀㰀戀爀㸀ഀഀ
<br>਍䄀猀 愀 猀洀愀氀氀 戀漀渀甀猀Ⰰ 栀愀瘀椀渀最 琀栀攀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀 漀渀 琀栀攀椀爀 猀攀瀀攀爀愀琀攀 昀椀氀攀最爀漀甀瀀⠀猀⤀Ⰰ 礀漀甀 栀愀瘀攀 猀漀洀攀 氀攀瘀攀氀 漀昀 愀搀搀椀琀椀漀渀愀氀 瀀爀漀琀攀挀琀椀漀渀⸀㰀戀爀㸀ഀഀ
If the drive(s) containing those filegroup(s) go bad, or something else crashes, you can regenerated the non-clustered indexes again.<br>਍伀渀氀礀 琀栀攀 琀愀戀氀攀猀 ⠀漀爀 琀栀攀 挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀⤀ 挀漀渀琀愀椀渀 琀栀攀 ∀琀爀甀攀∀ 搀愀琀愀⸀ 䄀氀氀 漀琀栀攀爀 椀渀搀攀砀攀猀 挀愀渀 戀攀 爀攀ⴀ挀爀攀愀琀攀搀Ⰰ 愀氀琀栀漀甀最栀 椀琀 挀漀甀氀搀㰀戀爀㸀ഀഀ
take quite some time.<br>਍㰀戀爀㸀ഀഀ
Note: always have a recent database script with create statements of all tables, indexes and all other objects !<br>਍㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀䄀瀀瀀爀漀愀挀栀 ㈀㨀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍䄀瀀瀀爀漀愀挀栀 渀甀洀戀攀爀 ㄀Ⰰ 椀猀 洀漀猀琀 愀瀀瀀攀愀氀椀渀最 琀漀 洀攀⸀ 䈀甀琀 猀漀洀攀 䐀䈀䄀✀猀 搀漀 猀漀洀攀琀栀椀渀最 攀氀猀攀⸀ 吀栀攀礀 樀甀猀琀 洀椀砀 琀愀戀氀攀猀 愀渀搀 渀漀渀ⴀ挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀㰀戀爀㸀ഀഀ
among a number of filegroups on different diskdrives. That's not a bad idea either.<br>਍㰀戀爀㸀ഀഀ
It's evident, that here, you are most sure that all diskdrives are used at all times.<br>਍㰀戀爀㸀ഀഀ
You only need to create a list of the largest and/or most active tables and indexes, and distribute those object<br>਍漀渀 猀攀瘀攀爀愀氀 昀椀氀攀最爀漀甀瀀猀 ⠀眀栀椀挀栀 琀栀攀洀猀攀氀瘀攀猀 猀栀漀甀氀搀 爀攀猀椀搀攀 漀渀 搀椀昀昀攀爀攀渀琀 ∀猀瀀椀渀搀攀氀猀∀⤀⸀㰀戀爀㸀ഀഀ
<br>਍䤀昀 礀漀甀 眀愀渀琀 琀漀 猀攀攀 眀栀椀挀栀 挀氀甀猀琀攀爀攀搀 愀渀搀 渀漀渀开挀氀甀猀琀攀爀攀搀 椀渀搀攀砀攀猀 爀攀猀椀搀攀 漀渀 眀栀椀挀栀 昀椀氀攀最爀漀甀瀀猀Ⰰ 礀漀甀 洀椀最栀琀 甀猀攀 琀栀椀猀 焀甀攀爀礀㨀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
਍匀䔀䰀䔀䌀吀 伀⸀一愀洀攀 䄀匀 嬀伀戀樀攀挀琀 一愀洀攀崀Ⰰ 伀⸀嬀吀礀瀀攀崀Ⰰ 䤀⸀渀愀洀攀 䄀匀 嬀䤀渀搀攀砀 渀愀洀攀崀Ⰰ 䤀⸀䤀渀搀攀砀开䤀搀Ⰰ 䤀⸀琀礀瀀攀开搀攀猀挀 䄀匀 嬀䤀渀搀攀砀 吀礀瀀攀崀Ⰰ 䘀⸀渀愀洀攀 䄀匀 嬀䘀椀氀攀最爀漀甀瀀 一愀洀攀崀㰀戀爀㸀ഀഀ
FROM sys.indexes I INNER JOIN sys.filegroups F<br>਍伀一 䤀⸀搀愀琀愀开猀瀀愀挀攀开椀搀 㴀 䘀⸀搀愀琀愀开猀瀀愀挀攀开椀搀㰀戀爀㸀ഀഀ
INNER JOIN sys.objects O ON I.[object_id] = O.[object_id]<br>਍䜀伀㰀戀爀㸀ഀഀ
<br>਍䤀昀 礀漀甀 搀漀 渀漀琀 眀愀渀琀 琀漀 ✀猀攀攀✀ 琀栀攀 猀礀猀琀攀洀瘀椀攀眀猀 ⠀猀琀愀爀琀椀渀最 琀栀攀椀爀 渀愀洀攀 漀昀琀攀渀 眀椀琀栀 ✀猀礀猀✀⤀ 椀渀 琀栀攀 漀甀琀瀀甀琀Ⰰ㰀戀爀㸀ഀഀ
then use:<br>਍㰀戀爀㸀ഀഀ
SELECT O.Name AS [Object Name], O.[Type], I.name AS [Index name], I.Index_Id, I.type_desc AS [Index Type], F.name AS [Filegroup Name]<br>਍䘀刀伀䴀 猀礀猀⸀椀渀搀攀砀攀猀 䤀 䤀一一䔀刀 䨀伀䤀一 猀礀猀⸀昀椀氀攀最爀漀甀瀀猀 䘀㰀戀爀㸀ഀഀ
ON I.data_space_id = F.data_space_id<br>਍䤀一一䔀刀 䨀伀䤀一 猀礀猀⸀漀戀樀攀挀琀猀 伀 伀一 䤀⸀嬀漀戀樀攀挀琀开椀搀崀 㴀 伀⸀嬀漀戀樀攀挀琀开椀搀崀㰀戀爀㸀ഀഀ
WHERE O.Name not like 'sys%'<br>਍䜀伀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍㰀栀㌀㸀㜀⸀㈀ 倀愀爀琀椀琀椀漀渀椀渀最 氀愀爀最攀 琀愀戀氀攀猀 愀渀搀 椀渀搀攀砀攀猀㨀㰀⼀栀㌀㸀ഀഀ
<br>਍䠀攀爀攀 椀猀 猀漀洀攀 㰀䤀㸀攀砀琀爀攀洀攀氀礀 猀栀漀爀琀Ⰰ 愀渀搀 氀椀最栀琀眀攀椀最栀琀Ⰰ㰀⼀䤀㸀 椀渀昀漀爀洀愀琀椀漀渀 漀渀 㰀䈀㸀 琀愀戀氀攀 愀渀搀 椀渀搀攀砀 瀀愀爀琀椀琀椀漀渀椀渀最⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍䤀渀 琀栀椀猀 猀攀挀琀椀漀渀Ⰰ 眀攀 最漀 漀渀攀 猀琀攀瀀 昀甀爀琀栀攀爀Ⰰ 戀礀 ∀瀀愀爀琀椀琀椀漀渀椀渀最∀ 㰀䈀㸀猀甀戀猀攀琀猀 漀昀 琀栀攀 猀愀洀攀 漀渀攀 琀愀戀氀攀㰀⼀䈀㸀Ⰰ 漀渀 琀栀攀椀爀 漀眀渀 昀椀氀攀最爀漀甀瀀猀⸀㰀戀爀㸀ഀഀ
<br>਍一漀眀 氀攀琀 琀栀愀琀 猀椀渀欀 椀渀㨀 眀攀 眀椀氀氀 搀攀瘀椀搀攀 愀 琀愀戀氀攀Ⰰ 椀渀琀漀 瀀愀爀琀猀Ⰰ 愀渀搀 瀀甀琀 琀栀漀猀攀 瀀愀爀琀猀 漀渀 搀椀昀昀攀爀攀渀琀 昀椀氀攀最爀漀甀瀀猀⸀ 䔀猀猀攀渀琀椀愀氀氀礀Ⰰ㰀戀爀㸀ഀഀ
that's partitioning !<br>਍㰀戀爀㸀ഀഀ
Ideally, you would have a certain column in your table, that lends itself easily to "get partioned". In other words,<br> ਍琀栀愀琀 瀀愀爀琀椀挀甀氀愀爀 挀漀氀甀洀渀 眀漀甀氀搀 栀愀瘀攀 瘀愀氀甀攀猀 琀栀愀琀 愀爀攀 攀愀猀椀氀礀 搀椀瘀椀搀攀搀 椀渀琀漀 猀甀戀猀攀琀猀Ⰰ 氀椀欀攀 昀漀爀 攀砀愀洀瀀氀攀 ∀礀攀愀爀猀∀⸀㰀戀爀㸀ഀഀ
For example, you might have a table with some date column, and you could group records belonging to<br>਍琀漀 琀栀攀 礀攀愀爀猀 ∀㈀　　　∀Ⰰ ∀㈀　　㄀Ⰰ ∀㈀　　㈀∀ 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
<br>਍䈀甀琀 攀瘀攀渀 椀昀 椀琀 搀漀攀猀渀✀琀 最漀 椀渀 猀甀挀栀 愀 ∀渀愀琀甀爀愀氀 眀愀礀∀Ⰰ 礀漀甀 挀愀渀 愀氀眀愀礀猀 昀漀爀挀攀 猀漀洀攀 昀漀爀洀 漀昀 猀甀戀猀攀琀琀椀渀最⸀ 䘀漀爀 攀砀愀洀瀀氀攀Ⰰ 礀漀甀 栀愀瘀攀㰀戀爀㸀ഀഀ
a nummeric column, and you just are going to distinquish the following subsets:<br>਍㰀戀爀㸀ഀഀ
1 - 10000000<br>਍㄀　　　　　　㄀ ⴀ ㈀　　　　　　　㰀戀爀㸀ഀഀ
20000001 - 30000000<br>਍攀琀挀⸀⸀㰀戀爀㸀ഀഀ
<br>਍䌀爀攀愀琀椀渀最 愀 瀀愀爀琀椀琀椀漀渀攀搀 吀愀戀氀攀Ⰰ 漀爀 䤀渀搀攀砀Ⰰ 椀猀 愀 ㌀ 猀琀攀瀀 瀀爀漀挀攀猀猀⸀㰀戀爀㸀ഀഀ
<br>਍䐀漀渀✀琀 昀漀爀最攀琀 琀栀愀琀 琀栀攀 眀栀漀氀攀 椀搀攀愀 戀攀栀椀渀搀 瀀愀爀琀椀琀椀漀渀椀渀最 愀 琀愀戀氀攀 椀猀 琀栀椀猀㨀 挀爀攀愀琀攀 刀愀渀最攀猀 漀昀 瘀愀氀甀攀猀Ⰰ 眀栀攀爀攀 琀栀攀 爀漀眀猀 漀昀 琀栀攀 琀愀戀氀攀 眀椀氀氀㰀戀爀㸀ഀഀ
fall into, and make sure that you can store those different record subsets (the different Ranges), onto separate Filegroups.<br>਍㰀戀爀㸀ഀഀ
- We start by defining a Partition Function. This is function that defines the boundaries, or Partition Ranges, that the subsets of rows will use.<br>਍ⴀ 匀攀挀漀渀搀氀礀Ⰰ 眀攀 挀爀攀愀琀攀 愀 倀愀爀琀椀琀椀漀渀椀渀最 匀挀栀攀洀攀Ⰰ 琀栀愀琀 搀攀昀椀渀攀猀 琀栀攀 洀愀瀀瀀椀渀最猀 漀昀 琀栀攀 倀愀爀琀椀琀椀漀渀 刀愀渀最攀猀 琀漀 䘀椀氀攀䜀爀漀甀瀀猀 ⠀椀渀搀椀瘀椀搀甀愀氀 猀琀漀爀愀最攀 猀琀爀甀挀琀甀爀攀猀⤀㰀戀爀㸀ഀഀ
- Thirdly, we create a Table, using the definitions above.<br>਍㰀戀爀㸀ഀഀ
That's all.<br>਍㰀戀爀㸀ഀഀ
So, a simple example will illustrate this.<br>਍㰀戀爀㸀ഀഀ
1. Suppose we have a certain database, which uses the filegroups FG1, FG2, FG3 and FG4.<br>਍㰀戀爀㸀ഀഀ
Suppose we have a table PARTSAMPLE that we want to partition. It uses the columns ID (datatype INT) and NAME (varchar(20)).<br>਍吀栀攀 瘀愀氀甀攀猀 琀栀愀琀 䤀䐀 挀愀渀 琀愀欀攀Ⰰ 愀爀攀 昀漀爀 攀砀愀洀瀀氀攀 ㄀☀ㄠ　　　☀†㜀　　　☀†㈀　　　　☀†㌀　　　　 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
<br>਍㈀⸀ 一漀眀 氀攀琀✀猀 搀攀昀椀渀攀 琀栀攀 ∀倀愀爀琀椀琀椀漀渀 刀愀渀最攀猀∀Ⰰ 漀爀 戀漀甀渀搀愀爀椀攀猀Ⰰ 琀栀愀琀 琀栀攀 猀甀戀猀攀琀猀 漀昀 爀漀眀猀 挀愀渀 琀愀欀攀㨀㰀戀爀㸀ഀഀ
We do that by creating a Partition Function, whereas later we are going to "bind" it somehow to the table.<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍䌀刀䔀䄀吀䔀 倀䄀刀吀䤀吀䤀伀一 䘀唀一䌀吀䤀伀一 猀愀洀瀀氀攀昀甀渀挀琀椀漀渀 ⠀䤀一吀⤀㰀戀爀㸀ഀഀ
AS<br>਍刀䄀一䜀䔀 䰀䔀䘀吀 䘀伀刀 嘀䄀䰀唀䔀匀 ⠀㄀　　　　Ⰰ ㈀　　　　Ⰰ ㌀　　　　⤀㰀戀爀㸀ഀഀ
GO<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍吀栀椀猀 昀甀渀挀琀椀漀渀Ⰰ 椀猀 愀渀 椀渀搀攀瀀攀渀搀攀渀琀 漀戀樀攀挀琀 椀渀 琀栀攀 搀愀琀愀戀愀猀攀⸀ 䰀愀琀攀爀 眀攀 眀椀氀氀 甀猀攀 椀琀 椀渀 琀栀攀 倀䄀刀吀匀䄀䴀倀䰀䔀 琀愀戀氀攀 搀攀昀椀渀椀琀椀漀渀⸀㰀戀爀㸀ഀഀ
<br>਍吀栀攀 ∀䰀䔀䘀吀∀ 漀爀 ∀刀䤀䜀䠀吀∀ 椀渀 琀栀攀 昀甀渀挀琀椀漀渀 搀攀昀椀渀椀琀椀漀渀 洀攀愀渀猀 椀昀 礀漀甀 眀愀渀琀 琀栀攀 椀渀琀攀爀瘀愀氀 琀漀 ∀氀攀昀琀猀椀搀攀搀∀ 漀爀 ∀爀椀最栀琀猀椀搀攀搀∀ 愀猀 椀渀㨀㰀戀爀㸀ഀഀ
10001 - 20000<br>਍㄀　　　　 ⴀ ㄀㤀㤀㤀㤀㰀戀爀㸀ഀഀ
<br>਍㌀⸀ 一攀砀琀Ⰰ 眀攀 眀椀氀氀 搀攀昀椀渀攀 琀栀攀 ∀倀愀爀琀椀琀椀漀渀 匀挀栀攀洀攀∀Ⰰ 琀栀愀琀 眀椀氀氀 爀攀氀愀琀攀 琀栀攀 刀愀渀最攀猀 琀漀 琀栀攀 䘀椀氀攀最爀漀甀瀀猀㨀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
CREATE PARTITON SCHEME samplescheme <br>਍䄀匀㰀戀爀㸀ഀഀ
PARTITION samplefunction TO<br>਍⠀嬀䘀䜀㄀崀Ⰰ 嬀䘀䜀㈀崀Ⰰ 嬀䘀䜀㌀崀Ⰰ 嬀䘀䜀㐀崀⤀㰀戀爀㸀ഀഀ
GO<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
<br>਍夀漀甀 猀攀攀 琀栀愀琀 椀渀 琀栀攀 倀愀爀琀椀琀椀漀渀 匀挀栀攀洀攀 搀攀昀椀渀椀琀椀漀渀Ⰰ 眀攀 爀攀氀愀琀攀 琀栀攀 䘀椀氀攀䜀爀漀甀瀀猀 琀漀 琀栀攀 ∀猀愀洀瀀氀攀昀甀渀挀琀椀漀渀∀ 昀甀渀挀琀椀漀渀Ⰰ 琀栀甀猀 琀栀攀爀攀戀礀㰀戀爀㸀ഀഀ
relating the FileGroups to the Ranges (or boundaries).<br>਍㰀戀爀㸀ഀഀ
4. As the last step, we will define our PARTSAMPLE table, using the Partition Scheme defined above.<br>਍㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍䌀刀䔀䄀吀䔀 吀䄀䈀䰀䔀 倀䄀刀吀匀䄀䴀倀䰀䔀㰀戀爀㸀ഀഀ
(<br>਍䤀䐀   䤀一吀         一伀吀 一唀䰀䰀Ⰰ㰀戀爀㸀ഀഀ
NAME VARCHAR(20) NOT NULL<br>਍⤀㰀戀爀㸀ഀഀ
ON samplescheme(ID)<br>਍䜀伀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
So, if a record with an ID of 15000 would be inserted, it would be stored on FileGroup "FG2".<br>਍䰀椀欀攀眀椀猀攀Ⰰ 椀昀 愀 爀攀挀漀爀搀 眀椀琀栀 愀渀 䤀䐀 漀昀 ㈀㔀　　　 眀漀甀氀搀 戀攀 椀渀猀攀爀琀攀搀Ⰰ 椀琀 眀漀甀氀搀 戀攀 猀琀漀爀攀搀 漀渀 䘀椀氀攀䜀爀漀甀瀀 ∀䘀䜀㌀∀⸀㰀戀爀㸀ഀഀ
<br>਍ഀഀ
<br>਍㰀栀㈀㸀䌀栀愀瀀琀攀爀 㠀⸀ 伀琀栀攀爀 爀攀洀愀爀欀猀 漀渀 猀攀瘀攀爀愀氀 猀甀戀樀攀挀琀猀⸀㰀⼀栀㈀㸀㰀戀爀㸀ഀഀ
਍䤀渀 琀栀椀猀 挀栀愀瀀琀攀爀Ⰰ 眀攀 眀椀氀氀 爀攀瘀椀攀眀 愀 挀漀甀瀀氀攀 漀昀 漀琀栀攀爀 椀洀瀀漀爀琀愀渀琀 猀甀戀樀攀挀琀猀⸀㰀戀爀㸀ഀഀ
<br>਍㰀栀㌀㸀㠀⸀㄀ 吀栀攀 爀椀最栀琀 挀栀漀椀挀攀 漀昀 搀愀琀愀琀礀瀀攀猀⸀㰀⼀栀㌀㸀ഀഀ
਍匀儀䰀 匀攀爀瘀攀爀 欀渀漀眀猀 愀 栀甀最攀 渀甀洀戀攀爀 漀昀 搀愀琀愀琀礀瀀攀猀⸀ 䤀昀 礀漀甀 搀攀昀椀渀攀 愀 琀愀戀氀攀Ⰰ 礀漀甀 琀攀氀氀 匀儀䰀 匀攀爀瘀攀爀 琀栀攀 挀漀氀甀洀渀渀愀洀攀猀Ⰰ㰀戀爀㸀ഀഀ
and the datatypes (and possibly other attributes as well).<br>਍䘀漀爀 攀砀愀洀瀀氀攀Ⰰ 眀攀 栀愀瘀攀 琀栀攀 搀愀琀愀琀礀瀀攀猀 ∀椀渀琀∀ ⠀椀渀琀攀最攀爀⤀Ⰰ ∀搀攀挀椀洀愀氀⠀渀Ⰰ洀⤀∀Ⰰ ∀挀栀愀爀⠀渀⤀∀Ⰰ ∀瘀愀爀挀栀愀爀⠀渀⤀∀Ⰰ ∀搀愀琀攀琀椀洀攀∀ 攀琀挀⸀⸀㰀戀爀㸀ഀഀ
<br>਍䤀昀 礀漀甀 挀爀攀愀琀攀 琀栀攀 琀愀戀氀攀猀 礀漀甀爀猀攀氀昀 昀漀爀 猀漀洀攀 愀瀀瀀氀椀挀愀琀椀漀渀Ⰰ 漀爀 礀漀甀 愀爀攀 愀戀氀攀 琀漀 愀搀瘀椀猀攀 愀 搀攀瘀攀氀漀瀀攀爀Ⰰ 琀栀攀 昀漀氀氀漀眀椀渀最 椀猀㰀戀爀㸀ഀഀ
quite important.<br>਍㰀戀爀㸀ഀഀ
If you choose "too wide" datatypes, you fill a database block "too quickly". This means that a smaller number of rows<br>਍昀椀琀猀 椀渀 愀 琀愀戀氀攀 瀀愀最攀⸀㰀戀爀㸀 ഀഀ
This cost performance, because the database needs to read more pages, to get the same imformation.<br>਍䘀漀爀 攀砀愀洀瀀氀攀Ⰰ 猀甀瀀瀀漀猀攀 猀漀洀攀 琀愀戀氀攀 栀愀猀 愀 ∀䌀伀䴀䴀䔀一吀∀ 挀漀氀甀洀渀⸀ 吀栀椀渀欀 漀昀 琀栀攀 挀漀渀猀攀焀甀攀渀挀攀 椀昀 猀漀洀攀 搀攀瘀攀氀漀瀀攀爀 挀栀漀漀猀攀 愀㰀戀爀㸀ഀഀ
a datatype of "char(2000)", meaning a fixed column lenght of 2000 bytes.<br>਍一漀眀 椀昀 琀栀攀 挀漀洀洀攀渀琀 椀猀 愀琀 洀漀猀琀 樀甀猀琀 愀 昀攀眀 眀漀爀搀猀Ⰰ 琀栀攀渀 琀栀愀琀✀猀 愀 琀爀甀攀 眀愀猀琀攀⸀㰀戀爀㸀ഀഀ
<br>਍匀漀Ⰰ 愀氀眀愀礀猀 琀爀礀 琀漀 挀栀漀漀猀攀 愀 搀愀琀愀琀礀瀀攀 ⠀眀椀琀栀 愀 ∀眀椀搀琀栀∀⤀ 琀栀愀琀 猀甀椀琀猀 琀栀攀 瀀甀爀瀀漀猀攀Ⰰ 戀甀琀 愀氀猀漀 渀漀琀 㰀䤀㸀∀琀栀愀琀 琀栀椀最栀琀∀㰀⼀䤀㸀⸀㰀戀爀㸀ഀഀ
Just try to balance it a bit.<br>਍㰀戀爀㸀ഀഀ
The choice a datatypes also infuences the amount of "processor time".<br>਍䤀昀 礀漀甀 琀栀椀渀欀 愀戀漀甀琀 愀 瘀攀爀礀 愀挀琀椀瘀攀 搀愀琀愀戀愀猀攀Ⰰ 琀栀攀 昀椀爀猀琀 琀栀椀渀最 琀栀愀琀 挀漀洀攀猀 琀漀 洀椀渀搀Ⰰ 椀猀 栀攀愀瘀礀 䐀椀猀欀 䤀伀⸀㰀戀爀㸀ഀഀ
But certainly not in all cases. High cpu utilization is a very important performance issue too.<br>਍一漀眀Ⰰ 搀漀渀琀 琀栀椀渀欀 琀栀愀琀 琀栀椀猀 眀椀氀氀 漀渀氀礀 栀愀瀀瀀攀渀 愀琀 琀栀攀 瀀栀礀猀椀挀猀 搀攀瀀愀爀琀洀攀渀琀Ⰰ 眀栀攀爀攀 搀椀昀昀椀挀甀氀琀 挀愀氀挀甀氀愀琀椀漀渀猀 愀爀攀 甀猀攀搀⸀㰀戀爀㸀ഀഀ
<br>਍䐀漀渀✀琀 甀渀搀攀爀攀猀琀椀洀愀琀攀 昀椀渀愀渀挀椀愀氀 愀瀀瀀氀椀挀愀琀椀漀渀猀Ⰰ 眀栀攀爀攀 焀甀椀琀攀 攀氀愀戀漀爀愀琀攀 挀愀氀挀甀氀愀琀椀漀渀猀 洀愀礀 戀攀 搀漀渀攀 漀渀 愀氀氀 猀漀爀琀猀 漀昀 愀猀猀攀琀猀㰀戀爀㸀ഀഀ
and securities etc..<br>਍䠀攀爀攀 琀漀漀Ⰰ 琀栀攀 挀栀漀椀挀攀 漀昀 琀栀攀 洀漀猀琀 漀瀀琀椀洀愀氀 搀愀琀愀琀礀瀀攀猀 椀猀 椀洀瀀漀爀琀愀渀琀⸀ 䤀琀✀猀 搀椀昀昀椀挀甀氀琀 琀漀 猀愀礀 椀渀 最攀渀攀爀愀氀 眀栀椀挀栀 搀愀琀愀礀瀀攀猀㰀戀爀㸀ഀഀ
are the best. Just depends on the application. Hopefully, the developers are aware of this fact. Not all are, so I have noticed.<br>਍㰀戀爀㸀ഀഀ
<h3>8.2 Some remarks on TEMPDB.</h3>਍ഀഀ
TEMPDB is a sort of "scratch workplace" for SQL Server. You might find many temporay tables here, which might be<br>਍甀猀攀搀 昀漀爀 愀氀氀 欀椀渀搀猀 漀昀 猀漀爀琀猀Ⰰ 漀爀 愀猀 愀 猀漀爀琀 漀昀 椀渀琀攀爀洀攀搀椀愀琀攀 猀琀漀爀愀最攀 挀漀渀琀愀椀渀攀爀猀Ⰰ 搀甀爀椀渀最 瀀爀漀挀攀猀猀椀渀最⸀㰀戀爀㸀ഀഀ
<br>਍䄀 戀漀琀琀氀攀渀攀挀欀 椀渀 琀攀洀瀀搀戀 䤀伀Ⰰ 挀愀渀 椀洀瀀愀挀琀 琀栀攀 漀瘀攀爀愀氀氀 琀栀爀漀甀最栀瀀甀琀 漀昀 礀漀甀爀 匀儀䰀 匀攀爀瘀攀爀⸀㰀戀爀㸀ഀഀ
<br>਍䠀漀眀 愀挀琀椀瘀攀 吀䔀䴀倀䐀䈀 眀椀氀氀 戀攀Ⰰ 搀攀瀀攀渀搀猀 漀渀 匀儀䰀 匀攀爀瘀攀爀 椀琀猀攀氀昀Ⰰ 㰀䈀㸀㰀唀㸀愀渀搀㰀⼀唀㸀㰀⼀䈀㸀 琀栀攀 愀瀀瀀氀椀挀愀琀椀漀渀⸀㰀戀爀㸀ഀഀ
Usually, the application is the most important factor. But, if for example, SQL Server "versioning" is in use,<br>਍琀栀攀渀 甀猀愀最攀 漀渀 吀䔀䴀倀䐀䈀 挀愀渀 戀攀 瘀攀爀礀 栀椀最栀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
Fortunately, Windows System Monitor (called Performance Monitor in the past) has the neccessary counters<br>਍琀漀 洀愀欀攀 愀 樀甀搀最攀洀攀渀琀 漀渀 栀漀眀 愀挀琀椀瘀攀 吀䔀䴀倀䐀 愀挀琀甀愀氀氀礀 椀猀⸀㰀戀爀㸀ഀഀ
<br>਍夀漀甀 挀愀渀 愀氀猀漀 眀爀椀琀攀 礀漀甀爀 漀眀渀 猀礀猀琀攀洀 焀甀攀爀椀攀猀 琀栀愀琀 最椀瘀攀猀 椀渀昀漀 漀渀 琀栀攀 愀挀琀椀瘀椀琀礀 漀渀 吀䔀䴀倀䐀䈀⸀㰀戀爀㸀ഀഀ
<br>਍䠀攀爀攀 愀爀攀 愀 昀攀眀 攀砀愀洀瀀氀攀猀㨀㰀戀爀㸀ഀഀ
<br>਍吀栀攀 昀漀氀氀漀眀椀渀最 眀椀氀氀 最椀瘀攀 愀渀 椀搀攀愀 漀渀 愀氀氀漀挀愀琀攀搀 瀀愀最攀猀 瀀攀爀 猀攀猀猀椀漀渀㨀㰀戀爀㸀ഀഀ
<font face="courier" size=2 color="black">਍㰀戀爀㸀ഀഀ
USE TEMPDB<br>਍㰀戀爀㸀ഀഀ
SELECT top 10 * <br>਍䘀刀伀䴀 猀礀猀⸀搀洀开搀戀开猀攀猀猀椀漀渀开猀瀀愀挀攀开甀猀愀最攀 㰀戀爀㸀 ഀഀ
ORDER BY (user_objects_alloc_page_count + internal_objects_alloc_page_count) DESC<br>਍㰀戀爀㸀ഀഀ
<font face="arial" size=2 color="black">਍吀栀攀 昀漀氀氀漀眀椀渀最 眀椀氀氀 最椀瘀攀 愀渀 椀搀攀愀 漀渀 琀栀攀 渀甀洀戀攀爀 漀昀 琀攀洀瀀漀爀愀爀礀 琀愀戀氀攀猀 ⠀眀栀椀挀栀 渀愀洀攀 猀琀愀爀琀猀 眀椀琀栀 ∀⌀∀⤀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
USE TEMPDB<br>਍㰀戀爀㸀ഀഀ
select name, create_date, modify_date from sys.all_objects<br>਍眀栀攀爀攀 渀愀洀攀 氀椀欀攀 ✀─⌀─✀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀愀爀椀愀氀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
A keypoint is this: if TEMPDB is very active, here too you might coinsider to place the TEMPDB data- and log files<br>਍漀渀 愀 昀愀猀琀 搀椀猀欀 眀栀椀挀栀 眀愀猀 渀漀琀 洀甀挀栀 甀猀攀搀 戀攀昀漀爀攀⸀㰀戀爀㸀ഀഀ
Although many of us don't have that luxury, you might consider to place the files at for example a backup dump<br>਍搀椀猀欀Ⰰ 眀栀椀挀栀 洀椀最栀琀 漀渀氀礀 戀攀 甀猀攀搀 ∀漀挀挀愀猀椀漀渀愀氀氀礀∀ ⠀漀渀挀攀 愀 搀愀礀Ⰰ 漀爀 漀渀挀攀 愀渀 栀漀甀爀Ⰰ 昀漀爀 昀甀氀氀ⴀ 漀爀 琀爀愀渀猀愀挀琀椀漀渀 戀愀挀欀甀瀀猀⤀⸀㰀戀爀㸀ഀഀ
Ofcourse, in some cases, that's not a good idea. Only you can determine how matters are in your situation.<br>਍㰀戀爀㸀ഀഀ
A recommendation you can find in many articles, is to let TEMPDB consist of several datafiles.<br>਍匀漀洀攀 攀瘀攀渀 爀攀挀漀洀洀攀渀搀Ⰰ 琀栀愀琀 礀漀甀 氀攀琀 琀栀攀 渀甀洀戀攀爀 漀昀 昀椀氀攀猀 琀漀 戀攀 攀焀甀愀氀 琀漀 琀栀攀 渀甀洀戀攀爀 漀昀 挀瀀甀 挀漀爀攀猀⸀㰀戀爀㸀ഀഀ
<br>਍䠀攀爀攀 椀猀 愀 猀愀洀瀀氀攀 漀渀 栀漀眀 礀漀甀 挀漀甀氀搀 洀漀搀椀昀礀 琀栀攀 吀䔀䴀倀䐀䈀 搀愀琀愀戀愀猀攀㨀㰀戀爀㸀ഀഀ
<br>਍㰀昀漀渀琀 昀愀挀攀㴀∀挀漀甀爀椀攀爀∀ 猀椀稀攀㴀㈀ 挀漀氀漀爀㴀∀戀氀愀挀欀∀㸀ഀഀ
ALTER DATABASE TEMPDB<br>਍䴀伀䐀䤀䘀夀 䘀䤀䰀䔀㰀戀爀㸀ഀഀ
   (NAME = tempdev,<br>਍   匀䤀娀䔀 㴀 ㄀　䴀䈀Ⰰ    ⴀⴀ 欀攀攀瀀 琀栀椀猀 漀渀攀 猀洀愀氀氀㰀戀爀㸀ഀഀ
   MAXSIZE=10MB);<br>਍䜀伀㰀戀爀㸀ഀഀ
<br>਍䄀䰀吀䔀刀 䐀䄀吀䄀䈀䄀匀䔀 吀䔀䴀倀䐀䈀 䄀䐀䐀 䘀䤀䰀䔀 ⠀   ⴀⴀ 氀攀琀✀猀 愀搀搀 㐀 搀愀琀愀昀椀氀攀猀㰀戀爀㸀ഀഀ
NAME = TempDevA,<br>਍䘀䤀䰀䔀一䄀䴀䔀 㴀 ✀䴀㨀尀洀猀猀焀氀尀搀愀琀愀尀琀攀洀瀀搀攀瘀愀⸀渀搀昀✀Ⰰ㰀戀爀㸀ഀഀ
SIZE = 100MB,<br>਍䴀䄀堀匀䤀娀䔀 㴀 ㈀　　䴀䈀Ⰰ㰀戀爀㸀ഀഀ
FILEGROWTH = 20MB),<br>਍⠀㰀戀爀㸀ഀഀ
NAME = TempDevB,<br>਍䘀䤀䰀䔀一䄀䴀䔀 㴀 ✀䴀㨀尀洀猀猀焀氀尀搀愀琀愀尀琀攀洀瀀搀攀瘀戀⸀渀搀昀✀Ⰰ㰀戀爀㸀ഀഀ
SIZE = 100MB,<br>਍䴀䄀堀匀䤀娀䔀 㴀 ㈀　　䴀䈀Ⰰ㰀戀爀㸀ഀഀ
FILEGROWTH = 20MB),<br>਍⠀㰀戀爀㸀ഀഀ
NAME = TempDevC,<br>਍䘀䤀䰀䔀一䄀䴀䔀 㴀 ✀䴀㨀尀洀猀猀焀氀尀搀愀琀愀尀琀攀洀瀀搀攀瘀挀⸀渀搀昀✀Ⰰ㰀戀爀㸀ഀഀ
SIZE = 100MB,<br>਍䴀䄀堀匀䤀娀䔀 㴀 ㈀　　䴀䈀Ⰰഀഀ
FILEGROWTH = 20MB),<br>਍⠀㰀戀爀㸀ഀഀ
NAME = TempDevD,<br>਍䘀䤀䰀䔀一䄀䴀䔀 㴀 ✀䴀㨀尀洀猀猀焀氀尀搀愀琀愀尀琀攀洀瀀搀攀瘀搀⸀渀搀昀✀Ⰰ㰀戀爀㸀ഀഀ
SIZE = 100MB,<br>਍䴀䄀堀匀䤀娀䔀 㴀 ㈀　　䴀䈀Ⰰ㰀戀爀㸀ഀഀ
FILEGROWTH = 20MB)<br>਍䜀伀 㰀戀爀㸀ഀഀ
<font face="arial" size=2 color="black">਍㰀戀爀㸀ഀഀ
<h3>8.3 Carefully consider the Max memory limit for SQL Server 64bit.</h3>਍ഀഀ
Suppose you use SQL Server 2005/2008 64. What should be the maximum memory you should assign to SQL Server?<br>਍䄀挀琀甀愀氀氀礀Ⰰ 琀栀椀猀 㰀䤀㸀氀漀漀欀猀㰀⼀䤀㸀 攀愀猀礀Ⰰ 戀甀琀 椀琀 椀猀渀✀琀⸀㰀戀爀㸀ഀഀ
<br>਍匀甀瀀瀀漀猀攀 礀漀甀爀 砀㘀㐀 猀礀猀琀攀洀 栀愀猀 漀渀氀礀 ㄀㘀䜀䈀 漀昀 洀攀洀漀爀礀⸀ 一漀眀Ⰰ 一吀 ⠀洀攀愀渀椀渀最 圀椀渀㈀欀㌀Ⰰ 圀椀渀㈀欀㠀 攀琀挀⸀⸀⤀ 愀渀搀 愀氀氀 猀礀猀愀搀洀椀渀 瀀爀漀最爀愀洀猀㰀戀爀㸀ഀഀ
(like backup software, anti-virus, monitoring agents etc..) needs memory too, which can be considerable.<br>਍䈀攀挀愀甀猀攀⸀⸀⸀ 礀漀甀 搀漀渀✀琀 眀愀渀琀 琀栀愀琀 琀栀攀 猀礀猀琀攀洀 攀砀栀椀戀椀琀猀 㰀䤀㸀攀砀挀攀猀猀椀瘀攀 瀀愀最椀渀最㰀⼀䤀㸀⸀㰀戀爀㸀ഀഀ
There is no good alternative other than to discuss this with your nearest senior sysadmin.<br>਍匀漀Ⰰ 椀渀 琀栀攀 甀瀀瀀攀爀 攀砀愀洀瀀氀攀 漀昀 愀 猀礀猀琀攀洀 漀昀 漀渀氀礀 ㄀㘀䜀䈀Ⰰ 䤀 猀甀最最攀猀琀 礀漀甀 氀椀洀椀琀 椀琀 琀漀 ㄀㈀䜀䈀⸀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀䨀甀猀琀 愀 昀攀眀 眀漀爀搀猀 漀渀 一吀 瀀愀最椀渀最⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍唀猀椀渀最 倀攀爀昀漀爀洀愀渀挀攀 䴀漀渀椀琀漀爀 挀漀甀渀琀攀爀猀 琀漀 ∀洀攀愀猀甀爀攀∀ 琀栀攀 愀洀漀甀渀琀 漀昀 瀀愀最椀渀最Ⰰ 挀愀渀 猀漀洀攀琀椀洀攀猀 戀攀 愀 戀椀琀 挀漀渀昀甀猀椀渀最⸀㰀戀爀㸀ഀഀ
If you see a moderate or high value of "Memory: Pages/sec", it does not neccesarily need all to be caused by paging alone,<br> ਍漀爀 瀀愀最攀猀 昀爀漀洀 愀渀搀 琀漀 挀愀挀栀攀⸀㰀戀爀㸀ഀഀ
Some applications or tools might "page" to memory mapped files, which will "distort" the view considerably.<br>਍䈀攀猀椀搀攀猀 琀栀愀琀Ⰰ 洀愀渀礀 挀愀甀猀攀猀 攀砀椀猀琀 眀栀礀 ∀䴀攀洀漀爀礀㨀 倀愀最攀猀⼀猀攀挀∀ 瀀爀漀搀甀挀攀 栀椀最栀 瘀愀氀甀攀猀⸀ 䈀甀琀 愀渀礀眀愀礀Ⰰ 椀琀 猀栀漀甀氀搀 渀漀琀 戀攀 㰀䤀㸀琀漀漀 栀椀最栀㰀⼀䤀㸀 漀昀挀漀甀爀猀攀⸀㰀戀爀㸀ഀഀ
<br>਍夀漀甀 洀椀最栀琀 栀愀瘀攀 栀椀最栀 愀洀漀甀渀琀 漀昀 瀀愀最椀渀最Ⰰ 椀昀 礀漀甀 猀攀攀㨀㰀戀爀㸀ഀഀ
"Memory: Pages/sec" - moderate to high.<br>਍∀䴀攀洀漀爀礀㨀 䄀瘀愀椀氀愀戀氀攀 䈀礀琀攀猀∀ ⴀ 眀漀甀氀搀 戀攀 氀漀眀⸀㰀戀爀㸀ഀഀ
"Paging File: % Usage" - would be high.<br>਍∀倀愀最椀渀最 䘀椀氀攀㨀 ─ 倀攀愀欀 唀猀愀最攀∀ ⴀ 眀漀甀氀搀 戀攀 栀椀最栀⸀㰀戀爀㸀ഀഀ
"Memory: Pages Output/Sec" - would be high.<br>਍㰀戀爀㸀ഀഀ
This last counter shows how many virtual memory pages were written to the pagefile to free RAM page frames,<br>਍愀渀搀 椀猀 琀栀攀爀攀昀漀爀攀 愀 最漀漀搀 椀渀搀椀挀愀琀漀爀⸀㰀戀爀㸀ഀഀ
<br>਍䤀琀✀猀 琀爀甀攀 琀栀愀琀 一吀 眀椀氀氀 愀氀眀愀礀猀 瀀愀最攀 琀漀 愀 挀攀爀琀愀椀渀 攀砀琀攀渀琀⸀㰀戀爀㸀ഀഀ
Especially, with all monitoring "tools" loaded, NT systems will certainly page somewhat.<br> ਍㰀戀爀㸀ഀഀ
As to the size of the pagefile, as a rule of thumb for "low" memory systems, it should be around 1.5xTotal RAM.<br>਍伀昀挀漀甀爀猀攀Ⰰ 琀栀攀 洀漀爀攀 洀攀洀漀爀礀 礀漀甀 栀愀瘀攀Ⰰ 琀栀攀 氀攀猀猀 椀洀瀀漀爀琀愀渀琀 琀栀攀 猀椀稀攀 漀昀 琀栀攀 瀀愀最攀昀椀氀攀 椀猀⸀㰀戀爀㸀ഀഀ
No sysadmin will ever create a pagefile of 128GB, if the system has 64GB RAM.<br>਍㰀戀爀㸀ഀഀ
਍㰀栀㌀㸀㠀⸀㐀 䌀漀洀洀椀琀 氀椀洀椀琀猀 愀渀搀 爀攀洀漀琀攀 氀漀最最椀渀最 漀昀 䈀愀琀挀栀攀猀⸀㰀⼀栀㌀㸀ഀഀ
਍圀栀愀琀 䤀 栀愀瘀攀 猀攀攀渀 漀挀挀愀猀椀漀渀愀氀氀礀Ⰰ 愀爀攀 琀眀漀 猀漀爀琀 漀昀 ∀洀椀猀挀漀渀昀椀最甀爀愀琀椀漀渀猀∀ 琀栀愀琀 挀愀渀 愀昀昀攀挀琀 瀀攀爀昀漀爀洀愀渀挀攀 椀渀 愀 渀攀最愀琀椀瘀攀 眀愀礀⸀㰀戀爀㸀ഀഀ
<br>਍䴀漀猀琀 愀瀀瀀氀椀挀愀琀椀漀渀猀Ⰰ 眀椀氀氀 栀愀瘀攀 猀漀洀攀 猀漀爀琀 漀昀 戀愀琀挀栀 昀愀挀椀氀椀琀礀Ⰰ 眀栀椀挀栀 椀猀 氀椀欀攀氀礀 琀漀 戀攀 猀挀栀攀搀甀氀攀搀 愀昀琀攀爀 眀漀爀欀椀渀最 栀漀甀爀猀⸀㰀戀爀㸀ഀഀ
The architecture of such batches, is very diverse.<br>਍㰀戀爀㸀ഀഀ
What can be worthwile, is to investigate if some "component" does "logging" (to a logfile) at a <B>remote</B> host.<br>਍䤀昀 椀渀 猀甀挀栀 愀 挀愀猀攀Ⰰ 愀 猀漀爀琀 漀昀 ∀匀䔀一䐀 ⴀ 䄀挀欀渀漀眀氀攀搀最攀∀ 猀挀栀攀洀攀 椀猀 椀渀 甀猀攀Ⰰ 琀栀愀琀 挀愀渀 猀氀漀眀 搀漀眀渀 琀栀攀 戀愀琀挀栀 猀椀最渀椀昀椀挀愀渀琀氀礀⸀㰀戀爀㸀ഀഀ
<br>਍䄀氀猀漀Ⰰ 椀琀 挀愀渀 戀攀 眀漀爀琀栀眀椀氀攀 椀昀 琀栀攀 ∀洀攀琀愀搀愀琀愀∀ ⠀椀渀 挀漀渀昀椀最昀椀氀攀猀Ⰰ 漀爀 椀渀 琀栀攀 爀攀最椀猀琀爀礀 攀琀挀⸀⸀⤀ 漀昀 琀栀攀 愀瀀瀀氀椀挀愀琀椀漀渀Ⰰ 甀猀攀猀㰀戀爀㸀ഀഀ
some sort of "commit limit". What I mean is this. Such an application generates smaller or larger batches of transactions.<br> ਍䔀愀挀栀 漀昀 琀栀攀猀攀 戀愀琀挀栀攀猀 椀猀 挀漀洀椀琀琀攀搀⸀ 䈀甀琀 眀栀愀琀 椀猀 琀栀攀 氀攀渀最栀琀㼀 䤀猀 猀甀挀栀 愀 戀愀琀挀栀 ㄀Ⰰ ㄀　Ⰰ ㄀　　　Ⰰ ㄀　　　　 爀攀挀漀爀搀猀 ∀眀椀搀攀∀㼀ഀഀ
In the extreme, if a "batch" is only 1 "wide", that too can slow down the batch significantly.<br>਍㰀戀爀㸀ഀഀ
<br>਍㰀栀㈀㸀䌀栀愀瀀琀攀爀 㤀⸀ 匀漀洀攀 爀攀愀氀 眀漀爀氀搀 挀愀猀攀猀Ⰰ 搀攀猀挀爀椀戀椀渀最 猀漀洀攀眀栀愀琀 洀漀爀攀 挀漀洀瀀氀攀砀 瀀攀爀昀漀爀洀愀渀挀攀 瀀爀漀戀氀攀洀猀⸀㰀⼀栀㈀㸀㰀戀爀㸀ഀഀ
਍㰀栀㌀㸀㤀⸀㄀ 匀漀洀攀 椀洀瀀漀爀琀愀渀琀 ⠀渀漀琀 猀漀 琀爀椀瘀椀愀氀⤀ 眀愀椀琀开琀礀瀀攀猀㨀㰀⼀栀㌀㸀ഀഀ
਍䤀渀 琀栀椀猀 渀漀琀攀Ⰰ 眀攀 栀愀瘀攀 猀攀攀渀 愀 昀攀眀 猀甀戀樀攀挀琀猀 琀栀愀琀 洀椀最栀琀 戀攀 琀栀攀 漀爀椀最椀渀 昀漀爀 瀀攀爀昀漀爀洀愀渀挀攀 瀀爀漀戀氀攀洀猀⸀㰀戀爀㸀ഀഀ
As said right from the start of this note, we do not cover <I>Query Design</I>.<br>਍䄀挀琀甀愀氀氀礀Ⰰ 琀栀椀猀 椀猀 漀渀攀 漀昀 琀栀攀 洀漀猀琀 挀漀洀洀漀渀 挀愀甀猀攀猀 漀昀 氀漀眀 瀀攀爀昀漀爀洀愀渀挀攀⸀ 䤀渀搀攀攀搀Ⰰ 琀栀攀 椀洀瀀愀挀琀 挀愀渀 戀攀 焀甀椀琀攀 猀攀瘀攀爀攀⸀㰀戀爀㸀ഀഀ
<br>਍一漀眀 猀甀瀀瀀漀猀攀 礀漀甀 栀愀瘀攀Ⰰ 眀栀愀琀 猀攀攀洀猀 琀漀 戀攀Ⰰ 愀 眀攀氀氀 挀漀渀昀椀最甀爀攀搀 猀礀猀琀攀洀⸀ 匀漀Ⰰ 礀漀甀 栀愀瘀攀 猀甀昀昀椀挀椀攀渀琀 洀攀洀漀爀礀Ⰰ 愀渀搀 䐀椀猀欀 䤀伀 猀攀攀洀猀 琀漀 戀攀 昀椀渀攀Ⰰ㰀戀爀㸀ഀഀ
lots of cpu power etc.. etc..<br>਍㰀戀爀㸀ഀഀ
Still you might encounter what appears to be "performance issues".<br>਍㰀戀爀㸀ഀഀ
Here are a few important wait_types to watch for:<br>਍㰀戀爀㸀ഀഀ
਍㰀䈀㸀䌀堀倀䄀䌀䬀䔀吀㨀㰀⼀䈀㸀 倀爀漀戀愀戀氀礀 爀攀氀愀琀攀搀 琀漀 ∀倀愀爀愀氀氀攀氀椀猀洀∀⸀㰀戀爀㸀ഀഀ
<B>SOS_SCHEDULER_YIELD:</B> Might be an indicator of CPU pressure.<br>਍㰀䈀㸀䄀匀夀一䌀开一䔀吀圀伀刀䬀开䤀伀㨀㰀⼀䈀㸀 䴀椀最栀琀 戀攀 愀渀 椀渀搀椀挀愀琀漀爀 漀昀 瀀漀漀爀 一攀琀眀漀爀欀 䤀⼀伀⸀㰀戀爀㸀ഀഀ
<B>LCK_X, LCK_M_U, & LCK_M_X:</B> Long lasting locks, and/or locks that involve many extents (leading to blocking).<br>਍㰀䈀㸀倀䄀䜀䔀䤀伀䰀䄀吀䌀䠀开堀㨀㰀⼀䈀㸀 䈀甀昀昀攀爀 䤀⼀伀 氀愀琀挀栀Ⰰ 洀愀礀戀攀 搀甀攀 琀漀 瀀漀漀爀 䐀椀猀欀 䤀伀Ⰰ 漀爀 氀漀眀 漀渀 洀攀洀漀爀礀⸀㰀戀爀㸀ഀഀ
<B>ASYNC_IO_COMPLETION & IO_COMPLETION:</B> Could also be attributed to poor Disk IO, or general IO issues.<br>਍㰀䈀㸀倀䄀䜀䔀䰀䄀吀䌀䠀开堀㨀㰀⼀䈀㸀 䈀甀昀昀攀爀 氀愀琀挀栀 瀀爀漀戀氀攀洀猀⸀㰀戀爀㸀ഀഀ
<B>WRITELOG & LOGBUFFER:</B> Might be due to poor IO to the Tranaction log disk subsystem.<br>਍㰀戀爀㸀ഀഀ
In the next sections we will some examples of these wait_types.<br>਍ഀഀ
<h3>9.2 LCK_M_U, CXPACKET, SOS_SCHEDULER_YIELD, DTC</h3>਍ഀഀ
<B>Problem: you see high "wait times" associated with one or more of the "wait_types" LCK_M_U, CXPACKET, SOS_SCHEDULER_YIELD,<br>਍愀渀搀 瀀漀猀猀椀戀氀礀 愀氀猀漀 䐀吀䌀⸀ഀഀ
Secondly, you <I>might</I> (but not neccessarily so) find a lot of dealocks in some application log, and/or users complains<br> ਍琀栀愀琀 琀栀攀椀爀 昀爀漀渀琀攀渀搀 愀瀀瀀氀椀挀愀琀椀漀渀猀 漀昀琀攀渀 ∀猀琀愀氀氀猀∀⸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍圀攀 欀渀漀眀 琀栀愀琀 ∀甀渀搀攀爀 琀栀攀 栀漀漀搀∀ 猀礀猀琀攀洀猀 氀椀欀攀 匀儀䰀 匀攀爀瘀攀爀Ⰰ 愀爀攀 椀渀挀爀攀搀愀戀氀礀 挀漀洀瀀氀攀砀⸀ 䈀甀琀Ⰰ 匀儀䰀 匀攀爀瘀攀爀 ㈀　　㔀⼀㈀　　㠀 最攀渀攀爀愀琀攀猀㰀戀爀㸀ഀഀ
a lot of tracing or logging "material", which you can "see" using the "dynamic mamagement views (DMV's)".<br>਍䄀氀琀栀漀甀最栀 礀漀甀 洀愀礀 渀漀琀 挀愀氀氀 椀琀 ∀琀爀愀挀椀渀最 洀愀琀攀爀椀愀氀∀Ⰰ 琀栀攀 䐀䴀嘀✀猀 猀甀爀攀 昀甀渀挀琀椀漀渀猀 琀栀愀琀 眀愀礀⸀㰀戀爀㸀ഀഀ
<br>਍吀栀攀 ∀欀攀礀眀漀爀搀猀∀ 椀渀 琀栀攀 琀椀琀氀攀 漀昀 琀栀椀猀 猀攀挀琀椀漀渀Ⰰ 氀漀漀欀 瀀爀攀琀琀礀 椀洀瀀爀攀猀猀椀瘀攀⸀ 䄀挀琀甀愀氀氀礀Ⰰ 琀栀攀猀攀 愀爀攀 ∀眀愀椀琀开琀礀瀀攀猀∀⸀㰀戀爀㸀ഀഀ
If you switch back quicly to section 1.3, you find a nice query giving you a top 10 "wait times"<br>਍愀渀搀 琀攀氀氀椀渀最 礀漀甀 眀栀愀琀 ∀眀愀椀琀 琀礀瀀攀猀∀ 琀栀攀礀 愀爀攀 愀猀猀漀挀椀愀琀攀搀 眀椀琀栀⸀㰀戀爀㸀ഀഀ
Note from the figure in section 1.3, that the "waittimes" due to "wait_type=CXPACKET" are pretty high too.<br>਍吀栀攀 眀愀椀琀开琀礀瀀攀猀 䌀堀倀䄀䌀䬀䔀吀Ⰰ 匀伀匀开匀䌀䠀䔀䐀唀䰀䔀刀开夀䤀䔀䰀䐀Ⰰ 䰀䌀䬀开䴀开唀 愀爀攀 椀渀 洀愀渀礀 挀愀猀攀猀Ⰰ 爀攀氀愀琀攀搀 琀漀 攀愀挀栀 漀琀栀攀爀⸀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀㰀唀㸀䌀堀倀䄀䌀䬀䔀吀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍䌀堀倀䄀䌀䬀䔀吀 眀愀椀琀猀 洀愀礀 椀渀搀椀挀愀琀攀 瀀愀爀愀氀氀攀氀椀猀洀 瀀爀漀戀氀攀洀猀⸀ 吀栀椀猀 戀愀猀椀挀愀氀氀礀 洀攀愀渀猀 礀漀甀 愀爀攀 爀甀渀渀椀渀最 愀 瀀愀爀愀氀氀攀氀 瀀爀漀挀攀猀猀 愀渀搀 漀渀攀㰀戀爀㸀ഀഀ
or more threads of it, are waiting for others to complete. CXPackets occur when a query has its operations run in parallel,<br>਍戀甀琀 渀漀琀 愀氀氀 漀瀀攀爀愀琀椀漀渀猀 挀漀洀瀀氀攀琀攀 愀琀 琀栀攀 猀愀洀攀 琀椀洀攀⸀ 匀儀䰀 匀攀爀瘀攀爀 挀愀渀渀漀琀 挀漀渀琀椀渀甀攀 琀漀 琀栀攀 渀攀砀琀 匀儀䰀 猀琀愀琀攀洀攀渀琀 㰀戀爀㸀ഀഀ
because not all operations have completed. This results in waiting defined as CXPacket.<br>਍吀栀攀 猀攀琀琀椀渀最 琀栀愀琀 搀攀琀攀爀洀椀渀攀猀 椀昀 ∀瀀愀爀愀氀氀攀氀椀猀洀∀ 椀猀 ∀猀眀椀琀挀栀攀搀 漀渀∀Ⰰ 椀猀 ∀䴀愀砀椀洀甀洀 䐀攀最爀攀攀 漀昀 倀愀爀愀氀氀攀氀椀猀洀∀ 漀爀 䴀䄀堀䐀伀倀⸀㰀戀爀㸀ഀഀ
If you rightclick the server object in SQL Server Management Studio, you can view and modify all sorts of settings.<br>਍䤀渀 琀栀攀 ∀䄀搀瘀愀渀挀攀搀∀ 瀀愀最攀Ⰰ 礀漀甀 眀椀氀氀 昀椀渀搀 琀栀攀 ∀䴀愀砀椀洀甀洀 䐀攀最爀攀攀 漀昀 倀愀爀愀氀氀攀氀椀猀洀∀ 猀攀琀琀椀渀最⸀ 䤀昀 礀漀甀 瀀甀琀 椀琀 琀漀 ∀㄀∀㰀戀爀㸀ഀഀ
you have it switched "off", although TSQL statements can override it with the MAXDOP clause.<br>਍伀昀挀漀甀爀猀攀Ⰰ 搀椀昀昀攀爀攀渀琀 猀攀猀猀椀漀渀猀 愀氀氀 漀瀀攀爀愀琀攀Ⰰ 愀渀搀 猀琀愀礀 琀漀 漀瀀攀爀愀琀攀Ⰰ 椀渀 ∀瀀愀爀愀氀氀攀氀∀Ⰰ 戀甀琀 琀栀攀 瀀愀爀愀氀氀攀氀椀猀洀 漀昀 漀渀攀 猀琀愀琀攀洀攀渀琀 椀猀 漀昀昀⸀㰀⼀氀椀㸀㰀戀爀㸀ഀഀ
If the MAXDOP setting was, for example, "8", you might lower the value, and see what the result is.<br>਍唀渀昀漀爀琀甀渀愀琀攀氀礀Ⰰ 琀愀挀欀氀椀渀最 䌀堀倀䄀䌀䬀䔀吀 眀愀椀琀猀 甀猀甀愀氀氀礀 洀攀愀渀猀 愀 氀漀琀 漀昀 琀攀猀琀椀渀最 ⠀琀爀椀愀氀 愀渀搀 攀爀爀漀爀⤀㰀戀爀㸀ഀഀ
<br>਍㰀䈀㸀㰀唀㸀䰀䌀䬀开䴀开唀㰀⼀唀㸀㰀⼀䈀㸀㰀戀爀㸀ഀഀ
<br>਍䄀挀琀甀愀氀氀礀Ⰰ 琀栀攀爀攀 愀爀攀 洀愀渀礀 ∀䰀䌀䬀开䴀⨀∀ 眀愀椀琀ⴀ琀礀瀀攀猀Ⰰ 氀椀欀攀㨀㰀戀爀㸀ഀഀ
<br>਍䰀挀欀开䴀开唀 椀猀 愀猀猀漀挀椀愀琀攀搀 琀漀 甀瀀搀愀琀攀 氀漀挀欀猀Ⰰ 琀栀愀琀 洀椀最栀琀 挀愀甀猀攀 漀琀栀攀爀 瀀爀漀挀攀猀猀攀猀 琀漀 眀愀椀琀Ⰰ 愀渀搀㰀戀爀㸀ഀഀ
Lck_M_X is associated to exclusive locks, which too might cause other processes to wait.<br>਍㰀戀爀㸀ഀഀ
The LCK_M_U wait_type might be found in many cases. It occurs when a task is waiting to acquire an Update lock, which it can't<br>਍搀漀 愀琀 琀栀愀琀 琀椀洀攀Ⰰ 戀攀挀愀甀猀攀 愀渀漀琀栀攀爀 瀀爀漀挀攀猀猀 愀氀爀攀愀搀礀 栀愀猀 愀焀甀椀爀攀搀 愀 氀漀挀欀 漀昀 猀漀洀攀 欀椀渀搀⸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
<B>-> Possible causes and some guidelines to what to do:</B><br>਍㰀戀爀㸀ഀഀ
A possible cause to high values of CXPACKET and LCK_M_U might be threads of an application that are frequently waiting on each other.<br>਍䤀渀 琀栀椀猀 挀愀猀攀Ⰰ 椀琀 洀椀最栀琀 戀攀 搀甀攀 琀漀 椀渀攀昀昀攀挀琀椀瘀攀 ∀愀瀀瀀氀椀挀愀琀椀漀渀 搀攀猀椀最渀∀⸀㰀戀爀㸀ഀഀ
<br>਍䤀昀 礀漀甀 愀氀猀漀 猀攀攀 挀漀渀猀椀搀攀爀愀戀氀攀 ∀䐀吀䌀∀ 眀愀椀琀猀⸀ 琀栀攀洀 琀栀愀琀 洀椀最栀琀 戀攀 愀 挀氀甀攀 琀栀愀琀 搀椀猀琀爀椀戀甀琀攀搀 琀爀愀渀猀愀挀琀椀漀渀猀 愀爀攀 渀漀琀㰀戀爀㸀ഀഀ
effectively doing their work.<br>਍䤀渀 琀栀椀猀 挀愀猀攀 琀漀漀Ⰰ 椀琀 洀椀最栀琀 戀攀 搀甀攀 琀漀 椀渀攀昀昀攀挀琀椀瘀攀 ∀愀瀀瀀氀椀挀愀琀椀漀渀 搀攀猀椀最渀∀⸀㰀戀爀㸀ഀഀ
Knowing the internals of MSDTC and distributed transactions and application design, is a complex world of it's own.<br>਍㰀戀爀㸀ഀഀ
If you have a system with many cpu's, it could even be counterproductive at some batches or statements which are allowed<br>਍琀漀 甀猀攀 瀀愀爀愀氀氀攀氀椀猀洀⸀ 䤀琀 洀椀最栀琀 琀栀甀猀 栀攀氀瀀 琀漀 爀攀搀甀挀攀 琀栀攀 䴀䄀堀䐀伀倀 猀攀琀琀椀渀最Ⰰ 愀猀 攀砀瀀氀愀椀渀攀搀 愀戀漀瘀攀⸀㰀戀爀㸀ഀഀ
Ofcourse, having many cpu's is very good for overall throughput, and independent sessions are then running<br>਍椀渀 瀀愀爀愀氀氀攀氀⸀㰀戀爀㸀ഀഀ
But, with some particular queries, they might use parallelism that might give rise to LCK_M* and CXPACKET waittimes.<br>਍㰀戀爀㸀 ഀഀ
Sometimes, using the SNAPSHOT Isolation Level with the option "ALLOW_SNAPSHOT_ISOLATION" set to ON at the database level,<br>਍洀椀最栀琀 椀洀瀀爀漀瘀攀 瀀攀爀昀漀爀洀愀渀挀攀⸀㰀戀爀㸀ഀഀ
<br>਍㰀栀㌀㸀㤀⸀㌀ 䤀猀漀氀愀琀椀漀渀 䰀攀瘀攀氀猀⸀㰀⼀栀㌀㸀ഀഀ
਍ഀഀ
<br>਍㰀栀㈀㸀䌀栀愀瀀琀攀爀 ㄀　㨀 䄀 昀攀眀 最漀漀搀 氀椀渀欀猀 琀漀 琀攀挀栀渀椀挀愀氀 愀爀琀椀挀氀攀猀猀㨀㰀⼀栀㈀㸀ഀഀ
<br>਍ⴀ㸀 䤀昀 礀漀甀 眀愀渀琀 洀漀爀攀 搀攀瀀琀栀 漀渀 匀儀䰀 匀攀爀瘀攀爀 瀀攀爀昀漀爀洀愀渀挀攀 搀椀猀挀甀猀猀椀漀渀猀Ⰰ 栀攀爀攀 椀猀 愀 最漀漀搀 䴀椀挀爀漀猀漀昀琀 愀爀琀椀挀氀攀㨀㰀戀爀㸀ഀഀ
<br>਍㰀愀 栀爀攀昀㴀∀栀琀琀瀀㨀⼀⼀琀攀挀栀渀攀琀⸀洀椀挀爀漀猀漀昀琀⸀挀漀洀⼀攀渀ⴀ甀猀⼀氀椀戀爀愀爀礀⼀挀挀㤀㘀㘀㔀㐀　⸀愀猀瀀砀∀㸀䴀椀挀爀漀猀漀昀琀 吀攀挀栀渀攀琀 愀爀琀椀挀氀攀㰀⼀愀㸀㰀戀爀㸀ഀഀ
<br>਍ⴀ㸀 䜀爀攀愀琀 氀椀渀欀 眀椀琀栀 最漀漀搀 焀甀攀爀椀攀猀㨀㰀戀爀㸀ഀഀ
<br>਍㰀愀 栀爀攀昀㴀∀栀琀琀瀀㨀⼀⼀最氀攀渀渀戀攀爀爀礀猀焀氀瀀攀爀昀漀爀洀愀渀挀攀⸀猀瀀愀挀攀猀⸀氀椀瘀攀⸀挀漀洀⼀戀氀漀最⼀挀渀猀℀㐀㔀　㐀㄀㐀㄀㠀䔀䌀䌀䄀䄀㤀㘀　℀㈀　㘀㄀⸀攀渀琀爀礀∀㸀最氀攀渀渀戀攀爀爀礀猀焀氀瀀攀爀昀漀爀洀愀渀挀攀⸀猀瀀愀挀攀猀⸀氀椀瘀攀⸀挀漀洀㰀⼀愀㸀㰀戀爀㸀ഀഀ
<br>਍ⴀ㸀 䤀昀 礀漀甀 眀愀渀琀 洀漀爀攀 搀攀瀀琀栀 漀渀 匀儀䰀 匀攀爀瘀攀爀 搀椀猀欀 猀琀漀爀愀最攀 搀攀猀椀最渀 挀漀渀猀椀搀攀爀愀琀椀漀渀猀Ⰰ 栀攀爀攀 椀猀 愀 最漀漀搀 氀椀渀欀㨀㰀戀爀㸀ഀഀ
<br>਍㰀愀 栀爀攀昀㴀∀栀琀琀瀀㨀⼀⼀琀攀挀栀渀攀琀⸀洀椀挀爀漀猀漀昀琀⸀挀漀洀⼀攀渀ⴀ甀猀⼀氀椀戀爀愀爀礀⼀挀挀㤀㘀㘀㐀㄀㐀⸀愀猀瀀砀∀㸀䴀椀挀爀漀猀漀昀琀 吀攀挀栀渀攀琀 愀爀琀椀挀氀攀㰀⼀愀㸀㰀戀爀㸀ഀഀ
<br>਍ⴀ㸀 䤀昀 礀漀甀 眀愀渀琀 洀漀爀攀 搀攀瀀琀栀 漀渀 琀栀攀 猀瀀攀挀椀昀椀挀猀 漀渀 吀䔀䴀倀䐀䈀Ⰰ 栀攀爀攀 椀猀 愀 最漀漀搀 氀椀渀欀㨀㰀戀爀㸀ഀഀ
<br>਍㰀愀 栀爀攀昀㴀∀栀琀琀瀀㨀⼀⼀琀攀挀栀渀攀琀⸀洀椀挀爀漀猀漀昀琀⸀挀漀洀⼀攀渀ⴀ甀猀⼀氀椀戀爀愀爀礀⼀挀挀㤀㘀㘀㔀㐀㔀⸀愀猀瀀砀∀㸀䴀椀挀爀漀猀漀昀琀 吀攀挀栀渀攀琀 愀爀琀椀挀氀攀㰀⼀愀㸀㰀戀爀㸀ഀഀ
<br>਍ⴀ㸀 匀漀洀攀 最攀渀攀爀愀氀 瀀攀爀昀漀爀洀愀渀挀攀 瀀愀瀀攀爀猀㨀㰀戀爀㸀ഀഀ
<br>਍㰀愀 栀爀攀昀㴀∀栀琀琀瀀㨀⼀⼀猀焀氀挀愀琀⸀挀漀洀⼀琀漀瀀㄀　氀椀猀琀猀⼀愀爀挀栀椀瘀攀⼀㈀　　㜀⼀㄀㄀⼀㈀㄀⼀琀漀瀀ⴀ㄀　ⴀ猀焀氀ⴀ猀攀爀瘀攀爀ⴀ㈀　　㔀ⴀ瀀攀爀昀漀爀洀愀渀挀攀ⴀ椀猀猀甀攀猀ⴀ昀漀爀ⴀ搀愀琀愀ⴀ眀愀爀攀栀漀甀猀攀ⴀ愀渀搀ⴀ爀攀瀀漀爀琀椀渀最ⴀ愀瀀瀀氀椀挀愀琀椀漀渀猀⸀愀猀瀀砀∀㸀吀漀瀀 ㄀　 匀儀䰀 匀攀爀瘀攀爀 瀀攀爀昀漀爀洀愀渀挀攀 椀猀猀甀攀猀 椀渀 䐀圀㰀⼀愀㸀㰀戀爀㸀ഀഀ
<a href="http://sqlcat.com/top10lists/archive/2007/11/21/top-sql-server-2005-performance-issues-for-oltp-applications.aspx">Top 10 SQL Server performance issues in OLTP</a><br>਍㰀戀爀㸀ഀഀ
Note: There are some other docs from myself too (excel files):<br>਍㰀戀爀㸀ഀഀ
<a href="http://antapex.org/sql2005_keypoints.xls">Listing of some SQL Server 2005 facts & structures (for exam 070-431, 5.5 MB)</a><br>਍㰀愀 栀爀攀昀㴀∀栀琀琀瀀㨀⼀⼀愀渀琀愀瀀攀砀⸀漀爀最⼀猀焀氀㈀　　㠀开欀攀礀瀀漀椀渀琀猀⸀砀氀猀∀㸀䰀椀猀琀椀渀最 漀昀 猀漀洀攀 匀儀䰀 匀攀爀瘀攀爀 ㈀　　㠀 昀愀挀琀猀 ☀ 猀琀爀甀挀琀甀爀攀猀 ⠀昀漀爀 攀砀愀洀 　㜀　ⴀ㐀㌀㈀Ⰰ 㤀 䴀䈀⤀㰀⼀愀㸀㰀戀爀㸀ഀഀ
਍㰀戀爀㸀ഀഀ
<br>਍吀栀愀琀✀猀 椀琀⸀ 䠀漀瀀攀 椀琀 眀愀猀 漀昀 愀渀礀 栀攀氀瀀⸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
<br>਍㰀戀爀㸀ഀഀ
</body>਍㰀⼀栀琀洀氀㸀�