基于 Oracle Datagurad快速恢复应用

 

 

本人就职公司快速恢复应用一说

一  Dataguard 快速切换实际应用场境。

  遇到下面的情况，应立即把备库拉起，接管主库角色，保证应用快速恢复。Dataguard主要解决数据单点存在的问题也保护了数据安全，但不能保证人为操作带来的数据丢失，例如，truncate table的后果，dml语句，它主要提供一些非人为的故障的数据库安全和冗余，可保数据不丢失的情况下快速切换角色。

primary库的数据文件丢失。

数据文件丢失有很多种，有普通数据文件（业务数据），系统数据文件，例如system表间，这时最好选择直接切换备库，避免恢复的时间影响了业务的恢复窗口。

primary 在线online redo 当前活动日志文件丢失。

Online redo current状态的日志损坏，也应切垃起备库接管业务，原因是在主库上恢复会停机有丢失数据，重建主备关系，直接拉起备库可保数据不丢失，业务快速恢复的特点。

控制文件丢失，并且没有可用备份。

控制文件有双份保存，一旦全部丢失，数据库实例会中止实例，因检查点无法写入控制文件。此时业务无法正常运行，如没有备份恢复是一个很慢长的过程。因此选择备库直接管服务。

Primary 数据坏块。

数据文件坏块，比效多样，恢复手段很多，大多会关闭实例下进行恢复，恢复时间也不好说。Dataguard主要解决了这个问题，保证数据非人为的故障，这也是他的产生出来的原因，不用多说直接切换

Primary  操作系统无法正常运行。

  系统层面的故障很多，只要是操系统带来的故障引起的主库无法提供服务，都因果断切换主备关系，后再重建主备。故障原因例如; 操作系统无法运行。人为删除了文件，网络无法正常，等等。

 

二  Datagurad下的数据完全恢复应用场境。

   完全恢复，主要是dg架构下并不保证人为操作的dml语句带来的数据丢失，一旦因dm语句操作带来的数据丢失，业务无法运行，dg也无能为力，因此在实际应用中，一般都是采用oracle 11g 闪回技术来恢复，这个也有局限性，并不是所有的都可以，例如truncate table 就无法使用闪回，使用闪回技术需要特定的条件，比如，归档文件，开启闪回，开启归档模式，开启回收站功能，oracle undo机制等，下面举例

2.1 drop table 下完全恢复

例如：

   2.11 介绍

Drop table tt; 操作oracle实际将它重名了，，表及索引所占空间分配给回收站对像，数据块并没有实际移动，恢复也是很快的，在所在表空间空间够用的情况下，会一直保存在回收站，在空间不够用的情况下，会按先入先出原则将回收回收站空间，一旦回收就无法使用闪回删除进行恢复。

 

   2.12 恢复条件

  2.121 

oracle实例开启回收站机制。

  2.122  

drop table tt;后，并没有执行下 purge user_recycleblin;或者purge dba_recyclebin操作。

  2.123 

表空间并没有自动扩大。

 

   2.13 恢复方法

2.131 查看回收站信息通过视图 dba_recyclebin、user_recyclebn获得。通登本用户为例

1：show recyclebin;  --查出回站信息.查看表对应的回收站对像名。   2：flashback table “recyclebin name” to before drop;  ---

 

   2.14 恢复时间评估

  因只是rename  因此闪回删除是很快的，1分种之内。

2.2 闪回表（flashback table）

2.21 介绍

闪回表是利用undo表空间的撤销数据，将表中的数据快速恢复到过去的一个是焦点或者系统改变号SCN上。用于错语的对表数据修改操作。通过show parameter undo命令可以了解这些信息。

2.22 恢复条件

闪回表多久看以下四条件

1： 初始化参数und0_retention值 默认900秒。

2： undo表空间是否为自动增长。

3： undo表空间属性。

4：数据库中的事务理。

2.23 恢复方法

1：开启表行移动功能 Sql> alter table table_name enable row movement; 2: 闪回表10分钟前数据 flashback table table_name to timestamp (systimestamp – interval ‘10’ minute); 3：闪回两张有关系的两张表10分钟前 Flashback table table_name1,table_name2 to timestamp (systimestamp – interval ‘10’ minute); 4：也可以其于scn号来闪回 Sql>flashback table table_name to scn 345353344;

 

2.24 恢复时间评估

看表的大小，io性能，表越大时间越久。

 

2.3闪回事务查询

 

2.31 介绍

闪回事务查询数据并非是旧的数据，而是能够将当前数据修改为以前的样子的撤消sql语句，集中在flashback_transaction_query表上查询撤消sql,只要用于取消某一个dml语句。

2.32 恢复条件。

1： 开启归档模式。

2： oracle开启打开了最小补充日志。

alter database add supplemental log data;

3： 初始化参数und0_retention值 默认900秒。

4： undo表空间是否为自动增长。

5： undo表空间属性。

6：数据库中的事务理。

 

2.33 恢复方法

举例

SQL> update pay_center set id=120000 where id=10000; 1 row updated. SQL> commit;   SQL> select versions_xid,versions_startscn,id   2  from zhifu.pay_center   3  versions between timestamp minvalue and maxvalue   4  where id=120000   5  order by 2 nulls first;   VERSIONS_XID     VERSIONS_STARTSCN         ID ---------------- ----------------- ---------- 0B000B0025400400         247247657     120000   SQL> 0B000B0025400400^C^C   SQL> select undo_sql   2  from flashback_transaction_query   3  where xid='0B000B0025400400' and table_owner='ZHIFU'; from flashback_transaction_query      * ERROR at line 2: ORA-01031: insufficient privileges     SQL> conn /as sysdba; Connected. SQL> select undo_sql   2  from flashback_transaction_query   3  where xid='0B000B0025400400' and table_owner='ZHIFU';   UNDO_SQL ---------------------------------------------------------------------------------------------------- update "ZHIFU"."PAY_CENTER" set "ID" = '10000' where ROWID = 'AAASrpAAJAAAAinAAA';   SQL>

 

 

2.34 恢复时间评估

具体时间，看执行回退的语句能性，数据量越小越快。

2.4  闪回事务

2.41 介绍

闪回事务能够撤消一个或多个事务的修改，其功能有一个名为DBMS_FLASHBACK.TRANSACTION_BACKOUT的存储过程来实现，闪回事务与闪回事务查询无需胆心事务的原子性，它发现重做日志，挖掘出变更前的值来在达到撤消事务。

2.42 恢复条件。

1： 开启归档模式。

2： 开启主键补充日志

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

3： 开启外键补充日志

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;

4： 归档文件要存在

 

select SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_PK,SUPPLEMENTAL_LOG_DATA_MIN from v$database;

 

2.43 恢复方法

举例说明，下在是sotre用户下操作

--查看employees employees_id段为1的工资记录。 SQL> select SALARY  from EMPLOYEES where EMPLOYEE_ID =1;       SALARY ----------     800000   ----- 模似错误修改工资记录 SQL> update employees set salary=salary*5;   4 rows updated.   SQL> commit;   Commit complete.   ----急接着为正常业务更新   SQL> update employees set salary=salary*1.1 where EMPLOYEE_ID =1;   1 row updated.   SQL> commit;   Commit complete.   ----发现出错，进行闪回事务   SQL> select distinct xid,commit_scn     2      from flashback_transaction_query     3      where table_owner='STORE' and     4      table_name='EMPLOYEES' and     5      commit_timestamp > systimestamp - interval '10' minute     6     order by commit_scn;    XID              COMMIT_SCN ---------------- ---------- 0400210097A50300  247441976 03001100E8380300  247442054 ------进行闪回  dbms_flashback.cascade模式为存在WAW依赖的一起闪回以前，执行成功两个事务都取消了。   declare       xids sys.xid_array;      begin       xids := sys.xid_array('0400210097A50300');       dbms_flashback.transaction_backout(1,xids,options=>dbms_flashback.cascade);      commit;    end;  /  PL/SQL procedure successfully completed. ----再查看employees_id=1的值时，应该还原了 SQL> conn store/611001 Connected. SQL> select SALARY  from EMPLOYEES where EMPLOYEE_ID =1;       SALARY ----------     800000   OK 结果和想像的一样，如果想还原错误的第一条sql  salary*5的那条，还原语句应该是这样 （1）NOCASCADE，TX1不可以被任何其他事务依赖（即TX2不存在），否则撤销操作报错。 （2）CASCADE，将TX1连同TX2一起撤销。 （3）NOCASCADE_FORCE，忽略TX2，直接执行TX1的撤销SQL将TX1撤销，如果没有约束上的冲突，操作将成功，否则约束报错导致撤销操作失败。 （4）NONCONFILICT_ONLY，在不影响TX2的前提下，撤销TX1的修改。与NOCASCADE_FORCE的不同点在于会首先过滤一下TX1的撤销SQL，确保它们不会作用在TX2修改的行上。 declare       xids sys.xid_array;      begin       xids := sys.xid_array('0400210097A50300');       dbms_flashback.transaction_backout(1,xids,options=>dbms_flashback.NOCASCADE_FORCE);      commit;    end;  /

 

 

2.44 恢复时间评估

具体时间看事务修改数据快的大小多少决定，一般来说都非常快。

 

2.5

三  不完全恢复应用场境。

3．1 主备库错误的ddl语句，导致数据库无法提供服务恢复场景。

3.11 场景介绍。

 

例如错误的删除用用 drop user cascade,  drop tablespace xxxx including contents and datafiles; 在这种情况下主备文件都会全部删除，备库已无能快速切换，在主备上利用rman虽可以恢复，但时间窗口效长，不可接受。因在另一台机器上快速做不完全恢复，快速恢复业务，待业务恢复正常，再利用rman 恢复找回数据。

2.32 恢复条件

  1： 平时有进行过恢复业务的准备。

2： 或者推荐使用导出、导入功能，每天定时备份关键表。过滤跟踪，通知，订单表大数据表，只导入表结构，这样一来，数据量就很小，每天二次自动备份，恢复。有效保证主备库同时出现故障的快速恢复条件。

 

2.33 恢复方法

1:每周全量的恢复等侍，逐次恢复增量，半实时同步redo log文件，这种方法维护时间多，并且效多工作量，也比效不灵活。优点是恢复的数据效全，一般都在故障出现前那时间内。

 

2： exp imp 导出，导入，定制脚本每天基于表来导出，在第三台机器上做导入，排除大表。这种方法灵活，自动化支持，恢复速度快，人工干预少，维护成本低。不足之处是不能实时恢复，只能恢复导出那时的数据，之后的数据就丢失。

 

2.34 恢复时间评估

 

Rman全量恢复，时间现无法评估，要机器到位做了测试才好判断

Exp 导入，目前如排除跟踪，通知，订单表，30分钟内应该不成问题，具体要做测试才能精准。

 

3.2 tuancate table 恢复

3.21  场景介绍

 

用户执行trancate table xxx,后，主备表同时丢失表，依赖这种表的业务无法进行，此时要恢复恢复业务有几种恢复方法。

 

3.22 恢复条件

第三台机器上存在备份，和归档文件，安装有oracle数据软件，和被恢复的版本最好一致或高于被恢复的版本。

3.23 恢复方法

两种方法，1个是恢复效全，2个是恢复快，但数据不全。用那一个看业务充许情况。

1： rman恢复，利用rman备份集和归档文件基于时间点的恢复，或者scn。

2： 导出导入的方法。

3.24 恢复时间

 

  Rman 看准备情况，和测试后才能评估。导出导入，测看表的大小即可。

3.3 极端情况下的恢复

3.31 场景介绍

 

  在遇到腾讯云，机房故障，电源故障，网络故障，自然灾后等情况下的恢复，如遇到整个腾讯机房无法提供正常IT服务下的恢复应用。

 

3.32 恢复条件

 

在腾讯云机房外有相关的备份，例如导出dmp文件，rman备份文件，归档文件，程序包。服务器基础安装是否准备好。域名是否可以指向过去。

1： 数据恢复

2：　程序包的恢复

3:  基础服务是否准备好，如nginx配制 域名指向，网络是否正常等

4： 客户是否加入了黑白名单。

 

3.33 恢复方法

 

1： 数据恢复含导出导入，rman。

2： 程序包的恢复

3:  域名dns重新指向。

 

3.34 恢复时间

 

看准备是否充足，还要采用那种数据库恢复方法。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/27252036/viewspace-1761593/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/27252036/viewspace-1761593/