共用方式為

SharePoint Server 2010 的資料庫維護

  • 發行項

 

上次修改主題的時間： 2016-11-30

**摘要：**了解如何維護針對 Microsoft SharePoint 2010 產品 裝載資料及組態設定的資料庫。請閱讀指導方針，並研究資料庫維護策略及工作的建議範例。

**適用於：**Microsoft SharePoint Server 2010、Microsoft SharePoint Foundation 2010

**作者：**Bill Baer 及 Bryan Porter

**技術檢閱者：**Paul S. Randal (SQLskills.com (可能為英文網頁))

內容

  • 簡介

  • 使用 Database Console Command (DBCC) CHECKDB 檢查一致性錯誤

  • 關於 DBCC CHECKDB

  • DBCC CHECKDB 及效能

  • 測量及降低索引分散情形

  • 線上重建索引及離線重建索引

  • 測量 SQL Server 2008 或 2005 資料庫的分散情形 (sys.dm_db_index_physical_stats)

  • 降低資料庫的分散情形

  • 降低特定資料表及其索引的分散情形

  • 透過設定填滿因數來微調索引器效能

  • 壓縮資料檔

  • 建立 SQL Server 2008 維護計畫

  • 總結

注意

實作任何資料庫維護或修改 SharePoint 2010 資料庫之前，請閱讀＜對於 Office 伺服器產品及 Windows SharePoint Services 使用的資料庫變更的支援＞(機器翻譯)。

簡介

例行資料庫維護是 Microsoft SharePoint 2010 資料庫順利運作的精髓。

SharePoint 2010 資料庫的建議維護工作包括下列各項：

  • 檢查資料庫完整性。

  • 透過重新組織或重新建置索引來予以重組。

  • 為伺服器設定填滿因數。

注意

本文討論資料庫維護而非容量或效能的規劃。如需容量或容量規劃的資訊，請參閱＜規劃及設定儲存空間及 SQL Server 容量 (SharePoint Server 2010)＞。

雖然舊版 SharePoint 產品及技術需要手動介入才能執行索引重組及統計資料維護，但是 SharePoint 2010 中已有數個 SharePoint 狀況分析規則可自動處理此程序。這些規則每天都會評估資料庫索引及統計資料的狀況，並針對下列資料庫自動處理這些項目：

  • 設定資料庫

  • 內容資料庫

  • User Profile Service 應用程式設定檔資料庫

  • User Profile Service 應用程式社交資料庫

  • Web Analytics Service 應用程式報表資料庫

  • Web Analytics Service 應用程式臨時資料庫

  • Word Automation Services 資料庫

您可以執行 Transact-SQL 命令或執行資料庫維護精靈，來執行資料庫維護工作。本文說明您可以使用的 Transact-SQL 命令，接著說明如何使用 Microsoft SQL Server 資料庫維護精靈建立資料庫維護計畫 (針對 Microsoft SQL Server 2008 R2 及 Microsoft SQL Server 2005 提供詳細範例)。

使用 Database Console Command (DBCC) CHECKDB 檢查一致性錯誤

從一致性檢查開始進行例行維護作業，可確保資料及索引不會損毀。您可以使用 Database Console Command (DBCC) CHECKDB 陳述式，來執行資料及索引頁面的內部一致性檢查。

大多數的資料庫一致性問題都是來自 I/O 子系統錯誤。不過其他因素及事件也會影響資料庫一致性；例如，資料庫伺服器不正確關機或磁碟機失敗。顯著的效能及可用性問題有時可能是基礎資料庫一致性問題的徵狀。每週至少執行一次 SharePoint 2010 資料庫一致性檢查；如果發生例如資料庫伺服器或 I/O 子系統失敗等事件，也應該執行資料庫一致性檢查。

關於 DBCC CHECKDB

DBCC CHECKDB 會執行下列作業，來檢查指定資料庫中所有物件的邏輯及實體完整性：

  • 執行＜DBCC CHECKALLOC＞的對應命令，確認資料庫中的配置結構。

  • 針對資料庫中的每個資料表及檢視執行＜DBCC CHECKTABLE＞的對應命令，確認其邏輯及實體完整性。

  • 針對資料庫執行＜DBCC CHECKCATALOG＞的對應命令，確認資料庫中的中繼資料一致性。

建議您執行 DBCC CHECKDB 而非個別作業 (DBCC CHECKALLOC、DBCC CHECKTABLE 及 DBCC CHECKCATALOG 命令)；因為 DBCC CHECKDB 可識別的錯誤範圍最廣，所以在實際執行環境中執行較為安全。

DBCC CHECKDB 會使用大量記憶體、I/O 及 CPU 資源。您可以對不同伺服器上的 SharePoint 資料庫還原備份執行 DBCC CHECKDB (而非在實際執行環境中執行)，藉此分攤實際執行環境的一致性檢查工作量。

建議您先執行 DBCC CHECKDB；如果顯示錯誤，再使用最新的備份來還原受影響的資料庫。

重要

您無法執行 DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS。不過，您可以執行 DBCC_CHECKDB WITH REPAIR_FAST 及 REPAIR_REBUILD，原因是這些命令只會更新相關聯資料庫的索引。

以下是 DBCC CHECKDB 的範例輸出。

DBCC results for 'Contoso_Content_1'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
DBCC results for 'sys.sysrowsetcolumns'.
There are 2663 rows in 21 pages for object "sys.sysrowsetcolumns".
DBCC results for 'sys.sysrowsets'.
There are 309 rows in 4 pages for object "sys.sysrowsets".

...more

CHECKDB found 0 allocation errors and 0 consistency errors in database 'Contoso_Content_1'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

如需如何使用 DBCC CHECKDB 搭配 SQL Server 2008 的詳細資訊，請參閱＜DBCC CHECKDB (Transact-SQL)＞。

DBCC CHECKDB 及效能

建議您在非實際執行時段執行一致性檢查，原因是 DBCC CHECKDB 會使用大量資源 (I/O、CPU、記憶體及 tempdb 空間)。有個常見的誤解就是 DBCC CHECKDB 會取得封鎖的鎖定；事實上，在 SQL Server 2000 之前就已經不是如此了。如需詳細資訊，請參閱＜SQL Server DBA 每日一迷思：(2/30) DBCC CHECKDB 會造成封鎖 (可能為英文網頁)＞(英文)。

您可能會發現，執行 DBCC CHECKDB 時使用了過多的實際執行環境資源。在此情況下，請勿嘗試對資料表逐一執行一致性檢查。若要降低針對實際執行環境進行完整性檢查時產生的額外負荷，最好的方法就是使用下列其中一個選項：

  • 使用 WITH PHYSICAL_ONLY 選項降低 CPU 及記憶體使用量。

  • 在不同的 SQL Server 上還原資料庫備份，然後針對資料庫的還原複本執行一致性檢查。

如需這些選項的詳細資訊，請參閱 Paul S. Randal 撰寫的部落格文章＜CHECKDB 面面觀：VLDB 的一致性檢查選項 (可能為英文網頁)＞(英文)。

測量及降低索引分散情形

如果資料表或索引中的頁面邏輯順序 (由索引鍵定義) 與資料檔中的頁面實體順序不同，就會發生索引分散情形。這也可能表示資料檔頁面上的資料密度很低，進而導致浪費磁碟空間、記憶體及 I/O。索引分散情形可能是對資料表進行多次插入、更新或刪除動作的結果。下圖比對沒有分散情況的新建索引，以及經過多次插入、更新和刪除而分散的索引。紅色箭頭顯示索引的實體順序，而黑色箭頭顯示索引頁面的邏輯順序。

圖 1. 沒有分散情況的索引 (圖片來源：Paul S. Randal)

非分散的索引

 

圖 2. 分散的索引 (圖片來源：Paul S. Randal)

分散的索引

 

因為插入、更新及刪除並未平均分佈於資料表及索引的資料列中，所以每個頁面的飽和度 (或資料密度) 可能會隨著時間經過而有差異。如果查詢會掃描資料表的部份或所有索引，則分散情況可能會造成額外的頁面讀取，進而阻礙資料平行掃描，且可能大幅影響搜尋效能。

索引分散情形可能會造成效能降低及空間使用效率不彰；在只有中等使用量的資料庫上，索引可能會快速分散。

實作索引分散情形維護計畫之前，請判定哪些資料表及索引最為分散。接著建立維護計畫來重新建置或重新組織這些索引。

例如，在 SharePoint 2010 中，經常出現分散情形的資料表就是 AllDocs，其中包含文件庫、相關聯的清單及清單項目，以及各自的中繼資料。

索引的分散程度就是邏輯順序與實體順序不同的索引頁面的百分比。

線上重建索引及離線重建索引

只有 SQL Server Enterprise、Developer 及 Evaluation 版才提供線上重建索引。本文說明的方法會將這些限制納入考量。如果裝載特定資料庫的 SQL Server 版本不支援線上重建索引，或是要重建的索引不符合線上重建索引的條件，本文中的程序就會回到離線重建索引。索引之所以不符合線上重建的條件，是由於出現大型物件 (LOB) 資料欄，例如資料類型為 NVARCHAR(MAX)、IMAGE 等的資料欄。

如需線上重建索引的資訊，請參閱＜線上索引作業如何運作＞。執行離線重建索引時，會在重建期間採用資料表層級鎖定，防止資料表遭寫入甚至存取。SharePoint 資料庫中的許多索引都因為有 LOB 資料欄，所以一律使用離線重建索引來重建。

即使使用線上重建索引，作業中仍會有兩個時間點會出現暫時資料表鎖定，而這樣會造成封鎖。因此建議您一律將索引重建活動排程於活動量低的時段進行。

測量 SQL Server 2008 或 2005 資料庫的分散情形 (sys.dm_db_index_physical_stats)

在 SQL Server 2008 或 SQL Server 2005 中，使用 sys.dm_db_index_physical_stats 動態管理檢視來判斷指定資料表或檢視上的索引分散情形。

若要測量分散情形，建議您監視 avg_fragmentation_in_percent 資料欄。avg_fragmentation_in_percent 的值應儘可能近似零，以取得最佳效能。不過，0% 到 10% 的值都是可接受的值。如需詳細資料，請參閱＜sys.dm_db_index_physical_stats＞。

下表顯示來自 sys.dm_db_index_physical_stats 的範例結果，其中一列的 avg_fragmentation_in_percent 值為 9.375。

database_id

index_type_desc

alloc_unit_type_

desc

avg_fragmentation_

in_percent

10

CLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

CLUSTERED INDEX

IN_ROW_DATA

0

10

NONCLUSTERED INDEX

IN_ROW_DATA

0

10

CLUSTERED INDEX

IN_ROW_DATA

9.375

使用 sys.dm_db_index_physical_stats 動態管理檢視

  1. 在工作列上，按一下 [開始]，指向 [所有程式] 及 [Microsoft SQL Server 2008]，然後按一下 [SQL Server Management Studio]。

    若要使用 sys.dm_db_index_physical_stats 搭配資料庫物件，則必須知道資料庫識別碼及物件識別碼。

  2. 在 [物件總管] 中選取內容資料庫，然後按一下 [新增查詢]。執行下列指令碼。

    SELECT DB_ID() AS [Database ID];

    注意

    如果使用 DB_ID 而不指定資料庫名稱，則目前資料庫的相容性層級必須是 100 (SQL Server 2008 資料庫) 或 90 (SQL Server 2005 資料庫)。如果已從舊版 SQL Server 升級，則必須在 DB_ID 陳述式中指定資料庫名稱。如需相容性層級的詳細資料，請參閱＜sp_dbcmptlevel (Transact-SQL)＞。

  3. 對您選取的資料庫或物件執行 sys.dm_db_index_physical_stats。您可以指定資料庫，以及指定資料表或索引。

    執行 sys.dm_db_index_physical_stats 時，請使用下列語法。

    sys.dm_db_index_physical_stats ( 
    { database_id | NULL | 0 | DEFAULT }
    , { object_id | NULL | 0 | DEFAULT }
    , { index_id | NULL | 0 | -1 | DEFAULT }
    , { partition_number | NULL | 0 | DEFAULT }
    , { mode | NULL | DEFAULT }
)

    因為 sys.dm_db_index_physical_stats DMV 可能會使用極大量資源，所以請小心使用。如需詳細指南以說明各種使用方式，請參閱＜深入探討 sys.dm_db_index_physical_stats (可能為英文網頁)＞(英文)。

降低資料庫的分散情形

使用下列指引來降低索引分散程度。

執行資料庫維護狀況分析規則

SharePoint 2010 包括狀況分析規則架構。架構包含許多規則，可監視 SharePoint 環境的狀況及適用性，有時還能採取行動以修正某些問題。

SharePoint 2010 包括數個與內容資料庫維護相關的規則。有些規則會自動針對某些 SharePoint 資料庫降低索引分散情形，有些規則會檢查統計資料是否已過時，並在必要時予以更新。這些狀況分析規則可取代已更新的資料庫統計資料計時器工作 (於 SharePoint 產品及技術 Service Pack 2 引進)。依預設，這些規則可根據規則目標，設定為每天、每週或視需要排程執行。

設定為每天執行且與特定 SharePoint 服務相關聯的所有狀況分析規則，都會由相同計時器工作執行。如果調整此計時器工作的排程，則設定為每天執行且與該服務相關聯的狀況分析規則，在一天當中執行的時間也會隨著調整。本文討論的所有規則都與 SharePoint Timer 服務相關聯。

設定以不同時間間隔 (例如每週) 執行或與不同服務相關聯的狀況分析規則，會使用不同的計時器工作。如果您設定狀況分析規則每週執行，該規則的執行方式就是利用已設定為每週執行的計時器工作，針對與該狀況分析規則相關聯的特定服務而進行。換句話說，規則會以針對該計時器工作所定義的排程來執行。

在管理中心的 [狀況分析規則] 頁面上，按一下功能區中的 [立即執行]，即可手動執行狀況分析規則。執行這些規則可評估索引及統計資料的狀況，也可視需要重建和重新計算索引。

SharePoint 所用的資料庫含有零碎的索引。執行此規則就會執行下列工作：

  • 規則會報告索引已分散。因為評估索引狀況是一項高成本的作業，所以執行狀況分析規則之後，此規則一定會報告索引已分散，進而觸發更正動作。

  • 規則動作會針對每個 SharePoint 資料庫搜尋和執行 proc_DefragmentIndices 預存程序 (如果有找到)，進而建置資料庫中所有索引的清單。會為每個索引評估目前的分散程度。分散程度超過 30% 的所有索引都會視為需要重建。

  • 如果 SQL Server 的版本支援線上重建索引，就會針對每個索引嘗試進行線上重建索引。如果此動作失敗 (例如，基礎索引因為 LOB 資料欄而不支援線上重建索引)，則會執行離線重建索引。

如前所述，此規則無法為 SharePoint 環境中的每一個資料庫提供服務。某些資料庫會使用不同規則來執行類似的維護活動。

搜尋 – 一或多個屬性資料庫含有分散的索引。此規則可維護 SharePoint 2010 Enterprise 搜尋屬性資料庫中的索引。依預設，此規則已設定針對伺服器陣列中的所有伺服器每週執行一次。此規則的所有處理 (包括更正動作) 都是在規則的 Check 階段發生。這表示，單單設定此規則使其不自動重建索引，並無法讓您管理 Enterprise 搜尋屬性資料庫的索引重建。如果不想讓 SharePoint 2010 自動執行索引維護作業，就必須完全停用規則。

執行 Search - One or more property databases have fragmented indices 就會執行下列工作：

  • 規則會確認環境狀態夠安全，適合執行索引重建。

  • 對於本機伺服器陣列中已針對搜尋應用程式設定的每個屬性資料庫，此規則會執行 proc_MSS_DefragSearchIndexes 預存程序，藉以重建分散程度平均超過 10% 的所有索引的清單。

  • 這樣會重建清單中可影響屬性資料庫效能的每個索引。如果 SQL Server 的版本支援線上重建索引，就會執行線上重建索引。如果嘗試進行線上重建索引但失敗，則會離線重建索引。

搜尋 - 一或多個編目資料庫可能含有分散的索引。此規則可維護 SharePoint 2010 Enterprise 搜尋屬性資料庫中的索引。依預設，此規則已設定針對伺服器陣列中的所有伺服器每週執行一次。此規則的所有處理 (包括更正動作) 都是在規則的 Check 階段發生。這表示，單單設定此規則使其不自動重建索引，並無法讓您管理 Enterprise 搜尋屬性資料庫的索引重建。如果不想讓 SharePoint 2010 自動執行索引維護作業，就必須完全停用規則。

執行 Search - One or more property databases have fragmented indices 就會執行下列工作：

  • 規則會確認環境狀態夠安全，適合執行索引重建。

  • 對於本機伺服器陣列中已針對搜尋應用程式設定的每個屬性資料庫，此規則會執行 proc_MSS_DefragSearchIndexes 預存程序，藉以重建分散程度平均超過 10% 的所有索引的清單。

  • 這樣會重建清單中可影響屬性資料庫效能的每個索引。如果 SQL Server 的版本支援線上重建索引，就會執行線上重建索引。如果嘗試進行線上重建索引但失敗，則會離線重建索引。

搜尋 - 一或多個編目資料庫可能含有分散的索引。此規則可維護 SharePoint 2010 Enterprise 搜尋編目資料庫中的索引。依預設，此規則已設定只在需要時執行。執行時，會從伺服器陣列中的任一伺服器執行。

因為檢查資料庫的分散情形是一項高成本的作業，所以規則會報告編目資料庫中的索引已分散。如果只停用此規則的「修復」活動，則即使編目資料庫最近才重建索引，也會產生所有編目資料庫狀況均不佳的報告。

若要手動維護編目資料庫中的索引，請完全停用 Search - One or more crawl databases may have fragmented indices 規則。

執行 Search - One or more crawl databases may have fragmented indices 就會執行下列工作：

  • 規則會確認環境狀態夠安全，適合執行索引重建。

  • 對於本機伺服器陣列中已針對搜尋應用程式設定的每個編目資料庫，此規則會執行 proc_MSS_DefragGathererIndexes 預存程序。

  • 這樣會重建清單中的編目資料庫的每個索引。如果 SQL Server 的版本支援線上重建索引，就會執行線上重建索引。如果嘗試進行線上重建索引但失敗，則會離線重建索引。

重要

無論分散程度如何，Search - One or more crawl databases may have fragmented indices 規則都會重建所有編目資料庫中的每個索引。這樣也會啟用頁面層級資料壓縮 (如果裝載編目資料庫的 SQL Server 的版本支援此動作)。

由於編目資料庫的本質所致，您通常不需要經常重組此資料庫。請在首次對內容執行完整編目之後執行此規則。然後監視編目資料庫中索引的分散程度，並在索引分散情形增長時執行此規則。索引分散情形可能會因為突然增加或移除大量編目內容而發生；例如，因為清理環境而導致排除內容，或是有新的內容來源 (例如檔案共用或大型 SharePoint Web 應用程式) 可供使用。

下列資料庫不提供自動化維護機制。這些資料庫的分散情形通常並不嚴重。監視這些資料庫的分散情形，並在分散程度超過 30% 時重建這些資料庫的索引。

  • 搜尋管理資料庫

  • Secure Store 資料庫

  • State Service 資料庫

  • Profile Sync 資料庫

  • 使用狀況資料庫

  • 受管理的中繼資料庫

  • Business Connectivity Services 資料庫

  • PerformancePoint Services 資料庫

如需 SharePoint 2010 資料庫支援之變更的詳細資訊，請參閱 Microsoft 知識庫的文章：＜對於 Office 伺服器產品及 Windows SharePoint Services 使用的資料庫變更的支援＞(機器翻譯)。

如果經常重組也無法顯著改善嚴重分散的資料庫或資料表的效能，就應該檢查 I/O 子系統的效能。

降低特定資料表及其索引的分散情形

如果您想重組與特定資料表相關聯的索引，而不是整個資料庫，則可以重新組織或重建索引。

  • 重新組織索引會指定重新組織索引分葉層級。索引重新組織會重組並壓縮資料表和檢視上的叢集和非叢集索引，並且會大幅提升索引掃描效能。重新組織索引會使用已配置給索引的現有空間。重新組織一律會在線上執行，因此使用者可以使用基礎資料表。

  • 重建索引會指定建置索引的全新複本。因此，重建作業需要足夠的額外空間，才能在移除舊的分散索引之前建置索引的新複本。重建可提升索引掃描和搜尋的效能。您可以使用資料表在線上或離線重建索引。

索引的分散程度決定重組索引所應使用的方法，以及是否可以保持連線，或應該離線工作。下表說明不同分散程度的建議重組方法。

分散程度 重組方法

10% (含) 以下

重新組織 (線上)

10-75%

重建 (線上)

75%

重建 (離線)

注意

SharePoint 2010 資料庫不支援使用 DROP INDEX 和 CREATE INDEX 命令。

您可以使用 SQL Server 2008 或 SQL Server 2005 ALTER INDEX 陳述式、或是 SQL Server 2008 或 SQL Server 2005 維護計畫精靈，來重新組織和重建索引。本文只提供 SQL Server 2008 或 SQL Server 2005 選項的詳細資料。

使用 ALTER INDEX

ALTER INDEX 可讓資料庫管理員針對資料表或檢視上的索引執行維護作業。您可以用它來停用、重建和重新組織索引。此外，您還可以用它來設定索引上的選項。在大多數情況下，您可以在資料庫連線時重建索引，讓資料較能供使用者使用 (與離線重建索引相比)。

重要

SQL Server 2000 過去支援 DBCC DBREINDEX 及 DBCC INDEXDEFRAG 進行索引維護。這些命令自 SQL Server 2005 起已過時，且將從 SQL Server 的未來版本中移除。請勿使用這些命令對 SharePoint 2010 資料庫執行索引維護。

注意

離線重建索引時，會在共用資料表上設置資料表鎖定，以避免進行 SELECT 之外的其他作業。SharePoint 2010 資料庫會特別使用叢集索引。離線重建叢集索引時，會在資料表上設置獨佔的資料表鎖定，以防止使用者存取資料表。

您可以自訂下列指令碼範例來重建資料表上的所有索引。

USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON)
GO

透過設定填滿因數來微調索引器效能

為了進一步改善索引資料儲存及效能，請使用填滿因數。建立或重建索引時，填滿因數值 (1-100) 可決定每個分葉層級頁面上可填入資料的空間百分比。剩餘空間會保留給未來成長使用。在許多情況下，預設全伺服器填滿因數層級 0 (將每個頁面 100% 填滿) 為最佳。但若是 SharePoint 2010，則全伺服器設定 80 最適合支援成長量，且可將分散情形降到最低。

注意

不建議您設定個別資料表或索引的填滿因數。雖然非 SharePoint SQL Server 資料庫適合使用此方法，但是測試顯示，SharePoint 資料庫使用 80% 的填滿因數最為適當。

若要檢視一或多個索引的填滿因數值，請查詢 sys.indexes 目錄檢視。如需檢視的詳細資訊，請參閱＜sys.indexes (Transact-SQL)＞。

若要設定全伺服器填滿因數值，請使用 sp_configure 系統預存程序。如需詳細資訊，請參閱＜spconfigure (Transact-SQL)＞。

壓縮資料檔

在 SQL Server 2008 及 SQL Server 2005 中，您可以壓縮資料庫中的每個檔案 (副檔名 .mdf, .ldf 及 .ndf)，來移除未使用的頁面並復原磁碟空間。雖然許多活動都會在資料庫中建立未使用的空間，但是 SharePoint 2010 資料庫不會自動壓縮資料檔。可能會建立未使用空間的活動包括執行 Move-SPSite Windows PowerShell 命令，以及刪除文件、文件庫、清單、清單項目與網站。

圖 3. 資料庫配置

資料庫配置

 

可用空間只會從檔案結尾處釋放；例如，指定目標大小為 40 GB 的 60 GB 的內容資料庫檔案，最多可從結尾處 (概念上的「右邊」) 釋放 20 GB 的資料庫檔案。如果使用的頁面包含在最後 20 GB 裡，這些頁面就會在稍後移到保留之檔案開頭的 40 GB 中。您可以分別壓縮資料庫檔案，或將整組檔案一起壓縮。

盡量少執行壓縮作業，且只在執行會從資料庫移除大量資料且您預期不會再使用該可用空間的作業之後，才執行壓縮作業。資料檔壓縮作業會造成索引嚴重分散，且會使用大量資源。可能需要壓縮資料庫檔案的範例時機，就是當您將大量網站集合從某個內容資料庫移到另一個內容資料庫時，或是當您刪除大型清單時。這些作業都會建立大量的未使用空間。資料庫檔案頂多只能減少到沒有剩餘可用空間的狀況。因此，對於您極少刪除其內容的內容資料庫而言，即使進行壓縮也無法提升效益，而且當它必須成長以容納沒有特定容納方式的額外資料時，效能還可能會降低。如需詳細資訊，請參閱＜資料庫檔案初始化＞(英文)。

因為壓縮會造成索引分散，所以請勿定期壓縮資料庫檔案。相反地，請只在進行某些作業導致出現大量未使用空間，而大幅影響資料庫中的相對已用空間量時，才壓縮資料庫檔案。請儘可能避免壓縮資料庫。

不過，如果您必須要壓縮資料庫，請使用下列指導方針：

  • 請勿自動壓縮資料庫，或設定維護計畫以程式設計方式壓縮資料庫。

  • 只有在使用者或管理員移除 50% 或更多內容，且您預期不會重複使用這些未使用空間時，才壓縮資料庫。

  • 只壓縮內容資料庫。使用者及管理員從設定資料庫、管理中心內容資料庫及各種服務應用程式資料庫中刪除的資料並不多，不足以包含大量可用空間。

  • 壓縮資料庫是一項使用大量資源的作業。因此，如果您一定要壓縮資料庫，請謹慎考量壓縮作業的排程時間。

  • 壓縮資料庫之後，該資料庫中的索引就會變得分散。使用 ALTER INDEX… REORGANIZE 即可處理分散情形。如果您尚未設定允許即時檔案初始化，則可將資料庫壓縮至能夠容納您預期之短期成長所需的目標大小。如需詳細資訊，請參閱＜資料庫檔案初始化＞(英文)。

在 SQL Server 2008 或 SQL Server 2005 Management Studio 中，執行 DBCC SHRINKFILE 及 DBCC SHRINKDATABASE 陳述式，即可手動壓縮資料庫及資料庫檔案以復原空間。

如需資料庫壓縮會損害效能之原因的詳細資訊，以及除非絕對必要否則不應執行資料庫壓縮之原因的詳細資訊，請參閱＜為何不該壓縮資料檔 (可能為英文網頁)＞(英文)。

使用 Transact-SQL 命令壓縮資料庫

DBCC SHRINKDATABASE 會壓縮特定資料庫的資料及記錄檔。若要壓縮個別檔案，請使用 DBCC SHRINKFILE。

DBCC SHRINKDATABASE

DBCC SHRINKDATABASE 會使用下列語法。

DBCC SHRINKDATABASE 
( 'database_name' | database_id | 0 
     [ ,target_percent ] 
     [ , { NOTRUNCATE | TRUNCATEONLY } ] 
)
[ WITH NO_INFOMSGS ]

database_name | database_id | 0 可指定資料庫名稱或識別碼。若要選取目前的資料庫，請使用 0。

target_percent 是您在壓縮資料庫之後要保留的可用空間 (以百分比為單位)。

NOTRUNCATE 可將檔案結尾處的已配置頁面移到檔案開頭處的未配置頁面，來壓縮資料檔中的資料。

TRUNCATEONLY 可將檔案結尾處的所有可用空間釋放給作業系統，但是不會移動檔案中的任何頁面。

注意

SharePoint 2010 內容資料庫不支援使用 TRUNCATEONLY 選項。

如需詳細資訊，請參閱＜DBCC SHRINKDATABASE (Transact-SQL)＞。

DBCC SHRINKFILE

DBCC SHRINKFILE 會使用下列語法。

DBCC SHRINKFILE 
(
     { 'file_name' | file_id } 
    { [ , EMPTYFILE ] 
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
    }
)
[ WITH NO_INFOMSGS ]

file_name | file_id 可指定檔案名稱或識別碼。

EMPTYFILE 可將所有資料從指定的檔案移轉到同一檔案群組中的其他檔案。

重要

SharePoint 2010 資料庫檔案不支援使用 EMPTYFILE 選項。

target_size 是以整數表示的檔案目標大小 (以 MB 為單位)。

NOTRUNCATE 可將檔案結尾處的已配置頁面移到檔案開頭處的未配置頁面，來壓縮資料檔中的資料。

TRUNCATEONLY 可將檔案結尾處的所有可用空間釋放給作業系統，但是不會移動檔案內的任何頁面。

重要

SharePoint 2010 內容資料庫不支援使用 TRUNCATEONLY 選項。

如需詳細資訊，請參閱＜DBCC SHRINKFILE (Transact-SQL)＞。

使用 SQL Server 2008 Management Studio 壓縮資料庫

請使用下列程序。

使用 SQL Server 2008 Management Studio 壓縮資料庫

  1. 在工作列上，依序按一下 [開始]、[所有程式]、[Microsoft SQL Server 2008]、[SQL Server Management Studio]。

  2. 在 [物件總管] 中，連線至 SQL Server 2008 Database Engine 的執行個體，然後展開該執行個體。

  3. 展開 [資料庫]，在您要壓縮的資料庫上按一下滑鼠右鍵，依序選擇 [工作]、[壓縮]、[檔案]。

  4. 選取檔案類型及檔案名稱。

  5. 選取 [釋放未使用空間前重新組織檔案]。您必須同時設定 [壓縮檔案] 值。選取此選項即可將檔案中任何未使用的空間釋放給作業系統，以及將資料列重新放置於未配置的頁面。

  6. 按一下 [確定]。

建立 SQL Server 2008 維護計畫

您可以實作 SQL Server 維護計畫，利用程式設計方式套用本文討論的許多資料庫維護作業。維護計畫也可以自動化和排程必要任務來保護資料。在 SQL Server 2008 或 SQL Server 2005 中使用維護計畫，管理員就能排程作業，例如執行資料庫一致性檢查、重新組織索引或重建索引。如需詳細資訊，請參閱下列資源：

設定 SQL Server 2008 資料庫維護計畫

  1. 在工作列上，依序按一下 [開始]、[所有程式]、[Microsoft SQL Server 2008]、[SQL Server Management Studio]。

  2. 在 [物件總管] 中，連線至 SQL Server 2008 Database Engine 的執行個體，然後展開該執行個體。

  3. 選擇 [管理]，在 [維護計畫] 上按一下滑鼠右鍵，然後選擇 [維護計畫精靈]。

  4. 選擇 [下一步]，直到到達 [選取計畫屬性] 頁面為止。

    圖 4. [選取計畫屬性] 頁面

    [選取計畫屬性] 頁面

  5. 在 [名稱] 及 [描述] 欄位中，指定名稱及描述。

  6. 決定要設定一或多個維護計畫。

    • 若要設定單一維護計畫，請選取 [對整個計劃單一排程或沒有排程]。

    • 若要設定含有特定工作的多個維護計畫，請選取 [對每一項工作個別排程]。

    如果您的環境具備 10 個以上的內容資料庫或內容超過 200 GB，建議您設定個別維護計劃，以提供適當的明確性並將維護視窗最大化。

    如果您為資料庫設定多個維護計畫，請指定名稱或描述來區分計畫及其目的，包括其排程。

  7. 按一下 [變更]，為一或多個計畫設定排程。

    [作業排程屬性] 對話方塊隨即出現。

    圖 5. [作業排程屬性] 對話方塊

    [作業排程屬性] 對話方塊

  8. 完成排程，按一下 [確定]，然後按 [下一步]。

  9. 在 [選取維護工作] 頁面上，選取要包含在計畫中的維護工作，然後按 [下一步]。

    圖 6. [選取維護工作] 頁面

    [選取維護工作] 頁面

    請考慮下列注意事項：

    • 維護計畫應該只包括索引重新組織或只包括索引重建，而非兩者。

    • 維護計畫絕對不能包括壓縮資料庫。

    • 若要判斷每項工作的所需時間，請先分別測試每項工作，再合併成單一計畫。您可能需要在不同排程上定義數個維護計畫，讓工作在不影響使用者的時段內完成。

    • [維護清除工作] 可移除排程維護之後遺留的檔案。

  10. 如有需要，可在 [選取維護工作順序] 頁面上變更維護計畫工作的順序。選取工作，然後按一下 [上移] 或 [下移]。工作順序安排完成之後，按 [下一步]。

    注意

    如果資料庫很大，則可建立不同的維護計畫，以低於索引維護的頻率檢查資料完整性。

    圖 7. [選取維護工作順序] 頁面

    [選取維護工作順序] 頁面

  11. 接著，精靈就會指引您為每項工作設定詳細資料。在 [定義資料庫檢查完整性工作] 頁面上，選取要檢查完整性的資料庫，然後按 [下一步]。

    注意

    您可以安全地檢查所有 SharePoint 2010 資料庫的完整性。

    圖 8. [定義資料庫檢查完整性工作] 頁面

    [定義資料庫檢查完整性工作] 頁面

  12. 在 [定義重新組織索引工作] 頁面的 [資料庫] 清單中，指定您要重新組織索引的資料庫，選取 [壓縮大型物件] 核取方塊，然後按 [下一步]。

    圖 9. [定義重新組織索引工作] 頁面

    [定義重新組織索引工作] 頁面

  13. 在 [定義重建索引工作] 頁面上，如果您選擇重建索引而非重新組織索引，請在 [資料庫] 清單中指定資料庫。

  14. 選取 [將每頁可用空間百分比變更為]，輸入 80，然後按 [下一步]。

    [將每頁可用空間百分比變更為] 會為資料庫設定填滿因數。

    圖 10. [定義重建索引工作] 頁面

    [定義重建索引工作] 頁面

  15. 在 [定義維護清除工作] 頁面上，指定要求的值，然後按 [下一步]。

    提示

    建議您刪除維護計畫文字報表。

    圖 11. [定義維護清除工作] 頁面

    [定義維護清除工作] 頁面

  16. 在 [選取報表選項] 頁面上，選取 [將報表寫入文字檔]，選取檔案的位置，然後按 [下一步] 直到完成精靈為止。

    圖 12. 選取報表選項

    選取報表選項

總結

以一致的方式維護裝載 SharePoint 2010 的資料庫，就能大幅改善系統的狀況及效能。

實作維護作業及維護計畫之前，請先確認所有資料庫都有可靠的備份。

實作維護計畫或是會持續執行的特定維護作業之前，請先測試該作業對於系統的影響以及執行所需的時間。

儘可能將所有維護作業或維護計畫設定於離峰時段執行，將對使用者的效能影響降到最低。

See Also

Other Resources

本主題也可供下載