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

oracle rac基于时间点的不完全恢复一例 2011年6月13 H凌晨1点多接到领导电话说某项H数裾库宕机了，于足3上打的赶到现场，马上发 现足归档日志满/，最后发现足同事的一个服务程序在处理-?些文件时没有权限而不停的死循环进行 数据库操作，导致归档円志增长异常快。 內天就留在现场进行一些数裾库维护操作和将一呰数据非常人的非分区表转为分区表的工作，晚上 6点30左右接到同事电话说是自己闯大祸了，本来是要消理二级数据库的测试数掘，结來连错数据 库连到了屮心数椐库，瞬间儿百张表的数据被沾空了。这个淸理脚木还是我写的，里而伞是tnmcat e语句，清理测试数裾那足相当快，我做梦也没想到我的这个脚本会带來这么人的灾难。 马上赶到现场，公司领导、业主公司领导及公司一些同事马上招开紧急会议确认恢案。山丁?在数 据淸理后乂有二级数据库的数据陆续上传到屮心数据库來，因此恢复只能用不完全恢复，Miff楚同事 的操作时问为6点20左右，于是大家根据会议各司其职开始忙碌起來。经过儿个小时的抢救终于在 6月14日凌晨3点30左右恢父了数裾库，止好赶在结算吋闾点04点之前完成，这样没有影响到各 二级单位的结算工作，真算足万幸了。下而是恢fi的过程 1.1检查数据库备份情况 经过检查，6月13 H凌晨5点TSM调试执行全备份成功，20点有执行TSM 调试执行归捫日志备份后清理归捫日志。这样的话需要从磁带庠恢复数据厍后再 从磁带库把6月13 H的相关归档H志也还原出来进行基于吋间点的应用。 数据库为oracle 10g rac+ASM环境，在进行恢复操作前将其中一个点关 闭，恢复操作全在一个节点上进行。 1.2查询需还原的归档日志号 因为是凌晨5点做的全备，因此考虑将6月13H全天的归档H都进行恢复 SQL〉select thread#,to_char(first time, J yyyymmdd，) riqi,sequence# fro m v$log_history where to_char (first_time, ’yyyymmdd’)= orde r by sequence#, riqi; THREAD# RIQI SEQUENCE# 12156 12157 12158 12159 12160 12161 12162 1216321642165 12165 THREAD# RIQI SEQUENCE# 22166 22167 22168 22169 22170 22171 22172 22173 22174 20 rows selected. 1.3恢复数据库 $ sqlplus /as sysdba SQL*l)lus: 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 lOg 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 on Tue Jun 14 01:17: 17 2011 C