亚洲乱色熟女一区二区三区丝袜,天堂√中文最新版在线,亚洲精品乱码久久久久久蜜桃图片,香蕉久久久久久av成人,欧美丰满熟妇bbb久久久

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

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

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

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

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

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

模擬環(huán)境

--窗口1USE PerfStatsGO

SELECT * INTO testObject FROM sys.all_objects
--前面腳本執(zhí)行完成再執(zhí)行該插入語句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ù)庫 PerfStats 中創(chuàng)建 testObject 表，并插入所有對象數(shù)據(jù)。接下來我們運(yùn)行插入腳本，使用多次 CROSS JOIN，以獲得足夠多的數(shù)據(jù)，贏得時(shí)間，讓我們在關(guān)閉測試實(shí)例時(shí)，插入事務(wù)仍然在運(yùn)行。這將使得數(shù)據(jù)庫處于不一致狀態(tài)，需要在數(shù)據(jù)庫啟動時(shí)，執(zhí)行恢復(fù)。在另外一個(gè) SSMS 窗口執(zhí)行如下關(guān)閉 SQL Server 實(shí)例的腳本：

--窗口2SHUTDOWN WITH NOWAIT

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

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

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

USE masterGO
ALTER DATABASE Archive SET OFFLINE;

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

使用 ATTACH_REBUILD_LOG 來重建日志文件：

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

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

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

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

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

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

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

方案一、未歸檔的ATTACH_FORCE_REBUILD_LOG命令

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

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

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

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

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ù)庫，但數(shù)據(jù)庫最后一次checkpoint點(diǎn)之后的所有數(shù)據(jù)將會丟失。

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

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

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ù)庫

USE masterGOALTER DATABASE PerfStats_Repair SET OFFLINE WITH ROLLBACK IMMEDIATE

步驟三、將新數(shù)據(jù)庫的文件路徑指向我們的孤立的?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

測試上線情況：

USE masterGO
ALTER DATABASE PerfStats_Repair SET ONLINE

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

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

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

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

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

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

ALTER DATABASE 語句失敗。

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

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

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

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

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

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

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

ALTER DATABASE 語句失敗。

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

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

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

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

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

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

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

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

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

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

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

寫在最后，完成數(shù)據(jù)庫備份策略必不可少，備份、備份，還是備份?。。?/p>