SQL Server 数据恢复到指点时间点(完整恢复)
SQL Server 数据恢复到指点时间点(完整恢复)
说到数据库恢复,其实我们一般最常见的有两种,一种就是简单恢复,通过备份的bak文件直接恢复数据库,缺点就是有可能数据丢失。另外一种就是通过备份的数据+事务日志还原数据。但是后者还原的话我们需要保证事务日志的完整性。我们今天就主要介绍的是第二种,所有的操作过程我们使用的是SSMS进行操作的。
注:使用第二种方法还原数据的时候需要注意的问题:1、要准备好之前的完整备份的数据,2、备份全新的事务日志。3、通过完整备份的数据进行完整还原。4、通过备份的全新的事务日志进行指定时间点的数据还原。
我们首先创建一个测试数据库---DB2,然后创建一个表info
定义字段信息
我们插入数据
select * from info insert into info(idcode,age)values('zs',18) insert into info(idcode,age)values('ls',20) insert into info(idcode,age)values('gwl',27)
接下来我们备份数据,备份路劲D:\DB_BACKUP
右击数据库---任务--备份
备份类型:完整。
备份路劲:D:\db_backup\db2.bak
备份完成
备份完成的文件
成功备份后,我们增加几条数据,然后删除几条数据(我们需要注意时间点,方便后面的操作)
此时就当是我们误操作结果;误操作后,我们正常还原了就可以了
需要注意的是,输入的写入和删除有可能是不同的用户进行操作的,所以 通过还原肯定是数据丢失了,所以我们通过完全备份恢复完成后,还需要通过log进行还原。
当前时间时21:32
我们插入了几条数据
select * from info insert into info(idcode,age)values('xll',118) insert into info(idcode,age)values('wc',210) insert into info(idcode,age)values('lc',127)
我们在过几分钟进行数据删除--删除2两条测试数据
当前时间为:
接下来我们删除两条数据
select * from info delete info where idcode = 'ls' delete info where idcode = 'gwl'
此时我们发现数据有异常所以需要通过备份进行还原。但是我们的备份之后,做了一些数据的插入,如果用之前备份的恢复的话,数据肯定有丢失,所以我们还需要借助日志进行还原。
所以我们需要通过完整备份进行恢复,然后通过log进行恢复,然后恢复到指定的时间点。
在恢复完整备份之前,我们需要进行一次全新的事务日志备份。
其实备份事务日志的目录是为了将其写入截断,保证数据的完整性
数据库---右击--任务---备份---备份类型--事务日志
备份成功后
此时我们需要通过完整备份进行还原以下数据
数据库---任务---还原--数据库
选择设备---浏览备份的数据库文件
记住,我们一定要在选项中选择 norecovery
恢复状态:RESTORE WITH NORECOVERY
开始还原提示以下信息:
我们也可以使用以下脚本进行还原
USE [master] BACKUP LOG [DB2] TO DISK = N'D:\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\DB2_LogBackup_2017-03-19_22-40-40.bak' WITH NOFORMAT, NOINIT, NAME = N'DB2_LogBackup_2017-03-19_22-40-40', NOSKIP, NOREWIND, NOUNLOAD, NORECOVERY , STATS = 5 RESTORE DATABASE [DB2] FROM DISK = N'D:\DB_BACKUP\DB2.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5 GO
出现以上问题,我们有两种解决方法
1、还原数据库时,点击选择页上的选项,勾选覆盖现有数据库(WITH REPLACE),点确定后即可成功还原数据库(推荐此方法)。
2、进行还原操作时,点击选择页上的选项,勾选保持源数据库处于正在还原状态(BACKUP LOG WITH NORECOVERY),即可解决问题。
我们选择第二种方法可以正常恢复成功
此时我们查看到数据库一直再提示---正在还原中,该现象为正常的。
接下来我们要通过事务日志进行数据还原。
数据库---任务---还原---事务日志
浏览到保存的事务日志文件—DB2.trn
然后我们需要选择删除数据的日期及时间:我们上面记载了删除数据的日期及时间 21:36
此时是恢复数据的主要关键地方。
确认的时间点信息
我们此时需要单击选项菜单:
恢复状态:回滚未提交的事务,使用数据库处理可以使用的状态。无法还原其他事务日志(RESTORE WITH RECOVERY)
我们也可以通过脚本进行数据还原。
RESTORE LOG [DB2] FROM DISK = N'D:\DB_BACKUP\DB.trn' WITH FILE = 1, NOUNLOAD, STATS = 10, STOPAT = N'2017-03-19T21:36:01' GO
还原成功后,数据库状态显示正常
接下来我们查看数据,恢复正常了;

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
一个无线网卡引发的血案
经常听说一个馒头引发血案,今天我要说的是一个无线网卡的故事...... 最近有同事反应无线网卡连接公司网络无法正常连接,但是连接家里的网络是OK了,于是让桌面支持的同事检测了一下,结果他们把系统重新安装了也还是不能够正常连接,为此只能自己出马了; 1、更新驱动至最新版 查看了一下网卡型号为Intel wireless-N 1030 ,于是下载了一个最新的网卡驱动给其安装了Wifi_Intel_Win7_32_VER15312.zip 2、开启无线事件记录功能 采集日志发现以下错误: #Event,Source,Time,Error Severity,Domain,User,Description 1,S24EvMon,05/05/2016 10:22:04,Information,General,SYSTEM,DeviceIoCtrlS24NDIS: (2) Failed to send OID 0xff100055 to driver. Error - 31 2,S24EvMon,05/05/2016 10:22:04,Information,General,SYSTEM,D...
- 下一篇
openstack 扩展开发最佳实践之计算节点高可用
前言:注意是扩展开发,这个词是我杜撰的,大概意思是指基于openstack的rest api做的一些开发,用于辅助相关功能,而不是直接改动openstack内的代码,怎么修改添加openstack各个组件的代码不在此文章内容内。 首先,千万,千万,千万不要用Openstack提供的SDK,原因如下。 一,SDK的相关文档并不健全。 二,版本不够统一,即兼容的问题。 所以不要使用openstack的SDK而是自己查阅openstack的API文档,通过requests库发http请求要比SDK灵活并便捷得多的方式。但是难过的地方在于开头,这也是本章的主要内容。为了使内容更加贴近现实,我们要做的需求是Openstack计算节点的高可用,主题内容如下: 一:解决思路 二:查询相关API 三:组织代码 四:总结 (一)解决思路 其实openstack计算节点高可用的方案应该是不同的厂商有不同解决方案,这里不具体分析各个方案,二是针对笔者自己实现的一个方案的实现讲解。 一,怎样确定计算节点挂了 二,怎样将计算节点上的虚拟机迁移到现存可用的计算节点 三,迁移之后是否应该采取...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS6,7,8上安装Nginx,支持https2.0的开启