數(shù)據(jù)庫(kù)置疑的解決辦法

1、MSDB置疑修復(fù)方法一：你可以采用以下的語(yǔ)句進(jìn)行修復(fù): USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='msdb'Gosp_dboption 'msdb', 'single user', 'true'GoDBCC CHECKDB('msdb') Goupdate sysdatabases set status

2、=28 where name='msdb'Gosp_configure 'allow updates', 0 reconfigure with overrideGo sp_dboption 'msdb', 'single user', 'false'Go方法二：MSDB數(shù)據(jù)庫(kù)解決過程難點(diǎn)：由于MSDB數(shù)據(jù)庫(kù)不能刪除，將其文件拷出來，再次附加數(shù)據(jù)庫(kù)，但新的附加數(shù)據(jù)庫(kù)不能叫MSDB，也就是不能同名，遇到了困難。1：先停止整個(gè)數(shù)據(jù)庫(kù)，將該數(shù)據(jù)庫(kù)的文件msdbdata.mdf和msdblog.ldf拷貝粘貼出來到另一個(gè)目錄

3、下。2：將以上的文件再拷貝到另一個(gè)目錄下，也就是說復(fù)制兩次。3：選擇 數(shù)據(jù)庫(kù)右擊鼠標(biāo) -所有任務(wù)-附加數(shù)據(jù)庫(kù) 將復(fù)制出的一個(gè)備份文件附加上去，其中，數(shù)據(jù)庫(kù)名稱叫MSDB1，用戶是SA或ADMINISTRATOR。4：將MSDB1數(shù)據(jù)庫(kù)備份，備份成一個(gè)文件，當(dāng)時(shí)我的叫MSDB。BAK。5：選擇置疑的數(shù)據(jù)庫(kù)MSDB，選擇恢復(fù)數(shù)據(jù)庫(kù)，將剛才備份出來的數(shù)據(jù)庫(kù)強(qiáng)行恢復(fù)到MSDB。6：?jiǎn)栴}解決，MSDB庫(kù)又能正常使用。完成后趕快將數(shù)據(jù)庫(kù)再次備份一次。呵呵。另附:SQL SERVER數(shù)據(jù)庫(kù)置疑后恢復(fù)步驟1 恢復(fù)步驟： a.將smlog_log.ldf文件備份到其它目錄下； b.將源目錄下的smlog_log

4、.ldf文件改名為smlog_log_bak.ldf； c.執(zhí)行以下語(yǔ)句修改數(shù)據(jù)庫(kù)的狀態(tài)： use Master go update sysdatabases set status=32768 where name=數(shù)據(jù)庫(kù)名稱 -修改狀態(tài) go shutdown with nowait -停止數(shù)據(jù)庫(kù)服務(wù)器 go d.退出SQL并在命令行模式中通過下面的代碼重新啟動(dòng)SQL： sqlservr -c -T3608 -T4022 -安全模式啟動(dòng)SQL SERVER e.在查詢分析器中執(zhí)行以下語(yǔ)句來查看剛剛修改過狀態(tài)的數(shù)據(jù)庫(kù)狀態(tài)： select Name,Status from sysdatabase

5、s where Name= 數(shù)據(jù)庫(kù)名稱 f.執(zhí)行以下代碼新建日志文件： dbcc traceon(3604) -跟蹤 dbcc rebuild_log(數(shù)據(jù)庫(kù)名稱,日志文件名稱) -文件名要有全路徑和擴(kuò)展名 g.將數(shù)據(jù)庫(kù)置回正常狀態(tài)： update sysdatabases set status=0 where name=數(shù)據(jù)庫(kù)名稱 h.重新啟動(dòng)數(shù)據(jù)庫(kù)后執(zhí)行以下語(yǔ)句檢查數(shù)據(jù)庫(kù)： DBCC CHECKDB -如果執(zhí)行完有錯(cuò)誤用以下語(yǔ)句修復(fù) i.要修復(fù)數(shù)據(jù)庫(kù)必需將數(shù)據(jù)庫(kù)改為單用戶模式： Exce sp_dboption 數(shù)據(jù)庫(kù)名稱,single user,true(false恢復(fù)多用戶) j.執(zhí)行

6、以下語(yǔ)句修復(fù)數(shù)據(jù)庫(kù)： DBCC CHECKDB(數(shù)據(jù)庫(kù)名稱,REPAIR_ALLOW_DATA_LOSS) REPAIR_ALLOW_DATA_LOSS：是比較高級(jí)的修復(fù)方式 REPAIR_FAST：是簡(jiǎn)單快速的修復(fù)方式 相似問題：系統(tǒng)重裝，忘記了備份SQL，然后又通過數(shù)據(jù)恢復(fù)工具找回了mcdb_data.mdf 和mcdb_Log.LDF，在企業(yè)管理器上用附加數(shù)據(jù)庫(kù)時(shí)提示錯(cuò)誤9004，日志錯(cuò)誤，在網(wǎng)上找了諸多方法，也試過建個(gè)同名空數(shù)據(jù)庫(kù)然后停止SQL SERVER然后覆蓋掉MDF。這是詳細(xì)步驟.1. 先建一個(gè)與你要恢復(fù)的數(shù)據(jù)庫(kù)名稱一樣的數(shù)據(jù)庫(kù)。 2.停止sql server,把你的數(shù)據(jù)庫(kù)替換

7、這個(gè)數(shù)據(jù)庫(kù)。 3.重啟sql server,把數(shù)據(jù)庫(kù)設(shè)置為緊急狀態(tài)。 sp_configure 'allow',1 reconfigure with overirde update sysdatabases set status=32768 where name='yourdata' 4.重建日志文件。 dbcc rebuild_log('yourdata','your data pathnewdata_log.ldf') 5.取消緊急模式。 update sysdatabases set status=0 where name=

8、'yourdata' restore sysdatabases yourdata with recovery sp_configure 'allow',0 reconfigure with override 6.重起sql server 7.ok22:09:21 |只看該作者 |倒序?yàn)g覽 SQL數(shù)據(jù)庫(kù)置疑解決方案一、數(shù)據(jù)庫(kù)置疑產(chǎn)生的原因1、SQL Server所在分區(qū)空間是否夠？數(shù)據(jù)庫(kù)文件大小是否達(dá)到最大文件限制？FAT32的格式只支持4G以內(nèi)的文件。2、數(shù)據(jù)庫(kù)文件損壞或被非正常刪除時(shí)出現(xiàn)這種情況。3、病毒防火墻的掃描也會(huì)引起數(shù)據(jù)庫(kù)置疑。4、當(dāng)SQL Serve

9、r啟動(dòng)時(shí)，將會(huì)嘗試獲得對(duì)數(shù)據(jù)庫(kù)文件的排他訪問權(quán)，如果此時(shí)該文件被其他程序占用，或者遺失，數(shù)據(jù)庫(kù)將會(huì)被標(biāo)記為置疑。5、電腦非法關(guān)機(jī)也會(huì)造成數(shù)據(jù)庫(kù)置疑。6、電腦磁盤有壞道有可能造成數(shù)據(jù)庫(kù)置疑。二、數(shù)據(jù)庫(kù)置疑的預(yù)防1、數(shù)據(jù)庫(kù)存放的盤符，空間是否夠大，經(jīng)常檢查盤符的空間。2、數(shù)據(jù)庫(kù)存放的盤符的格式設(shè)置為NTFS格式。3、進(jìn)行病毒清除時(shí)，盡量把SQL服務(wù)停掉，再進(jìn)行檢查。4、盡量減少非正常關(guān)機(jī)。5、建議客戶購(gòu)買后備電源。6、給客戶實(shí)施軟件之后一定要做好自動(dòng)備份。7、建議客戶每隔一定時(shí)間手動(dòng)備份一次。三、數(shù)據(jù)庫(kù)置疑的修復(fù)1、正常的備份、SQL數(shù)據(jù)庫(kù)恢復(fù)方式 正常方式下，我們要備份一個(gè)數(shù)據(jù)庫(kù)，首先要先將該數(shù)

10、據(jù)庫(kù)從運(yùn)行的數(shù)據(jù)服務(wù)器中斷開，或者停掉整個(gè)數(shù)據(jù)庫(kù)服務(wù)器，然后復(fù)制文件。 卸下數(shù)據(jù)庫(kù)的命令：Sp_detach_db 數(shù)據(jù)庫(kù)名 連接數(shù)據(jù)庫(kù)的命令：Sp_attach_db或者sp_attach_single_file_db s_attach_db dbname = dbname, filename1 = filename_n ,.16 sp_attach_single_file_db dbname = dbname, physname = physical_name 使用此方法可以正確恢復(fù)SQL Sever7.0和SQL Server 2000的數(shù)據(jù)庫(kù)文件，要點(diǎn)是備份的時(shí)候一定要將mdf和ldf

11、兩個(gè)文件都備份下來，mdf文件是數(shù)據(jù)庫(kù)數(shù)據(jù)文件，ldf是數(shù)據(jù)庫(kù)日志文件。 例子： 假設(shè)數(shù)據(jù)庫(kù)為pdm，其數(shù)據(jù)文件為pdm_data.mdf，日志文件為pdm_log.ldf。下面我們討論一下如何備份、恢復(fù)該數(shù)據(jù)庫(kù)。 卸下數(shù)據(jù)庫(kù)：sp_detach_db 'pdm' 連接數(shù)據(jù)庫(kù)：sp_attach_db 'pdm','C:Program FilesMicrosoft SQL ServerMSSQLDatapdm_data.mdf','C:Program FilesMicrosoft SQL ServerMSSQLDatapdm_log.ld

12、f' sp_attach_single_file_db 'pdm','C:Program FilesMicrosoft SQL ServerMSSQLDatapdm_data.mdf' 2、只有mdf文件的恢復(fù)技術(shù) 由于種種原因，我們?nèi)绻?dāng)時(shí)僅僅備份了mdf文件，那么恢復(fù)起來就是一件很麻煩的事情了。    如果您的mdf文件是當(dāng)前數(shù)據(jù)庫(kù)產(chǎn)生的，那么很僥幸，也許你使用sp_attach_db或者sp_attach_single_file_db 可以恢復(fù)數(shù)據(jù)庫(kù)，但是會(huì)出現(xiàn)類似下面的提示信息     設(shè)備激活錯(cuò)誤。物理文

13、件名 'C:Program FilesMicrosoft SQL ServerMSSQLdatapdm_Log.LDF' 可能有誤。     已創(chuàng)建名為 'C:Program FilesMicrosoft SQL ServerMSSQLDatapdm_log.LDF' 的新日志文件。但是，如果您的數(shù)據(jù)庫(kù)文件是從其他計(jì)算機(jī)上復(fù)制過來的，那么很不幸，也許上述辦法就行不通了。你也許會(huì)得到類似下面的錯(cuò)誤信息 服務(wù)器: 消息 1813，級(jí)別 16，狀態(tài) 2，行 1 未能打開新數(shù)據(jù)庫(kù) 'pdm'。CREATE DATABASE 將終止。

14、設(shè)備激活錯(cuò)誤。物理文件名 'd:pdm_log.LDF' 可能有誤。 怎么辦呢？別著急，下面我們舉例說明恢復(fù)辦法?，F(xiàn)在我從其他機(jī)器上拷貝回來了數(shù)據(jù)庫(kù)文件pdm_Data.MDF到本計(jì)算機(jī)上，存放到了E盤的一個(gè)文件夾里 A我們使用SQL Server企業(yè)管理器建立一個(gè)供恢復(fù)使用的數(shù)據(jù)庫(kù)pdm，存放在E盤（不要與拷貝回來的數(shù)據(jù)庫(kù)放到一個(gè)文件夾就行）。 2011-11-22 22:00:23 上傳下載附件 (25.95 KB)     B停掉數(shù)據(jù)庫(kù)服務(wù)器。2011-11-22 22:00:24 上傳下載附件 (33.47 KB) 2011-11-22 22:00:

15、25 上傳下載附件 (28.62 KB) C將剛才生成的數(shù)據(jù)庫(kù)的日志文件pdm_log.ldf刪除，用要恢復(fù)的數(shù)據(jù)庫(kù) mdf文件覆蓋剛才生成的數(shù)據(jù)庫(kù)數(shù)據(jù)文件pdm_data.mdf。 2011-11-22 22:00:25 上傳下載附件 (21.97 KB) 2011-11-22 22:00:26 上傳下載附件 (15.86 KB) D啟動(dòng)數(shù)據(jù)庫(kù)服務(wù)器。此時(shí)會(huì)看到數(shù)據(jù)庫(kù)pdm的狀態(tài)為“置疑”。這時(shí)候不 能對(duì)此數(shù)據(jù)庫(kù)進(jìn)行任何操作。 2011-11-22 22:00:26 上傳下載附件 (40.04 KB) E設(shè)置數(shù)據(jù)庫(kù)允許直接操作系統(tǒng)表。此操作可以在SQL Server Enterprise M

16、anager里面選擇數(shù)據(jù)庫(kù)服務(wù)器，按右鍵，選擇“屬性”，在“服務(wù)器設(shè)置”頁(yè)面中將“允許對(duì)系統(tǒng)目錄直接修改”一項(xiàng)選中。2011-11-22 22:00:27 上傳下載附件 (44.77 KB) 2011-11-22 22:00:28 上傳下載附件 (39.61 KB) 也可以用SQL查詢分析器執(zhí)行如下語(yǔ)句來實(shí)現(xiàn)。 use master go sp_configure 'allow updates',1 go reconfigure with override go 2011-11-22 22:00:28 上傳下載附件 (40.88 KB) F設(shè)置pdm為緊急修復(fù)模式 ，運(yùn)行SQL

17、查詢分析器執(zhí)行如下語(yǔ)句來實(shí) 現(xiàn)。2011-11-22 22:00:29 上傳下載附件 (34.47 KB) update sysdatabases set status=-32768 where dbid=DB_ID('pdm') 2011-11-22 22:00:30 上傳下載附件 (31.17 KB) 此時(shí)可以在SQL Server Enterprise Manager里面看到該數(shù)據(jù)庫(kù)處于“只讀 置疑脫機(jī)緊急模式”可以看到數(shù)據(jù)庫(kù)里面的表，但是僅僅有系統(tǒng)表 2011-11-22 22:00:31 上傳下載附件 (31.9 KB) G下面執(zhí)行真正的恢復(fù)操作，重建數(shù)據(jù)庫(kù)日志文件

18、dbcc rebuild_log('pdm','E:pdm_log.ldf') 2011-11-22 22:00:31 上傳下載附件 (49.06 KB) 執(zhí)行過程中，如果遇到下列提示信息： 服務(wù)器: 消息 5030，級(jí)別 16，狀態(tài) 1，行 1 未能排它地鎖定數(shù)據(jù)庫(kù)以執(zhí)行該操作。 DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。 說明您的其他程序正在使用該數(shù)據(jù)庫(kù)，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了pdm庫(kù)的系統(tǒng)表，那么退出SQL Server Enterprise Manager就可

19、以了。 正確執(zhí)行完成的提示應(yīng)該類似于： 警告: 數(shù)據(jù)庫(kù) 'pdm' 的日志已重建。已失去事務(wù)的一致性。應(yīng)運(yùn)行 DBCC CHECKDB 以驗(yàn)證物理一致性。將必須重置數(shù)據(jù)庫(kù)選項(xiàng)，并且可能需要?jiǎng)h除多余的日志文件。     DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。     此時(shí)打開在SQL Server Enterprise Manager里面會(huì)看到數(shù)據(jù)庫(kù)的狀態(tài)為“只供DBO使用”。此時(shí)可以訪問數(shù)據(jù)庫(kù)里面的用戶表了。 2011-11-22 22:00:32 上傳下載附件 (30.86 KB) H驗(yàn)證數(shù)據(jù)庫(kù)一致性（

20、數(shù)據(jù)庫(kù)較大時(shí)會(huì)耗費(fèi)一些時(shí)間，此步可省略） dbcc checkdb('pdm') 一般執(zhí)行結(jié)果如下： CHECKDB 發(fā)現(xiàn)了 0 個(gè)分配錯(cuò)誤和 0 個(gè)一致性錯(cuò)誤（在數(shù)據(jù)庫(kù) 'pdm' 中）。DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。I設(shè)置數(shù)據(jù)庫(kù)為正常狀態(tài) sp_dboption 'pdm','dbo use only','false' 2011-11-22 22:00:33 上傳下載附件 (32.38 KB) 如果沒有出錯(cuò)，那么恭喜，現(xiàn)在就可以正常的使用恢復(fù)后的數(shù)據(jù)庫(kù)啦。 2011-1

21、1-22 22:00:33 上傳下載附件 (32.01 KB) J最后一步，我們要將步驟E中設(shè)置的“允許對(duì)系統(tǒng)目錄直接修改”一項(xiàng)恢復(fù)。因?yàn)槠綍r(shí)直接操作系統(tǒng)表是一件比較危險(xiǎn)的事情。當(dāng)然，我們可以在SQL Server Enterprise Manager里面恢復(fù)，也可以使用如下語(yǔ)句完成 sp_configure 'allow updates',0 go reconfigure with override go會(huì)出現(xiàn)以下信息，此時(shí)就可以正常使用數(shù)據(jù)庫(kù)了。2011-11-22 22:00:34 上傳下載附件 (46.72 KB) 18.jpg (33.04 KB, 下載次數(shù): 93)

22、 2011-11-22 22:00:23 上傳下載次數(shù): 93SQL數(shù)據(jù)庫(kù)置疑，解決過程   復(fù)制鏈接 heyer heyer 當(dāng)前離線 性別保密推廣0 魅力12 個(gè)人主頁(yè)金幣14 威望12 精華0主題6帖子15積分98閱讀權(quán)限10在線時(shí)間3 小時(shí)最后登錄2011-12-16注冊(cè)時(shí)間2009-12-6UID184338IP卡 狗仔卡 正式員工正式員工, 積分 98, 距離下一級(jí)還需 402 積分魅力12 推廣0 金幣14 威望12 帖子15積分98閱讀權(quán)限10UID184338· 串個(gè)門· 加好友· 打招呼· 發(fā)消息電梯直達(dá) 1# 發(fā)表于 20

23、10-7-2 14:06:49 |只看該作者 |倒序?yàn)g覽 問題描述：   sqlserver數(shù)據(jù)庫(kù)被質(zhì)疑 產(chǎn)生原因： 數(shù)據(jù)庫(kù)質(zhì)疑 解決方法：   :請(qǐng)根據(jù)實(shí)際情況修改db_name1、在SQL查詢分析器中執(zhí)行以下命令，以允許更新系統(tǒng)表：use mastergosp_configure 'allow updates',1reconfigure with overridego2 將這個(gè)數(shù)據(jù)庫(kù)置為緊急模式：update sysdatabases set status = 32768 where name = 'db_name'g

24、o3. 使用DBCC CHECKDB命令檢查數(shù)據(jù)庫(kù)中的錯(cuò)誤：DBCC CHECKDB(db_name')GO4. 先將數(shù)據(jù)庫(kù)置為單用戶模式，再嘗試對(duì)其進(jìn)行修復(fù)：sp_dboption 'db_name','single user','true'DBCC CHECKDB(db_name', REPAIR_ALLOW_DATA_LOSS)GO如果在執(zhí)行DBCC CHECKDB(db_name', REPAIR_ALLOW_DATA_LOSS)命令時(shí)提示說數(shù)據(jù)庫(kù)未處于單用戶模式狀態(tài)的話，則重新啟動(dòng)SQL Server服務(wù)，然后繼

25、續(xù)嘗試。5、若成功修復(fù)了數(shù)據(jù)庫(kù)中的錯(cuò)誤：重新執(zhí)行DBCC CHECKDB(db_name')命令，確認(rèn)數(shù)據(jù)庫(kù)中已沒有錯(cuò)誤存在。清除數(shù)據(jù)庫(kù)的置疑狀態(tài)：sp_resetstatus 'db_name'清除數(shù)據(jù)庫(kù)的單用戶模式狀態(tài)：sp_dboption 'db_name','single user','false'重新啟動(dòng)SQL Server服務(wù)，如果一切正常的話，則數(shù)據(jù)庫(kù)已經(jīng)成功恢復(fù)。6、修改數(shù)據(jù)庫(kù)的標(biāo)志update sysdatabases set status=28 where name =''db_nam

26、e'( 'db_name'表示相應(yīng)的數(shù)據(jù)庫(kù)名字)數(shù)據(jù)庫(kù)置疑操作過程（轉(zhuǎn)）   復(fù)制鏈接 naojin naojin 當(dāng)前離線 性別男真實(shí)姓名帝國(guó)戰(zhàn)士推廣54 魅力2628 個(gè)人主頁(yè)金幣86118 威望9707 精華18主題75帖子1882積分118561閱讀權(quán)限70在線時(shí)間1593 小時(shí)最后登錄2012-8-31注冊(cè)時(shí)間2008-12-16UID125567IP卡 狗仔卡 高級(jí)會(huì)計(jì)師高級(jí)會(huì)計(jì)師, 積分 118561, 距離下一級(jí)還需 881439 積分魅力2628 推廣54 真實(shí)姓名帝國(guó)戰(zhàn)士金幣86118 威望9707 帖子1882積分118561閱讀權(quán)限70

27、UID125567· 串個(gè)門· 加好友· 打招呼· 發(fā)消息電梯直達(dá) 1# 發(fā)表于 2009-10-30 16:56:12 |只看該作者 |倒序?yàn)g覽 下列文件名均為假設(shè)，實(shí)際過程中需要對(duì)應(yīng)替換-1 恢復(fù)步驟：  -a.將smlog_log.ldf文件備份到其它目錄下；  -b.將源目錄下的smlog_log.ldf文件改名為smlog_log_bak.ldf；  -c.執(zhí)行以下語(yǔ)句修改數(shù)據(jù)庫(kù)的狀態(tài)：  use Master  go  up

28、date sysdatabases set status=32768 where name='數(shù)據(jù)庫(kù)名稱'     -修改狀態(tài),設(shè)為緊急狀態(tài)go  shutdown with nowait     -停止數(shù)據(jù)庫(kù)服務(wù)器  go  -d.退出SQL并在(COMMAND)命令行模式中通過下面的代碼重新啟動(dòng)SQL：  sqlservr -c -T3608 -T4022     -安全模式啟

29、動(dòng)SQL SERVER-e.在查詢分析器中執(zhí)行以下語(yǔ)句來查看剛剛修改過狀態(tài)的數(shù)據(jù)庫(kù)狀態(tài)：  select Name,Status from sysdatabases where Name='數(shù)據(jù)庫(kù)名稱'-f.執(zhí)行以下代碼新建日志文件：  dbcc traceon(3604)-跟蹤  dbcc rebuild_log('數(shù)據(jù)庫(kù)名稱','日志文件全路徑') -文件名要有全路徑和擴(kuò)展名-dbcc rebuild_log('prs_msc','d:mscsqlmssqld

30、ataprs_msc_log.ldf-g.將數(shù)據(jù)庫(kù)置回正常狀態(tài)：  update sysdatabases set status=0 where name='數(shù)據(jù)庫(kù)名稱'  -h.重新啟動(dòng)數(shù)據(jù)庫(kù)后執(zhí)行以下語(yǔ)句檢查數(shù)據(jù)庫(kù)：  DBCC CHECKDB -如果執(zhí)行完有錯(cuò)誤用以下語(yǔ)句修復(fù)  -i.要修復(fù)數(shù)據(jù)庫(kù)必需將數(shù)據(jù)庫(kù)改為單用戶模式：  Exce sp_dboption '數(shù)據(jù)庫(kù)名稱','single user','true'-(

31、9;false'恢復(fù)多用戶)  -j.執(zhí)行以下語(yǔ)句修復(fù)數(shù)據(jù)庫(kù)：  DBCC CHECKDB('數(shù)據(jù)庫(kù)名稱',REPAIR_ALLOW_DATA_LOSS)  REPAIR_ALLOW_DATA_LOSS：是比較高級(jí)的修復(fù)方式  REPAIR_FAST：是簡(jiǎn)單快速的修復(fù)方式/*處理狀態(tài)就為"置疑"的數(shù)據(jù)庫(kù)備份數(shù)據(jù)文件,然后按下面的步驟處理:  1.新建一個(gè)同名的數(shù)據(jù)庫(kù)(數(shù)據(jù)文件與原來的要一致)  2.再停掉sql server(注意不

32、要分離數(shù)據(jù)庫(kù))  3.用原數(shù)據(jù)庫(kù)的數(shù)據(jù)文件覆蓋掉這個(gè)新建的數(shù)據(jù)庫(kù)  4.再重啟sql server  5.此時(shí)打開企業(yè)管理器時(shí)會(huì)出現(xiàn)置疑，先不管，執(zhí)行下面的語(yǔ)句（注意修改其中的數(shù)據(jù)庫(kù)名)  6.完成后一般就可以訪問數(shù)據(jù)庫(kù)中的數(shù)據(jù)了,這時(shí),數(shù)據(jù)庫(kù)本身一般還要問題,解決辦法是,利用數(shù)據(jù)庫(kù)的腳本創(chuàng)建一個(gè)新的數(shù)據(jù)庫(kù),并將數(shù)據(jù)導(dǎo)進(jìn)去就行了.*/USE   MASTER  GO  SP_CONFIGURE 'ALLOW UPDATES',1GORECO

33、NFIGURE WITH OVERRIDE  GO  UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的數(shù)據(jù)庫(kù)名'  Go  sp_dboption '置疑的數(shù)據(jù)庫(kù)名','single user','true'  Go  DBCC CHECKDB('置疑的數(shù)據(jù)庫(kù)名')    Go  update sys

34、databases set status=28 where name='置疑的數(shù)據(jù)庫(kù)名'  Go  sp_configure 'allow updates',0GOreconfigure with override  Go    sp_dboption '置疑的數(shù)據(jù)庫(kù)名', 'single user','false'  Go  /*只有mdf文件的恢復(fù)技術(shù)由于種種原因，我們?nèi)绻?dāng)時(shí)僅僅備份了mdf

35、文件，那么恢復(fù)起來就是一件很麻煩的事情了。如果您的mdf文件是當(dāng)前數(shù)據(jù)庫(kù)產(chǎn)生的，那么很僥幸，也許你使用sp_attach_db或者sp_attach_single_file_db可以恢復(fù)數(shù)據(jù)庫(kù)，但是會(huì)出現(xiàn)類似下面的提示信息設(shè)備激活錯(cuò)誤。物理文件名 'C:Program FilesMicrosoft SQL ServerMSSQLdatatest_Log.LDF' 可能有誤。已創(chuàng)建名為 'C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.LDF' 的新日志文件。但是，如果您的數(shù)據(jù)庫(kù)文件是從其他計(jì)算機(jī)上復(fù)制過來

36、的，那么很不幸，也許上述辦法就行不通了。你也許會(huì)得到類似下面的錯(cuò)誤信息服務(wù)器: 消息 1813，級(jí)別 16，狀態(tài) 2，行 1未能打開新數(shù)據(jù)庫(kù) 'test'。CREATE DATABASE 將終止。設(shè)備激活錯(cuò)誤。物理文件名 'd:test_log.LDF' 可能有誤。怎么辦呢？別著急，下面我們舉例說明恢復(fù)辦法。*/-A我們使用默認(rèn)方式建立一個(gè)供恢復(fù)使用的數(shù)據(jù)庫(kù)(如test)?？梢栽赟QL Server Enterprise Manager里面建立。-B停掉數(shù)據(jù)庫(kù)服務(wù)器。-C將剛才生成的數(shù)據(jù)庫(kù)的日志文件test_log.ldf刪除，用要恢復(fù)的數(shù)據(jù)庫(kù)mdf文件覆蓋剛才

37、生成的數(shù)據(jù)庫(kù)數(shù)據(jù)文件test_data.mdf。-D啟動(dòng)數(shù)據(jù)庫(kù)服務(wù)器。此時(shí)會(huì)看到數(shù)據(jù)庫(kù)test的狀態(tài)為“置疑”。這時(shí)候不能對(duì)此數(shù)據(jù)庫(kù)進(jìn)行任何操作。-E設(shè)置數(shù)據(jù)庫(kù)允許直接操作系統(tǒng)表。此操作可以在SQL Server Enterprise Manager里面選擇數(shù)據(jù)庫(kù)服務(wù)器，按右-鍵，選擇“屬性”，在“服務(wù)器設(shè)置”頁(yè)面中將“允許對(duì)系統(tǒng)目錄直接修改”一項(xiàng)選中。也可以使用如下語(yǔ)句來實(shí)現(xiàn)。use mastergosp_configure 'allow updates',1goreconfigure with overridego-F設(shè)置test為緊急修復(fù)模式-在查詢管理器里設(shè)置如下命令：

38、update sysdatabases set status=-32768 where dbid=DB_ID('test')-此時(shí)可以在SQL Server Enterprise Manager里面看到該數(shù)據(jù)庫(kù)處于“只讀置疑脫機(jī)緊急模式”可以看到數(shù)據(jù)庫(kù)里面的表，但是僅僅有系統(tǒng)表-G下面執(zhí)行真正的恢復(fù)操作，重建數(shù)據(jù)庫(kù)日志文件dbcc rebuild_log('test','C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf')/*執(zhí)行過程中，如果遇到下列提示信息：服務(wù)器: 消息 5030

39、，級(jí)別 16，狀態(tài) 1，行 1未能排它地鎖定數(shù)據(jù)庫(kù)以執(zhí)行該操作。DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。說明您的其他程序正在使用該數(shù)據(jù)庫(kù)，如果剛才您在F步驟中使用SQL Server Enterprise Manager打開了test庫(kù)的系統(tǒng)表，那么退出SQL Server Enterprise Manager就可以了。正確執(zhí)行完成的提示應(yīng)該類似于：警告: 數(shù)據(jù)庫(kù) 'test' 的日志已重建。已失去事務(wù)的一致性。應(yīng)運(yùn)行 DBCC CHECKDB 以驗(yàn)證物理一致性。將必須重置數(shù)據(jù)庫(kù)選項(xiàng)，并且可能需要?jiǎng)h除多余的日志文件。DBCC 執(zhí)行完畢。如果 DB

40、CC 輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。此時(shí)打開在SQL Server Enterprise Manager里面會(huì)看到數(shù)據(jù)庫(kù)的狀態(tài)為“只供DBO使用”。此時(shí)可以訪問數(shù)據(jù)庫(kù)里面的用戶表了。*/-H驗(yàn)證數(shù)據(jù)庫(kù)一致性（可省略）dbcc checkdb('test')/*一般執(zhí)行結(jié)果如下：CHECKDB 發(fā)現(xiàn)了 0 個(gè)分配錯(cuò)誤和 0 個(gè)一致性錯(cuò)誤（在數(shù)據(jù)庫(kù) 'test' 中）。DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。*/-I設(shè)置數(shù)據(jù)庫(kù)為正常狀態(tài)sp_dboption 'test','dbo use only

41、9;,'false'-如果沒有出錯(cuò)，那么恭喜，現(xiàn)在就可以正常的使用恢復(fù)后的數(shù)據(jù)庫(kù)啦。-J最后一步，我們要將步驟E中設(shè)置的“允許對(duì)系統(tǒng)目錄直接修改”一項(xiàng)恢復(fù)。因?yàn)槠綍r(shí)直接操作系統(tǒng)表是一件比較危險(xiǎn)的事情。當(dāng)然，我們可以在SQL Server Enterprise Manager里面恢復(fù)，也可以使用如下語(yǔ)句完成sp_configure 'allow updates',0goreconfigure with overridego-日志文件出現(xiàn)問題（丟失或文件格式非法），怎么使數(shù)據(jù)庫(kù)恢復(fù)正常  -如果用sp_attach_single_file 

42、9;TEST','C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log.mdf'失敗則需要用下列步驟完成  -1.將置疑的數(shù)據(jù)庫(kù)分離，將mdf文件移走或改名！  sp_detach_db 'TEST'  -2.重新在原來目錄下建立同名的數(shù)據(jù)庫(kù)TEST  -3.停掉SQL Service,將先前的mdf文件拷貝回來覆蓋(或改名),刪除原來的log文件(或改名)  -4.啟動(dòng)SQL Service(否則下面的

43、語(yǔ)句沒辦法運(yùn)行)  -5.將數(shù)據(jù)庫(kù)設(shè)成緊急模式(status=32768)  sp_configure 'allow updates',1  reconfigure with override  update sysdatabases set status=32768 where name='TEST'  -重新建立日志文件  DBCC traceon(3604)  dbcc rebuild_log('test','