Oracle 使用第三方快照技术的支持备份,还原和恢复

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected]

适用于:

Oracle Database – Standard Edition – 版本9.2.0.1 11.2.0.2 [Release 9.2 11.2]
Oracle Database – Enterprise Edition – 版本9.2.0.1 11.2.0.2 [Release 9.2 11.2]
本文信息适用于任何平台。

摘要

适用于:

Oracle Server – Enterprise Edition – 版本:Oracle 9iR2及以上
本文信息适用于任何平台。

问题描述

许多客户使用Oracle数据库和第三方快照技术进行备份,还原和恢复操作来进行

    • 为其数据库创建数据库快照,无需数据库处于备份模式。
    • 还原第三方快照,将数据库恢复到一致状态

Oracle需要使相关的数据文件或数据库处于备份模式的主要原因是

  • 备份之前确保文件头一致性,并以恢复开始时间更新文件头
  • 创建足够的重做从任何损坏或不一致块中恢复
  • 创建‘end backup’ 标记来规定最少恢复时间,以确保还原和恢复数据文件后的数据库一致性。

当你使用一个操作系统工具,而不是通过RMAN备份联机数据文件时,你必须使数据库或/和相关的数据文件处于备份模式(通过ALTER DATABASE [BEGIN | END] BACKUPALTER TABLESPACE [BEGIN | END] BACKUP 命令),以便Oracle可以解决上述情况。

使数据库在备份模式及不在该模式的转换的代价是

  • 额外的重做数据被记录,
  • 需要完整的数据库检查点
  • 更可操作的步骤和备份操作过程中的复杂性

注:

12C中,只要满足以下所有条件,就不需要满足这一要求:

数据库崩溃一致在快照点,且
对快照中的每个文件保留写入顺序write ordering,且
快照储存快照完成的时间。

12c中,你可以使用新关键字SNAPSHOT TIME RECOVER命令来恢复在数据文件不在备份模式下进行的快照。

详情

如果第三方快照技术能够满足下面2部分中列出的前提条件,Oracle将正式支持以下操作。

备份操作

  • 完整数据库快照而无需数据库处于备份模式
    • 如果需要数据库的时间点复制,快照必须包含所有数据文件,控制文件和联机重做日志。请参考还原和恢复部分中的#1步骤。
    • If full (i.e. zero data loss) recovery or point-in-time recovery is required, the snapshot must contain only the data files or have the ability to restore only the data files. Refer to #2 and #3 procedures under Restore and Recovery section. 如果需要完整的(即零数据丢失)恢复或时间点恢复,快照必须只包含数据文件或有仅恢复数据文件的能力。请参阅还原和恢复部分中的#2和#3步骤。

还原和恢复操作

  • 数据库的时间点复制。

If all the controlfiles, data files and online redo logs are restored from a snapshot backup, then the database can be restarted and crashed recovery will occur. After restoring the complete snapshot, issue STARTUP. The database will be consistent to the last redo commit of the snapshot copy. No future redo beyond this snapshot can be applied. 如果所有控制文件,数据文件和联机重做日志从快照备份中恢复,则数据库可以被重启,恢复崩溃会发生。在还原整个快照后,发出STARTUP。该数据库将与快照复制的最后重做提交一致。超出此快照的未来重做不能被应用。

要区别新的归档和你归档目录或备份中现有的归档,请执行下列操作步骤为数据库创建一个新的resetlog ID

    • SHUTDOWN IMMEDIATE
    • STARTUP MOUNT
    • RECOVER DATABASE UNTIL CANCEL
    • CANCEL
    • ALTER DATABASE OPEN RESETLOGS

   2.  完整数据库恢复,而无数据丢失

如果所有的数据文件从快照备份中恢复,且所有当前控制文件恢复,当前联机重做日志和所有归档可用,则完整数据库恢复是可能的。还原快照而不覆盖联机重做日志或当前控制文件。在还原快照之后,发出RECOVER AUTOMATIC DATABASE命令,Oracle会自动应用所有相关的归档日志和联机重做日志。当恢复应用了当前日志,恢复将自动停止并返回‘Media recovery complete’的信息。然后,你可以使用ALTER DATABASE OPEN命令打开数据库。

   3.  时间点数据库恢复

如果所有数据文件从快照备份中恢复,且所有当前控制文件,归档和当前联机重做日志可用使数据库一致到快照之后的时间点,那么数据库时间点恢复是可能的。还原快照而无需覆盖联机重做日志或当前控制文件。mount数据库并发出以下scandatafile脚本。该脚本会扫描所有数据文件并报告最小的数据库更改号(SCN),‘Minimum PITR SCN’,使数据库保持一致性。

# 扫描所有文件并使用元信息更新文件头
#
取决于文件的数量和大小,scandatafile 过程可能是一个耗时的操作。
#
创建一个脚本,‘scandatafile’,使用以下内容

 spool scandatafile.sql
set serveroutput on
declare
scn number(12) := 0;
scnmax number(12) := 0;
begin
for f in (select * from v$datafile) loop
scn := dbms_backup_restore.scandatafile(f.file#);
dbms_output.put_line(‘File ‘ || f.file# ||’ absolute fuzzy scn = ‘ || scn);
if scn > scnmax then scnmax := scn; end if;
end loop;

dbms_output.put_line(‘Minimum PITR SCN = ‘ || scnmax);
end;

/

注:对于Oracle 9iR2,以上脚本不适用,因为在mountedd数据库中执行匿名PL / SQL块是受限的。一个解决方法是:
步骤 1:创建一个脚本,对每个数据文件执行scandatafile过程。
Set heading off
Spool scandatafile.sql
Select ‘execute 😡 := dbms_backup_restore.scandatafile(‘||file#||’)’ from v$datafile;
Spool off
步骤 2:编辑scandatafile.sql 脚本并插入以下:
Set heading on # first line of the script
Variable x number # second line of the script
select max(fhafs) “Minimum PITR SCN” from x$kcvfh; # last line of the script

步骤 3:执行脚本scandatafile.sql

示例:
SQL> @scandatafile
File 1 absolute fuzzy scn = 861391
File 2 absolute fuzzy scn = 0
File 3 absolute fuzzy scn = 0
File 4 absolute fuzzy scn = 0
Minimum PITR SCN = 861391

PL/SQL procedure successfully completed.

如果最少PITR SCN0,则数据库当前一致且无需要进一步恢复就能被打开。

如果最少PITR SCN部位0,发出RECOVER AUTOMATIC DATABASE until CHANGE [最少PITR SCN 或更高] alter database recover database until change [最少PITR SCN 或更高] 命令,Oracle 将自动应用所有相关的归档日志和联机重做日志。然后,你可以使用ALTER DATABASE OPEN RESETLOGS命令打开数据库。

示例:

# 如果数据库被恢复到最少PITR SCN,数据库仍不一致且尝试打开resetlogs会失败。
SQL> alter database recover database until change 861390;
*
ERROR at line 1:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/+DATA/db/datafile/tbs_01.f’

# 如果数据库被恢复到最少Minimum PITR SCN及以上,则数据库在此时点是一致的且可以使用resetlogs被打开。
SQL> alter database recover database until change 861391;
Database altered.

 4. 12c中,可以使用新关键字SNAPSHOT TIMERECOVER命令来恢复在数据文件不在备份模式下进行的快照。例如,你现在可以:

使用最近的快照恢复数据库:

RMAN> recover database;

使用特定快照恢复数据库:

RMAN> recover database UNTIL TIME ‘02/26/2013 11:00:00’
SNAPSHOT TIME ‘02/26/2013 10:00:00’;

使用归档日志文件执行部分恢复:

RMAN> recover database until cancel
SNAPSHOT TIME ‘02/26/2013 10:00:00’;

总结

第三方快照前提条件

第三方供应商需要保证和承担责任,他们的快照需要符合以下所有条件:

  • 结合Oracle建议的以上还原和恢复操作
  • 数据库崩溃在快照点一致
  • 对快照中的每个文件保留写入顺序write ordering

注:本文不包括启动可能需要的任何其他文件,如初始化文件(spfile)和wallets

参考

NOTE:221779.1 – How to prepare the Oracle database for Third Party Snapshot Technologies and ensure a consistent recovery
NOTE:1534487.1 – RMAN Enhancements in Oracle 12c


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *