SQL Server無日記恢單數據庫(2種辦法)。本站提示廣大學習愛好者：（SQL Server無日記恢單數據庫(2種辦法)）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server無日記恢單數據庫(2種辦法)正文
SQL Server是一個關系數據庫治理體系，運用很普遍，在停止SQL Server數據庫操作的進程中不免會湧現誤刪或許其余緣由惹起的日記破壞，又因為SQL Server數據庫中數據的主要性，湧現了以上的毛病以後就必需對數據庫中數據停止恢復。下文就為年夜家引見一種恢單數據庫日記文件的辦法。
處理辦法一
1.新建一個同名的數據庫
2.再停失落sql server(留意不要分別數據庫)
3.用原數據庫的數據文件籠罩失落這個新建的數據庫
4.再重啟sql server
5.此時翻開企業治理器時會湧現置疑，先不論，履行上面的語句(留意修正個中的數據庫名)
6.完成後普通便可以拜訪數據庫中的數據了,這時候,數據庫自己普通還要成績,處理方法是,應用
數據庫的劇本創立一個新的數據庫,並將數據導出來就好了.
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的數據庫名'
Go
sp_dboption '置疑的數據庫名', 'single user', 'true'
Go
DBCC CHECKDB('置疑的數據庫名')
Go
update sysdatabases set status =28 where name='置疑的數據庫名'
Go
sp_configure 'allow updates', 0 reconfigure with override
Go
sp_dboption '置疑的數據庫名', 'single user', 'false'
Go
處理辦法二
沒有用果的恢復步調
附加數據庫
_Rambo講過被刪除日記文件中不存在運動日記時，可以這麼做來恢復:
1，分別被置疑的數據庫，可使用sp_detach_db
2，附加數據庫，可使用sp_attach_single_file_db
然則，很遺憾，履行以後，SQL Server質疑數據文件和日記文件不符，所以沒法附加數據庫數據文件。
DTS數據導出
不可，沒法讀取XXX數據庫，DTS Wizard申報說“初始化高低文產生毛病”。
緊迫形式
沒有日記用於恢復時，還可以這麼做:
1，把數據庫設置為emergency mode
2，從新樹立一個log文件
3，把SQL Server 從新啟動一下
4，把運用數據庫設置成單用戶形式
5，做DBCC CHECKDB
6，假如沒有甚麼年夜成績便可以把數據庫狀況改歸去了，記得別忘了把體系表的修正選項關失落
我理論了一下，把運用數據庫的數據文件移走，從新樹立一個同名的數據庫XXX，然後停失落SQL辦事，把本來的數據文件再籠罩回來。以後，依照怡紅令郎的步調走。
然則，也很遺憾，除第2步以外，其他步調履行異常勝利。惋惜，重啟SQL Server以後，這個運用數據庫依然是置疑!
不外，讓我欣喜的是，這麼做以後，卻是可以或許Select數據了，讓我年夜出一口吻。只不外，組件應用數據庫時，申報說:“產生毛病:-2147467259,未能在數據庫 'XXX' 中運轉 BEGIN TRANSACTION，由於該數據庫處於躲避恢復形式。”
終究勝利恢復的全體步調
設置數據庫為緊迫形式
停失落SQL Server辦事;
把運用數據庫的數據文件XXX_Data.mdf移走;
從新樹立一個同名的數據庫XXX;
停失落SQL辦事;
把本來的數據文件再籠罩回來;
運轉以下語句，把該數據庫設置為緊迫形式;
Use Master Go sp_configure 'allow updates', 1 reconfigure with override Go
履行成果:
DBCC 履行終了。假如 DBCC 輸入了毛病信息，請與體系治理員接洽。
已將設置裝備擺設選項 'allow updates' 從 0 改成 1。請運轉 RECONFIGURE 語句以裝置。
接著運轉“update sysdatabases set status = 32768 where name = 'XXX'”
履行成果:
(所影響的行數為 1 行)
重啟SQL Server辦事;
運轉以下語句，把運用數據庫設置為Single User形式;
運轉“sp_dboption 'XXX', 'single user', 'true'”
履行成果:
敕令已勝利完成。
ü 做DBCC CHECKDB;
運轉“DBCC CHECKDB('XXX')”
履行成果:
'XXX' 的 DBCC 成果。
'sysobjects' 的 DBCC 成果。
對象 'sysobjects' 有 273 行，這些行位於 5 頁中。
'sysindexes' 的 DBCC 成果。
對象 'sysindexes' 有 202 行，這些行位於 7 頁中。
'syscolumns' 的 DBCC 成果。
………
ü 運轉以下語句把體系表的修正選項關失落;
運轉
“sp_resetstatus "XXX" go sp_configure 'allow updates', 0 reconfigure with override Go”
履行成果:
在 sysdatabases 中更新數據庫 'XXX' 的條目之前，形式 = 0，狀況 = 28(狀況 suspect_bit = 0)，沒有更新 sysdatabases 中的任何行，由於已准確地重置了形式和狀況。沒有毛病，未停止任何更改。
DBCC 履行終了。假如 DBCC 輸入了毛病信息，請與體系治理員接洽。
已將設置裝備擺設選項 'allow updates' 從 1 改成 0。請運轉 RECONFIGURE 語句以裝置。
從新樹立別的一個數據庫XXX.Lost;
DTS導出領導
運轉DTS導出領導;
復制源選擇EmergencyMode的數據庫XXX，導入到XXX.Lost;
選擇“在SQL Server數據庫之間復制對象和數據”，試了屢次，似乎不可，只是復制過去了一切表構造，然則沒稀有據，也沒有視圖和存儲進程，並且DTS領導最初申報復制掉敗;
所以最初選擇“從源數據庫復制表和視圖”，然則後來發明，如許老是只能復制一部門表記載;
因而選擇“用一條查詢指定要傳輸的數據”，缺哪一個表記載，就導哪一個;
視圖和存儲進程是履行SQL語句添加的。
保護Sql Server中表的索引
在應用和創立數據庫索引中常常會碰著一些成績，在這裡可以采取一些另類的辦法處理…
--第一步:檢查能否須要保護，檢查掃描密度/Scan Density能否為100%
declare @table_id int
set @table_id=object_id('表名')
dbcc showcontig(@table_id)
--第二步:重構表索引
dbcc dbreindex('表名',pk_索引名,100)
--重做第一步，如發明掃描密度/Scan Density照樣小於100%則重構表的一切索引
--其實不必定能達100%
dbcc dbreindex('表名','',100)
這就是我要為年夜家引見的SQL Server數據庫中日記文件的恢復辦法，願望對年夜家可以或許有所贊助。
