SQLserver201*數(shù)據(jù)庫修復(fù)辦法總結(jié)

SQLserver201*數(shù)據(jù)庫修復(fù)辦法總結(jié)

Praymid戴華倪

總結(jié)步驟如下：1、檢測數(shù)據(jù)庫，

使用命令（Dbcccheckdb）

拿到數(shù)據(jù)庫后附加到本地SQLserver使其運行，打開企業(yè)管理器，查看它。同時打開查詢分析器，在里面輸入

Dbcccheckdb檢測數(shù)據(jù)庫命令然后回車即可以看到數(shù)據(jù)庫的分析資料看到問題，

評注：拿到問題先不要盲目的卸載SQLServer，本次因為新手，上手后就把數(shù)據(jù)庫卸載，這樣就耗費了一天的時間，過沒有任何作用，測試服務(wù)器的完整性可以拿一個好的數(shù)據(jù)庫做對比，自己可以建一個“test”，如果測試數(shù)據(jù)庫運行正常，則不需要對服務(wù)器做任何改動。千萬不要改動系統(tǒng)，麻煩會更大。

提示：錯誤會以紅色顯示。2、簡單修復(fù)：命令：dbcccheckdb輸入以下兩句嘗試修復(fù)。

DBCCCHECKDB("AIS201*01201*2605",repair_allow_data_loss)DBCCCHECKDB("AIS201*01201*2605",repair_rebuild)

不管他究竟哪里錯了，先用這兩句試試一般的索引系統(tǒng)文件丟失，SQLserver都可以解決這個問題，基本就差不多了。但是對于主鍵索引損壞，這個命令基本修不好，所以對一個滿身是傷的數(shù)據(jù)庫，他可以修復(fù)70%。

注：修復(fù)時系統(tǒng)提示必須要在單用戶模式下才可以生效，用戶可以去企業(yè)管理器，對要修理的數(shù)據(jù)庫：右擊屬性選項限制訪問單用戶。也可以使用以下語句實現(xiàn)：

ALTERDATABASEAIS201*04201*1143SETsingle_USERGO改為單用戶

ALTERDATABASEAIS201*04201*1143SETMULTI_USERGO改為多用戶。

繼續(xù)使用dbcccheckdb檢測，如果繼續(xù)報錯。再次運行：

DBCCCHECKDB("DataBasename")withNO_INFOMSGS,PHYSICAL_ONLY然后再運行：

DBCCCHECKDB("DataBasename",repair_allow_data_loss)WITHTABLOCK再次運行:DBCCCHECKDB("DBname")系統(tǒng)顯示修復(fù)成功，說明本次問題主要由索引等數(shù)據(jù)庫系統(tǒng)本身問題引起，這樣的修復(fù)可能會導(dǎo)致數(shù)據(jù)丟失，但是絕對不會是大批丟失，基本沒有影響。

2、檢測表：命令：dbccchecktable(‘tablename’)

接上述檢測提示：我們可以看到一個id號，這個基本就是這個錯誤的表在系統(tǒng)表“sysobjects”里面的注冊信息。

輸入如下語句即可以看見：

select*fromsysobjectswhereid=1205579333（錯誤提示號碼）接下來檢測這張表究竟是什么問題。輸入：dbccchecktable(‘tablename’)

接下來將會得到一些錯誤提示，基本上就是檢測表的時候那些，提示什么B樹錯誤，父節(jié)點，子節(jié)點錯誤，這些都別管，因為這個可能就是索引引起的錯誤：

嘗試用下列語句修復(fù)：

DBCCCHECKtable("Tablename",repair_rebuild)執(zhí)行完后查看提示：如果出現(xiàn)下面的提示

CREATEUNIQUEINDEX終止，因為發(fā)現(xiàn)了索引ID1的重復(fù)鍵。最重要的主鍵為"3"。這里基本上就可以確定就是索引出的問題，而且數(shù)據(jù)表沒有被修復(fù)的可能很可能就是內(nèi)容產(chǎn)生的問題。根據(jù)提示，我們得出的結(jié)論就是主鍵重復(fù)。

這是我們使用select查詢語句是看不到的甚至表里面打開也沒有反映。此時，關(guān)閉查詢分析器，打開企業(yè)管理器，找到那個數(shù)據(jù)表，然后右擊選擇設(shè)計表，選擇主鍵，右擊，取消主鍵，回到查詢分析器，找到該表，右擊選擇索引，這時候表以前所有的索引都能看見了，但是上面的唯一性選項很明顯沒有了，然后給表里面添加一個新的字段，字段名id需要生成編號：

語句如下：altertablet_itemaddidintegeridentity該字段用完后刪除，語句如下：altertablet_itemdropcolumnid

在查詢分析器這里右擊索引，選擇唯一性選項，然后點擊確定，系統(tǒng)會提示重復(fù)鍵，和最重要的主鍵ID，根據(jù)id數(shù)字，進(jìn)行查詢

如提示最重要的鍵值是3則，

select*fromt_itemwherefitemid=3

有時候查詢的結(jié)果，是合法的，比如這個3可能只有一條，這個時候，就右擊索引，點擊編輯勾選唯一性，在列上面去掉一個，從上往下第一個開始，但是必須記住他的名字，最好寫下來，這時候，你會發(fā)現(xiàn)錯誤信息里面的ID換成了另外一個數(shù)字，繼續(xù)用select語句查詢該數(shù)字，字段仍然是該表的第一個字段，你會發(fā)現(xiàn)他有兩條，仔細(xì)對比這兩條，什么都是一樣的，每一個字段的值都一樣，這顯然不符合邏輯，用剛才添加的id記錄刪除一條，語句如下：

Deletetablenamewhereid=兩著任何一個，刪除完后，

右擊恢復(fù)剛才被點掉的那一條列名，勾選上唯一性，點擊確定，則正常，回到企業(yè)管理器，打開表設(shè)計，設(shè)置主鍵。完成。

回到查詢分析器，輸入dbccchecktable顯示正常，再次檢測數(shù)據(jù)庫，顯示正常。刪除剛才增加的列，修復(fù)完成。

結(jié)論：修復(fù)這類數(shù)據(jù)表，別急著導(dǎo)出數(shù)據(jù)，新建庫文件，這個應(yīng)該還不到那一步，最好就是能這樣修復(fù)，少動干戈，如果是主鍵重復(fù)，你導(dǎo)出數(shù)據(jù)，在把這個錯誤的數(shù)據(jù)倒進(jìn)來（這里假設(shè)能正常導(dǎo)入），表的錯誤會依然存在。

擴(kuò)展閱讀：SQL Server 201*數(shù)據(jù)庫LDF損壞,只有mdf的恢復(fù)

SQLServer201*數(shù)據(jù)庫LDF損壞,只有mdf的恢復(fù)

SQLServer201*數(shù)據(jù)庫文件遭到破壞的現(xiàn)象經(jīng)常出現(xiàn)，數(shù)據(jù)庫出錯是否可以修復(fù)呢？答案是可以的，本日志以一個sqlserver201*數(shù)據(jù)庫，數(shù)據(jù)庫日志文件ldf損壞了，mdf正常，數(shù)據(jù)庫附加失敗的修復(fù)方法總結(jié)一下，數(shù)據(jù)庫數(shù)據(jù)恢復(fù)在很多時候比較復(fù)雜，當(dāng)數(shù)據(jù)庫存在大量錯誤的時候，使用DBCC修復(fù)也是不可以的，需要拆解數(shù)據(jù)庫來搶救重要的數(shù)據(jù)，下面是較為常見的一種SQLServer201*數(shù)據(jù)庫修復(fù)方式：

1）先及時把原來的數(shù)據(jù)庫文件（如test.mdf)備份到其他地方2）停掉服務(wù)器3）刪除這個test.mdf

4)重新建立一個test同名數(shù)據(jù)庫

5）刪除這個新建立的test數(shù)據(jù)庫的test.ldf文件，并用開始備份好的test.mdf文件覆蓋這個新建立的test.mdf文件

6）啟動數(shù)據(jù)庫服務(wù)器。此時會看到數(shù)據(jù)庫test的狀態(tài)為“置疑”。這時候不能對此數(shù)據(jù)庫進(jìn)行任何操作。.設(shè)置數(shù)據(jù)庫允許直接操作系統(tǒng)表。此操作可以在SQLServerEnterpriseManager里面選擇數(shù)據(jù)庫服務(wù)器，按右鍵，選擇“屬性”，在“服務(wù)器設(shè)置”頁面中將“允許對系統(tǒng)目錄直接修改”7）設(shè)置test為緊急修復(fù)模式

updatesysdatabasessetstatus=-32768wheredbid=DB_ID("test")

此時可以在SQLServerEnterpriseManager里面看到該數(shù)據(jù)庫處于“只讀\\置疑\\脫機\\緊急模式”可以看到數(shù)據(jù)庫里面的表，但是僅僅有系統(tǒng)表

8下面執(zhí)行真正的恢復(fù)操作，重建數(shù)據(jù)庫日志文件

dbccrebuild_log("test","C:\\ProgramFiles\\MicrosoftSQLServer\\MSSQL\\Data\\test_log.ldf")

執(zhí)行過程中，如果遇到下列提示信息：

服務(wù)器:消息5030，級別16，狀態(tài)1，行1未能排它地鎖定數(shù)據(jù)庫以執(zhí)行該操作。

DBCC執(zhí)行完畢。如果DBCC輸出了錯誤信息，請與系統(tǒng)管理員聯(lián)系。

說明您的其他程序正在使用該數(shù)據(jù)庫，如果剛才您在F步驟中使用SQLServerEnterpriseManager打開了test庫的系統(tǒng)表，那么退出SQLServerEnterpriseManager就可以了。

正確執(zhí)行完成的提示應(yīng)該類似于：

警告:數(shù)據(jù)庫"test"的日志已重建。已失去事務(wù)的一致性。應(yīng)運行DBCCCHECKDB以驗證物理一致性。將必須重置數(shù)據(jù)庫選項，并且可能需要刪除多余的日志文件。

DBCC執(zhí)行完畢。如果DBCC輸出了錯誤信息，請與系統(tǒng)管理員聯(lián)系。

此時打開在SQLServerEnterpriseManager里面會看到數(shù)據(jù)庫的狀態(tài)為“只供DBO使用”。此時可以訪問數(shù)據(jù)庫里面的用戶表了。

9.驗證數(shù)據(jù)庫一致性dbcccheckdb("test")10.設(shè)置數(shù)據(jù)庫為正常狀態(tài)

sp_dboption"test","dbouseonly","false"

如果沒有出錯，那么恭喜，現(xiàn)在就可以正常的使用恢復(fù)后的數(shù)據(jù)庫啦。11最后一步，我們要將步驟E中設(shè)置的“允許對系統(tǒng)目錄直接修改”一項恢復(fù)；

友情提示：本文中關(guān)于《SQLserver201*數(shù)據(jù)庫修復(fù)辦法總結(jié)》給出的范例僅供您參考拓展思維使用，SQLserver201*數(shù)據(jù)庫修復(fù)辦法總結(jié)：該篇文章建議您自主創(chuàng)作。

來源：網(wǎng)絡(luò)整理 免責(zé)聲明：本文僅限學(xué)習(xí)分享，如產(chǎn)生版權(quán)問題，請聯(lián)系我們及時刪除。

《SQLserver201*數(shù)據(jù)庫修復(fù)辦法總結(jié)》由互聯(lián)網(wǎng)用戶整理提供,轉(zhuǎn)載分享請保留原作者信息,謝謝!
鏈接地址：http://www.weilaioem.com/gongwen/672249.html

• 上一篇：sql知識點歸納總結(jié)
• 下一篇：數(shù)據(jù)庫知識點總結(jié)