經(jīng)?？吹接腥苏`刪數(shù)據(jù)，或者誤操作，特別是update和delete的時(shí)候沒(méi)有加where，然后就喊爹喊娘了。人非圣賢孰能無(wú)過(guò)，做錯(cuò)可以理解，但不能縱容，這個(gè)以后再說(shuō)，現(xiàn)在先來(lái)解決問(wèn)題。

        遇到這種情況，一般都是沒(méi)有做備份，不然也不會(huì)來(lái)發(fā)問(wèn)了。首先要冷靜，否則會(huì)有更大的災(zāi)難。直到你放棄。

解決方法：

       對(duì)于這類問(wèn)題，主要是找回誤操作之前的數(shù)據(jù)，在2008之前，有個(gè)很出名的工具Log Exploer，聽說(shuō)還挺好用的，這個(gè)網(wǎng)上大把教程，這里就不多說(shuō)了。但是唯一遺憾的是，不支持2008及更高版本，這時(shí)除了其他第三方工具，那么最常用的就是本文提到的方法——日志尾部備份。本文實(shí)驗(yàn)環(huán)境2008R2，對(duì)于2008及其以上版本可以使用這個(gè)方法，其實(shí)2005也可以，2000很少用，沒(méi)試過(guò)，只是2008之前可以使用Log Exploer，所以就沒(méi)必要用這種方法。

      下面圖文并茂講解操作方法，至于原理，不屬于本文范圍，而且我相信真遇到誤操作的時(shí)候，估計(jì)沒(méi)人會(huì)看原理了。

步驟：

（1）、檢查數(shù)據(jù)庫(kù)的恢復(fù)模式，如圖：

或者使用腳本檢查：

SELECT recovery_model,recovery_model_desc 
FROM sys.databases 
WHERE name ='

結(jié)果如下：

        確保數(shù)據(jù)庫(kù)的恢復(fù)模式最起碼不能為【簡(jiǎn)單】。至于如何修改成完整模式，我覺(jué)得這些應(yīng)該沒(méi)必要多說(shuō)了。 

       切記，對(duì)于任何重要環(huán)境，不僅僅是客戶正式環(huán)境（俗稱生產(chǎn)環(huán)境），都強(qiáng)烈建議使用【完整恢復(fù)模式】，雖然對(duì)于另外兩種（大容量日志（BULK_LOGGED）、簡(jiǎn)單（SIMPLE））來(lái)說(shuō)，完整恢復(fù)模式產(chǎn)生的日志會(huì)大，但是在出現(xiàn)問(wèn)題的時(shí)候，就會(huì)覺(jué)得這些都不算什么了。并且我也想不到任何理由對(duì)于正式環(huán)境不使用完整恢復(fù)模式。只要管理得當(dāng)，完整恢復(fù)模式的日志也不會(huì)太變態(tài)。 

（2）、這里其實(shí)隱含另外一步，曾經(jīng)做過(guò)最少一次的完整備份。因?yàn)樗蓄愋偷膫浞荻蓟谕暾麄浞荩绻麤](méi)有最少一次完整備份，其他類型的備份都是多余的，所以在這里強(qiáng)調(diào)一下，在創(chuàng)建完一個(gè)新數(shù)據(jù)庫(kù)之后，強(qiáng)烈建議甚至強(qiáng)制做一次完整備份。

SELECT database_name,recovery_model,name 
FROM ms

使用上面的語(yǔ)句粗略可以看到有那些數(shù)據(jù)庫(kù)做過(guò)備份，由于測(cè)試，所以做了幾次備份，可以看到我這個(gè)時(shí)間點(diǎn)已經(jīng)做了備份了。

（3）、確保別人不再連接數(shù)據(jù)庫(kù)，然后做一次日志尾部備份：

首先先創(chuàng)建一點(diǎn)數(shù)據(jù)：

由于tempdb永遠(yuǎn)為簡(jiǎn)單恢復(fù)模式，所以不適合做案例。 
這里使用微軟的示例數(shù)據(jù)庫(kù)AdventureWorks 

*/ 
USE AdventureWorks 
GO 
IF OBJECT_ID('testRestore') IS NOT NULL 
 DROP TABLE testRestore 
GO 
CREATE TABLE testRestore 
 ( 
  id INT IDENTITY(1, 1) , 
  NAME VARCHAR(50) 
 ); 
--插入測(cè)試數(shù)據(jù)：  
INSERT INTO testRestore(Name) 
SELECT 'test1' 
UNION ALL 
SELECT 'test2' 
UNION ALL 
SELECT 'test3' 
UNION ALL 
SELECT 'test4' 
UNION ALL 
SELECT 'test5' 
UNION ALL 
SELECT 'test6' 
UNION ALL 
SELECT 'test7' 
UNION ALL 
SELECT 'test8' 
SELECT * FROM testRestore 

檢查一下結(jié)果：

然后來(lái)做個(gè)刪除操作，為了定位是啥時(shí)候發(fā)生的，我加了一個(gè)waitfor命令，讓它在某個(gè)時(shí)間發(fā)生，這樣恢復(fù)的時(shí)候就有準(zhǔn)確性：

USE AdventureWorks 
GO 
WAITFOR TIME '21:45' 
DELETE FROM dbo.testRestore 

現(xiàn)在來(lái)看看數(shù)據(jù)：

USE AdventureWorks 
GO 
SELECT * FROM dbo.testRestore 

到這一步，災(zāi)難出現(xiàn)了，但是切記要冷靜。

下面就是本文的重點(diǎn)開始，做一次日志備份，最重要是選擇【備份日志尾部】

然后在【選項(xiàng)】頁(yè)選擇：除【事務(wù)日志】除，其他紅框包裹的地方為強(qiáng)烈建議勾選的地方。并且保證數(shù)據(jù)庫(kù)不要有別人在連接，因?yàn)閭浞萑罩疚膊繒?huì)使數(shù)據(jù)庫(kù)處于還原狀態(tài)，拒絕其他會(huì)話的連接，如果不斷開其他連接，是備份不了的。

然后按確定，當(dāng)然，可以使用上方的【腳本】來(lái)生成語(yǔ)句：

USE Master 
GO 
BACKUP LOG [AdventureWorks] TO DISK = N'E:\AdventureWorks.bak' WITH NO_TRUNCATE , NOFORMAT, NOINIT, NAME = N'AdventureWorks-事務(wù)日志 備份', SKIP, NOREWIND, NOUNLOAD, NORECOVERY , COMPRESSION, STATS = 10, CHECKSUM 
GO 
declare @backupSetId as int 
select @backupSetId = position from msdb..backupset where database_name=N'AdventureWorks' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'AdventureWorks' ) 
if @backupSetId is null begin raiserror(N'驗(yàn)證失敗。找不到數(shù)據(jù)庫(kù)“AdventureWorks”的備份信息。', 16, 1) end 
RESTORE VERIFYONLY FROM DISK = N'E:\AdventureWorks.bak' WITH FILE = @backupSetId, NOUNLOAD, NOREWIND 
GO 

此時(shí)，數(shù)據(jù)庫(kù)會(huì)處于【正在還原】的狀態(tài)

如果發(fā)現(xiàn)備份不了可以用下面語(yǔ)句查看，并把spid殺掉：

SELECT  * FROM sys.sysprocesses WHERE dbid=DB_ID('AdventureWorks') 

執(zhí)行結(jié)果：

然后kill掉。

接著繼續(xù)備份。

 然后進(jìn)行還原，如圖：

先要還原完整備份，選擇最近的那次，由于日志備份的特性（以后其他文章再說(shuō)），只認(rèn)最后一次備份，所以要選擇最新的那次，否則還原不了。

這里又有一個(gè)注意事項(xiàng)，記得選擇：

接著還原日志文件，這是最最重要的一步：

然后：

由于實(shí)驗(yàn)的時(shí)候出了點(diǎn)問(wèn)題，后面重做了，所以時(shí)間選擇到22：19分，我是在22：20分刪除數(shù)據(jù)的。這里不用太在意，只要把時(shí)間點(diǎn)指定到你誤刪除的時(shí)間之前即可。而由于日志尾部備份都是最后一個(gè)備份文件，所以這里選則紅框部分即可：

現(xiàn)在再檢查一下：

可以看到，數(shù)據(jù)已經(jīng)還原成功。

總結(jié)：

平時(shí)不做備份，出問(wèn)題來(lái)喊急，這是茍有自取，還有一些腦袋發(fā)熱的人喜歡看到ldf很大就直接刪除，那以后出問(wèn)題就別怪微軟了。

本文中的方法看上去有點(diǎn)繁瑣，但是實(shí)操幾次就覺(jué)得好了，但是步驟建議嚴(yán)格按照上面說(shuō)的，因?yàn)橐坏┎僮麇e(cuò)誤，就很麻煩，此時(shí)再次強(qiáng)調(diào)——冷靜冷靜再冷靜?。。。。?！

這種方法有幾個(gè)缺點(diǎn)：

1、如果你發(fā)現(xiàn)誤操作以后還有很多人做了操作，那么你還原成功后，別人的操作就會(huì)沖掉，所以發(fā)生誤操作后，要馬上停止別人對(duì)數(shù)據(jù)庫(kù)的操作。

2、 這個(gè)方法要對(duì)數(shù)據(jù)庫(kù)獨(dú)占，所以你想偷偷恢復(fù)是不行的了。勇敢承認(rèn)錯(cuò)誤吧。

對(duì)于核心數(shù)據(jù)表，還是要先做好預(yù)防操作，可以看：SQLServer恢復(fù)表級(jí)數(shù)據(jù)。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助。