CaryHsu - 學無止盡: 2月 2012

2012年2月18日星期六

如何建立 Log Shipping

經過前面幾篇的介紹，相信大家對高可用性 (High Availability) 已有一定的了解，其實在SQL Server上一直有許多不同的選擇，如 Cluster、Database Mirroring、Replication，接下來我們再介紹一個在SQL Server存在已久的一個功能，也就是 Log Shipping。

Log Shipping 架構圖

Log Shipping 從 SQL Server 7.0 就開始出現，在後來 SQL Server 2005 的時候出現了一個與他類似的兄弟，稱為Database Mirroring，為何會稱他們為類似，我們簡單的進行一下比較。

Log Shipping vs Database Mirroring

兩者都不需要像Cluster一樣，需要一組特定的 Shared Disk 才可以進行。
Cluster是以一個Instance為主，而兩者都是以 Database 為主進行。
同樣透過交易檔進行還原到第二台，但是 Database Mirroring 只能1對1的還原，但是Log Shipping 可以還原到多台上(如上述圖表所示)。
交易檔還原的過程中 Database Mirroring 可以選擇同步或非同步進行，但是 Log Shipping 則只能透過非同步。
Database Mirroring可以支援自動 Failover (交易檔傳遞需設定為同步模式)，但是 Log Shipping 則不行，需手動切換。
交易檔還原的過程中 Database Mirroring的第二台 (Mirror)，不能進行讀取，但是 Log Shipping 的第二台可以。
PS：但是 Database Mirroring 的情況下，第二台可以透過資料庫快照的方式讓資料庫可以進行讀取。
兩者在第三台的分別上，Database Mirroring只需 Express的版本即可，但是 Log Shipping 需要 Workgroup or Standard or Enterprise 的版本才可以。
兩者雖然都可以透過第三台進行活動的觀察，Database Mirroring 可以透過第三台電腦達到自動 Failover ，但是 Log Shipping 上，第三台只是將原本在第一與第二台上的警示功能移到第三台上，藉以減輕負擔。
在資料庫的復原模式上，Database Mirroring只能使用 Full Mode，但是 Log Shipping 可以設定為 Full Mode或是 Bluk Logged
Database Mirroring可以透過 [資料庫鏡像監視器] 來進行觀察彼此之間的活動，但是Log Shipping只能透過統計報表來察看。

資料庫鏡像監視器

接下來大家應該了解到 Log Shpping 在 High Aviliability 算是一個很好入門的選擇，接下來，我們就來說明如何進行設定。

配備說明：
第一台
角色名稱：Primary
電腦名稱：WIN-2008R2-1
OS：Windows 2008R2 Enterprise
DB：Windows 2008R2 Enterprise
說明：主要資料庫，資料庫復原模式(Recovery Mode)需設定成完整 (Full)。

第二台
角色名稱：Secondary
電腦名稱：WIN-2008R2-2
OS：Windows 2008R2 Enterprise
DB：Windows 2008R2 Enterprise
說明：次要資料庫，接收從主要資料庫的交易資料，在沒有還原的過程中，資料庫可以使用。

底下以 [AdventureWork2008R2] 資料庫為範例

1、登入主要伺服器，選擇 [AdventureWork2008R2] -> [屬性] -> [選項] -> [復原模式]，請選擇完整或大量紀錄，再選擇 [確定]。

2、勾選 [AdventureWork2008R2] -> [屬性] -> [交易記錄傳送] -> [將此啟用為記錄傳送組態的主要資料庫]

3、點選 [備份設定]，輸入在主要伺服器上的備份資料夾與對應的本機路徑，請注意此資料夾一定要讓SQL Server Agent的服務帳號擁有讀取和寫入的權限，否則會造成排程失敗，請再點選 [備份作業] -> [排程] 進到下一個步驟。

4、此處特別注意的是設定排程的頻率，最小可以設定到10秒，你可以依照實際情況進行設定預設為15分鐘。

5、設定完成後，請將你要加入的次要伺服務器點選 [加入] 進行選擇。

6、請先點選 [連接] ，設定連接到你的次要伺服器，此處的次要資料庫如果你在次要伺服器上沒有先建立或對應的資料庫時，可以手動輸入，系統會自行搜尋如果沒有會自行輸入與主要伺服器相同的名稱。

7、切換到 [複製檔案] 的頁次後，輸入次要伺服器上的分享資料夾，請注意同樣的此資料夾一定要讓SQL Server Agent的服務帳號擁有讀取和寫入的權限，否則會造成排程失敗。

8、切換到 [還原交易記錄] 的頁次後，由於我們希望讓第二台同時也可以進行讀取，所以選擇 [待命模式]，並且勾選 [還原備份時，中斷連接資料庫中的使用者]。

9、再來可設定 [記錄傳送監視器]，監視器主要用來負責主要與次要伺服器的警示提醒的動作，如果透過另一台進行時，可以減輕二台主機的負擔，偍由於版本的要求，所以不像 Database Mirroring可以透過 Express來進行，所以此處可以不設定，我先將此監視器設定在第二台上。

10、設定完成後，回到主畫面，你可以看到設定如下，再點選 [確定] 即可。

11、切換到次要伺服器上，你會發現已將資料庫新增完成，而且狀態會變成 [待命/唯讀]。

如果你在第8個步驟中，選擇 [不復原模式] 時，就會如下圖，無法進行讀取。

12、上述的流程已設定完成，Log Shipping已可正常執行，接下來我們來看一下目前的執行狀況，可以透過 [Instance] -> [報表] -> [標準報表] -> [交易記錄傳案狀態]

13、你就可以透過此報表來觀察目前 Log Shipping 的狀況。

相關文章：

參考連結：
Log Shipping Overview
http://msdn.microsoft.com/en-us/library/ms187103.aspx
sp_help_log_shipping_monitor (Transact-SQL)
http://msdn.microsoft.com/en-us/library/ms187820.aspx
Using Secondary Servers for Query Processing
http://msdn.microsoft.com/en-us/library/ms189572.aspx
Database Mirroring and Log Shipping
http://msdn.microsoft.com/en-us/library/ms187016.aspx

關鍵字：Log Shipping、High Availability、Transaction Logs

2012年2月14日星期二

索引分析與維護建議

相信大家對Windows內建的磁碟重組這個工具一定不陌生，由於磁碟使用一陣子之後，不斷的有資料進行新增、修改、刪除的動作，所以會造成檔案的不連續性，而透過此工具可以用來進行磁碟重組並將檔案重新排序，藉以增加檔案的連續性，重組之後由於可以讓檔案在磁碟中更密集，所以可以有效的降低磁頭移動的次數。

在以前使用Oracle時，只要遇到效能不好時，前輩就教我們一個最簡單的方式進行，就是將資料透過Oracle中提供的 imp/exp(Import/Export)的指令將某表格的資料重新的載出再載入，執行完成後，非常神奇的，果然效能馬上提升，這個原理其實也是相同，由於資料重新的載入，所以可以將資料更密集的排放在一起。

PS：Oracle也是有許多調整資料庫的作法，由於並非我的強項，在此僅介紹以往的一個小方法給大家參考。

資料庫也是有相同的問題，運作的過程中不斷的有資料進行新增、修改、刪除的動作，相對的，是否有需要進行重組，這個答案是肯定的，當然是需要的，但是透過磁碟重組是否也可以完成，首先我們先簡單的分成兩個部分進行說明：

MDF與LDF檔案：一個資料庫的組成通常有這兩個檔案，相信有看過我的另一篇文章 [SQL Server 儲存設備 (Storage) 最佳調整作業] 的人一定知道，盡可能的規畫MDF與LDF的初使大小與檔案數量，不要太仰賴自動成長，因為每次檔案的成長會造成大量的I/O，所以請盡量注意初使值的設定。那是否要在進行磁碟重組，其實個人不太建議進行，而且也不太需要，因為磁碟重組需要大量的I/O可能會造成效能的問題，如果您真的有需要進行的話，最好執行完成後，透過 DBCC CHECKDB 的指令檢查一下資料庫，這樣會比較保險。
Index與Data：這個也是本篇的重點，指的就是寫入到MDF檔中的資料與索引，由於彼此的資料結構不相同，所以需要透過SQL Server中的重組方式來進行，在下列我們會接續介紹。

其實一般我們講在SQL Server上的重整與重建，主要是針對 Index ，那到底 Data需不需要進行，其實是不用的，因為 Data 主要是根據叢集索引 (Clustered Index) 進行排序存放，所以當將叢集索引(Clustered Index) 進行重整或重建時，相對的也就會將資料進行排序了。

在什麼樣的的情況下需要進行 Index 的重整與重建，其實最主要的就是進行索引碎片(Index Fragmentation) 的分析，而索引碎片 (Index Fragmentation) 主要分成下列兩個部份：

外部碎片 (External Fragmentation)：外部碎片主要發生於資料存放的索引頁 (Index Leaf Page) 不連續所造成，當有新的索引產生時，會先檢查索引頁中是否有空間可以進行存放，如果沒有時，就會產生一個新的索引頁，然後再將資料放入，因此也就造成索引存放不連續，當進行索引掃描 (Index Scan) 時，會造成讀寫頭過多的移動，造成 I/O 的浪費。
內部碎片 (Internal Fragmentation)：內部碎片主要發生在當填滿因素 (fill factor) 不為 0 或 100 %的時候，比如說設定填滿因素 (fill factor) 為 80%，剩下的20%就是內部碎片，但是填滿因素到底要設定多少才是合適的，你可以參考我的另外一篇文章 [效能調整 - 填滿因數對資料庫的影響] 裡面會有詳細的說明與實驗比較。

關於碎片的分析可以透過下列的指令進行，可以得知目前使用中的資料庫所有資料表的索引情況，此處外部碎片主要是看 Avg_fragmentation_in_percent 的欄位，而內部碎片主要是看 Avg_page_space_used_in_percent 的欄位，兩個欄位的判斷條件如下：

Avg_fragmentation_in_percent：

如果此欄位的值 > 10 and < 30 的話請進行索引的重整 (REORGANIZE) 即可。
如果此欄位的值 > 30 的話請進行索引的索引重建 (REBUILD) 。

Avg_page_space_used_in_percent ：

如果此欄位的值 > 60 and < 75 的話請進行索引的重整 (REORGANIZE) 即可。
如果此欄位的值 > 30 的話請進行索引的索引重建 (REBUILD) 。

PS：請特別注意第二段(Avg_page_space_used_in_percent)的部份，當您的 fill factor 設定不為預設值 0 或 100 時，請再自行調整值與比率的部份，而且一般不會判斷此欄位的值，就進行重整或重建。

索引碎片分析語法：


SELECT CAST(DB_NAME(database_id) AS VARCHAR(20)) AS [DATABASE Name],

CAST(OBJECT_NAME(OBJECT_ID) AS VARCHAR(20)) AS [TABLE NAME], Index_id, 

Index_type_desc, Avg_fragmentation_in_percent, 

Avg_page_space_used_in_percent

FROM sys.dm_db_index_physical_stats(DB_ID(N'AdventureWorks2008R2'),

NULL,NULL,NULL,'Detailed')

WHERE index_id > 0

索引重整 (REORGANIZE)：


ALTER INDEX IX_SalesOrderDetail ON Sales.SalesOrderDetail

REORGANIZE  WITH (FILLFACTOR = 100);

索引重建 (REBUILD)：


ALTER INDEX IX_SalesOrderDetail ON Sales.SalesOrderDetail

REBUILD WITH (FILLFACTOR = 100);

PS：FILLFACTOR可以不指定，如果不指定時，系統會透過預設的 fill factor 進行。

最後我在分享一個在官網上分享的一段自動分析索引碎片進行重整與重建的動作，你可以透過下列的語法進行，請特別注意，此段語法主要會根據你目前使用的資料庫進行分析，所以請在執行時確認一下即可。


-- Ensure a USE <databasename> statement has been executed first.
SET NOCOUNT ON;
DECLARE @objectid int;
DECLARE @indexid int;
DECLARE @partitioncount bigint;
DECLARE @schemaname nvarchar(130); 
DECLARE @objectname nvarchar(130); 
DECLARE @indexname nvarchar(130); 
DECLARE @partitionnum bigint;
DECLARE @partitions bigint;
DECLARE @frag float;
DECLARE @command nvarchar(4000); 
-- Conditionally select tables and indexes from the sys.dm_db_index_physical_stats function 
-- and convert object and index IDs to names.
SELECT
    object_id AS objectid,
    index_id AS indexid,
    partition_number AS partitionnum,
    avg_fragmentation_in_percent AS frag
INTO #work_to_do
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED')
WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;

-- Declare the cursor for the list of partitions to be processed.
DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do;

-- Open the cursor.
OPEN partitions;

-- Loop through the partitions.
WHILE (1=1)
    BEGIN;
        FETCH NEXT
           FROM partitions
           INTO @objectid, @indexid, @partitionnum, @frag;
        IF @@FETCH_STATUS < 0 BREAK;
        SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name)
        FROM sys.objects AS o
        JOIN sys.schemas as s ON s.schema_id = o.schema_id
        WHERE o.object_id = @objectid;
        SELECT @indexname = QUOTENAME(name)
        FROM sys.indexes
        WHERE  object_id = @objectid AND index_id = @indexid;
        SELECT @partitioncount = count (*)
        FROM sys.partitions
        WHERE object_id = @objectid AND index_id = @indexid;

-- 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding.
        IF @frag < 30.0
            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';
        IF @frag >= 30.0
            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD';
        IF @partitioncount > 1
            SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10));
        EXEC (@command);
        PRINT N'Executed: ' + @command;
    END;

-- Close and deallocate the cursor.
CLOSE partitions;
DEALLOCATE partitions;

-- Drop the temporary table.
DROP TABLE #work_to_do;
GO

相關文章：
維護記錄檔與索引的技巧
http://caryhsu.blogspot.com/2011/05/blog-post.html
SQL Server 上大型資料表的索引效能調整與維護
http://caryhsu.blogspot.com/2011/08/sql-server.html
效能調整 - 填滿因數對資料庫的影響
http://caryhsu.blogspot.com/2012/02/blog-post.html
索引分析與維護建議
http://caryhsu.blogspot.com/2012/02/blog-post_14.html

參考連結：
SQL Server Index Fragmentation and Its Resolution
http://www.sql-server-performance.com/2004/index-fragmentation/
What is disk defragmentation?
http://windows.microsoft.com/en-US/windows-vista/What-is-disk-defragmentation
Microsoft SQL Server 2000 Index Defragmentation Best Practices
http://technet.microsoft.com/en-us/library/cc966523.aspx
DBCC INDEXDEFRAG (Transact-SQL)
http://technet.microsoft.com/zh-tw/library/ms177571.aspx
sys.dm_db_index_physical_stats (Transact-SQL)
http://msdn.microsoft.com/zh-tw/library/ms188917.aspx
Index Fragmentation in SQL Server 2005
http://sql-articles.com/articles/performance-tunning/index-fragmentation-in-sql-server-2005/
How to Detect Table Fragmentation in SQL Server 2000 and 2005
http://www.sql-server-performance.com/2006/detect-fragmentation-sql2000-sql2005/
How to check Fragmentation on SQL Server 2005
http://blogs.msdn.com/b/jorgepc/archive/2007/12/09/how-to-check-fragmentation-on-sql-server-2005.aspx

關鍵字：SQL Server、Index Maintenance、Index Fragmentation、Index Defragmentation、REORGANIZE、REBUILD、Internal Fragmentation、External Fragmentation

2012年2月6日星期一

效能調整 - 填滿因數對資料庫的影響

索引是資料庫中非常重要的一環，它可以有效的加快查詢時的速度，但是相對的，可能也會造成新增資料時的負擔，在SQL Server中有許多相關的參數中其實可以進行調整，並針對各個不同的公司的使用情況來加以調整，藉以讓索引發揮更大的效能。

而 Fill Factor 是在索引中非常重要的一個參數設定，詳細的說明整理如下 (來自 MSDN)，簡單的說如果你的系統如果為 OLAP 類型時，那你就可以將設定值設定為 0 或 100 (0 為預設值，且 0 與 100 的設定皆相同)，因為執行的語法類型全部都是查詢，但如果是 OLTP 則可以自行觀察並調整設定值，底下我分成幾個部份進行實驗，藉以讓大家更了解 Fill Factor 參數調整與 IO的影響。

Fill Factor
使用 fill factor 選項，主要指定 Microsoft SQL Server 在使用現有的資料建立新索引時，應該在每一頁填滿多少空間。填滿因數會影響效能，因為當頁面填滿之後，SQL Server 就必須花費時間進行頁面的分割。

PS：
A、填滿因數的預設值為 0；有效值介於 0 到 100 之間。當 FILL FACTOR 設定為 0 或 100 時，分葉層級會完全填滿。
B、填滿因數只會用於建立或重建索引時。所有分頁都不會保持在特定的填滿程度。

重建索引：


ALTER INDEX IX_SalesOrderDetail ON Sales.SalesOrderDetail
REBUILD WITH (FILLFACTOR = 50, SORT_IN_TEMPDB = ON,
              STATISTICS_NORECOMPUTE = ON);

頁面分割
選擇正確的填滿因數值，可以減少可能的分頁分割，因為當基礎資料表中加入資料時，將有足夠的空間來進行索引擴充。

將新的資料列加入全文檢索頁時，Database Engine 會將幾乎一半的資料列移到新的分頁，以留出空間給新的資料列。這個重組動作稱為分頁分割。分頁分割可留出空間給新的記錄，但是執行時需要時間，而且是一項耗用大量資源的作業。此外，它也可能會造成資料片段過多，因而增加 I/O 作業。如果分頁分割次數過於頻繁，可以使用新的或現有的填滿因數值重建索引，藉以重新分配資料。

雖然 0 以外的較低填滿函數值能夠減少索引成長時進行分頁分割的需求，但是索引將需要更多的儲存空間，而且可能會降低讀取效能。即使對於會大量執行插入和更新作業的應用程式而言，讀取資料庫的次數通常比寫入資料庫的次數還要高，因數為 5 比 10。因此，指定預設值以外的填滿因數，將可能以與填滿因數設定呈反比的數量，降低資料庫的讀取效能。例如，一個 50 的填滿因數值，可能會使資料庫的讀取效能降低兩倍。讀取效能降低是因為索引包含更多的分頁，造成擷取資料所需的磁碟 IO 作業增加所致。

實驗測試：
1、使用空間上的比較：


sp_spaceused 'Sales.SalesOrderDetail';

fill factor -> 50%

fill factor -> 100%

在 fill factor 設定為50%的時候，當有新的資料加入時，為了保留額外空間給日後 Index 異動時快速加入，所以在 Index 的部份，你會看到系統會佔用了較大的空間。

2、資料讀取上的比較
查詢語法：


SELECT TOP 1000 [SalesOrderID]

      ,[SalesOrderDetailID]

      ,[CarrierTrackingNumber]

      ,[OrderQty]

      ,[ProductID]

      ,[SpecialOfferID]

      ,[UnitPrice]

      ,[UnitPriceDiscount]

      ,[LineTotal]

      ,[rowguid]

      ,[ModifiedDate]

  FROM [AdventureWorks2008R2].[Sales].[SalesOrderDetail]

  where ProductID = 776 and OrderQty > 2

I/O分析：
fill factor -> 50%
89 row(s) affected)
Table 'SalesOrderDetail'. Scan count 1, logical reads 285, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

fill factor -> 100%
(89 row(s) affected)
Table 'SalesOrderDetail'. Scan count 1, logical reads 283, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

從上述的結果來看，由於 Fill Factory 設為50%時，為了預留較多的空間，所以索引會較為分散，當然在查詢時，logical reads 的次數就會比較多，相對的也會比較慢，根據官方的說法，實際上可能會有2倍的落差，所以請小心評估後，再設定這個值。

3、資料新增上的比較：
新增語法：


INSERT INTO [AdventureWorks2008R2].[Sales].[SalesOrderDetail]

           ([SalesOrderID]

           ,[CarrierTrackingNumber]

           ,[OrderQty]

           ,[ProductID]

           ,[SpecialOfferID]

           ,[UnitPrice]

           ,[UnitPriceDiscount]

           )

     VALUES

           (43909

           ,'9467-4A37-A4'

           ,5

           ,776

           ,1

           ,100.114

           ,0)

I/O分析：
fill factor -> 50%
Table 'SpecialOfferProduct'. Scan count 0, logical reads 2, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderHeader'. Scan count 0, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderDetail'. Scan count 0, logical reads 17, physical reads 3, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

fill factor -> 100%
Table 'SpecialOfferProduct'. Scan count 0, logical reads 2, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderHeader'. Scan count 0, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'SalesOrderDetail'. Scan count 0, logical reads 22, physical reads 6, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

佔用空間：
fill factor -> 50%

table name	count	Reserved	data	index_size	unused
SalesOrderDetail	121317	20072 KB	9888 KB	9432 KB	752 KB
SalesOrderDetail	121318	20080 KB	9888 KB	9440 KB	752 KB

fill factor -> 100%

table name	count	Reserved	data	index_size	unused
SalesOrderDetail	121317	18032 KB	9888 KB	7400 KB	744 KB
SalesOrderDetail	121318	18048 KB	9888 KB	7416 KB	744 KB

執行時間：

Time Statistics
Fill Factor	100%	50%
Client processing time	12	11
Total execution time	43	31
Wait time on server replies	31	20

在如同上述的 I/O 分析，你可以看出在 Insert 的狀況下， Fill Factory 50% 可以很快的加入表格中， logical reads 只需要17即可，比 Fill Factory 100% 的 22還要快，這是因為 50% 的情況下，頁面未填滿，所以可以很快的將 index 加入。

4、頁面分散程度分析：


select * from sys.dm_db_index_physical_stats

 (DB_ID(N'AdventureWorks2008R2'), OBJECT_ID(N'SalesOrderDetail'),

 NULL, NULL , 'DETAILED');

fill factor	name	avg fragmentation in_percent	fragment count	avg_page space_used in_percent
50%	IX_SalesOrderDetail	0.196850394	2	50.13369162
	IX_SalesOrderDetail	0	1	72.15221151
	IX_SalesOrderDetail	0	1	0.543612553

100%	IX_SalesOrderDetail	0	2	99.89869039
	IX_SalesOrderDetail	0	1	72.43637262

透過 sys.dm_db_index_physical_stats 可以查出索引的分散程度，你可以看出 avg_page_space_used_in_percent 就是大約你設定的索引分散程度，當然你可以透過索引的重組或重建來進行調整，關於詳細的細節，請參考 [索引分析與維護建議]。

5、索引頁面分散程度監視
當 fill factor 設定太低時，可能會造成索引頁面過於分散，可以透過效能監視器中的 SQLServer:Access Methods -> Page Splits/sec來進行觀察，此值建議要低於20以下，如果這個值太高的話，建議你可以降低 fill factor 的值，藉以改善問題。

Object: - SQLServer:Access Methods
Counter: - Page Splits/sec
Preferred Value: - < 20

總結：
從上述的幾個章節，你可以很快的了解到 fill factor 參數對整體效能的影響，當然你可以依舊使用原本的預設值，依然可以有很好的表現，但是由於每一個系統的讀寫頻率比重不一，所以建議你可以監視資料表的使用情況，再加以調整後會讓你的系統運作的更好。

相關文章：
維護記錄檔與索引的技巧
http://caryhsu.blogspot.com/2011/05/blog-post.html
SQL Server 上大型資料表的索引效能調整與維護
http://caryhsu.blogspot.com/2011/08/sql-server.html
效能調整 - 填滿因數對資料庫的影響
http://caryhsu.blogspot.com/2012/02/blog-post.html
索引分析與維護建議
http://caryhsu.blogspot.com/2012/02/blog-post_14.html

參考連結：
SQL Server 的 Access Methods 物件
http://technet.microsoft.com/zh-tw/library/ms177426.aspx
What is a page split? What happens? Why does it happen? Why worry?
http://sqlblogcasts.com/blogs/tonyrogerson/archive/2007/06/28/what-is-a-page-split-what-happens-why-does-it-happen-why-worry.aspx
How to check Fragmentation on SQL Server 2005
http://blogs.msdn.com/b/jorgepc/archive/2007/12/09/how-to-check-fragmentation-on-sql-server-2005.aspx
sys.dm_db_index_physical_stats (Transact-SQL)
http://msdn.microsoft.com/zh-tw/library/ms188917.aspx
Understanding SQL Server Index Fill Factor Setting
http://www.mssqltips.com/sqlservertip/1940/understanding-sql-server-index-fill-factor-setting/
SET STATISTICS IO (Transact-SQL)
http://technet.microsoft.com/zh-tw/library/ms184361.aspx
填滿因數
http://technet.microsoft.com/zh-tw/library/ms177459(SQL.90).aspx
Performance Counters
http://sqlserverplanet.com/sql-optimization/performance-counters

關鍵字：SQL Server、Fill Factor、Index、IO Statistics、填滿因數

訂閱：文章 (Atom)

2012年2月18日 星期六