本章阐述如何调查不想要的数据库更改,基于Oracle闪回技术和数据库备份选择和执行适合的恢复策略。
本概述描述Oracle闪回技术和数据库时间点恢复的目的和基本概念。
某些情形适合使用时间点恢复或闪回特性来恢复数据库或数据库对象到它在一个以前的时间点的状态。
某些典型的情形包括以下情况:
1)用户错误或损坏移除了需要的数据或带来了损坏的数据。例如,用户或DBA可能错误地删除或更新了一个或多个表的内容,在更新应用程序的过程中清空了仍然需要的数据库对象,或运行一个大批量的更新时中途失败了。
2)数据库升级失败或升级脚本出错。
3)因为没有所有需要的redo日志或增量备份,在介质故障之后完全数据库恢复不成功。
数据库时间点恢复(DBPITR)和闪回特性让你可以恢复数据库到一个先前的时间点。
DBPITR是解决不想要的数据库更改的最基本方法。它有时候称为不完全的恢复,因为它不使用所有可用的redo或完全恢复所有的更改到数据库。在这个情况中,你还原整个数据库备份,然后应用redo日志或增量备份来重建所有更改直到不想要的更改之前的时间点。
如果不想要的数据库更改是大量的但只局限于特定的表空间,那么可以使用表空间时间点恢复来恢复这些表空间到一个早期的SCN,而不受影响的表空间仍然可用。
如果不想要的数据库更改仅限于特定的表或表分区,那么可以使用之前创建的RMAN备份来只恢复这些对象到不想要的更改发生之前的时间点。
Oracle数据库也共同提供一组特性称为闪回技术,支持查看数据过去的状态,在时间上向前移动和向后倒回数据,而不需要从备份中还原数据库。取决于对数据库进行的更改,闪回技术常常可以更快地撤消不想要的更改和对数据库的可用性有更少的影响。
DBPITR在物理层上运行以恢复数据文件到它们在过去的一个目标时间的状态。
在RMAN DBPITR操作中,可以指定一个目标SCN,日志序列,还原点或时间。RMAN从在目标时间之前创建的备份中还原数据库,然后应用增量备份和日志重建在数据文件备份的时间和恢复结束点之间发生的所有更改。当使用SCN指定结束点时,数据库应用redo日志和在每个redo线程或指定的SCN两者中首先发生的那个之后停止。当使用时间来指定结束点时,数据库内部为指定的时间点确认一个合适的SCN和恢复到这个SCN。
如果你的备份策略被恰当地设计和数据库运行在ARCHIVELOG模式,那么DBPITR是在几乎所有环境中的一个选项。给出一个目标SCN,数据文件就从备份中有效还原和恢复而不需要用户的介入。然而,RMAN DBPITR有以下缺点:
1)不能恢复选择的对象到它们早前的状态,只能是整个数据库。
2)整个数据库在DBPITR过程中是不可用的。
3)DBPITR可能是很费时间因为RMAN必须还原所有数据文件。同时,RMAN需要还原redo日志和增量备份来恢复数据文件。如果备份在磁带上,那么这个过程会花更长的时间。
Oracle数据库的闪回特性在大部分它们可用的情况下比介质恢复更高效。可以使用它们来调查数据库过去的状态。
Oracle闪回数据库是DBPITR最有效的可替代方案。
不像其它闪回特性,它在物理层操作和恢复当前的数据文件到它们在过去的一个时间的内容。这个结果与DBPITR相像,包括OPEN RESETLOGS,但闪回数据库通常更快,因为它不需要还原数据文件和相比介质恢复只需要应用有限的redo。
闪回数据库要求有一个快速恢复区域。为了启用闪回数据库的日志,必须设置DB_FALSHBACK_RETENTION_TARGET初始化参数和执行ALTER DATABASE FLASHBACK ON语句。
在正常操作过程中,数据库定期将数据文件块的旧映像写到闪回日志。闪回日志按顺序和经常成批写。在某些方面,闪回日志像持续的备份。数据库自动创建,删除和调整恢复区域中的闪回日志大小。闪回日志不会被归档。你只需要监控闪回日志的性能和决定恢复区域的磁盘空间分配。
当执行闪回数据库操作时,数据库使用闪回日志来访问数据块的过去版本和使用归档redo日志中的某些数据。因此,不能在故障被发现之后启用闪回数据库和再使用闪回数据库来倒回穿过故障。可以使用相关的功能保证还原点来保护数据库在一个固定时间点的内容,比如在紧接着有风险的数据库更改前。
如果在应用少量要求的redo的过程中遇到任何不可恢复的操作,那么会产生逻辑损坏的数据块。当访问这些块时会引起数据库错误。
逻辑闪回特性用来恢复表和它们的内容到一个过去的时间。
逻辑特性是如下所示:
1)闪回表(Flashback Table)
可以恢复一个表或一组表到一个指定的早前的时间点而不用将数据库的任何部分脱机。在很多情况中,闪回表消除执行更复杂的时间点恢复操作的需要。闪回表还原表时自动维护关联的属性比如当前索引,触发器和约束,不需要找到和还原应用程序相关的属性。
2)闪回删除(Flashback Drop)
可以撤销DROP TABLE语句的效果。
所有逻辑闪回特性除了Flashback Drop之外都依赖undo数据。主要被用来为SQL查询提供读一致性和回滚事务,undo记录包含需要重构在过去的时间存在的数据的信息和检查从过去时间以来更改的记录。
Flash Drop依赖一个机制称为回收站(recycle bin),数据库用它来管理删除的数据库对象直到它们占用的空间用于新数据为止。没有固定数量的空间被分配给回收站,删除的对象在回收桶保留多长时间没有保证。取决于系统的活动情况,删除的对象可能在回收站保留数秒或数月。
闪回表使用undo表空间中的信息而不是还原备份来找回表。当闪回表操作发生时,新的行会被删除,旧的行会被重新插入。当表在在执行闪回时,数据库的其余部分保持可用。
为了执行闪回表操作,表必须符合闪回的条件和执行操作的用户必须具有要求的权限。
必须拥有以下权限来使用闪回表特性:
1)必须已经授予FLASHBACK ANY TABLE系统权限或必须对表具有FLASHBACK对象的权限
2)必须对表有READ或SELECT,INSERT,DELETE和ALTER权限。
3)为了闪回表到还原点,必须具有SELECT ANY DICTIONARY或FLASHBACK ANY TABLE系统权限或SELECT_CATALOG_ROLE角色。
对于符合闪回条件的对象,必须满足以下前提要求:
1)对象必须不包括以下种类:表是集群中的一部分,物化视图,高级队列(AQ)表,静态数据字典表,系统表,远程表,对象表,嵌套表,或个别的表分区或子分区。
2)表结构必须在当前时间和目标闪回时间之间没有被更改。
以下表定义语言(DDL)操作更改了表的结构:升级,移动或清空表;增加约束到表;增加表到集群;修改或删除列;增加,删除,合并(merging),分割,联合(coalescing)或清空分区或子分区(除了增加范围分区之外)。
3)行移动必须在表上启用,这表示在闪回发生之后行ID会更改。
这个限制存在是因为如果行ID在闪回之前由应用程序存储,那么就没有保证行ID在闪回之后对应相同行。如果应用程序依赖于行ID,那么不能使用闪回表。
4)undo表空间中的undo数据必须在时间上向后延伸足够长来满足闪回目标时间或SCN。
可以执行闪回表到哪个时间点由表空间特征和undo保留时间决定,即是undo数据在回收之前保留的最短时间。闪回操作使用undo来重建原始数据。
为了确保为闪回表操作保留undo信息,Oracle建议为undo表空间设置UNDO_RETENTION参数为86400秒(24小时)或更大。
使用SQL语句FLASHBACK TABLE和目标时间或SCN对一个或多个表使用闪回表特性。
假设你在用户做了某些错误的更新之后想对表hr.temp_employees执行闪回,使用以下步骤:
1)确保前面提到的前提要求已经满足。
2)连接SQL*Plus到目标数据库和确认当前的SCN。
你不能回滚FLASHBACK TABLE语句,但可以执行另外一个FLASHBACK TABLE语句和指定一个当前时间以前的时间。因此,建议记录当前的SCN。可以如下所示查询V$DATABASE获取它。
SELECT CURRENT_SCN FROM V$DATABASE;
3) 确认你想恢复表到的时间,SCN或还原点。
如果你已经创建还原点,那么你可以通过执行以下查询列出可用的还原点:
SELECT NAME, SCN, TIME FROM V$RESTORE_POINT;
4)确保存在足够的undo数据倒回表到指定的目标。
如果设置了UNDO_RETENTION初始化参数,undo保留保证是启用的,那么可以使用以下查询确认undo数据保留多少时间:
SELECT NAME, VALUE/60 MINUTES_RETAINED
FROM V$PARAMETER
WHERE NAME = ‘undo_retention’;
5)确保为所有你使用闪回表倒回的对象启用行移动。
可以使用以下语句为表启用行移动:
ALTER TABLE hr.temp_employees ENABLE ROW MOVEMENT;
6)确认你想闪回的表是否依赖于其它表。如果依赖存在,那么决定是否同样也闪回这些表。
可以执行以下SQL查询来确认依赖,其中schema_name是要闪回的表的模式,table_name是表的名称:
SELECT other.owner, other.table_name
FROM sys.all_constraints this, sys.all_constraints other
WHERE this.owner = schema_name
AND this.table_name = table_name
AND this.r_owner = other.owner
AND this.r_constraint_name = other.constraint_name
AND this.constraint_type=‘R’;
7)为要执行闪回的对象执行FLASHBACK TABLE语句。
以下SQL语句恢复表hr.temp_employees到名称为temp_employees_update的还原点:
FLASHBACK TABLE hr.temp_employees
TO RESTORE POINT temp_employees_update;
以下SQL语句倒回hr.temp_employees表到数据库在由SCN指定的时间时它的状态:
FLASHBACK TABLE hr.temp_employees
TO SCN 123456;
如以下示例所示,也可以使用TO_TIMESTAMP指定目标时间点:
FLASHBACK TABLE hr.temp_employees
TO TIMESTAMP TO_TIMESTAMP(‘2013-10-17 09:30:00’, ‘YYYY-MM-DD HH:MI:SS’);
注:时间戳到SCN的映射不总是精确的。当FLASHBACK TABLE语句使用时间戳时,表闪回的时间可能会在指定的时间TO_TIMESTAMP中变化达大约3秒。如果要求精确的时间点,那么使用SCN而不是时间。
8)可选地,查询表来检查数据。
缺省情况下,数据库在执行闪回表操作之前禁用在受影响的表上的触发器。在操作之后,数据库返回触发器到在操作之前的状态(启用或禁用)。
为了在闪回表的过程中保持触发器启用,增加ENABLE TRIGGERS子语句到FLASHBACK TABLE语句。
例如,假设在17:00一个HR管理员发现一个用户在表hr.temp_empolyees中缺失。这个员工在14:00上一次运行报告时还包含在表中。因此,某人在14:00和17:00之间意外删除了这个员工的记录。HR管理员使用闪回表来恢复表到14:00时它的状态,通过使用以下示例中的SQL语句避免破坏在表hr.temp_employees上设置的任何触发器:
FLASHBACK TABLE hr.temp_employees
TO TIMESTAMP TO_TIMESTAMP(‘2013-03-03 14:00:00’ , ‘YYYY-MM-DD HH:MI:SS’)
ENABLE TRIGGERS;
可以使用FLASHBACK TABLE … TO BEFORE DROP语句从回收站中找回对象。
Flashback Drop逆转DROP TABLE操作的效果。Flashback Drop比在这种情形中使用的其它恢复机制比如时间点恢复更快,不会导致停机时间或最近的事务丢失。
当删除表时,数据库不会立即移除与表关联的空间。表被重命名和与任何相关的对象一起放置在回收站中。系统生成的回收站对象名称是唯一的。可以正如查询其它对象一样查询回收站中的对象。
闪回操作从回收站中找回表。当找回删除的表时,可以指定原始的用户指定的表名或系统生成的名称。
当删除一个表时,表和所有依赖它的对象一起进入回收站。类似地,当执行Flashback Drop时,一般全部一起找回对象。当从回收站还原表时,依赖对象比如索引不会找回它们的原始名称;它们保持系统生成的回收站名称。Oracle数据库找回表上定义的除了位图联接索引之外的所有索引,所有触发器,在表上定义的除了引用其它表的引用完整性约束之外的约束。
某些依赖对象比如索引可能由于空间紧张已经被回收。在这些情况中,回收的依赖对象不能从回收站找回。
在执行闪回删除操作前必须满足前提条件。
与闪回删除相关的操作和回收站要求的用户权限如下:
1) DROP,任何在对象上具有DROP权限的用户可以删除对象,将它放置在回收站。
2)FLASHBACK TABLE … TO BEFORE DROP,这个语句的权限与DROP权限绑定,即任何可以删除对象的用户可以执行FLASHBACK DROP从回收站找回删除的对象。
3)PURGE,清除回收站的权限与DROP权限绑定。任何具有DROP TABLE,DROP ANY TABLE或PURGE DBA_RECYCLE_BIN权限的用户可以清除回收站中的对象。
4)回收站中的对象的READ或SELECT和FLASHBACK,用户必须在回收站中的对象上具有READ或SELECT和FLASHBACK权限来查询回收站中的对象。任何在对象被删除前在其上具有READ或SELECT权限的用户继续在回收站中的对象上具有READ或SELECT权限。用户必须具有FLASHBACK权限来查询回收站中的任何对象,因为这些是来自数据库过去状态的对象。
对象必须满足以下前提条件从而符合从回收站中找回的条件:
1)回收站只对非系统,本地管理的表空间可用。如果表在一个非系统,本地管理的表空间中,但一个或多个依赖它的段(对象)是字典管理的表空间,那么这些对象被回收站保护。
2)定义了FGA(fine-grained auditing)和VPD(Virtual Private Database)策略的表不被回收站保护。
3)分区索引组织的表不被回收站保护。
4)表必须没有被用户或空间回收操作过程中被数据库清空。
使用FLASHBACK TABLE … TO BEFORE DROP语句从回收站中恢复对象,可以指定回收站中的表名或原始表名。
本节假设一个错误地删除了表hr.employee_demo的场景。你决定使用FLASHBACK TABLE找回删除的对象。
找回删除的表:
1)确保已满足前面描述的前提条件。
2)连接SQL*Plus到目标数据库和获取回收站中的删除表的名称。
SHOW RECYCLEBIN;
ORIGINAL NAME RECYCLEBIN NAME TYPE DROP TIME
---------------- --------------------------------- ------------ ------------------
EMPLOYEE_DEMO BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 TABLE 2013-04-11:17:08:54
ORIGINAL NAME列显示对象的原始名称,而RECYCLEBIN NAME列显示对象在回收站中存在的名称。
可替代地,可以查询USER_RECYCLEBIN或DBA_RECYCLEBIN来获取表名。以下示例查询RECYCLEBIN视图来确认删除对象的原始名称。
SELECT object_name AS recycle_name, original_name, type
FROM recyclebin;
RECYCLE_NAME ORIGINAL_NAME TYPE
-------------------------------- --------------------- ----------
BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0 EMPLOYEE_DEMO TABLE
BIN$JKS983293M1dsab4gsz/I249==$0 I_EMP_DEMO INDEX
如果计划手动还原依赖对象的原始名称,那么在还原表前请确保记录下每个依赖对象的系统生成的回收站名称。
注:对象视图比如DBA_TABLES不显示回收站对象。
3)可选地,查询回收站中的表。
必须在查询中使用对象的回收站名称而不是对象的原始名称。以下示例使用回收站名称查询表:
SELECT * FROM “BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0”;
由于回收站名称中的特定字符,因此需要用双引号标记。
4)找回删除的表。
以下示例还原表BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0,更改它的名称回hr.employee_demo,从回收站中清除它的条目:
FLASHBACK TABLE “BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0” TO BEFORE DROP;
由于特殊字符可能出现在回收站对象名称中,因此表名被包围在双引号中。
或者,使用表的原始名称:
FLASHBACK TABLE HR.EMPLOYEE_DEMO TO BEFORE DROP;
也可以通过指定RENAME TO子语句分配一个新名称给还原的表:
FLASHBACK TABLE “BIN$gk3lsj/3akk5hg3j2lkl5j3d==$0” TO BEFORE DROP
RENAME TO hr.emp_demo;
5)可选地,核实表的所有依赖对象保留它们的系统生成的回收站名称。
以下查询确认找回表hr.employee_demo的索引的名称:
SELECT INDEX_NAME
FROM USER_INDEXES
WHERE TABLE_NAME = ‘EMPLOYEE_DEMO’;
INDEX_NAME
------------------------------
BIN$JKS983293M1dsab4gsz/I249==$0
6)可选地,重命名找回的索引到它们的原始名称。
ALTER INDEX “BIN$JKS983293M1dsab4gsz/I249==$0” RENAME TO I_EMP_DEMO;
7)如果找回的表在放置在回收站前有引用约束,那么重建它们。
这个步骤必须手动执行,因为回收站没有保留表的引用约束。
可以创建,然后删除使用相同名称的多个对象。所有删除的对象保存在回收站中。
例如,探讨以下示例中的SQL语句:
CREATE TABLE temp_employees ( …columns ); # temp_employees version 1
DROP TABLE temp_employees;
CREATE TABLE temp_employees ( …columns ); # temp_employees version 2
DROP TABLE temp_employees;
CREATE TABLE temp_employees ( …columns ); # temp_employees version 3
DROP TABLE temp_employees;
当被删除时,每个表temp_employees在回收站中被分配一个唯一的名称。可以使用FLASHBACK TABLE … TO BEFORE DROP语句和原始的表名,如下所示:
FLASHBACK TABLE temp_employees TO BEFORE DROP;
最近被删除使用这个原始名称的表会连同原始名称从回收站中找回。
以下示例显示从回收站中找回所有3个在前面示例中被删除的表temp_emplyees,每个分配一个新名称。
FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_3;
FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_2;
FLASHBACK TABLE temp_employees TO BEFORE DROP
RENAME TO temp_employees_VERSION_1;
因为在FLASHBACK TABLE中的原始名称指向最近被删除的表,最后被删除的表首先被找回。
通过使用表的唯一的回收站名称,你也可以找回回收站中的任何表,不管原始名称之中有任何冲突。例如,假设查询回收站的结果如下所示:
SELECT object_name, original_name, createtime
FROM recyclebin;
OBJECT_NAME ORIGINAL_NAME CREATETIME
------------------------------ --------------- -------------------
BIN$yrMKlZaLMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES 2013-02-05:21:05:52
BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES 2013-02-05:21:25:13
BIN$yrMKlZaQMhfgNAgAIMenRA==$0 TEMP_EMPLOYEES 2013-02-05:22:05:53
可以使用以下命令来找回中间的表:
FLASHBACK TABLE BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TO BEFORE DROP;
闪回数据库通过返回数据库到它在之前的一个时间点的状态来撤销不想要的更改。
闪回数据库通过撤销对运行命令时存在的数据文件的更改来运行。必须满足前提条件来执行闪回数据库操作。
为了使用FLASHBACK DATABASE命令返回数据库的内容到闪回窗口内的时间点,数据库必须先配置闪回日志。为返回数据库到一个保证还原点,必须先定义一个保证还原点。
注意以下重要的前提条件:
1)当前的数据文件没有丢失或损坏。只可以使用FLASHBACK DATABASE来倒回Oracle数据库对数据文件的更改,而不是修复介质故障。
2)不要尝试从数据文件意外删除中恢复,撤销数据文件的缩小操作或撤销对数据库名称的更改。
3)不要尝试使用FLASHBACK DATABASE来返回到控制文件还原或重建之前的时间点。如果数据库控制文件是从备份中还原或重建,那么所有累积的闪回日志信息会被丢弃。
4)不要尝试使用FLASHBACK DATABASE来撤销兼容性更改。
闪回数据库操作使用FLASHBACK DATABASE命令来倒回数据库到过去的时间点。
本主题展现执行数据库闪回的一个基本技术,使用时间表达式,正常或保证的还原点名称,或SCN指定期望的目标时间点。假设以下条件:
1)倒回数据库到当前数据库转生内的时间点。
2)在FLASHBACK DATABASE命令中使用的SCN指向数据库转生的直接祖先路径(direct ancestral path)中的SCN。转生在这个路径上如果它在数据库先前使用RESETLOGS选项打开之后没有被抛弃。
执行闪回数据库操作:
1)确保闪回数据库的前提条件都满足。
2)连接SQL*Plus到目标数据库和确认闪回数据库命令期望的SCN,还原点或时间点。
获取闪回数据库窗口最早的SCN:
SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
FROM V$FLASHBACK_DATABASE_LOG;
闪回数据库可以到达的最近的SCN是数据库当前的SCN。以下查询返回当前的SCN:
SELECT CURRENT_SCN FROM V$DATABASE;
查询可用的保证还原点:
SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,GUARANTEE_FLASHBACK_DATABASE
FROM V$RESTORE_POINT
WHERE GUARANTEE_FLASHBACK_DATABASE=‘YES’;
NAME SCN TIME DATABASE_INCARNATION# GUA
--------------- ---------- --------------------- --------------------- -------
BEFORE_CHANGES 5753126 04-MAR-12 12.39.45 AM 2 YES
3)一致性关闭数据库,确保它没有被任何实例打开,然后挂载它:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
4)重复步骤2中的查询。
当数据库关闭时会产生某些闪回日志数据。如果由于快速恢复区域的空间紧张闪回日志被删除,那么目标SCN可能不能到达。
5)启动RMAN,连接到目标数据库。
6)运行SHOW命令来查看预配置了哪些通道。
在闪回操作过程中,RMAN可能需要从备份还原归档redo日志。
SHOW ALL;
如果已经配置必要的设备和通道,那么不需要做任何操作。否则,使用CONFIGURE来配置自动通道,或在RUN块中包含ALLOCATE CHANNEL命令。
7)运行RMAN的FLASHBACK DATABASE命令。
可以使用以下示例中的一种命令格式指定目标时间。
FLASHBACK DATABASE TO SCN 46963;
FLASHBACK DATABASE TO RESTORE POINT BEFORE_CHANGES;
FLASHBACK DATABASE TO TIME “TO_DATE(‘09/20/12’,‘MM/DD/YY’)”;
当FLASHBACK DATABASE命令完成时,数据库留在挂载状态和恢复到指定的目标时间。
8)以只读方式打开数据库,运行某些查询来验证数据库内容。
ALTER DATABASE OPEN READ ONLY;
如果满意数据库的状态,那么使用步骤9结束过程。如果不满意数据库的状态,跳到步骤10。
9)如果满意这个结果,那么执行以下一种互斥的操作:
a.使用RESETLOGS选项打开数据库让数据库可用于更新。如果数据库当前以只读方式打开,那么在SQL*Plus中执行以下命令:
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER DATABASE OPEN RESETLOGS;
注:在执行OPEN RESETLOGS操作之后,所有FLASHBACK DATABASE的目标SCN之后对数据库所做的更改会被丢弃。然而,当它们仍然在闪回窗口中时,可以使用“倒回数据库到丢弃的转生分支中的SCN”来返回数据库到SCN范围。
b.使用Oracle Data Pump Export逻辑备份之前状态是损坏的对象。然后,使用RMAN恢复数据库到当前时间:
RECOVER DATABASE;
这个步骤通过应用所有redo日志中的更改到数据库来撤销闪回数据库的效果,将它返回到最近的SCN。
在重新以读写方式打开数据库之后,可以使用Data Pump Import工具导入之前导出的对象。
10)如果发现闪回使用了错误的还原点,时间,或SCN,那么挂载数据库,执行以下一种互斥的选项:
a.如果选择的目标时间向后不够远,那么使用另外一个闪回命令来倒回数据库更向后:
FLASHBACK DATABASE TO SCN 42963; #earlier than current SCN
b.如果选择的目标SCN向后太远,那么使用RECOVER DATABASE UNTIL将数据库向前滚动到期望的SCN:
RECOVER DATABASE UNTIL SCN 56963; #later than current SCN
c.如果你想完全撤销闪回数据库命令的效果,可以通过使用RECOVER DATABASE不带UNTIL子语句或SET UNTIL 命令执行数据库的完全恢复:
RECOVER DATABASE;
命令RECOVER DATABASE重新应用所有更改到数据库,返回它到最近的SCN。
数据字典视图包含用来监控闪回数据库的信息。
当使用闪回数据库来倒回数据库到一个过去的时间点时,闪回数据库确认哪些块在目标时间之后更改过和从闪回日志中还原它们。这个称为还原阶段。在这个阶段完成后,闪回数据库使用redo日志来重新应用在这些块写到闪回日志之后所做的更改。这个称为恢复阶段。
在还原阶段的闪回数据库进度可以通过查询 V$SESSION_LONGOPS视图监控。opname是Flashback Database。在列TOTALWORK下面是必须读取的闪回日志的数量(MB)。列SOFAR列出当前已经读取的数量(MB)。
SQL> SELECT sofar, totalwork, units FROM v$session_longops WHERE opname =
‘Flashback Database’;
SOFAR TOTALWORK UNITS
----- ---------- --------------------------------
17 60 Megabytes
在恢复阶段闪回数据库的进度可以通过查询V$RECOVERY_PROGRESSS视图监控。
RMAN DBPITR从恢复的目标时间前的备份中还原数据库,然后使用增量备份和redo向前滚动数据库到目标时间。可以恢复到一个SCN,时间,日志序列号,或还原点。Oracle建议在重要的时间点创建还原点,从而在必要的时候让时间点恢复更易管理。
Oracle建议在可能的情况下执行闪回数据库而不是数据库时间点恢复。当闪回技术不能用来撤销最近的更改时,使用备份进行介质恢复是最后的选项。
必须满足某些前提条件来执行数据库时间点恢复(DBPITR)。
它们包括以下:
1)数据库必须运行在ARCHIVELOG模式。
2)必须有所有数据文件在DBPITR的目标SCN之前做的备份和在备份SCN和目标SCN之间的时间段的归档日志。
3)如果使用透明加密创建的备份和如果使用密码保护的软件密钥库,那么必须在还原操作执行之前提供密钥库密码。使用SET命令和DECRYPTION WALLET OPEN IDENTIFIED BY选项来指定必须使用的密码打开基于密码的密钥库。
如果具有SYSBACKUP权限的用户在执行恢复和使用密码保护的软件密钥库,授予SYSKM权限给这个用户。
4)如果使用密码模式加密创建的备份,那么必须在运行RESTORE和RECOVER命令之前提供密码来解密备份。使用SET DECRYPTION IDENTIFIED BY命令来指定用来解密备份的密码。
使用RESTORE和RECOVER命令执行DBPITR。
当执行DBPITR时,可以在步骤开始的时候使用SET UNTIL命令设置目标时间来避免错误,而不是分别在RESTORE和RECOVER命令中指定UNTIL子语句。这确保从备份中还原的数据文件有足够早的时间戳从而在接下来的RECOVER操作中使用。
本节做以下假设:
1)在当前数据库转生中执行DBPITR。如果目标时间不在当前转生中,请参考“恢复数据库到祖先转生(Ancestor Incarnation)”章节来进行DBPITR到祖先转生。
2)控制文件是当前的。如果必须还原备份的控制文件,那么请参考“使用备份的控制文件执行恢复”章节。
3)数据库使用当前的spfile。如果必须还原备份的spfile,那么参考“还原服务器参数文件”章节。
执行时间点恢复:
1) 确保前面描述的前提条件已经满足。
2) 确认结束恢复的时间,SCN,还原点或日志序列。
可以使用闪回查询(Flashback Query)特性来帮助鉴别逻辑损坏什么时候发生。如果为表启用了闪回数据归档,那么可以查询在过去很久的存在的数据。
也可以使用alert日志来尝试确认必须从哪里恢复的事件时间。
或者可以使用SQL查询来确认包含目标SCN的日志序列号,然后恢复通过这个日志。例如,运行以下查询列出当前数据库转生中的日志:
SELECT RECID, STAMP, THREAD#, SEQUENCE#, FIRST_CHANGE#,FIRST_TIME, NEXT_CHANGE#
FROM V$ARCHIVED_LOG
WHERE RESETLOGS_CHANGE# =
(SELECT RESETLOGS_CHANGE#
FROM V$DATABASE_INCARNATION
WHERE STATUS = ‘CURRENT’);
RECID STAMP THREAD# SEQUENCE# FIRST_CHAN FIRST_TIM NEXT_CHANG
---------- ---------- ---------- ---------- ---------- --------- ----------
1 344890611 1 1 20037 24-SEP-13 20043
2 344890615 1 2 20043 24-SEP-13 20045
3 344890618 1 3 20045 24-SEP-13 20046
例如,如果发现用户在9:02a.m.意外删除表空间,那么可以恢复到9a.m.,正好在删除发生前。你会丢失这个时间之后数据库做的所有更改。
3)如果使用目标时间表达式而不是目标SCN,那么确保在调用RMAN之前时间格式环境变量是适合的。
以下是全球化支持设置示例:
NLS_LANG = american_america.us7ascii
NLS_DATE_FORMAT=“Mon DD YYYY HH24:MI:SS”
3) 连接RMAN到目标数据库。如果适用的,连接到恢复目录。
4)将数据库启动到挂载状态:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
5)在一个RUN块中执行以下操作:
a.对于DBPITR,使用SET UNTIL来指定目标时间,SCN或日志序列号,或使用SET设置还原点。如果指定一个时间,那么使用NLS_LANG和NLS_DATE_FORMAT环境变量中指定的日期格式。
b.如果没有配置自动通道,那么手动分配需要的磁盘和磁带通道。
c.还原和恢复数据库。
以下示例在目标数据库上执行DBPITR直到SCN 1000:
RUN
{
SET UNTIL SCN 1000;
RESTORE DATABASE;
RECOVER DATABASE;
}
如上例所示,也可以使用时间表达式,还原点或日志序列号来指定SET UNTIL时间:
SET UNTIL TIME ‘Nov 15 2013 09:00:00’;
SET UNTIL SEQUENCE 9923;
SET TO RESTORE POINT before_update;
如果操作完成没有出现错误,那么DBPITR已经成功。
7)执行以下一种互斥的操作:
a.打开数据库进行读写,丢弃在目标SCN之后的所有更改。在这种情况中,必须先关闭数据库,挂载它,然后执行以下命令:
ALTER DATABASE OPEN RESETLOGS;
如果数据文件脱机(除非数据文件正常脱机或只读),则OPEN RESETLOGS操作失败。可以在RESETLOGS之后将只读的文件或正常脱机的表空间联机,因为它们不需要任何redo。
b.使用Data Pump Export导出一个或多个数据库对象。然后可以恢复数据库到当前的时间点和重新导入导出的对象,这样返回这些对象到它们不想要的更改之前的状态而不用丢弃所有其它更改。
本节描述基本的闪回数据库和DBPITR的变化场景。
闪回数据库可以用来撤销OPEN RESETLOGS操作。
使用闪回数据库撤销不想要的ALTER DATABASE OPEN RESETLOGS语句的过程与在“执行闪回数据库操作”章节中描述的一般情况类似。然而,不是为FLASHBACK DATABASE指定特定的SCN或时间点,而使用FLASHBACK DATABASE TO BEFORE RESETLOGS。
撤销OPEN RESETLOGS操作:
1)连接SQL*Plus到目标数据库,核实闪回窗口的开端比最近的OPEN RESETLOGS时间更早。
SELECT RESETLOGS_CHANGE# FROM V$DATABASE;
SELECT OLDEST_FLASHBACK_SCN FROM V$FLASHBACK_DATABASE_LOG;
如果V$DATABASE.RESETLOGS_CHANGE#比V$FLASHBACK_DATABSAE_LOG.OLDEST_FLASHBACK_SCN更大,那么可以使用闪回数据库逆转OPEN RESETLOGS操作。
2)关闭数据库,挂载它,重新检查闪回窗口。如果resetlogs SCN仍然在闪回窗口内,那么继续下一步骤。
3)连接RMAN到目标数据库。
4)执行闪回到正好在RESETLOGS之前的SCN。
FLASHBACK DATABASE TO BEFORE RESETLOGS;
如同其它FLASHBACK DATABASE的使用一样,如果目标SCN在闪回数据库窗口的开端之前,会返回一个错误,数据库不会修改。如果命令成功完成,那么数据库留在挂载状态和恢复到之前的转生中的OPEN RESETLOGS操作之前的最近的SCN。
5)在SQL*Plus中以只读方式打开数据库,执行需要的查询来确保逻辑损坏的效果已经被逆转。
ALTER DATABASE OPEN READ ONLY;
6)为了让数据库再次可用于更新,关闭数据库,挂载它,然后执行以下命令:
ALTER DATABASE OPEN RESETLOGS;
闪回数据库跨过OPEN RESETLOGS可用于在Data Guard环境中执行多种功能,包括以下:
1)闪回来撤销逻辑备数据库的切换
在这种情况中,闪回数据库操作逆转数据库在目标时间的角色(主或备)。
2)撤销物理备数据库激活
可以临时激活物理备数据库,使用它进行测试或生成报表,然后使用闪回数据库返回它的角色为物理备数据库。
3)持续使用备数据库来测试
闪回数据库的使用意味不需要使用存储快照。
可以使用闪回数据库倒回数据库到一个遗弃的数据库转生。
后面跟着OPEN RESETLOGS的闪回数据库或DBPITR操作是将数据库返回到一个之前的SCN,然后丢弃这个点之后的更改。因此,在这个点之后的某些SCN可以指向丢弃的更改或数据库当前历史中的更改。在这种方式中,在FLASHBACK DATABASE中指定的目标SCN是模棱两可不明确的。
不像SCN,时间表达式和还原点不是模糊的。时间表达式总是与那个时间时是当前的转生相关联。还原点总是与它被创建时的当前转生相关联。即使对于与遗弃的数据库转生对应的时间和还原点也是如此。数据库转生会自动重设为指定时间或还原点被创建时是当前的转生。
你可能想使用闪回数据库倒回数据库到父转生中的一个比当前转生路径从旧转生中分支时的OPEN RESETLOGS操作更后的SCN。下图显示SCN甚至在OPEN RESETLOGS操作创建一个新的转生之后如何在转生分支中产生。如图所示,数据库可能在转生3中的SCN 3000时必须返回转生1中遗弃的SCN 1500。
如果你要倒回的SCN是在直接祖先路径(direct ancestral path)中,或你倒回数据库到一个还原点,那么对于闪回数据库一个明确的RESET DATABASE命令不是必要的。然而,当使用FLASHBACK DATABASE倒回数据库到一个遗弃的数据库转生中的SCN时,一个明确的RESET DATABASE TO INCARNATION命令是必需的。
倒回数据库到一个遗弃的转生分支中的SCN:
1)使用SQL*Plus连接到目标数据库,核实闪回日志包含足够的信息闪回到SCN:
SELECT OLDEST_FLASHBACK_SCN FROM V$FLASHBACK_DATABASE_LOG;
2)确认闪回数据库操作的目标转生序号,即是父转生的转生键。
SELECT PRIOR_INCARNATION#
FROM V$DATABASE_INCARNATION
WHERE STATUS = ‘CURRENT’;
3)启动RMAN,连接到目标数据库。
4)关闭数据库,挂载它:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
5)设置数据库转生到父转生。
例如,使用以下命令返回转生1:
RESET DATABASE TO INCARNATION 1;
6)运行FLASHBACK DATABASE命令,指定目标SCN。
FLASHBACK DATABASE TO SCN 1500;
7)以只读方式打开数据库,执行需要的查询来确保逻辑损坏效果已经被逆转。
ALTER DATABASE OPEN READ ONLY;
8)为了让数据库再次可用于更新,关闭数据库,挂载它和执行以下命令:
ALTER DATABASE OPEN RESETLOGS;
为执行DBPITR到一个非当前的数据库转生,必须明确执行RESET DATABASE来重置数据库到目标SCN时是当前的转生。你也必须从包含目标SCN的数据库转生中还原控制文件。
当RMAN连接到恢复目录时,RESTORE CONTROLFILE命令只搜索当前数据库转生的UNTIL子语句中指定的最接近的时间。为了从非当前转生中还原控制文件,必须执行LIST INCARNATION来鉴别目标数据库转生和在RESET DATABASE TO INCARNATION命令中指定这个转生。
当RMAN没有连接到恢复目录时,在数据库被挂载以前不能执行RESET DATABASE TO INCARNATION命令。因此,必须执行SET UNTIL,从自动备份中还原控制文件,然后挂载它。
假设以下情形:
1)RMAN连接到恢复目录
2)拥有目标数据库trgt来自2013-10-02的备份。
3)2013-10-10在数据库上执行DBPITR来纠正早先的错误。在DBPITR之后的OPEN RESETLOGS操作启动一个新的转生。
在2013-10-25,你发现你需要一个在2013-10-8 8:00a.m.从数据库中删除的重要数据。这个时间在当前转生的开始之前。
执行非当前转生的DBPITR:
1)确保数据库时间点恢复的前提条件已经满足。
2) 启动RMAN,连接到目标数据库和恢复目录。
3)确认哪个数据库在备份的时候是当前的。
使用LIST INCARNATION找到目标时间时是当前的转生的主键:
LIST INCARNATION OF DATABASE trgt;
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- ------- ------ ------- ---------- ----------
1 2 TRGT 1224038686 PARENT 1 02-OCT-13
1 582 TRGT 1224038686 CURRENT 59727 10-OCT-13
查看Reset SCN和Rest Time列来鉴别正确的转生,记下Inc Key列的转生键。在这个示例中,在2013-10-2做的备份。在这个示例中,转生健的值是2。
4)确保数据库已经启动但没有挂载。
STARTUP FORCE NOMOUNT;
5)重置目标数据库到步骤3中获得的转生。
在这个示例中,指定在10-02备份时是当前的转生。
RESET DATABASE TO INCARNATION 2;
6)还原和恢复数据库,在RUN命令中执行以下操作:
a.设置恢复的结束时间为正好在数据丢失前的时间
b.分配没有配置和需要的通道
c.从10-02的备份中还原控制文件和挂载它
d.还原数据文件和恢复数据库。使用RECOVER DATABASE … UNTIL命令执行DBPITR,将数据库恢复到目标时间10-08 7:55a.m.,正好在数据丢失前。
以下示例显示在这个情况中的所有步骤:
RUN
{
SET UNTIL TIME ‘Oct 8 2013 07:55:00’;
RESTORE CONTROLFILE;
# without recovery catalog, use RESTORE CONTROLFILE FROM AUTOBACKUP
ALTER DATABASE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;
来源:《Oracle Database Backup and Recovery User’s Guide,19c》