修複發生“由於資料移動，未能繼續以 NOLOCK 方式掃描”錯誤的資料庫

標籤：

最近在系統運行中發現了一個錯誤，錯誤資訊如下：錯誤資訊：查詢A201412C20568單證資訊錯誤 ---> System.Data.OleDb.OleDbException: 由於資料移動，未能繼續以 NOLOCK 方式掃描。
一開始我認為企業的資料庫是SQL SERVER 2005以上的版本，使用了以下方式：

USE MASTERGO  ALTER DATABASE work_yf SET SINGLE_USERGO --允許遺失資料修複DBCC CHECKDB (work_yf, REPAIR_ALLOW_DATA_LOSS)GO ALTER DATABASE work_yf SET MULTI_USER 

在執行了命令之後，發現無法成功。後研究了一下企業使用的資料庫，發現是SQL SERVER 2000的。所以只能使用以下方式進行修複。

 

第一步：通過以下代碼查詢，是哪些表中出錯了

DECLARE @table_name sysnameDECLARE ROY_table CURSOR FORSELECT name FROM sysobjects where xtype  in (‘u‘,‘s‘)OPEN ROY_tableFETCH NEXT FROM ROY_table INTO @table_nameWHILE @@FETCH_STATUS = 0 BEGINDBCC CheckTable (@table_name)PRINT ‘--------------資料表‘+@table_name + ‘的檢查整理完成------------------‘FETCH NEXT FROM ROY_table INTO @table_nameENDCLOSE ROY_tableDEALLOCATE ROY_table

 

執行上述命名之後，會在“訊息”視窗中顯示如下資訊：（以下資訊中只有出錯資訊，其他正常資訊已經去除）

伺服器: 訊息 8929，層級 16，狀態 1，行 10物件識別碼 2: 在文本 ID 177078272 中發現錯誤，該文本的所有者是由 RID = (1:135:19) id = 661577395 and indid = 3 標識的資料記錄。伺服器: 訊息 8961，層級 16，狀態 1，行 10表錯誤: 物件識別碼 2。text、ntext 或 image 節點（位於頁 (1:66)，槽 2，文本 ID 177078272）與該節點位於頁 (1:284)，
槽 6 處的引用不匹配。‘sysindexes‘ 的 DBCC 結果。對象 ‘sysindexes‘ 有 304 行，這些行位於 14 頁中。CHECKTABLE 發現了 0 個分配錯誤和 2 個一致性錯誤（在表 ‘sysindexes‘ 中，該表的物件識別碼 為 2）。通過上面的提示資訊，找到出錯的索引或統計資訊--------------資料表sysindexes的檢查整理完成------------------伺服器: 訊息 8936，層級 16，狀態 1，行 10表錯誤: 物件識別碼 709577566，索引 ID 1。B 樹鏈的連結不匹配。(1:2203)->next = (1:176)，但 (1:176)->Prev = (1:2045)。伺服器: 訊息 8977，層級 16，狀態 1，行 10表錯誤: 物件識別碼 709577566，索引 ID 1。未遇到頁 (1:2203) 的父節點。‘PDE_LIST_ORG‘ 的 DBCC 結果。對象 ‘PDE_LIST_ORG‘ 有 216 行，這些行位於 11 頁中。CHECKTABLE 發現了 0 個分配錯誤和 2 個一致性錯誤（在表 ‘PDE_LIST_ORG‘ 中，該表的物件識別碼 為 709577566）。repair_rebuild 是最低的修複層級（對於由 DBCC CHECKTABLE (work_yf.dbo.PDE_LIST_ORG ) 發現的錯誤而言）。--------------資料表PDE_LIST_ORG的檢查整理完成------------------伺服器: 訊息 8978，層級 16，狀態 1，行 10表錯誤: 物件識別碼 725577623，索引 ID 1。頁 (1:3891) 缺少上一頁 (1:3892) 對它的引用。可能是因為鏈的連結有問題。伺服器: 訊息 8976，層級 16，狀態 1，行 10表錯誤: 物件識別碼 725577623，索引 ID 1。在掃描操作中未發現頁 (1:3892)，而其父代 (1:2198) 和上一頁 (1:3889) 指向了該頁。
請檢查先前的錯誤。‘PDE_LIST_ORG_HISTROY‘ 的 DBCC 結果。對象 ‘PDE_LIST_ORG_HISTROY‘ 有 16755 行，這些行位於 489 頁中。CHECKTABLE 發現了 0 個分配錯誤和 2 個一致性錯誤（在表 ‘PDE_LIST_ORG_HISTROY‘ 中，該表的物件識別碼 為 725577623）。repair_rebuild 是最低的修複層級（對於由 DBCC CHECKTABLE (work_yf.dbo.PDE_LIST_ORG_HISTROY ) 發現的錯誤而言）。--------------資料表PDE_LIST_ORG_HISTROY的檢查整理完成------------------第二步，進行分析，除了上面的斜體字部分，需要注意，其他都很清楚，就是兩張業務表發生了錯誤。而斜體字部分是指一張系統資料表sysindexes，需要進一步查詢是哪些索引出錯了。1） 使用以下語句檢查是哪些索引出現了問題，原來是_WA_Sys_STATUS_276EDEB3出錯是問題。

SELECT *  FROM SYSINDEXES WHERE  id = 661577395 and indid = 3 select * from sysobjects where id = 661577395

第三步，進行修得操作。具體操作方法如下：--方法如下:--1. 先停掉資料庫伺服器，把出問題的資料庫（例如:work_yf）的.mdf與.ldf檔案備份到備份目錄中。--2．我們使用預設建立一個供恢複使用的資料庫(如work_yf)。可以在SQL   Server   Enterprise   Manager裡面建立。  --3．停掉資料庫伺服器。  --4．將剛才產生的資料庫的記錄檔work_yf_log.ldf刪除，用要修複的資料庫mdf檔案覆蓋剛才產生的資料庫資料檔案work_yf_data.mdf。  --5．啟動資料庫伺服器。此時會看到資料庫work_yf的狀態為“置疑”。這時候不能對此資料庫進行任何操作。  --6．設定資料庫允許直接作業系統表。此操作可以在SQL   Server   Enterprise   Manager裡面選擇資料庫伺服器，按右鍵，選擇“屬性”，
     在“伺服器設定”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。  

use   master  go  exec sp_configure   ‘allow updates‘,1  go    reconfigure   with   override  go  

--7．設定work_yf為緊急修複模式  

update sysdatabases set status=-32768 where dbid=DB_ID(‘work_yf‘)  

--此時可以在SQL   Server   Enterprise   Manager裡面看到該資料庫處於“唯讀\置疑\離線\緊急模式”可以看到資料庫裡面的表，
但是僅僅有系統資料表  --8．下面執行真正的恢複操作，重建資料庫記錄檔  

godbcc rebuild_log(‘work_yf‘,‘D:\Program Files\Microsoft SQL Server\MSSQL\Data\work_yf_log.ldf‘)  go

--執行過程中，如果遇到下列提示資訊：  --伺服器:   訊息   5030，層級   16，狀態   1，行   1  --未能排它地鎖定資料庫以執行該操作。  --DBCC   執行完畢。如果   DBCC   輸出了錯誤資訊，請與系統管理員聯絡。  --說明您的其他程式正在使用該資料庫，如果剛才您在F步驟中使用SQL   Server   Enterprise   Manager開啟了work_yf庫的系統資料表，
   那麼退出SQL   Server   Enterprise   Manager就可以了。  --正確執行完成的提示應該類似於：  --警告:   資料庫   ‘work_yf‘   的日誌已重建。已失去事務的一致性。應運行   DBCC   CHECKDB   以驗證物理一致性。
   將必須重設資料庫選項，並且可能需要刪除多餘的記錄檔。  --DBCC   執行完畢。如果   DBCC   輸出了錯誤資訊，請與系統管理員聯絡。  --此時開啟在SQL   Server   Enterprise   Manager裡面會看到資料庫的狀態為“只供DBO使用”。此時可以訪問資料庫裡面的使用者表了。  --9 設定為單使用者狀態

goexec sp_dboption ‘work_yf‘,‘dbo use only‘,‘false‘  GOexec sp_dboption ‘work_yf‘, ‘single user‘, ‘true‘go    reconfigure   with   override  

--10 修複表，具體要修複哪些表，請在執行DBCC CheckTable (表名) ，自行檢查。我在這裡使用了"重建索引並修複(REPAIR_REBUILD)"的選項。
一共有三個選項：

--1) 快速修複          REPAIR_FAST--2) 重建索引並修複     REPAIR_REBUILD--3) 允許遺失資料修複    REPAIR_ALLOW_DATA_LOSS

use work_yfGODBCC CheckTable (PDE_LIST_ORG_HISTROY,REPAIR_REBUILD)GODBCC CheckTable (PDE_LIST_ORG,REPAIR_REBUILD)GODBCC CheckTable (PDE_HEAD,REPAIR_REBUILD)

--剛才我在檢查的時候，發現一個_WA_Sys_STATUS_276EDEB3也出錯了，這是SQL SERVER自動建立的統計資訊，
所以需要進行刪除，然後在進行修複

GODROP STATISTICS PDE_HEAD._WA_Sys_STATUS_276EDEB3GODBCC CheckTable (SYSINDEXES,REPAIR_REBUILD)GO

--11．驗證資料庫一致性（可省略）  

 use   master   go   DBCC CheckDB (work_yf) 

go

--一般執行結果如下：  --CHECKDB   發現了   0   個分配錯誤和   0   個一致性錯誤（在資料庫   ‘work_yf‘   中）。  --DBCC   執行完畢。如果   DBCC   輸出了錯誤資訊，請與系統管理員聯絡。  --12．設定資料庫為正常狀態  

exec sp_dboption ‘work_yf‘, ‘single user‘, ‘false‘goexec sp_dboption ‘work_yf‘,‘dbo use only‘,‘false‘  go

--如果沒有出錯，那麼恭喜，現在就可以正常的使用恢複後的資料庫啦。  --13．最後一步，我們要將步驟E中設定的“允許對系統目錄直接修改”一項恢複。因為平時直接作業系統表是一件比較危險的事情。
當然，我們可以在SQL   Server   Enterprise   Manager裡面恢複，也可以使用如下陳述式完成  

exec sp_configure   ‘allow updates‘,0  go    reconfigure   with   override  go 

 

 

修複發生“由於資料移動，未能繼續以 NOLOCK 方式掃描”錯誤的資料庫