sqlserver 誤刪除數(shù)據(jù)恢復(fù)：(https://blog.csdn.net/zcj18537150970/article/details/108833211)
原文出處：http://blog.csdn.net/dba_huangzj/article/details/8491327

問題：

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

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

解決方法：

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

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

步驟：

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

或者使用腳本檢查：

SELECT recovery_model,recovery_model_descFROM sys.databasesWHERE name ='AdventureWorks'

結(jié)果如下：

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

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

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

SELECT  database_name,recovery_model,name FROM msdb.dbo.backupset

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

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

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

/*由于tempdb永遠(yuǎn)為簡(jiǎn)單恢復(fù)模式，所以不適合做案例。這里使用微軟的示例數(shù)據(jù)庫AdventureWorks*/USE AdventureWorksGOIF OBJECT_ID('testRestore') IS NOT NULL     DROP TABLE testRestoreGOCREATE 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é)果：

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

USE AdventureWorksGOWAITFOR TIME '21:45'DELETE FROM dbo.testRestore

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

USE AdventureWorksGOSELECT * FROM dbo.testRestore

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

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

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

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

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ù)庫“AdventureWorks”的備份信息。', 16, 1) end
RESTORE VERIFYONLY FROM  DISK = N'E:\AdventureWorks.bak' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO

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

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

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

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

然后kill掉。

接著繼續(xù)備份。

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

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

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

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

然后：

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

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

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

總結(jié)：

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

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

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

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

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

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

關(guān)于備份，可以看我的另外一篇文章：第一篇——第一文 SQL Server 備份基礎(chǔ)文章來源地址http://www.zghlxwxcb.cn/news/detail-496491.html

到了這里，關(guān)于SQL Server 無備份情況下誤操作數(shù)據(jù)恢復(fù)（3）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！