當事務日志擴展到無法接受的限度時您必須執(zhí)行的步驟。事務日志的擴展會導致 Microsoft SQL Server 數(shù)據(jù)庫無法使用。

　　在 SQL Server 2000 中，每個數(shù)據(jù)庫都至少包含一個數(shù)據(jù)文件和一個事務日志文件。SQL Server 2000 在該數(shù)據(jù)文件中以物理方式存儲數(shù)據(jù)。事務日志文件存儲您對 SQL Server 數(shù)據(jù)庫執(zhí)行的所有修改的詳細信息，以及執(zhí)行每個修改的事務的詳細信息。由于事務完整性被視為 SQL Server 的一個基本而固有的特點，因此不能在 SQL Server 2000 中關閉對事務詳細信息的記錄。

　　在邏輯意義上，事務日志文件被劃分為更小的段，這些段被稱為虛擬日志文件。在 SQL Server 2000 中，您可以將事務日志文件配置為根據(jù)需要擴展。用戶可以控制事務日志的擴展，也可以將其配置為使用所有可用的磁盤空間。SQL Server 對事務日志文件大小所做的任何修改(如截斷或增長事務日志文件)都是以虛擬日志文件為單位執(zhí)行的。

　　如果與 SQL Server 數(shù)據(jù)庫相對應的事務日志文件被充滿，而且事務日志文件選項被設置為自動增長，則事務日志文件將以虛擬日志文件為單位增長。有時，事務日志文件可能變得非常大，以致沒有足夠的磁盤空間。如果事務日志文件不斷增長，致使日志文件占用了所有可用的磁盤空間而無法繼續(xù)擴展，則將無法再對數(shù)據(jù)庫執(zhí)行任何數(shù)據(jù)修改操作。不僅如此，由于事務日志缺乏擴展空間，SQL Server 可能會將您的數(shù)據(jù)庫標記為可疑數(shù)據(jù)庫。

　　減小事務日志的大小

　　如果事務日志已經(jīng)增長到無法接受的限度，而您希望從這種狀況中恢復，則必須減小事務日志的大小。為此，必須截斷事務日志中非活動的事務并收縮事務日志文件。

　　注意：事務日志對于維護數(shù)據(jù)庫的事務完整性非常重要。因此，即使您為數(shù)據(jù)庫和事務日志制作了備份，也不得刪除事務日志文件。

　　截斷事務日志中非活動的事務

　　當事務日志增長到無法接受的限度時，您必須立即備份事務日志文件。創(chuàng)建事務日志文件的備份后，SQL Server 會自動截斷事務日志的非活動部分。事務日志文件的非活動部分包含已完成的事務，因此，在恢復過程中 SQL Server 將不再用到事務日志文件。SQL Server 會重新利用事務日志中這段被截斷的非活動空間，而不會允許事務日志繼續(xù)增長并占用更多空間。

　　還可以通過截斷的方法，從事務日志文件中刪除非活動的事務。有關截斷事務日志的其他信息，請參見 SQL Server 聯(lián)機叢書中的“截斷事務日志”主題。

　　重要說明：手動截斷事務日志文件后，必須在創(chuàng)建事務日志備份之前創(chuàng)建一個完整的數(shù)據(jù)庫備份。

　　收縮事務日志文件

　　備份操作或截斷方法都不會減小日志文件的大小。要減小事務日志文件的大小，必須收縮事務日志文件。要將事務日志文件收縮到所需大小并刪除無用的頁面，您必須使用 DBCC SHRINKFILE 操作。DBCC SHRINKFILE Transact-SQL 語句只能收縮日志文件中的非活動部分。

　　注意：當 DBCC SHRINKFILE Transact-SQL 語句單獨使用時，不能截斷日志并收縮日志文件中的已用空間。

　　防止事務日志文件異常增長

　　要防止事務日志文件異常增長，建議使用以下方法之一：

    • 將事務日志文件的大小設置為一個較大值，以避免事務日志文件自動擴展。

　　• 充分評估最佳內(nèi)存大小后，使用內(nèi)存單位而不是百分比來配置事務日志文件的自動擴展。

　　• 更改恢復模型。如果發(fā)生災難或數(shù)據(jù)損壞，您必須恢復數(shù)據(jù)庫，以維護數(shù)據(jù)庫數(shù)據(jù)的一致性和事務的完整性。根據(jù)數(shù)據(jù)在數(shù)據(jù)庫中的重要程度，您可以選擇以下恢復模型之一，以便確定如何備份數(shù)據(jù)以及數(shù)據(jù)丟失可能給您帶來的風險：

    • 簡單恢復模型 (SIMPLE)

　　• 完全恢復模型 (FULL)

　　• 大容量日志記錄恢復模型 (BULK-LOGGED)

　　使用簡單恢復模型，您可以將數(shù)據(jù)庫恢復到最近的數(shù)據(jù)庫備份。使用完全恢復模型或大容量日志記錄恢復模型，您可以通過使用事務日志文件備份來還原數(shù)據(jù)庫，這樣可以將數(shù)據(jù)庫恢復到故障發(fā)生時的故障點。

　　默認情況下，在 SQL Server 2000 中，SQL Server 數(shù)據(jù)庫的恢復模型被設置為完全恢復模型。在完全恢復模型中，會定期備份事務日志，從而防止事務日志文件增長得過大，以致與數(shù)據(jù)庫大小相比嚴重失衡。相比之下，如果不執(zhí)行事務日志的定期備份，事務日志文件會不斷增長，直至充滿整個磁盤，而且您可能無法對 SQL Server 數(shù)據(jù)庫執(zhí)行任何數(shù)據(jù)修改操作。

　　如果您不希望在災難恢復操作過程中使用事務日志文件，則可以從完全恢復模型更改為簡單恢復模型。

　　• 定期備份事務日志文件，刪除事務日志中非活動的事務。

　　• 將事務設計為小型事務。

　　• 確保沒有任何未遂事務繼續(xù)無限期地運行。

　　• 將“更新統(tǒng)計”選項安排為每天運行。

　　• 要對索引進行碎片整理以改善生產(chǎn)環(huán)境中的工作負荷性能，請使用 DBCC INDEXDEFRAG Transact-SQL 語句而不是 DBCC DBREINDEX Transact-SQL 語句。如果運行 DBCC DBREINDEX 語句，當 SQL Server 數(shù)據(jù)庫處于完全恢復模式時，事務日志可能會大大擴展。此外，DBCC INDEXDEGRAG 語句不像 DBCC DBREINDEX 語句那樣長時間持有鎖。

　　如果您必須運行 DBCC DBREINDEX 語句，因為這是一個作業(yè)，是數(shù)據(jù)庫維護計劃的一部分，則必須將該作業(yè)分解為多個作業(yè)。此外，在執(zhí)行這些作業(yè)的間歇，還必須經(jīng)常備份事務日志。

關鍵字：SQL Server、數(shù)據(jù)庫、事務日志