SQL Server：無日志恢復數據庫

　　事情的起因
　　
　　昨天系統管理員告訴我我們一個內部應用數據庫所在的磁盤空間不足了我注意到數據庫事件日志文件XXX_Dataldf文件已經增長到了GB於是我決意縮小這個日志文件經過收縮數據庫等操作未果後我犯了一個自進入行業以來的最大最愚蠢的錯誤:竟然誤刪除了這個日志文件!後來我看到所有論及數據庫恢復的文章上都說道:無論如何都要保證數據庫日志文件存在它至關重要甚至微軟甚至有一篇KB文章講如何只靠日志文件恢復數據庫的我真是不知道我那時候是怎麼想的?!
　　
　　這下子壞了!這個數據庫連不上了企業管理器在它的旁邊寫著(置疑)而且最要命的這個數據庫從來沒有備份了我唯一找得到的是遷移半年前的另外一個數據庫服務器應用倒是能用了但是少了許多記錄表和存儲過程真希望這只是一場噩夢!
　　
　　數據庫日志文件的誤刪或別的原因引起數據庫日志的損壞
　　
　　方法一
　　
　　新建一個同名的數據庫
　　
　　再停掉sql server(注意不要分離數據庫)
　　
　　用原數據庫的數據文件覆蓋掉這個新建的數據庫
　　
　　再重啟sql server
　　
　　此時打開企業管理器時會出現置疑先不管執行下面的語句(注意修改其中的數據庫名)
　　
　　完成後一般就可以訪問數據庫中的數據了這時數據庫本身一般還要問題解決辦法是利用
　　
　　數據庫的腳本創建一個新的數據庫並將數據導進去就行了
　　
　　USE MASTER
　　
　　GO
　　
　　SP_CONFIGURE ALLOW UPDATES RECONFIGURE WITH OVERRIDE
　　
　　GO
　　
　　UPDATE SYSDATABASES SET STATUS = WHERE NAME=置疑的數據庫名
　　
　　Go
　　
　　sp_dboption 置疑的數據庫名 single user true
　　
　　Go
　　
　　DBCC CHECKDB(置疑的數據庫名)
　　
　　Go
　　
　　update sysdatabases set status = where name=置疑的數據庫名
　　
　　Go
　　
　　sp_configure allow updates reconfigure with override
　　
　　Go
　　
　　sp_dboption 置疑的數據庫名 single user false
　　
　　Go
　　
　　方法二
　　
　　事情的起因
　　
　　昨天系統管理員告訴我我們一個內部應用數據庫所在的磁盤空間不足了我注意到數據庫事件日志文件XXX_Dataldf文件已經增長到了GB於是我決意縮小這個日志文件經過收縮數據庫等操作未果後我犯了一個自進入行業以來的最大最愚蠢的錯誤:竟然誤刪除了這個日志文件!後來我看到所有論及數據庫恢復的文章上都說道:無論如何都要保證數據庫日志文件存在它至關重要甚至微軟甚至有一篇KB文章講如何只靠日志文件恢復數據庫的我真是不知道我那時候是怎麼想的?!
　　
　　這下子壞了!這個數據庫連不上了企業管理器在它的旁邊寫著(置疑)而且最要命的這個數據庫從來沒有備份了我唯一找得到的是遷移半年前的另外一個數據庫服務器應用倒是能用了但是少了許多記錄表和存儲過程真希望這只是一場噩夢!
　　
　　沒有效果的恢復步驟
　　
　　附加數據庫
　　
　　_Rambo講過被刪除日志文件中不存在活動日志時可以這麼做來恢復:
　　
　　分離被置疑的數據庫可以使用sp_detach_db
　　
　　附加數據庫可以使用sp_attach_single_file_db
　　
　　但是很遺憾執行之後SQL Server質疑數據文件和日志文件不符所以無法附加數據庫數據文件
　　
　　DTS數據導出
　　
　　不行無法讀取XXX數據庫DTS Wizard報告說初始化上下文發生錯誤
　　
　　緊急模式
　　
　　怡紅公子講過沒有日志用於恢復時可以這麼做:
　　
　　把數據庫設置為emergency mode
　　
　　重新建立一個log文件
　　
　　把SQL Server 重新啟動一下
　　
　　把應用數據庫設置成單用戶模式
　　
　　做DBCC CHECKDB
　　
　　如果沒有什麼大問題就可以把數據庫狀態改回去了記得別忘了把系統表的修改選項關掉
　　
　　我實踐了一下把應用數據庫的數據文件移走重新建立一個同名的數據庫XXX然後停掉SQL服務把原來的數據文件再覆蓋回來之後按照怡紅公子的步驟走
　　
　　但是也很遺憾除了第步之外其他步驟執行非常成功可惜重啟SQL Server之後這個應用數據庫仍然是置疑!
　　
　　不過讓我欣慰的是這麼做之後倒是能夠Select數據了讓我大出一口氣只不過組件使用數據庫時報告說:發生錯誤:未能在數據庫 XXX 中運行 BEGIN TRANSACTION因為該數據庫處於回避恢復模式
　　
　　最終成功恢復的全部步驟
　　
　　設置數據庫為緊急模式
　　
　　停掉SQL Server服務;
　　
　　把應用數據庫的數據文件XXX_Datamdf移走;
　　
　　重新建立一個同名的數據庫XXX;
　　
　　停掉SQL服務;
　　
　　把原來的數據文件再覆蓋回來;
　　
　　運行以下語句把該數據庫設置為緊急模式;
　　
　　運行Use Master
　　
　　Go
　　
　　sp_configure allow updates
　　
　　reconfigure with override
　　
　　Go
　　
　　執行結果:
　　
　　DBCC 執行完畢如果 DBCC 輸出了錯誤信息請與系統管理員聯系
　　
　　已將配置選項 allow updates 從 改為 請運行 RECONFIGURE 語句以安裝
　　
　　接著運行update sysdatabases set status = where name = XXX
　　
　　執行結果:
　　
　　(所影響的行數為 行)
　　
　　重啟SQL Server服務;
　　
　　運行以下語句把應用數據庫設置為Single User模式;
　　
　　運行sp_dboption XXX single user true
　　
　　執行結果:
　　
　　命令已成功完成
　　
　　ü 做DBCC CHECKDB;
　　
　　運行DBCC CHECKDB(XXX)
　　
　　執行結果:
　　
　　XXX 的 DBCC 結果
　　
　　sysobjects 的 DBCC 結果
　　
　　對象 sysobjects 有 行這些行位於 頁中
　　
　　sysindexes 的 DBCC 結果
　　
　　對象 sysindexes 有 行這些行位於 頁中
　　
　　syscolumns 的 DBCC 結果
　　
　　………
　　
　　ü 運行以下語句把系統表的修改選項關掉;
　　
　　運行sp_resetstatus XXX
　　
　　go
　　
　　sp_configure allow updates
　　
　　reconfigure with override
　　
　　Go
　　
　　執行結果:
　　
　　在 sysdatabases 中更新數據庫 XXX 的條目之前模式 = 狀態 = (狀態 suspect_bit = )
　　
　　沒有更新 sysdatabases 中的任何行因為已正確地重置了模式和狀態沒有錯誤未進行任何更改
　　
　　DBCC 執行完畢如果 DBCC 輸出了錯誤信息請與系統管理員聯系
　　
　　已將配置選項 allow updates 從 改為 請運行 RECONFIGURE 語句以安裝
　　
　　重新建立另外一個數據庫XXXLost;
　　
　　DTS導出向導
　　
　　運行DTS導出向導;
　　
　　復制源選擇EmergencyMode的數據庫XXX導入到XXXLost;
　　
　　選擇在SQL Server數據庫之間復制對象和數據試了多次好像不行只是復制過來了所有表結構但是沒有數據也沒有視圖和存儲過程而且DTS向導最後報告復制失敗;
　　
　　所以最後選擇從源數據庫復制表和視圖但是後來發現這樣總是只能復制一部分表記錄;
　　
　　於是選擇用一條查詢指定要傳輸的數據缺哪個表記錄就導哪個;
　　
　　視圖和存儲過程是執行SQL語句添加的
　　
　　維護Sql Server中表的索引
　　
　　在使用和創建數據庫索引中經常會碰到一些問題在這裡可以采用一些另類的方法解決…
　　
　　第一步:查看是否需要維護查看掃描密度/Scan Density是否為%
　　
　　declare @table_id int
　　
　　set @table_id=object_id(表名)
　　
　　dbcc showcontig(@table_id)
　　
　　第二步:重構表索引
　　
　　dbcc dbreindex(表名pk_索引名)
　　
　　重做第一步如發現掃描密度/Scan Density還是小於%則重構表的所有索引
　　
　　並不一定能達%
　　
　　dbcc dbreindex(表名)
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22169.html