欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

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

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

無法重新生成日志，原因是數據庫關閉時存在打開的事務/用戶，該數據庫沒有檢查點或者該數據庫是只讀的。如果事務日志文件被手動刪除或者由于硬件或環境問題而丟失，則可能出現此錯誤。

消息 1813，級別 16，狀態 2，第 18 行

無法打開新數據庫 'PerfStats'。CREATE DATABASE 中止。

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

模擬環境

--窗口1USE PerfStatsGO

SELECT * INTO testObject FROM sys.all_objects
--前面腳本執行完成再執行該插入語句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

首先，在數據庫 PerfStats 中創建 testObject 表，并插入所有對象數據。接下來我們運行插入腳本，使用多次 CROSS JOIN，以獲得足夠多的數據，贏得時間，讓我們在關閉測試實例時，插入事務仍然在運行。這將使得數據庫處于不一致狀態，需要在數據庫啟動時，執行恢復。在另外一個 SSMS 窗口執行如下關閉 SQL Server 實例的腳本：

--窗口2SHUTDOWN WITH NOWAIT

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

此時，我們僅有一個孤立的，不一致的數據庫文件。

首先，讓我們通過刪除數據庫來清除系統分類。此時，我們必須先離線數據庫：

USE masterGO
ALTER DATABASE Archive SET OFFLINE;

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

使用 ATTACH_REBUILD_LOG 來重建日志文件：

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

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

無法重新生成日志，原因是數據庫關閉時存在打開的事務/用戶，該數據庫沒有檢查點或者該數據庫是只讀的。如果事務日志文件被手動刪除或者由于硬件或環境問題而丟失，則可能出現此錯誤。

消息 1813，級別 16，狀態 2，第 7 行

無法打開新數據庫 'PerfStats'。CREATE DATABASE 中止。

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

本文接下來將介紹兩種可以用來恢復數據庫的方式，以幫助您度過劫難。第一種方式是使用 CREATE DATABASE 語句中非歸檔的的命令。如你所知，微軟是不支持使用非歸檔的語句，因為使用這個語句一旦出了問題，他們是概不負責的。另一種方法更機智，不需要使用非歸檔功能。

方案一、未歸檔的ATTACH_FORCE_REBUILD_LOG命令

到目前為止，因為沒有日志文件，我們使用 CREATE DATABASE…FOR ATTACH 語句恢復數據庫會失敗。同時，因為數據庫中有打開的事務，我們也不能使用 ATTACH_REBUILD_LOG 命令。有一個未歸檔的命令 ATTACH_FORCE_REBUILD_LOG 命令，正如其名稱所顯示，強制 CREATE DATABASE…FOR ATTACH 語句恢復數據庫，盡管其是孤立的、有打開事務的數據庫。當然，也會創建一個新日志文件。

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

數據庫雖然恢復正常，但數據表對象仍然無效：

使用最小數據丟失的方式，修復數據庫：

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

看到，有380個一致性錯誤，僅僅修復兩個。

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

最后雖然修復好了數據庫，但數據庫最后一次checkpoint點之后的所有數據將會丟失。

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

步驟一、創建新數據庫

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

步驟二、離線新數據庫

USE masterGOALTER DATABASE PerfStats_Repair SET OFFLINE WITH ROLLBACK IMMEDIATE

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

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，狀態 101，第 39 行

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

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

消息 5181，級別 16，狀態 5，第 39 行

無法重新啟動數據庫“PerfStats_Repair”。將恢復到以前的狀態。

消息 5069，級別 16，狀態 1，第 39 行

ALTER DATABASE 語句失敗。

無法打開物理文件“D:\DB\PerfStats.mdf”。操作系統錯誤 5:“5(拒絕訪問。)”。這是因為在移動MDF 文件時，Authenticated Users 的權限改變了，需要為其添加“完全控制”權限，右擊文件→屬性→點選 Authenticated Users 用戶→編輯→點選Authenticated Users→勾選下方“完全控制”右側“允許”下的多選框→確定即可

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

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

無法重新生成日志，原因是數據庫關閉時存在打開的事務/用戶，該數據庫沒有檢查點或者該數據庫是只讀的。如果事務日志文件被手動刪除或者由于硬件或環境問題而丟失，則可能出現此錯誤。

消息 5181，級別 16，狀態 5，第 39 行

無法重新啟動數據庫“PerfStats_Repair”。將恢復到以前的狀態。

消息 5069，級別 16，狀態 1，第 39 行

ALTER DATABASE 語句失敗。

此時數據庫 PerfStats_repair 數據庫處于“恢復還原”狀態。

步驟四、重建SQL Server 事務日志文件

現在，您會看到，重建 SQL Server 事務日志并不是非常復雜，但是，您必須接受將要丟失數據這一事實。事實上，只有在從備份恢復損壞的數據庫這條路被斷掉之后，您才能選擇使用這種方式。例如，如果一個事務在更新索引，并且更新操作執行了一個頁拆分，你可能丟失之前提交的事務，因為頁拆分是要進行日志記錄的，而這一記錄會因為日志文件的丟失而消失。

下面是恢復數據庫的腳本：

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

第一個DBCC 命令是將所有的輸出展示在查詢結果中，而不是記錄在錯誤日志中。接下來兩個腳本將數據庫分別置于緊急模式和單用戶模式，這是我們執行 DBCC CHECKDB 的 REPAIR_ALLOW_DATA_LOSS 選項的前提。最后一句腳本是將數據庫恢復多用戶模式。

下圖框起來的部分說明錯誤日志已經重建了：

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

無法重新生成日志，原因是數據庫關閉時存在打開的事務/用戶，該數據庫沒有檢查點或者該數據庫是只讀的。如果事務日志文件被手動刪除或者由于硬件或環境問題而丟失，則可能出現此錯誤。

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

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

至此，數據庫已經恢復完成。

寫在最后，完成數據庫備份策略必不可少，備份、備份，還是備份！！！