基于时间点恢复数据库stopat

create database newtestdb

use newtestdb
go

drop table t1
go

create table t1 (
id int not null identity(1,1) primary key
,vdate datetime default (getdate())
,name varchar(32)
)

backup database newtestdb to disk=‘c:\newtestdb_ful.bak‘
insert into t1 (name) values (‘aa‘)

insert into t1 (name) values (‘bb‘)
backup log newtestdb to disk=‘c:\newtestdb_1.trn‘ --2016-05-18 13:42:30.767
select getdate()

insert into t1 (name) values (‘cc‘)
backup log newtestdb to disk=‘c:\newtestdb_2.trn‘ --2016-05-18 13:43:59.707
select getdate()

insert into t1 (name) values (‘dd‘)
backup log newtestdb to disk=‘c:\newtestdb_3.trn‘ --2016-05-18 13:45:05.310
select getdate()

insert into t1 (name) values (‘ee‘)
backup log newtestdb to disk=‘c:\newtestdb_4.trn‘ --2016-05-18 13:46:29.783
select getdate()

insert into t1 (name) values (‘ff‘)
backup log newtestdb to disk=‘c:\newtestdb_5.trn‘ --2016-05-18 13:47:21.833
select getdate()

--恢复到dd
use master
go
restore database newtestdb from disk=‘c:\newtestdb_ful.bak‘ with replace,norecovery;
/*
Processed 344 pages for database ‘newtestdb‘, file ‘newtestdb‘ on file 1.
Processed 6 pages for database ‘newtestdb‘, file ‘newtestdb_log‘ on file 1.
RESTORE DATABASE successfully processed 350 pages in 0.025 seconds (109.179 MB/sec).
*/
restore log newtestdb from disk=‘c:\newtestdb_1.trn‘ with replace,norecovery,stopat=‘2016-05-18 13:45:09.310‘;
/*
Processed 0 pages for database ‘newtestdb‘, file ‘newtestdb‘ on file 1.
Processed 7 pages for database ‘newtestdb‘, file ‘newtestdb_log‘ on file 1.
This backup set contains records that were logged before the designated point in time. The database is being left in the restoring state so that more roll forward can be performed.
RESTORE LOG successfully processed 7 pages in 0.008 seconds (6.103 MB/sec).
*/
restore log newtestdb from disk=‘c:\newtestdb_2.trn‘ with replace,norecovery,stopat=‘2016-05-18 13:45:09.310‘;
/*
Processed 0 pages for database ‘newtestdb‘, file ‘newtestdb‘ on file 1.
Processed 1 pages for database ‘newtestdb‘, file ‘newtestdb_log‘ on file 1.
This backup set contains records that were logged before the designated point in time. The database is being left in the restoring state so that more roll forward can be performed.
RESTORE LOG successfully processed 1 pages in 0.006 seconds (0.325 MB/sec).
*/
restore log newtestdb from disk=‘c:\newtestdb_3.trn‘ with replace,norecovery,stopat=‘2016-05-18 13:45:09.310‘;
/*
Processed 0 pages for database ‘newtestdb‘, file ‘newtestdb‘ on file 1.
Processed 1 pages for database ‘newtestdb‘, file ‘newtestdb_log‘ on file 1.
This backup set contains records that were logged before the designated point in time. The database is being left in the restoring state so that more roll forward can be performed.
RESTORE LOG successfully processed 1 pages in 0.006 seconds (0.325 MB/sec).
*/
restore log newtestdb from disk=‘c:\newtestdb_4.trn‘ with replace,norecovery,stopat=‘2016-05-18 13:45:09.310‘;
/*
Processed 0 pages for database ‘newtestdb‘, file ‘newtestdb‘ on file 1.
Processed 1 pages for database ‘newtestdb‘, file ‘newtestdb_log‘ on file 1.
RESTORE LOG successfully processed 1 pages in 0.004 seconds (0.488 MB/sec).
*/
restore log newtestdb from disk=‘c:\newtestdb_5.trn‘ with replace,norecovery,stopat=‘2016-05-18 13:45:09.310‘;
/*
Msg 4305, Level 16, State 1, Line 57
The log in this backup set begins at LSN 34000000022700001, which is too recent to apply to the database. An earlier log backup that includes LSN 34000000022500002 can be restored.
Msg 3013, Level 16, State 1, Line 57
RESTORE LOG is terminating abnormally.
*/

restore database newtestdb with replace,recovery;
/*
RESTORE DATABASE successfully processed 0 pages in 0.086 seconds (0.000 MB/sec).
*/

--成功恢复至dd

select * from newtestdb.dbo.t1

id vdate name
1 2016-05-18 13:41:44.500 aa
2 2016-05-18 13:42:26.767 bb
3 2016-05-18 13:43:57.707 cc
4 2016-05-18 13:45:05.290 dd

时间: 2024-10-09 22:31:56

基于时间点恢复数据库stopat的相关文章

【Oracle】rman基于时间点恢复

rman基于时间点恢复 场景: 由于某研究的误操作,导致财务模块的数据丢失,如何使用rman基于时间点恢复数据. 思路 1.克隆数据库的虚拟机,直接对数据库的数据进行恢复 RMAN> shutdown immediate; RMAN> startup nomount; RMAN> alter database mount; RMAN> run{ set until time "to_date('20190918 22:00:00','yyyymmdd hh24:mi:ss

Oracle 学习之RMAN(十四)恢复实战--基于时间点恢复

1. 我们先做一个全备 RMAN> backup database ; Starting backup at 2015/07/09 13:40:47 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=28 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in b

13. Clustrix 基于时间点恢复

在不太可能发生灾难的情况下,可以在特定数据库.表或整个集群上执行ClustrixDB集群的某个时间点恢复.应该非常小心地处理这一问题. 先决条件 在你可以使用时间点恢复之前,你的集群应该有几个先决条件: ClustrixDB并行备份的二进制备份应该是可用的.有关此功能的更多信息,请参见ClustrixDB快速备份和恢复.https://www.cnblogs.com/yuxiaohao/p/11956565.html 需要启用binlogging.您可以在配置复制时找到有关启用binlog的信息

xtrabackup全量备份+binlog基于时间点恢复

1.通过xtrabackup的备份恢复数据库. 2.找到start-position和binlog名称 cat xtrabackup_info 3.导出mysqlbinlog为sql文件,并确定恢复的时间点 mysqlbinlog --no-defaults --start-position=51178055 --stop-datetime='2017-05-22 15:30' -vv mysql-bin.000004 > backup2.sql 4.导入sql source backup2.s

Mysql的增量备份 及基于时间点与位置的恢复

增量备份的优点是没有重复数据,备份量不大,时间短.缺点也很明显,需要上次完全备份及完全备份之后所有的增量备份才能恢复,反推恢复,操作较为繁琐. Mysql没有提供增量备份的方法,但是可以通过二进制日志间接实现增量备份. 二进制日志对备份的意义如下:1)二进制日志保存了所有更新或者可能更新数据库的日志文件2)二进制日志在启动Mysql服务器后开始记录,并在文件达到max_binlog_size 所设置的大小或者接收到的flush logs命令后重新创建新的日志文件.3)只需要定时执行flush l

Oracle 基于用户管理恢复的处理

================================ -- Oracle 基于用户管理恢复的处理 --================================ Oracle支持多种方式来管理数据文件的备份与恢复来保证数据库的可靠与完整.除了使用RMAN工具以及第三方备份与恢复工具之外,基于 用户管理的备份与恢复也是DBA经常使用的方式之一.本文首先介绍了恢复的相关概念,接下来详细讲述了在归档模式下使用基于用户管理恢 复的处理过程. 一.恢复的相关概念 介质恢复 首先使用备份还

(转)mysql5.7 根据二进制文件mysqlbinlog恢复数据库 Linux

原文:http://blog.csdn.net/qq_15058425/article/details/61196085 1.开始mysqlbinlog日志功能 先找打my.cnf文件的位置: 2.编辑my.cnf文件,添加如下内容,然后按ecs, wq保存退出 3.这样的话mysqlbinlog功能就打开了.再根据mysql日志恢复数据库 4.查看日志文件,我的日志文件在数据库文件的data目录: 5.通过mysqlbinlog来查看日志文件里面的内容: a.先找到mysqlbinlog的目录

表空间基于时间点的恢复

步骤:1.检测和解决对要恢复的表空间有依赖关系的对象问题select *  from sys.ts_pitr_check where (ts1_name = 'UERS' and ts2_name != 'USERS')    or (ts1_name != 'USERS' and ts2_name = 'USERS');如果有依赖约束,可以考虑disable掉约束:或者同时还原依赖对象所在的表空间 2.检测哪些对象不会被还原如果有些表,在还原后还需要存在,可以使用数据泵等工具导出,等表空间还原

基于时间点的恢复

由于误操作,删除了一张表,那么基于时间点的恢复是没有用的,因为日志里还存在着一些误操作,我们需要恢复到误操作之前的状态,然后跳过误操作,再恢复后面的语句,完成最后的恢复 1 如果10点发生误操作 mysqlbinlog --stop-date='2015-06-15 9:59:59' mysql-bin.000015 | mysql -uroot -p test 2 跳过故障时间点,进行后面的恢复 mysqlbinlog --start-date='2015-06-15 10:00:01' my