sql數(shù)據(jù)庫備份和恢復(fù)常用操作

1、sql 數(shù)據(jù)庫備份和恢復(fù)常用操作導(dǎo)讀 ：本文 sql 數(shù)據(jù)庫備份和恢復(fù)常用操作 ，僅供參考，如果覺得很 不錯，歡迎點評和分享。ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS =32768 WHERENAME=' 置疑的數(shù)據(jù)庫名 'Gosp_dboption ' 置疑的數(shù)據(jù)庫名 ', 'single user', 'true'GoDBCC CHECKDB（' 置疑的數(shù)據(jù)庫名 '）Goupdate sysdat

2、abases set status =28 where name='置疑的數(shù)據(jù)庫名 'Gosp_configure 'allow updates', 0 reconfigure with overrideGosp_dboption ' 置疑的數(shù)據(jù)庫名 ', 'single user', 'false'Go方法二事情的起因昨天，系統(tǒng)管理員告訴我， 我們一個內(nèi)部應(yīng)用數(shù)據(jù)庫所在的磁盤 空間不足了。我注意到數(shù)據(jù)庫事件日志文件 XXX_Data.ldf 文件已經(jīng) 增長到了 3GB，于是我決意縮小這個日志文件。經(jīng)過收縮數(shù)據(jù)庫等

3、 操作未果后， 我犯了一個自進入行業(yè)以來的最大最愚蠢的錯誤： 竟然 誤刪除了這個日志文件！ 后來我看到所有論及數(shù)據(jù)庫恢復(fù)的文章上都 說道：“無論如何都要保證數(shù)據(jù)庫日志文件存在，它至關(guān)重要”，甚 至微軟甚至有一篇 KB 文章講如何只靠日志文件恢復(fù)數(shù)據(jù)庫的。我真 是不知道我那時候是怎么想的？！這下子壞了！ 這個數(shù)據(jù)庫連不上了， 企業(yè)管理器在它的旁邊寫著 “ （ 置疑 ） ”。而且最要命的，這個數(shù)據(jù)庫從來沒有備份了。我唯一找 得到的是遷移半年前的另外一個數(shù)據(jù)庫服務(wù)器， 應(yīng)用倒是能用了， 但 是少了許多記錄、表和存儲過程。真希望這只是一場噩夢！沒有效果的恢復(fù)步驟附加數(shù)據(jù)庫_Rambo 講過被刪除日志文

4、件中不存在活動日志時， 可以這么做 來恢復(fù)：1，分離被置疑的數(shù)據(jù)庫，可以使用 sp_detach_db 2，附加數(shù)據(jù)庫，可以使用 sp_attach_single_file_db 但是，很遺憾，執(zhí)行之后， SQL Server 質(zhì)疑數(shù)據(jù)文件和日志文 件不符，所以無法附加數(shù)據(jù)庫數(shù)據(jù)文件。DTS 數(shù)據(jù)導(dǎo)出不行，無法讀取 XXX 數(shù)據(jù)庫， DTS Wizard 報告說“初始化上 下文發(fā)生錯誤”。緊急模式怡紅公子講過沒有日志用于恢復(fù)時，可以這么做：1 ，把數(shù)據(jù)庫設(shè)置為 emergency mode2，重新建立一個 log 文件3 ，把 SQL Server 重新啟動一下4，把應(yīng)用數(shù)據(jù)庫設(shè)置成單用戶模式

5、5，做 DBCC CHECKDB6，如果沒有什么大問題就可以把數(shù)據(jù)庫狀態(tài)改回去了，記得別 忘了把系統(tǒng)表的修改選項關(guān)掉我實踐了一下， 把應(yīng)用數(shù)據(jù)庫的數(shù)據(jù)文件移走， 重新建立一個同 名的數(shù)據(jù)庫 XXX ，然后停掉 SQL 服務(wù)，把原來的數(shù)據(jù)文件再覆蓋回 來。之后，按照怡紅公子的步驟走。但是，也很遺憾，除了第 2 步之外，其他步驟執(zhí)行非常成功?？?惜，重啟 SQL Server 之后，這個應(yīng)用數(shù)據(jù)庫仍然是置疑！不過，讓我欣慰的是，這么做之后，倒是能夠 Select 數(shù)據(jù)了， 讓我大出一口氣。 只不過，組件使用數(shù)據(jù)庫時， 報告說：“發(fā)生錯誤： -2147467259, 未 能 在 數(shù) 據(jù) 庫 '

6、;XXX' 中 運 行 BEGIN TRANSACTION ，因為該數(shù)據(jù)庫處于回避恢復(fù)模式?！弊罱K成功恢復(fù)的全部步驟設(shè)置數(shù)據(jù)庫為緊急模式停掉 SQL Server 服務(wù)；把應(yīng)用數(shù)據(jù)庫的數(shù)據(jù)文件 XXX_Data.mdf 移走； 重新建立一個同名的數(shù)據(jù)庫 XXX； 停掉 SQL 服務(wù)； 把原來的數(shù)據(jù)文件再覆蓋回來；運行以下語句，把該數(shù)據(jù)庫設(shè)置為緊急模式；運行“ Use MasterGosp_configure 'allow updates', 1reconfigure with overrideGo”執(zhí)行結(jié)果：DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯誤信息，請與系統(tǒng)管

7、理 員聯(lián)系。已將配 置選 項 'allow updates' 從 0 改為 1 。請運 行 RECONFIGURE 語句以安裝。接著運行“ update sysdatabases set status = 32768 where name = 'XXX'”執(zhí)行結(jié)果：（所影響的行數(shù)為 1 行）重啟 SQL Server 服務(wù)； 運行以下語句，把應(yīng)用數(shù)據(jù)庫設(shè)置為 Single User 模式； 運行“ sp_dboption 'XXX', 'single user', 'true'如果對您有幫助！感謝評論與分享 執(zhí)行結(jié)

8、果：命令已成功完成。U 做 DBCC CHECKDB ;運行“ DBCC CHECKDB('XXX') ”執(zhí)行結(jié)果：'XXX' 的 DBCC 結(jié)果。'sysobjects' 的 DBCC 結(jié)果。對象 'sysobjects' 有 273 行，這些行位于 5 頁中。'sysindexes' 的 DBCC 結(jié)果。對象 'sysindexes' 有 202 行，這些行位于 7 頁中。'syscolumns' 的 DBCC 結(jié)果。ii運行以下語句把系統(tǒng)表的修改選項關(guān)掉；運行“ sp_rese

9、tstatus "XXX"gosp_configure 'allow updates', 0reconfigure with overrideGo”執(zhí)行結(jié)果：在 sysdatabases 中更新數(shù)據(jù)庫 'XXX' 的條目之前，模式 = 0 ， 狀態(tài) = 28 (狀態(tài) suspect_bit = 0 )，沒有更新 sysdatabases 中的任何行，因為已正確地重置了模式和狀態(tài)。沒有錯誤，未進行任何更改。 DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯誤信息，請與系統(tǒng)管理員聯(lián)系。已將配置選項 'allow updates' 從 1 改為 0。請運行 RECONFIGURE 語句以安裝。重新建立另外一個數(shù)據(jù)庫 XXX.Lost ；DTS 導(dǎo)出向?qū)н\行 DTS 導(dǎo)出向?qū)?；?fù)制源選擇 EmergencyMode 的數(shù)據(jù)庫 XXX ，導(dǎo)入到 XXX.Lost ；選擇“在 SQL Server 數(shù)據(jù)庫之間復(fù)制對象和數(shù)據(jù)”，試了 多次，好像不行，只是復(fù)制過來了所有表結(jié)構(gòu)，但是沒有數(shù)據(jù)