『壹』 創建資料庫的日誌文件被記事本程序打來，現在無法載入到sql上了，怎麼恢復被記事本打開的日誌文件
1. Microsoft SQL Server->企業管理器->控制台根目錄->SQL Server組->新建SQL Server 注冊->可用的伺服器添加->windows身份驗證->在現握戚唯有SQL Server組里添加SQL Server->完成
2. 找到圖標下的「資料庫」選項->右鍵,有任務->附加資料庫->選擇要附加資料庫的MDF文件路徑->確定完成
--右鍵段培"資料庫"
--所有任務
--附加資料庫
--選仔陪擇你的.mdf文件名
--確定
--如果提示沒有.ldf文件,是否創建,選擇"是"?
『貳』 sql附加資料庫誤刪除，怎麼恢復
SQL Server中誤刪除數據的恢復本來不是件難事，從事務日誌恢復即可。但是，這個恢復需要有兩個前提條件：
1. 至少有一個誤刪除之前的資料庫完全備份。
2. 資料庫的恢復模式（Recovery mode）是「完整（Full）」。
針對這兩個前提條件，會有三種情況：
情況一、如果這兩個前提條件都存在，通過SQL語句只需三步就能恢復（參考文章），無需藉助第三方工具。
a) 備份當前數握孝蔽據庫的事務日誌：BACKUP LOG [資料庫名] TO disk= N'備份文件名' WITH NORECOVERY
b) 恢復一個誤刪除之前的完全備份：RESTORE DATABASE [資料庫名] FROM DISK = N'完全備份段州文件名' WITH NORECOVERY, REPLACE
c) 將資料庫恢復至誤刪除之慎雀前的時間點：RESTORE LOG [資料庫] FROM DISK = N'第一步的日誌備份文件名' WITH STOPAT = N'誤刪除之前的時間點' , RECOVERY
『叄』 MSSQL無資料庫日誌文件恢復資料庫方法兩則
方法一
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
方法二
事情的起因
昨天，系統管理員告訴我，我們一個內部應用資料庫所在的磁碟空間不足了。我注意到資料庫事件日誌文件XXX_Data.ldf文件已經增長到了3GB，於是我決意縮小這個日誌文件。經過收縮資料庫等操作未果後，我犯了一個自進入行業以來的最大最愚蠢的錯誤：竟然誤刪除了這個日誌文件！後來我看到所有論及資料庫恢復的文章上都說道：「無論如何都要保證資料庫日誌文件存在，它至關重要」，甚至微軟甚至有一篇KB文章講如何只靠日誌文件恢復資料庫的。我真是不知道我那時候是怎麼想的？！
這下子壞了！這個資料庫連不上了，企業管理器在它的旁邊寫著「(置疑)」。而且最要命的，這個資料庫從來沒有備份了。我唯一找得到的是遷移半年前的另外一個資料庫伺服器，應用倒是能用了，但是少了許多記錄、表和存儲過程。真希望這只是一場噩夢！
沒有效果的恢復步驟
附加資料庫
_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語句添加的。
這樣，XXX.Lost資料庫就可以替換原來的應用資料庫了
『肆』 我把SQL資料庫日誌刪除了,現在恢復不了了,,怎麼辦啊~~急呀!!
5.把資料庫設成緊急狀鍵銀態:
在SQL查詢分析器中逐條執行以下語句
sp_configure 'allow'清亮消,1
reconfigure with override
update sysdatabases set status=32768 where name='kmjxc'
6.重建日誌文件（請將路徑換成你的數據文件路徑）
其中「D:\MSSQL$PROD\Data\」為存放資料庫文件的路徑
「KMJXC_log.ldf」為一個新的不存在的文件，在執行以下語句時將自動建立
dbcc rebuild_log('kmjxc','D:\MSSQL$PROD\Data\KMJXC_log.ldf')
7.逐條執行以答知下語句，取消緊急模式
update sysdatabases set status=0 where name='kmjxc'
restore database kmjxc with recovery
sp_configure 'allow',0
reconfigure with override
8.重起sql server
『伍』 SQL Server2005 附加資料庫的時候報錯 事務日誌已滿
日誌文件滿而造成SQL資料庫無法寫入文件時，可用兩種方法：
一種方法：清空日誌。
1．打開查詢分析器，輸入命令
DUMP TRANSACTION 資料庫名 WITH NO_LOG
2.再打開企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮文件--選擇日誌文件--在收縮方式里選擇收縮至XXM,這里會給備世出一個允許收縮到的最小M數,直接輸入這個數,確定就可以了。
另一種方法有一定的風險性，因為SQL SERVER的日誌文件不是即時寫入資料庫主文件的，如處理不判神當，會造成數據的損失。
1: 刪除LOG
分離資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞分離資料庫
2：刪除LOG文件
附加資料庫 企業管理器－＞伺服器－＞資料庫－＞右鍵－＞附加資料庫
此法生成新的掘滾虧LOG，大小隻有500多K。
注意：建議使用第一種方法。
如果以後,不想要它變大。
SQL2000下使用：
在資料庫上點右鍵->屬性->選項->故障恢復-模型-選擇-簡單模型。
或用SQL語句：
alter database 資料庫名 set recovery simple
另外，如上圖中資料庫屬性有兩個選項，與事務日誌的增長有關：
Truncate log on checkpoint
(此選項用於SQL7.0，SQL 2000中即故障恢復模型選擇為簡單模型)
當執行CHECKPOINT 命令時如果事務日誌文件超過其大小的70% 則將其內容清除在開發資料庫時時常將此選項設置為True
Auto shrink
定期對資料庫進行檢查當資料庫文件或日誌文件的未用空間超過其大小的25%時，系統將會自動縮減文件使其未用空間等於25% 當文件大小沒有超過其建立時的初始大小時不會縮減文件縮減後的文件也必須大於或等於其初始大小對事務日誌文件的縮減只有在對其作備份時或將Truncate log on checkpoint 選項設為True 時才能進行。
『陸』 SQL2000資料庫被置疑分離後附加報錯 3456:未能恢復日誌記錄
靠，才5分
『柒』 SQL Server：無日誌恢復資料庫
事情的起因 昨天 系統管理員告訴我 我們一個內部應用資料庫所在的磁碟空間不足了 我注意到資料庫事件日誌文件XXX_Data ldf文件已經增長到了 GB 於是我決意縮小這個日誌文件 經過收縮資料庫等操作未果後 我犯了一個自進入行業以來的最大最愚蠢的錯誤:竟然誤刪除了這個日誌文件!後來我看到所有論及資料庫恢復的文章上都說道: 無論如何都要保證資料庫日誌文件存在 它至關重要 甚至微軟甚至有一篇KB文章講如何只靠日誌文件恢復資料庫的 我真是不知道我那時候是怎麼想的?!這下子壞了!這個資料庫連不上了 企業管理器在它的旁邊寫著 (置疑) 而且最要命的 這個資料庫從來沒有備份了 我唯一找得到的是遷移半年前的另外一個資料庫伺服器 應用倒是能用了 但是少了許多記錄 表和存儲過程 真希望這只是一場噩夢!資料庫日誌文件的誤刪或別的原因引起資料庫日誌的損壞 方法一 新睜輪建一個同名的資料庫 再停掉sql server(注意不要分離資料庫) 用原資料庫的數據文件覆蓋掉這個新建的資料庫 再重啟sql server 此時打開企業管理器時會出現置疑 先不管 執行下面的語句(注意修改其中的資料庫名) 完成後一般就可以訪問資料庫中的數據了 這時 資料庫本身一般還要問題 解決辦法是 利用資料庫的腳本創建一個新的資料庫 並將數據導進去就行了 USE MASTERGOSP_CONFIGURE ALLOW UPDATES RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS = WHERE NAME= 置疑的資料庫名 Gosp_dboption 置疑雀臘的資料庫名 single user true GoDBCC CHECKDB( 置疑的資料庫名 )Goupdate sysdatabases set status = where name= 置疑的資料庫名 Gosp_configure allow updates reconfigure with overrideGosp_dboption 置疑的資料庫名 single user false Go 方法二 事情的起因昨天 系統管理員告訴我 我們一個內部應用資料庫所在的磁碟空間不足了 我注意到資料庫事件日誌文件XXX_Data ldf文件已經增長到了 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_Data mdf移走;重新建立一個同名的資料庫XXX;停掉SQL服務;把原來的數據文件再覆蓋回來;運行以下語句 把該資料庫設置為緊急模式;運行 Use MasterGosp_configure allow updates reconfigure with overrideGo 執行結果: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 gosp_configure allow updates reconfigure with overrideGo 執行結果:在 sysdatabases 中更新資料庫 XXX 的條目之前 模式 = 狀態 = (狀態 suspect_bit = ) 沒有更新 sysdatabases 中的任何行 因為已正確地重置了模式和狀態 沒有錯誤 未進行任何更改 DBCC 執行完畢 如果 DBCC 輸出了錯誤信息 請與系統管理員聯系 已將配置選項 allow updates 從 改為 請運行 RECONFIGURE 語句以安裝 重新建立另外一個資料庫XXX Lost;DTS導出向導運行DTS導出向導;復制源選擇EmergencyMode的資料庫XXX 導入到XXX Lost;選擇 在SQL Server資料庫之間復制對象和數據 試了多次 好像不行 只是復制過來了所有表結構 但是沒有數據 也沒有視圖和存儲過程 而且DTS向導最後報告復制失敗;所以最後選擇 從源資料庫復製表和視圖 但是後來發現 這樣總是只能復制一部分表記錄;於是選擇 用一條查詢指定要傳輸的數據 缺哪個表記錄 就導哪個;視圖和存儲過程是執行SQL語句添加的 維護Sql Server中表的索引在使用和創建資料庫索引中經常會碰到一些問題 在這里可以採用一些另類的方法解決… 第一步:查看是否需要維護 查看掃描密度/Scan Density是否為 %declare @table_id intset @table_id=object_id( 表名 )dbcc showcontig(@table_id) 第二步:重構表索引dbcc dbreindex( 表名 pk_索引名 ) 重做第一步 如發現掃描密度/Scan Density還是小於 %則重構表的所有索引 並不一定能達 % dbcc dbreindex( 表名 ) lishixin/Article/program/SQLServer/201311/22169
『捌』 日誌文件丟失或出錯的情況下如何恢復SQL資料庫
1. 新建資料庫（同名）
2. 停掉資料庫
3. 刪除新建資料庫的日誌文件，用要恢復的覆蓋mdf文件
4. 啟動資料庫伺服器
5. 設置資料庫允許直接操作系統表
6. 設置資料庫為緊急修復模式
update sysdatabases set status=-32768 where dbid=DB_ID('dbDataHome')
7. 重建資料庫日誌文件
dbcc rebuild_log('dbDataHome','D:\Data\dbData_Data.LDF')
8. 驗證資料庫一致性（可省略）
dbcc checkdb('dbDataHome')
9．設置資料庫為正常狀態
exec sp_dboption 'dbDataHome','dbo use only','false'
10. 最後一步，我們要將步驟E中設置的「允許對系統目錄直接修改」一項恢復。