win10系统不同的还原方式所要使用的时间不同:
1、只还原C盘部分所要使用的时间很短,约一小时左右。
2、还原所有文件(释放镜像),约5到6小时。
3、还原点还原,约4到5小时。
还原点提供与闪回数据库和其他介质恢复 *** 作相关的功能。 特别是,在系统改变号(SCN)上创建的保证还原点可以使用闪回数据库将数据库回滚到此SCN。 还原点功能和闪回数据库功能可以单独使用,也可以一起使用。
扩展资料
保证还原点与正常还原点一样充当恢复 *** 作中SCN的别名。 主要区别在于保证的还原点永远不会超出控制文件的范围,必须明确删除。它的使用和正常还原点没有区别。
需要注意的是,无论是否启动了闪回数据库功能,保证还原点都可以使用闪回数据库将数据库回滚到还原点SCN的状态。 如果启用了闪回日志记录,则保证还原点会强制保留从最早的保证还原点之后,闪回数据库闪回到任意SCN所需的闪回日志。
因此,如果启用了闪回日志记录,则可以将数据库闪回到开启保证还原点以后的任何SCN,而不是仅闪回到单个SCN。
参考资料来源:
百度百科——还原点
首先你要知道依赖关系:
flashback database依赖于:闪回日志
flashback drop依赖于:回收站
flashback table/query依赖于:undo
开启闪回要在mount状态下:
alter system set db_flashback_retention_target=2880 scope=both;
alter database flashback on;
再者你要利用事务号获得undo语句
查看事务号:select versions_xid,empno,ename,sal from tt01
versions between timestamp minvalue and maxvalue
order by empno;
根据得到的事务号查看undo_sql语句:
select undo_sql from flashback_transaction_query
where xid='versions_xid' //这里的XID就是上面查询到的versions_xid
如果只是闪回误删除的表:
flashback table TT01 to before drop;
闪回的是最近删除的一张表,当然也可以根据情况自定义闪回误删的表
步骤:
查看DB回收站内容:show recyclebin;
在里面可以查看到删除的表,根据里面的recyclebin name可以来查看表结构
比如:desc "BIN$3naDFKEKFIDISB332DI"
这里说点自己的理解,不写那些名词解释了。
闪回功能和回收站并不一样。
举例来说,闪回一般 *** 作就是短时间内的恢复(DML *** 作,个人感觉类似于win的ctrl+z(不过没有win的好用))。比如说你刚刚删除了数据,那么利用闪回功能可以回到删除之前。但是如果表的交易量很大,或者时间过长,那么就不能回到你需要的时间(比如你想回到一天前,那闪回是基本不可能实现的)
回收站则不同,它主要是删除段的放置空间。和windows的回收站一个意思(什么见过回收站能还原一段在word中删除的内容的),就是将删除的段放置在这里。oracle中drop的段(主要是表),如果不加purge(加了就是彻底删除),那么就会放置在回收站中,就好像我们在win系统中的删除,如果直接删除一个文件,那么在回收站中,如果是shift+del那么就是彻底删除,不可恢复。
其实回收站的表是可以看到的,就是那些一堆乱码(BIN$开头的字符串)表名的表。可以用show recyclebin查到,也可以zairecyclebin的视图中看到。
rollback是针对事务的,你如果没有在执行语句之前开启事务,那么无法rollback,建议你还是想别的办法吧,事务语句如下(sqlserver的给你借鉴):
--开启事务
begin tran
--执行 *** 作
update Accounts_UsersExp set TelPhone=123456 where userid=14
--执行错误事务回滚
rollback
--如果正确进行事务提交
commit
可以勾选一句执行一句,但是commit了就不能rollback
是oracle数据库吗,删除多长时间了?
恢复两个小时之前的数据,注意使用管理员登录系统:
select
from
表名
as
of
timestamp
sysdate-1/12
//查询两个小时前的某表数据!既然两小时以前的数据都得到了,继续怎么做,知道了吧。
如果drop了表,怎么办?可以闪回:
drop
table
表名;
数据库误删除表之后恢复,不过要记得删除了哪些表名。
flashback
table
表名
to
before
drop;
注意:数据库版本是10g,不过大部分9i的也适用,闪回9i就没有
在不开归档日志的情况下,Oracle数据库的备份只能依赖exp命令(逻辑备份)导出数据文件(注意:不包括日志文件以及控制文件等),导出的所有数据仅仅以一个大文件的方式来存放,但是这种备份容易导致丢失数据。举个例子:如果5号晚上进行了exp数据导出,但是在6号的运行过程中发生宕机,数据丢失,这个时候从5号备份后一直到6号宕机前的数据将全部丢失(即使将日志文件和控制文件拷出来都无法恢复,因为exp导出的数据无法与这些日志文件一一对应起来恢复)。所以采用exp方式备份数据还是存在很大风险的。
另一种方式就是使用Oracle自带的备份工具rman。一次rman备份(物理备份)的全过程如下:
因为使用rman备份不会产生数据丢失的情况,所以必须有一个全备份的文件,使用rman需要先进行一次全备份,相当于将当前数据库里面的所有文件以及日志都全盘拷贝一份到备份介质中,然后通过归档日志(实时更新的)的记录看每个进程都对数据库做了哪些修改,只要保留了一份物理备份以及物理备份之后的所有归档日志,就能够将数据库恢复到宕机前一刻的状态,将数据丢失降到最低。(每个redo log写满之后就开始写到achive log里面进行归档,这个里面还是有个时间段的,不能做到完全的实时)
不小心Truncate表的事情也是有的, 其中大部份时因为工具连错了库, 从儿跑错了角本 遇到这种事情而没有备份时怎么办呢 首先要停止数据库, 将这个表所在的表空间的文件拷贝出来, 因为Oracle在Truncate只时将相应Segment的第一个块格式化掉了, 而后面的都还存在, 到下次用时到才真正地重新格式化 下面来讲一个Truncate表后进行恢复的例子: SQL> CREATE TABLE T_TRUNCATE AS SELECT FROM TAB;
Table created
SQL> SELECT COUNT() FROM T_TRUNCATE;
COUNT()
----------
14
SQL> ALTER SYSTEM CHECKPOINT;
System altered
SQL> TRUNCATE TABLE T_TRUNCATE;
Table truncated
SQL> ALTER SYSTEM CHECKPOINT;
System altered
在Truncate时只是Segment Header格式化了, 并将Data Object ID换成一个新的值, 我们可以在AUL中用DESC命令来查看:
AUL> desc anysqlt_truncate
Storage(OBJ#=9976 OBJD=9977 TS=4 FILE=4 BLOCK=5235 CLUSTER=0)
No SEQ INT Column Name Type
--- --- --- ----------------------------- ----------------
1 1 1 TNAME VARCHAR2(30) NOT NULL
2 2 2 TABTYPE VARCHAR2(7)
3 3 3 CLUSTERID NUMBER
要恢复这个表的数据, 首先要在AUL中运行SCAN EXTENT命令, 因为Segment Header被格式化了, 所以Extent Map也可能丢失, 而Scan Extent则将扫描整个数据文件并将Extent分配信息写入AULEXTTXT文件:
AUL> SCAN EXTENT FILE 4
2006-12-18 21:32:10
2006-12-18 21:32:24
恢复的关键是要获得这个表原来的Data Object ID, 在这个例子中我在Truncate表后什么也没有做就关闭数据库进行恢复了 从上面的DESC命令可以看出表的Segment Header是(4,5235), 而新的Data Object ID是9977, 老的Data Object ID我们可以从Segment Header的后面一个数据块中得到, 如果这个表有几个Free List Group, 则可能还要再后面几个块 用AUL的ORADUMP命令来看一下后面一个块:
AUL> ORADUMP FILE 4 BLOCK 5236
RDBA=0x01001474(4/5236)=16782452,type=0x06,fmt=0xa2,seq=0x02,flag=0x04
seg/obj=0x000026f8=9976,csc=0x00000006caf5,itc=3,typ=1 - DATA
FLG=0x32, fls=0, nxt=0x01001471(4/5233)=16782449
可以看到原来的Data Object ID是9976, 现在可以恢复了, 先不指定原来的Data Object ID试试
AUL> unload table anysqlt_truncate;
2006-12-18 21:33:37
Unload OBJD=9977 FILE=4 BLOCK=5235 CLUSTER=0
2006-12-18 21:33:37
接下来指定原来的Data Object ID, 再试试
AUL> unload table anysqlt_truncate object 9976;
2006-12-18 21:33:45
Unload OBJD=9976 FILE=4 BLOCK=5235 CLUSTER=0
P_MV_FACT_SALES|TABLE
TIME_DIM|TABLE
FACT_SALES|TABLE
MV_FACT_SALES|TABLE
SEG$|TABLE
NUMTEST|TABLE
T_OBJECTS|TABLE
T_LOBTEST|TABLE
T_INCLOB|TABLE
CF_XXK|TABLE
T_TESTDMP|TABLE
T_CLOBDEMO|TABLE
T_BLOBDEMO|TABLE
T_TRUNCATE|TABLE
2006-12-18 21:33:45
可以看到14条数据全回来了, 当然数据库是复杂的, 如果是一个很大的表, 还是不能保证可以100%恢复的
最近至少看到二次错误地截断(Truncate)表的例子, 并在网上询问如何恢复, 在这儿我给出AUL/MyDUL的解决方案, 下面是我用的一个测试表:
ASQL> DESC TRUNCDEMO
NO# NAME NULLABLE TYPE
--- ----------------- -------- ------------
1 COL1 VARCHAR2(20)
ASQL> SELECT FROM TRUNCDEMO;
COL1
-----
ROW 1
ROW 2
2 rows returned
接下来我们来截断表, 其实这个 *** 作只是重新格式化了段头块(Segment Header), 并分配一个新的数据对象号(Data Object ID), 当然空间分配信息也改了, 除非加了重用空间选项(Reuse Storage) 来看一下这个 *** 作的前后变化:
ASQL> SELECT DATA_OBJECT_ID, OBJECT_NAME FROM USER_OBJECTS;
DATA_OBJECT_ID OBJECT_NAME
-------------- -----------
13676 TRUNCDEMO
1 rows returned
ASQL> truncate table truncdemo;
Truncate Table Succeed
ASQL> SELECT DATA_OBJECT_ID, OBJECT_NAME FROM USER_OBJECTS;
DATA_OBJECT_ID OBJECT_NAME
-------------- -----------
13677 TRUNCDEMO
1 rows returned
由于在System表空间中已经记录了新的信息, 因此用当前的System信息是不能恢复过来的,在AUL/MyDUL中可以当作没有System时的情况来处理,在下面的命令中, 我们用Truncate后的数据对象号就不能进行恢复, 而使用Truncate以前的就可以, 当然空间不能被重新利用了是恢复的前提
AUL> unload object 13676 column varchar file 4;
2006-09-18 22:38:58
ROW 1
ROW 2
2006-09-18 22:39:04
AUL> unload object 13677 column varchar file 4;
2006-09-18 22:39:10
2006-09-18 22:39:10
AUL>
因此在意外发生Truncate后, 如果没有备份可以恢复, 首先要做的事是备份一下当前的文件, 免得空间被重用 而Truncate之前的数据对象号在AUL/MyDUL中是很容易找出来的 到此已经说明了如何恢复Truncate表了
以上就是关于win10使用系统还原点还原需要多久全部的内容,包括:win10使用系统还原点还原需要多久、oracle高级数据库应用,实验报告:数据闪回 使用flashback实现对表、模式以及数据库级误删除进行恢复。、oracle数据库中闪回和回收站不是一个意思吗等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)