SQLserver201*數(shù)據(jù)庫(kù)修復(fù)辦法總結(jié)
SQLserver201*數(shù)據(jù)庫(kù)修復(fù)辦法總結(jié)
Praymid戴華倪
總結(jié)步驟如下:1、檢測(cè)數(shù)據(jù)庫(kù),
使用命令(Dbcccheckdb)
拿到數(shù)據(jù)庫(kù)后附加到本地SQLserver使其運(yùn)行,打開企業(yè)管理器,查看它。同時(shí)打開查詢分析器,在里面輸入
Dbcccheckdb檢測(cè)數(shù)據(jù)庫(kù)命令然后回車即可以看到數(shù)據(jù)庫(kù)的分析資料看到問題,
評(píng)注:拿到問題先不要盲目的卸載SQLServer,本次因?yàn)樾率,上手后就把?shù)據(jù)庫(kù)卸載,這樣就耗費(fèi)了一天的時(shí)間,過(guò)沒有任何作用,測(cè)試服務(wù)器的完整性可以拿一個(gè)好的數(shù)據(jù)庫(kù)做對(duì)比,自己可以建一個(gè)“test”,如果測(cè)試數(shù)據(jù)庫(kù)運(yùn)行正常,則不需要對(duì)服務(wù)器做任何改動(dòng)。千萬(wàn)不要改動(dòng)系統(tǒng),麻煩會(huì)更大。
提示:錯(cuò)誤會(huì)以紅色顯示。2、簡(jiǎn)單修復(fù):命令:dbcccheckdb輸入以下兩句嘗試修復(fù)。
DBCCCHECKDB("AIS201*01201*2605",repair_allow_data_loss)DBCCCHECKDB("AIS201*01201*2605",repair_rebuild)
不管他究竟哪里錯(cuò)了,先用這兩句試試一般的索引系統(tǒng)文件丟失,SQLserver都可以解決這個(gè)問題,基本就差不多了。但是對(duì)于主鍵索引損壞,這個(gè)命令基本修不好,所以對(duì)一個(gè)滿身是傷的數(shù)據(jù)庫(kù),他可以修復(fù)70%。
注:修復(fù)時(shí)系統(tǒng)提示必須要在單用戶模式下才可以生效,用戶可以去企業(yè)管理器,對(duì)要修理的數(shù)據(jù)庫(kù):右擊屬性選項(xiàng)限制訪問單用戶。也可以使用以下語(yǔ)句實(shí)現(xiàn):
ALTERDATABASEAIS201*04201*1143SETsingle_USERGO改為單用戶
ALTERDATABASEAIS201*04201*1143SETMULTI_USERGO改為多用戶。
繼續(xù)使用dbcccheckdb檢測(cè),如果繼續(xù)報(bào)錯(cuò)。再次運(yùn)行:
DBCCCHECKDB("DataBasename")withNO_INFOMSGS,PHYSICAL_ONLY然后再運(yùn)行:
DBCCCHECKDB("DataBasename",repair_allow_data_loss)WITHTABLOCK再次運(yùn)行:DBCCCHECKDB("DBname")系統(tǒng)顯示修復(fù)成功,說(shuō)明本次問題主要由索引等數(shù)據(jù)庫(kù)系統(tǒng)本身問題引起,這樣的修復(fù)可能會(huì)導(dǎo)致數(shù)據(jù)丟失,但是絕對(duì)不會(huì)是大批丟失,基本沒有影響。
2、檢測(cè)表:命令:dbccchecktable(‘tablename’)
接上述檢測(cè)提示:我們可以看到一個(gè)id號(hào),這個(gè)基本就是這個(gè)錯(cuò)誤的表在系統(tǒng)表“sysobjects”里面的注冊(cè)信息。
輸入如下語(yǔ)句即可以看見:
select*fromsysobjectswhereid=1205579333(錯(cuò)誤提示號(hào)碼)接下來(lái)檢測(cè)這張表究竟是什么問題。輸入:dbccchecktable(‘tablename’)
接下來(lái)將會(huì)得到一些錯(cuò)誤提示,基本上就是檢測(cè)表的時(shí)候那些,提示什么B樹錯(cuò)誤,父節(jié)點(diǎn),子節(jié)點(diǎn)錯(cuò)誤,這些都別管,因?yàn)檫@個(gè)可能就是索引引起的錯(cuò)誤:
嘗試用下列語(yǔ)句修復(fù):
DBCCCHECKtable("Tablename",repair_rebuild)執(zhí)行完后查看提示:如果出現(xiàn)下面的提示
CREATEUNIQUEINDEX終止,因?yàn)榘l(fā)現(xiàn)了索引ID1的重復(fù)鍵。最重要的主鍵為"3"。這里基本上就可以確定就是索引出的問題,而且數(shù)據(jù)表沒有被修復(fù)的可能很可能就是內(nèi)容產(chǎn)生的問題。根據(jù)提示,我們得出的結(jié)論就是主鍵重復(fù)。
這是我們使用select查詢語(yǔ)句是看不到的甚至表里面打開也沒有反映。此時(shí),關(guān)閉查詢分析器,打開企業(yè)管理器,找到那個(gè)數(shù)據(jù)表,然后右擊選擇設(shè)計(jì)表,選擇主鍵,右擊,取消主鍵,回到查詢分析器,找到該表,右擊選擇索引,這時(shí)候表以前所有的索引都能看見了,但是上面的唯一性選項(xiàng)很明顯沒有了,然后給表里面添加一個(gè)新的字段,字段名id需要生成編號(hào):
語(yǔ)句如下:altertablet_itemaddidintegeridentity該字段用完后刪除,語(yǔ)句如下:altertablet_itemdropcolumnid
在查詢分析器這里右擊索引,選擇唯一性選項(xiàng),然后點(diǎn)擊確定,系統(tǒng)會(huì)提示重復(fù)鍵,和最重要的主鍵ID,根據(jù)id數(shù)字,進(jìn)行查詢
如提示最重要的鍵值是3則,
select*fromt_itemwherefitemid=3
有時(shí)候查詢的結(jié)果,是合法的,比如這個(gè)3可能只有一條,這個(gè)時(shí)候,就右擊索引,點(diǎn)擊編輯勾選唯一性,在列上面去掉一個(gè),從上往下第一個(gè)開始,但是必須記住他的名字,最好寫下來(lái),這時(shí)候,你會(huì)發(fā)現(xiàn)錯(cuò)誤信息里面的ID換成了另外一個(gè)數(shù)字,繼續(xù)用select語(yǔ)句查詢?cè)摂?shù)字,字段仍然是該表的第一個(gè)字段,你會(huì)發(fā)現(xiàn)他有兩條,仔細(xì)對(duì)比這兩條,什么都是一樣的,每一個(gè)字段的值都一樣,這顯然不符合邏輯,用剛才添加的id記錄刪除一條,語(yǔ)句如下:
Deletetablenamewhereid=兩著任何一個(gè),刪除完后,
右擊恢復(fù)剛才被點(diǎn)掉的那一條列名,勾選上唯一性,點(diǎn)擊確定,則正常,回到企業(yè)管理器,打開表設(shè)計(jì),設(shè)置主鍵。完成。
回到查詢分析器,輸入dbccchecktable顯示正常,再次檢測(cè)數(shù)據(jù)庫(kù),顯示正常。刪除剛才增加的列,修復(fù)完成。
結(jié)論:修復(fù)這類數(shù)據(jù)表,別急著導(dǎo)出數(shù)據(jù),新建庫(kù)文件,這個(gè)應(yīng)該還不到那一步,最好就是能這樣修復(fù),少動(dòng)干戈,如果是主鍵重復(fù),你導(dǎo)出數(shù)據(jù),在把這個(gè)錯(cuò)誤的數(shù)據(jù)倒進(jìn)來(lái)(這里假設(shè)能正常導(dǎo)入),表的錯(cuò)誤會(huì)依然存在。
擴(kuò)展閱讀:SQL Server 201*數(shù)據(jù)庫(kù)LDF損壞,只有mdf的恢復(fù)
SQLServer201*數(shù)據(jù)庫(kù)LDF損壞,只有mdf的恢復(fù)
SQLServer201*數(shù)據(jù)庫(kù)文件遭到破壞的現(xiàn)象經(jīng)常出現(xiàn),數(shù)據(jù)庫(kù)出錯(cuò)是否可以修復(fù)呢?答案是可以的,本日志以一個(gè)sqlserver201*數(shù)據(jù)庫(kù),數(shù)據(jù)庫(kù)日志文件ldf損壞了,mdf正常,數(shù)據(jù)庫(kù)附加失敗的修復(fù)方法總結(jié)一下,數(shù)據(jù)庫(kù)數(shù)據(jù)恢復(fù)在很多時(shí)候比較復(fù)雜,當(dāng)數(shù)據(jù)庫(kù)存在大量錯(cuò)誤的時(shí)候,使用DBCC修復(fù)也是不可以的,需要拆解數(shù)據(jù)庫(kù)來(lái)?yè)尵戎匾臄?shù)據(jù),下面是較為常見的一種SQLServer201*數(shù)據(jù)庫(kù)修復(fù)方式:
1)先及時(shí)把原來(lái)的數(shù)據(jù)庫(kù)文件(如test.mdf)備份到其他地方2)停掉服務(wù)器3)刪除這個(gè)test.mdf
4)重新建立一個(gè)test同名數(shù)據(jù)庫(kù)
5)刪除這個(gè)新建立的test數(shù)據(jù)庫(kù)的test.ldf文件,并用開始備份好的test.mdf文件覆蓋這個(gè)新建立的test.mdf文件
6)啟動(dòng)數(shù)據(jù)庫(kù)服務(wù)器。此時(shí)會(huì)看到數(shù)據(jù)庫(kù)test的狀態(tài)為“置疑”。這時(shí)候不能對(duì)此數(shù)據(jù)庫(kù)進(jìn)行任何操作。.設(shè)置數(shù)據(jù)庫(kù)允許直接操作系統(tǒng)表。此操作可以在SQLServerEnterpriseManager里面選擇數(shù)據(jù)庫(kù)服務(wù)器,按右鍵,選擇“屬性”,在“服務(wù)器設(shè)置”頁(yè)面中將“允許對(duì)系統(tǒng)目錄直接修改”7)設(shè)置test為緊急修復(fù)模式
updatesysdatabasessetstatus=-32768wheredbid=DB_ID("test")
此時(shí)可以在SQLServerEnterpriseManager里面看到該數(shù)據(jù)庫(kù)處于“只讀\\置疑\\脫機(jī)\\緊急模式”可以看到數(shù)據(jù)庫(kù)里面的表,但是僅僅有系統(tǒng)表
8下面執(zhí)行真正的恢復(fù)操作,重建數(shù)據(jù)庫(kù)日志文件
dbccrebuild_log("test","C:\\ProgramFiles\\MicrosoftSQLServer\\MSSQL\\Data\\test_log.ldf")
執(zhí)行過(guò)程中,如果遇到下列提示信息:
服務(wù)器:消息5030,級(jí)別16,狀態(tài)1,行1未能排它地鎖定數(shù)據(jù)庫(kù)以執(zhí)行該操作。
DBCC執(zhí)行完畢。如果DBCC輸出了錯(cuò)誤信息,請(qǐng)與系統(tǒng)管理員聯(lián)系。
說(shuō)明您的其他程序正在使用該數(shù)據(jù)庫(kù),如果剛才您在F步驟中使用SQLServerEnterpriseManager打開了test庫(kù)的系統(tǒng)表,那么退出SQLServerEnterpriseManager就可以了。
正確執(zhí)行完成的提示應(yīng)該類似于:
警告:數(shù)據(jù)庫(kù)"test"的日志已重建。已失去事務(wù)的一致性。應(yīng)運(yùn)行DBCCCHECKDB以驗(yàn)證物理一致性。將必須重置數(shù)據(jù)庫(kù)選項(xiàng),并且可能需要?jiǎng)h除多余的日志文件。
DBCC執(zhí)行完畢。如果DBCC輸出了錯(cuò)誤信息,請(qǐng)與系統(tǒng)管理員聯(lián)系。
此時(shí)打開在SQLServerEnterpriseManager里面會(huì)看到數(shù)據(jù)庫(kù)的狀態(tài)為“只供DBO使用”。此時(shí)可以訪問數(shù)據(jù)庫(kù)里面的用戶表了。
9.驗(yàn)證數(shù)據(jù)庫(kù)一致性dbcccheckdb("test")10.設(shè)置數(shù)據(jù)庫(kù)為正常狀態(tài)
sp_dboption"test","dbouseonly","false"
如果沒有出錯(cuò),那么恭喜,現(xiàn)在就可以正常的使用恢復(fù)后的數(shù)據(jù)庫(kù)啦。11最后一步,我們要將步驟E中設(shè)置的“允許對(duì)系統(tǒng)目錄直接修改”一項(xiàng)恢復(fù);
友情提示:本文中關(guān)于《SQLserver201*數(shù)據(jù)庫(kù)修復(fù)辦法總結(jié)》給出的范例僅供您參考拓展思維使用,SQLserver201*數(shù)據(jù)庫(kù)修復(fù)辦法總結(jié):該篇文章建議您自主創(chuàng)作。
來(lái)源:網(wǎng)絡(luò)整理 免責(zé)聲明:本文僅限學(xué)習(xí)分享,如產(chǎn)生版權(quán)問題,請(qǐng)聯(lián)系我們及時(shí)刪除。