TSMfororaclerac基于时间点的不完全恢复一例.doc

oracle rac基于时间点的不完全恢复一例2011年6月13日凌晨1点多接到领导电话说某项目数据库宕机了，于是马上打的赶到现场，马上发现是归档日志满了，最后发现是同事的一个服务程序在处理一些文件时没有权限而不停的死循环进行数据库操作，导致归档日志增长异常快。 白天就留在现场进行一些数据库维护操作和将一些数据量非常大的非分区表转为分区表的工作，晚上6点30左右接到同事电话说是自己闯大祸了，本来是要清理二级数据库的测试数据，结果连错数据库连到了中心数据库，瞬间几百张表的数据被清空了。这个清理脚本还是我写的，里面全是truncate语句，清理测试数据那是相当快，我做梦也没想到我的这个脚本会带来这么大的灾难。 马上赶到现场，公司领导、业主公司领导及公司一些同事马上招开紧急会议确认恢复方案。由于在数据清理后又有二级数据库的数据陆续上传到中心数据库来，因此恢复只能用不完全恢复，问清楚同事的操作时间为6点20左右，于是大家根据会议各司其职开始忙碌起来。经过几个小时的抢救终于在6月14日凌晨3点30左右恢复了数据库，正好赶在结算时间点04点之前完成，这样没有影响到各二级单位的结算工作，真算是万幸了。下面是恢复的过程 1.1 经过检查，6月13日凌晨5点TSM调试执行全备份成功，20点有执行TSM调试执行归档日志备份后清理归档日志。这样的话需要从磁带库恢复数据库后再从磁带库把6月13日的相关归档日志也还原出来进行基于时间点的应用。 数据库为oracle 10g rac+ASM环境，在进行恢复操作前将其中一个节点关闭，恢复操作全在一个节点上进行。 1.2 　查询需还原的归档日志号 因为是凌晨５点做的全备，因此考虑将６月１３日全天的归档日都进行恢复 SQL select thread#,to_char(first_time,yyyymmdd) riqi,sequence# from v$log_history where to_char(first_time,yyyymmdd)order by sequence#,riqi; THREAD# RIQI SEQUENCE# ---------- -------- ---------- 12156 12157 12158 12159 12160 12161 12162 12163 12164 22165 12165 THREAD# RIQI SEQUENCE# ---------- -------- ---------- 22166 22167 22168 22169 22170 22171 22172 22173 22174 20 rows selected. 1.3 　恢复数据库 $ sqlplus / as sysdba SQL*Plus: Release 10.2.0.4.0 - Production on Tue Jun 14 01:16:45 2011 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Connected to an idle instance. SQL startup nomount ORACLE instance started. Total System Global Area 1.0737E+10 bytes Fixed Size 2101872 bytes Variable Size 2466254224 bytes Database Buffers 8254390272 bytes Redo Buffersbytes SQL exit Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, Real Application Clusters, OLAP, Data Mining and Real Application Testing options $ rman target / Recovery Manager: Release 10.2.0.4.0 - Production