公交车上荫蒂添的好舒服的电影-公用玩物(np双xing总受)-公用小荡货芊芊-公与妇仑乱hd-攻把受做哭边走边肉楼梯play-古装一级淫片a免费播放口

在數(shù)據(jù)庫(kù)的日常管理中，我們不可避免的會(huì)遇到，服務(wù)器突然斷電（沒(méi)有進(jìn)行電源冗余），服務(wù)器崩潰或者 SQL Server 服務(wù)突然停掉，悲催的是日志文件也損毀了，SQL Server服務(wù)器起來(lái)之后，發(fā)現(xiàn)數(shù)據(jù)庫(kù)處于“恢復(fù)掛起”模式；更悲哀的是該數(shù)據(jù)庫(kù)沒(méi)有備份或者備份已經(jīng)比較久遠(yuǎn)；最最可悲的是，已經(jīng)做好了丟失部分?jǐn)?shù)據(jù)的準(zhǔn)備，使用 DBCC CEHECKDB 的 REPAIR_ALLOW_DATA_LOSS 選項(xiàng)修復(fù)數(shù)據(jù)庫(kù)后，數(shù)據(jù)庫(kù)還是無(wú)法上線：

文件激活失敗。物理文件名稱(chēng)'D:\data\archlog1.ldf'可能不正確。

無(wú)法重新生成日志，原因是數(shù)據(jù)庫(kù)關(guān)閉時(shí)存在打開(kāi)的事務(wù)/用戶，該數(shù)據(jù)庫(kù)沒(méi)有檢查點(diǎn)或者該數(shù)據(jù)庫(kù)是只讀的。如果事務(wù)日志文件被手動(dòng)刪除或者由于硬件或環(huán)境問(wèn)題而丟失，則可能出現(xiàn)此錯(cuò)誤。

消息 1813，級(jí)別 16，狀態(tài) 2，第 18 行

無(wú)法打開(kāi)新數(shù)據(jù)庫(kù) 'PerfStats'。CREATE DATABASE 中止。

本文將分享兩種處理這種問(wèn)題的方式，幫助您成功恢復(fù)數(shù)據(jù)庫(kù)。

模擬環(huán)境

--窗口1USE PerfStatsGO

SELECT * INTO testObject FROM sys.all_objects
--前面腳本執(zhí)行完成再執(zhí)行該插入語(yǔ)句INSERT INTO dbo.testObjectSELECT o.* FROM sys.all_objects o CROSS JOIN sys.all_objects o1 CROSS JOIN sys.all_objects o2 CROSS JOIN sys.all_objects o3

首先，在數(shù)據(jù)庫(kù) PerfStats 中創(chuàng)建 testObject 表，并插入所有對(duì)象數(shù)據(jù)。接下來(lái)我們運(yùn)行插入腳本，使用多次 CROSS JOIN，以獲得足夠多的數(shù)據(jù)，贏得時(shí)間，讓我們?cè)陉P(guān)閉測(cè)試實(shí)例時(shí)，插入事務(wù)仍然在運(yùn)行。這將使得數(shù)據(jù)庫(kù)處于不一致?tīng)顟B(tài)，需要在數(shù)據(jù)庫(kù)啟動(dòng)時(shí)，執(zhí)行恢復(fù)。在另外一個(gè) SSMS 窗口執(zhí)行如下關(guān)閉 SQL Server 實(shí)例的腳本：

--窗口2SHUTDOWN WITH NOWAIT

停服后，將PerfStats 的日志文件改名或者移到其他路徑，重新啟動(dòng)SQL Server 服務(wù)，可以看到，PerfStats 數(shù)據(jù)庫(kù)處于“恢復(fù)掛起”狀態(tài)：

此時(shí)，我們僅有一個(gè)孤立的，不一致的數(shù)據(jù)庫(kù)文件。

首先，讓我們通過(guò)刪除數(shù)據(jù)庫(kù)來(lái)清除系統(tǒng)分類(lèi)。此時(shí)，我們必須先離線數(shù)據(jù)庫(kù)：

USE masterGO
ALTER DATABASE Archive SET OFFLINE;

copy或者重命名數(shù)據(jù)文件，以備我們測(cè)試使用。然后通過(guò)刪除數(shù)據(jù)庫(kù)，來(lái)清除系統(tǒng)分類(lèi)：

使用 ATTACH_REBUILD_LOG 來(lái)重建日志文件：

USE masterGOCREATE DATABASE PerfStats ON(FILENAME='D:\db\PerfStats.mdf')FOR ATTACH_REBUILD_LOGGO

文件激活失敗。物理文件名稱(chēng)'D:\DB\PerfStats_log.ldf'可能不正確。

無(wú)法重新生成日志，原因是數(shù)據(jù)庫(kù)關(guān)閉時(shí)存在打開(kāi)的事務(wù)/用戶，該數(shù)據(jù)庫(kù)沒(méi)有檢查點(diǎn)或者該數(shù)據(jù)庫(kù)是只讀的。如果事務(wù)日志文件被手動(dòng)刪除或者由于硬件或環(huán)境問(wèn)題而丟失，則可能出現(xiàn)此錯(cuò)誤。

消息 1813，級(jí)別 16，狀態(tài) 2，第 7 行

無(wú)法打開(kāi)新數(shù)據(jù)庫(kù) 'PerfStats'。CREATE DATABASE 中止。

到此為止，我們很可能只有去找備份文件還原了（如果有的話），否則可能就是一場(chǎng)大災(zāi)難了。

本文接下來(lái)將介紹兩種可以用來(lái)恢復(fù)數(shù)據(jù)庫(kù)的方式，以幫助您度過(guò)劫難。第一種方式是使用 CREATE DATABASE 語(yǔ)句中非歸檔的的命令。如你所知，微軟是不支持使用非歸檔的語(yǔ)句，因?yàn)槭褂眠@個(gè)語(yǔ)句一旦出了問(wèn)題，他們是概不負(fù)責(zé)的。另一種方法更機(jī)智，不需要使用非歸檔功能。

方案一、未歸檔的ATTACH_FORCE_REBUILD_LOG命令

到目前為止，因?yàn)闆](méi)有日志文件，我們使用 CREATE DATABASE…FOR ATTACH 語(yǔ)句恢復(fù)數(shù)據(jù)庫(kù)會(huì)失敗。同時(shí)，因?yàn)閿?shù)據(jù)庫(kù)中有打開(kāi)的事務(wù)，我們也不能使用 ATTACH_REBUILD_LOG 命令。有一個(gè)未歸檔的命令 ATTACH_FORCE_REBUILD_LOG 命令，正如其名稱(chēng)所顯示，強(qiáng)制 CREATE DATABASE…FOR ATTACH 語(yǔ)句恢復(fù)數(shù)據(jù)庫(kù)，盡管其是孤立的、有打開(kāi)事務(wù)的數(shù)據(jù)庫(kù)。當(dāng)然，也會(huì)創(chuàng)建一個(gè)新日志文件。

USE masterGO
CREATE DATABASE PerfStats ON(FILENAME='D:\db\PerfStats.mdf')FOR ATTACH_FORCE_REBUILD_LOGGO

數(shù)據(jù)庫(kù)雖然恢復(fù)正常，但數(shù)據(jù)表對(duì)象仍然無(wú)效：

使用最小數(shù)據(jù)丟失的方式，修復(fù)數(shù)據(jù)庫(kù)：

USE PerfStatsGO
ALTER DATABASE PerfStats SET SINGLE_USER WITH NO_WAITGO
DBCC CHECKDB(PerfStats,REPAIR_REBUILD) WITH ALL_ERRORMSGSGO

看到，有380個(gè)一致性錯(cuò)誤，僅僅修復(fù)兩個(gè)。

USE PerfStatsGO ALTER DATABASE PerfStats_Repair SET EMERGENCYGO
ALTER DATABASE PerfStats SET SINGLE_USER WITH NO_WAITGO

DBCC CHECKDB(PerfStats,REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS

最后雖然修復(fù)好了數(shù)據(jù)庫(kù)，但數(shù)據(jù)庫(kù)最后一次checkpoint點(diǎn)之后的所有數(shù)據(jù)將會(huì)丟失。

方案二、不使用未歸檔的功能附加損毀的SQL Server數(shù)據(jù)庫(kù)

步驟一、創(chuàng)建新數(shù)據(jù)庫(kù)

USE masterGO
CREATE DATABASE PerfStats_RepairCONTAINMENT=NONEON PRIMARY(NAME='PerfStats_Repair' ,FILENAME=N'D:\DB\PerfStats_Repair.mdf' ,SIZE=8MB ,MAXSIZE=UNLIMITED ,FILEGROWTH=64MB)LOG ON(NAME=N'PerfStats_Repair_log' ,FILENAME=N'D:\DB\PerfStats_Repair_log.ldf' ,SIZE=8MB ,MAXSIZE=20GB ,FILEGROWTH=32MB)GO

步驟二、離線新數(shù)據(jù)庫(kù)

USE masterGOALTER DATABASE PerfStats_Repair SET OFFLINE WITH ROLLBACK IMMEDIATE

步驟三、將新數(shù)據(jù)庫(kù)的文件路徑指向我們的孤立的?mdf?文件，并且將日志文件指向一個(gè)不存在的文件

USE masterGOALTER DATABASE PerfStats_Repair MODIFY FILE(NAME='PerfStats_Repair' ,FILENAME='D:\DB\PerfStats.mdf')ALTER DATABASE PerfStats_Repair MODIFY FILE(NAME='PerfStats_Repair_log' ,FILENAME='D:\DB\PerfStats_log.ldf')GO

測(cè)試上線情況：

USE masterGO
ALTER DATABASE PerfStats_Repair SET ONLINE

消息 5120，級(jí)別 16，狀態(tài) 101，第 39 行

無(wú)法打開(kāi)物理文件“D:\DB\PerfStats.mdf”。操作系統(tǒng)錯(cuò)誤 5:“5(拒絕訪問(wèn)。)”。

文件激活失敗。物理文件名稱(chēng)'D:\DB\PerfStats_log.ldf'可能不正確。

消息 5181，級(jí)別 16，狀態(tài) 5，第 39 行

無(wú)法重新啟動(dòng)數(shù)據(jù)庫(kù)“PerfStats_Repair”。將恢復(fù)到以前的狀態(tài)。

消息 5069，級(jí)別 16，狀態(tài) 1，第 39 行

ALTER DATABASE 語(yǔ)句失敗。

無(wú)法打開(kāi)物理文件“D:\DB\PerfStats.mdf”。操作系統(tǒng)錯(cuò)誤 5:“5(拒絕訪問(wèn)。)”。這是因?yàn)樵谝苿?dòng)MDF 文件時(shí)，Authenticated Users 的權(quán)限改變了，需要為其添加“完全控制”權(quán)限，右擊文件→屬性→點(diǎn)選 Authenticated Users 用戶→編輯→點(diǎn)選Authenticated Users→勾選下方“完全控制”右側(cè)“允許”下的多選框→確定即可

重新運(yùn)行ONLINE 腳本。即使您不是 SQL Server 專(zhuān)家，也能夠猜測(cè)到，運(yùn)行那個(gè)腳本會(huì)報(bào)錯(cuò)。但是，如果您看一看下圖捕獲到的錯(cuò)誤信息，您將會(huì)發(fā)現(xiàn)，當(dāng)SQL Server 無(wú)法找到事務(wù)日志文件時(shí)（我們之前的操作是改變系統(tǒng)目錄，將其指向一個(gè)不存在的文件），會(huì)對(duì)日志文件進(jìn)行重建。當(dāng)然，重建日志文件失敗，其錯(cuò)誤信息和我們附加孤立的 *.mdf 文件相同，此時(shí)，和之前附件情況唯一不同的是，*.mdf 文件附加成功了，這離我們成功又進(jìn)了一步。

文件激活失敗。物理文件名稱(chēng)'D:\DB\PerfStats_log.ldf'可能不正確。

無(wú)法重新生成日志，原因是數(shù)據(jù)庫(kù)關(guān)閉時(shí)存在打開(kāi)的事務(wù)/用戶，該數(shù)據(jù)庫(kù)沒(méi)有檢查點(diǎn)或者該數(shù)據(jù)庫(kù)是只讀的。如果事務(wù)日志文件被手動(dòng)刪除或者由于硬件或環(huán)境問(wèn)題而丟失，則可能出現(xiàn)此錯(cuò)誤。

消息 5181，級(jí)別 16，狀態(tài) 5，第 39 行

無(wú)法重新啟動(dòng)數(shù)據(jù)庫(kù)“PerfStats_Repair”。將恢復(fù)到以前的狀態(tài)。

消息 5069，級(jí)別 16，狀態(tài) 1，第 39 行

ALTER DATABASE 語(yǔ)句失敗。

此時(shí)數(shù)據(jù)庫(kù) PerfStats_repair 數(shù)據(jù)庫(kù)處于“恢復(fù)還原”狀態(tài)。

步驟四、重建SQL Server 事務(wù)日志文件

現(xiàn)在，您會(huì)看到，重建 SQL Server 事務(wù)日志并不是非常復(fù)雜，但是，您必須接受將要丟失數(shù)據(jù)這一事實(shí)。事實(shí)上，只有在從備份恢復(fù)損壞的數(shù)據(jù)庫(kù)這條路被斷掉之后，您才能選擇使用這種方式。例如，如果一個(gè)事務(wù)在更新索引，并且更新操作執(zhí)行了一個(gè)頁(yè)拆分，你可能丟失之前提交的事務(wù)，因?yàn)轫?yè)拆分是要進(jìn)行日志記錄的，而這一記錄會(huì)因?yàn)槿罩疚募膩G失而消失。

下面是恢復(fù)數(shù)據(jù)庫(kù)的腳本：

USE masterGO
DBCC TRACEON(3604)GO
ALTER DATABASE PerfStats_Repair SET EMERGENCYGO
ALTER DATABASE PerfStats_Repair SET SINGLE_USERGO
DBCC CHECKDB(PerfStats_Repair,REPAIR_ALLOW_DATA_LOSS)GO
ALTER DATABASE PerfStats_Repair SET MULTI_USER

第一個(gè)DBCC 命令是將所有的輸出展示在查詢(xún)結(jié)果中，而不是記錄在錯(cuò)誤日志中。接下來(lái)兩個(gè)腳本將數(shù)據(jù)庫(kù)分別置于緊急模式和單用戶模式，這是我們執(zhí)行 DBCC CHECKDB 的 REPAIR_ALLOW_DATA_LOSS 選項(xiàng)的前提。最后一句腳本是將數(shù)據(jù)庫(kù)恢復(fù)多用戶模式。

下圖框起來(lái)的部分說(shuō)明錯(cuò)誤日志已經(jīng)重建了：

文件激活失敗。物理文件名稱(chēng)'D:\DB\PerfStats_log.ldf'可能不正確。

無(wú)法重新生成日志，原因是數(shù)據(jù)庫(kù)關(guān)閉時(shí)存在打開(kāi)的事務(wù)/用戶，該數(shù)據(jù)庫(kù)沒(méi)有檢查點(diǎn)或者該數(shù)據(jù)庫(kù)是只讀的。如果事務(wù)日志文件被手動(dòng)刪除或者由于硬件或環(huán)境問(wèn)題而丟失，則可能出現(xiàn)此錯(cuò)誤。

將禁用數(shù)據(jù)庫(kù) "PerfStats_Repair" 中的 Service Broker，因?yàn)閿?shù)據(jù)庫(kù)(316755B8-71DB-41B0-A4C5-1D076DB9EA0E)中的 Service Broker GUID 與 sys.databases (52C1EA48-8B63-446C-95AA-76D65C6DE5C5)中的不匹配。

警告: 數(shù)據(jù)庫(kù) 'PerfStats_Repair' 的日志已重新生成。已失去事務(wù)的一致性。RESTORE 鏈已斷開(kāi)，服務(wù)器不再有以前的日志文件的上下文，因此您需要了解它們的內(nèi)容。應(yīng)運(yùn)行 DBCC CHECKDB 驗(yàn)證物理一致性。數(shù)據(jù)庫(kù)已置于 dbo-only 模式。在準(zhǔn)備使數(shù)據(jù)庫(kù)可用時(shí)，需要重置數(shù)據(jù)庫(kù)選項(xiàng)，并刪除所有多余的日志文件。

至此，數(shù)據(jù)庫(kù)已經(jīng)恢復(fù)完成。

寫(xiě)在最后，完成數(shù)據(jù)庫(kù)備份策略必不可少，備份、備份，還是備份！！！