MS SQL Server 2000 DBCC 簡介

MS SQL Server 2000 DBCC 簡介

        今天跟“雲網首席程式員”旺旺（點選進入旺旺部落格）聊天，發現自己好久沒有發表技術類文章了，有點對不起程式員朋友們了，（呵呵，自大的家夥）。

        前些天一個好朋友的SQL SERVER 2000資料庫崩潰了，詢問我如何解決。錯誤号為8925，資料庫無法使用。這個問題以前（兩年前了，嘿嘿，時間飛度啊）我曾經碰到過，并解決過，這裡小結一下吧，希望在大家碰到類似問題的時候能提供幫助。

        一般來說，這種錯誤主要是由于資料庫在存儲資料過程中發生的硬性錯誤，而且多數是由于索引錯誤引起的。SQL SERVER DBCC指令集就是這樣一套提供檢查資料庫錯誤并修複錯誤的工具集。作為DBA的同志們應該一個月至少執行一次DBCC指令差錯并修複錯誤。

        注意：特别地，本文為針對資料庫錯誤号為8925、8935、8956的解決方案。且建議做好資料庫的備份工作。

------------------------------------------------------------

錯誤描述：

錯誤 8925

嚴重級别 16

消息正文

表錯誤：跨對象連結：頁 %1!，槽 %2!（位于對象 ID %3!，索引 ID %4! 中）指向了頁 %5!，槽 %6!（位于對象 ID %7!，索引 ID %8! 中）。

解釋

當 Microsoft? SQL Server? 在與表關聯的一個頁鍊的頁連結中檢測到不一緻時會出現該錯誤。發現某一頁在本應該隻連結一個鍊時連結了多個頁鍊。表資料具有一個雙向連結頁鍊，每個索引級别也具有一個這樣的頁鍊。

重要  這屬于嚴重錯誤，必須立即更正。

如果不帶修複子句的 DBCC CHECKDB 在運作時處理期間檢測到該錯誤，還會出現錯誤 605。

錯誤 8956

嚴重級别 16

消息正文

索引行 (%1!:%2!:%3!)（其值為 %4!）指向由 %5! 辨別的資料行。

解釋

如果 Microsoft? SQL Server? 傳回該錯誤資訊，通常是在錯誤 8952 之後。

該錯誤資訊表明一個或多個索引損壞，必須進行修複或除去。

對策

通過執行帶有 REPAIR_ALLOW_DATA_LOSS、REPAIR_FAST 或 REPAIR_REBUILD 子句的 DBCC CHECKDB 來修複索引。若要确定最符合需要的修複子句，執行前請參考 DBCC CHECKDB。

重要  如果執行帶有修複子句之一的 DBCC CHECKDB 未更正索引問題，或者您不确定帶有修複子句的 DBCC CHECKDB 對資料的作用，請與您的主要支援提供者聯系。

------------------------------------------------------------

--示例解決方案（在查詢分析器中執行）

--将資料庫狀态置為單使用者模式（必須）

ALTER DATABASE YourDataBaseName SET SINGLE_USER

GO

--修複資料庫

DBCC CHECKDB('YourDataBaseName',REPAIR_ALLOW_DATA_LOSS)

GO

--将資料庫狀态置為多使用者模式（必須）

ALTER DATABASE YourDataBaseName SET MULTI_USER

GO

------------------------------------------------------------

--MS SQL Server 2000 Help 相關說明

DBCC CHECKDB

檢查指定資料庫中的所有對象的配置設定和結構完整性。

文法

DBCC CHECKDB

    ( 'database_name'

            [ , NOINDEX

                | { REPAIR_ALLOW_DATA_LOSS

                    | REPAIR_FAST

                    | REPAIR_REBUILD

                    } ]

    )    [ WITH { [ ALL_ERRORMSGS ]

                    [ , [ NO_INFOMSGS ] ]

                    [ , [ TABLOCK ] ]

                    [ , [ ESTIMATEONLY ] ]

                    [ , [ PHYSICAL_ONLY ] ]

                    }

        ]

參數

'database_name'

是要對其中的所有對象配置設定和結構完整性進行檢查的資料庫。如果未指定，則預設為目前資料庫。資料庫名稱必須符合辨別符的規則。有關更多資訊，請參見使用辨別符。

NOINDEX

指定不檢查非系統表的非聚集索引。NOINDEX 減少執行總時間，因為它不對使用者定義的表的非聚集索引進行檢查。NOINDEX 對系統表沒有影響，因為 DBCC CHECKDB 總是對所有系統表索引進行檢查。

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

指定 DBCC CHECKDB 修複發現的錯誤。給定的 database_name 必須在單使用者模式下以使用修複選項，它可以是下列值之一。

值 描述

REPAIR_ALLOW_DATA_LOSS 執行由 REPAIR_REBUILD 完成的所有修複，包括對行和頁進行配置設定和取消配置設定以改正配置設定錯誤、結構行或頁的錯誤，以及删除已損壞的文本對象。這些修複可能會導緻一些資料丢失。修複操作可以在使用者事務下完成以允許使用者復原所做的更改。如果復原修複，則資料庫仍會含有錯誤，應該從備份進行恢複。如果由于所提供修複等級的緣故遺漏某個錯誤的修複，則将遺漏任何取決于該修複的修複。修複完成後，備份資料庫。

REPAIR_FAST 進行小的、不耗時的修複操作，如修複非聚集索引中的附加鍵。這些修複可以很快完成，并且不會有丢失資料的危險。

REPAIR_REBUILD 執行由 REPAIR_FAST 完成的所有修複，包括需要較長時間的修複（如重建索引）。執行這些修複時不會有丢失資料的危險。

WITH

指定有關下列内容的選項：傳回錯誤資訊的數量、獲得的鎖或估計的 tempdb 要求。

ALL_ERRORMSGS

顯示每個對象不受限制的錯誤數。如果沒有指定 ALL_ERRORMSGS，每個對象至多顯示 200 個錯誤資訊。按對象 ID 對錯誤資訊進行排序（從 tempdb 中生成的消息除外）。

NO_INFOMSGS

禁止顯示所有資訊性消息（嚴重級别 10）和關于所用空間的報告。

TABLOCK

導緻 DBCC CHECKDB 獲得共享表鎖。TABLOCK 可使 DBCC CHECKDB 在負荷較重的資料庫上運作得更快，但 DBCC CHECKDB 運作時會減少資料庫上可獲得的并發性。

ESTIMATE ONLY

顯示估計的 tempdb 空間大小，要運作帶有所有其它指定選項的 DBCC CHECKDB 則需要該空間。不執行該檢查。

PHYSICAL_ONLY

僅限于檢查頁和記錄标題實體結構的完整性，以及頁對象 ID 和索引 ID 與配置設定結構之間的一緻性。該檢查旨在以較低的開銷檢查資料庫的實體一緻性，同時還檢測會危及使用者資料安全的殘缺頁和常見的硬體故障。PHYSICAL_ONLY 始終意味着 NO_INFOMSGS，并且不能與任何修複選項一起使用。

注釋

DBCC CHECKDB 對索引視圖執行實體一緻性檢查。隻用于向後相容的 NOINDEX 選項也适用于索引視圖上的任何輔助索引。

DBCC CHECKDB 是最安全的修複語句，因為它對最多的可能出現的各種錯誤進行辨別和修複。如果隻報告資料庫中有配置設定錯誤，請執行帶修複選項的 DBCC CHECKALLOC 以對這些錯誤進行修複。然而，若要確定正确修複所有錯誤（包括配置設定錯誤），請執行帶修複選項的 DBCC CHECKDB，而不要執行帶修複選項的 DBCC CHECKALLOC。

DBCC CHECKDB 對資料庫中所有内容的完整性進行驗證。如果目前正在執行或最近已執行 DBCC CHECKDB，則不需要運作 DBCC CHECKALLOC 或 DBCC CHECKTABLE。

DBCC CHECKDB 執行同樣的檢查，仿佛是對資料庫中的每個表執行 DBCC CHECKALLOC 語句和 DBCC CHECKTABLE 語句。

預設情況下，DBCC CHECKDB 不擷取表鎖。但它擷取架構鎖，該鎖防止對中繼資料進行更改，但允許更改資料。擷取的架構鎖将防止使用者得到排它表鎖，在生成聚集索引、除去任何索引或截斷表時需要排它表鎖。

DBCC 語句收集資訊，然後掃描日志以查找所做的任何其它更改，并在掃描的結尾将兩組資訊合并在一起以産生資料的一緻視圖。

如果指定 TABLOCK 選項，DBCC CHECKDB 将擷取共享表鎖。這樣可允許某些類别的錯誤有更詳細的錯誤資訊，并通過避免使用事務日志資料而将所要求的 tempdb 空間大小降為最低。TABLOCK 選項不阻止日志截斷并使指令可以更快地運作。

DBCC CHECKDB 對資料庫中每個表的 text、ntext 和 image 頁的連結和大小及資料庫中所有頁的配置設定進行檢查。

對于資料庫中每個表，DBCC CHECKDB 檢查其：

索引和資料頁是否已正确連結。

索引是否按照正确的順序排列。

各指針是否一緻。

每頁上的資料是否均合理。

頁面偏移量是否合理。

錯誤表示資料庫中的潛在問題，應該立即改正。

預設情況下，DBCC CHECKDB 對對象執行并行檢查。并行度由查詢處理器自動确定。最大并行度的配置方式與并行查詢相同。使用 sp_configure 系統存儲過程限制可用于 DBCC 檢查的最大處理器數。有關更多資訊，請參見 max degree of parallelism 選項。

使用跟蹤标記 2528 可禁用并行檢查。有關更多資訊，請參見跟蹤标記。

結果集

不管是否指定任何選項（NO_INFOMSGS 或 NOINDEX 選項除外），如果未指定資料庫，DBCC CHECKDB 傳回目前資料庫的以下結果集（值可能會變化）：

DBCC results for 'master'.

DBCC results for 'sysobjects'.

There are 862 rows in 13 pages for object 'sysobjects'.

DBCC results for 'sysindexes'.

There are 80 rows in 3 pages for object 'sysindexes'.

'...'

DBCC results for 'spt_provider_types'.

There are 23 rows in 1 pages for object 'spt_provider_types'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

如果指定 NO_INFOMSGS 選項，DBCC CHECKDB 将傳回以下結果集（消息）：

The command(s) completed successfully.

如果指定 ESTIMATEONLY 選項，DBCC CHECKDB 将傳回以下結果集。

Estimated TEMPDB space needed for CHECKALLOC (KB)

-------------------------------------------------

13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)

--------------------------------------------------

57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

權限

DBCC CHECKDB 權限預設授予 sysadmin 固定伺服器角色或 db_owner 固定資料庫角色的成員且不可轉讓。

------------------------------------------------------------