解决方法:
       对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了。但是唯一遗憾的是,不支持2008及更高版本,这时除了其他第三方工具,那么最常用的就是本文提到的方法——日志尾部备份。本文实验环境2008R2,对于2008及其以上版本可以使用这个方法,其实2005也可以,2000很少用,没试过,只是2008之前可以使用Log Exploer,所以就没必要用这种方法。

下面图文并茂讲解操作方法,至于原理,不属于本文范围,而且我相信真遇到误操作的时候,估计没人会看原理了。

步骤:
(1)、检查数据库的恢复模式,如图:

或者使用脚本检查:

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

结果如下:

确保数据库的恢复模式最起码不能为【简单】。至于如何修改成完整模式,我觉得这些应该没必要多说了。

切记,对于任何重要环境,不仅仅是客户正式环境(俗称生产环境),都强烈建议使用【完整恢复模式】,虽然对于另外两种(大容量日志(BULK_LOGGED)、简单(SIMPLE))来说,完整恢复模式产生的日志会大,但是在出现问题的时候,就会觉得这些都不算什么了。并且我也想不到任何理由对于正式环境不使用完整恢复模式。只要管理得当,完整恢复模式的日志也不会太变态。

(2)、这里其实隐含另外一步,曾经做过最少一次的完整备份。因为所有类型的备份都基于完整备份,如果没有最少一次完整备份,其他类型的备份都是多余的,所以在这里强调一下,在创建完一个新数据库之后,强烈建议甚至强制做一次完整备份。

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

使用上面的语句粗略可以看到有那些数据库做过备份,由于测试,所以做了几次备份,可以看到我这个时间点已经做了备份了。

(3)、确保别人不再连接数据库,然后做一次日志尾部备份:

首先先创建一点数据:

/*
由于tempdb永远为简单恢复模式,所以不适合做案例。
这里使用微软的示例数据库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)
);
--插入测试数据:
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
检查一下结果:

然后来做个删除操作,为了定位是啥时候发生的,我加了一个waitfor命令,让它在某个时间发生,这样恢复的时候就有准确性:

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

现在来看看数据:

USE AdventureWorks
GO
SELECT * FROM dbo.testRestore

到这一步,灾难出现了。但是切记要冷静。

下面就是本文的重点开始,做一次日志备份,最重要是选择【备份日志尾部】

然后在【选项】页选择:除【事务日志】除,其他红框包裹的地方为强烈建议勾选的地方。并且保证数据库不要有别人在连接,因为备份日志尾部会使数据库处于还原状态,拒绝其他会话的连接,如果不断开其他连接,是备份不了的。

然后按确定,当然,可以使用上方的【脚本】来生成语句:

USE Master
GO
BACKUP LOG [AdventureWorks] TO DISK = N'E:\AdventureWorks.bak' WITH NO_TRUNCATE , NOFORMAT, NOINIT, NAME = N'AdventureWorks-事务日志 备份', 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'验证失败。找不到数据库“AdventureWorks”的备份信息。', 16, 1) end
RESTORE VERIFYONLY FROM DISK = N'E:\AdventureWorks.bak' WITH FILE = @backupSetId, NOUNLOAD, NOREWIND
GO

此时,数据库会处于【正在还原】的状态

如果发现备份不了可以用下面语句查看,并把spid杀掉:

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

执行结果:

然后kill掉。

接着继续备份。

然后进行还原,如图:

先要还原完整备份,选择最近的那次,由于日志备份的特性(以后其他文章再说),只认最后一次备份,所以要选择最新的那次,否则还原不了。

这里又有一个注意事项,记得选择:

接着还原日志文件,这是最最重要的一步:

然后:

由于实验的时候出了点问题,后面重做了,所以时间选择到22:19分,我是在22:20分删除数据的。这里不用太在意,只要把时间点指定到你误删除的时间之前即可。而由于日志尾部备份都是最后一个备份文件,所以这里选则红框部分即可:

现在再检查一下:

可以看到,数据已经还原成功。
---------------------
作者:發糞塗牆
来源:CSDN
原文:https://blog.csdn.net/dba_huangzj/article/details/8491327
版权声明:本文为博主原创文章,转载请附上博文链接!

SQLServer 2008以上误操作数据库恢复方法的更多相关文章

  1. SQLServer 2008以上误操作数据库恢复方法——日志尾部备份(转)

    问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这 ...

  2. [转]SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

    原文出处:http://blog.csdn.net/dba_huangzj/article/details/8491327 问题: 经常看到有人误删数据,或者误操作,特别是update和delete的 ...

  3. SQLServer 2008以上误操作数据库恢复方法—日志尾部备份

    原文出处:http://blog.csdn.net/dba_huangzj/article/details/8491327 问题: 经常看到有人误删数据,或者误操作,特别是update和delete的 ...

  4. SQL Server 2008以上误操作数据库恢复方法——日志尾部备份

    原文出处:http://blog.csdn.net/dba_huangzj/article/details/8491327 问题: 经常看到有人误删数据,或者误操作,特别是update和delete的 ...

  5. binlog2sql实现MySQL误操作的恢复

    对于MySQL数据库中的误操作删除数据的恢复问题,可以使用基于MySQL中binlog做到类似于闪回或者生成反向操作的SQL语句来实现,是MySQL中一个非常实用的功能.原理不难理解,基于MySQL的 ...

  6. MySQL binlog2sql实现MySQL误操作的恢复

    对于MySQL数据库中的误操作删除数据的恢复问题,可以使用基于MySQL中binlog做到类似于闪回或者生成反向操作的SQL语句来实现,是MySQL中一个非常实用的功能.原理不难理解,基于MySQL的 ...

  7. 用ADO操作数据库的方法步骤(ZT)

    http://www.cppblog.com/changshoumeng/articles/113437.html 学习ADO时总结的一些经验 用ADO操作数据库的方法步骤 ADO接口简介 ADO库包 ...

  8. 摘:用ADO操作数据库的方法步骤

    用ADO操作数据库的方法步骤 ADO接口简介 ADO库包含三个基本接口:_ConnectionPtr接口._CommandPtr接口和_RecordsetPtr接口. _ConnectionPtr接口 ...

  9. 用ADO操作数据库的方法步骤

    用ADO操作数据库的方法步骤 学习ADO时总结的一些经验 - 技术成就梦想 - 51CTO技术博客 http://freetoskey.blog.51cto.com/1355382/989218   ...

随机推荐

  1. sqlite3使用总结(转并且修改)

    此文来自http://blog.csdn.net/shengfang666/article/details/7937200,我在这儿重新发一下,备份参考. 前序:一.       版本二.       ...

  2. Web版记账本开发记录(一)代码和功能展示

    一丶基本机构 数据库截图 record表 年份表 index.jsp <%@ page language="java" contentType="text/html ...

  3. 长时间关机测试脚本.VBS

    Sub Main Dim cnt Dim delay Dim time Dim atttime atttime = 20 delay = 3000 time = 50 cnt_time=3 crt.s ...

  4. KXO151 Programming & Problem Solving

    Page 1 of 9KXO151 Programming & Problem SolvingAIEN-SOU - 2019Assignment 2Deadline for Submissio ...

  5. 监听器 Listener

    监听器:监听某个对象状态的变化 被监听的对象:request.session.servletContext 监听对象的创建和销毁/对象属性的变化 ServletContext HttpSession ...

  6. centos7 + php7

    安装php7 https://www.zntec.cn/archives/centos7-lamp.html composer安装tp curl -sS https://getcomposer.org ...

  7. mysql统计库下所有表数据行数

    一.执行下面sql select concat( 'select "', TABLE_name, '", count(*) from ', TABLE_SCHEMA, '.', T ...

  8. Android系统裁剪:手把手教你如何进行系统裁剪

    前言:android系统裁剪优化一直是各个厂商定制产品的关键步骤,包括浅层次的去除不必要的apk(android apk裁剪定制 )和深层次的裁剪整个编译系统和框架层.   android作为开源系统 ...

  9. DateTimeFormat

    中文:星期一,星期二 System.Globalization.CultureInfo.CurrentCulture.DateTimeFormat.GetDayName(DateTime.Now.Da ...

  10. 潜在风险的频次vs潜在风险的严重影响的程度(以及恢复)

    潜在风险的频次vs潜在风险的严重影响的程度 海量数据的存储对于海量数据,不要存在这样的侥幸心理,一定要好好设计你的系统.把数据增长后存储的影响降到最低.面对海量数据,鸡肋的设计必然会导致系统的崩溃. ...