记一次Oracle数据恢复过程
事情的起因是，一个应用升级后，某一个操作导致一个表的几个列全部被更新为同一值（忍不住又要唠叨测试的重要性）。这样的错误居然出现在应用代码中，显然是重大的BUG。那个是罪魁祸首的SQL，UPDATE语句，其WHERE条件仅仅只有一个where 1=1。
系统的维护人员称是星期五出的错，发现出错是在星期天，也就是我恢复数据的日期，与声称的出错时间已经隔了将近2天。开始尝试用flashback query恢复数据，报ORA-01555错误，此路不通。维护人员说，星期五之前的RMAN备份已经被删除了（又是一个备份恢复策略不当地例子），使用基于时间点的恢复也不可能了。剩下的一条路，只有使用log miner。还好归档文件还在数据库服务器上。
这套库是一套RAC数据库，由于没有人能确认操作发生在哪个节点，因此需要将一个节点下所有的归档复制到另一个节点上（如果没有足够的空间，可以使用NFS）。然后需要找到我们用于数据恢复的归档日志：
set linesize 170 pagesize 10000
alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
col name for a30
col first_change for a10
col next_change for a10
select max(first_time) from v$archived_log
where first_time < to_date('200909251900','yyyymmddhh24mi'); --这里的时间为错误发生时估计的最早时间。
select sequence#,first_time,name,to_char(first_change#,'xxxxxxxx') first_change,
to_char(next_change#,'xxxxxxxx') next_change
from v$archived_log
where first_time >=to_date('200909251707','yyyymmddhh24mi')
order by 2;--这里的时间为前一SQL的max(first_time)结果
SEQUENCE# FIRST_TIME NAME FIRST_CHAN NEXT_CHANG
---------- ------------------- ------------------------------ ---------- ----------
4039 2009-09-25 17:07:10 /arch/db1_1_4039.arc 88ce7eff 88d1457c
4040 2009-09-26 12:24:52 /arch/db1_1_4040.arc 88d1457c 88d1459f
4041 2009-09-26 12:25:22 /arch/db1_1_4041.arc 88d1459f 88d156a4
4688 2009-09-26 12:37:59 /arch/db1_2_4688.arc 88d1457f 88d1464a
4689 2009-09-26 12:38:27 /arch/db1_2_4689.arc 88d1464a 88d1569c
4042 2009-09-26 12:54:44 /arch/db1_1_4042.arc 88d156a4 88d157e7
4043 2009-09-26 12:54:56 /arch/db1_1_4043.arc 88d157e7 88d1ab06
4690 2009-09-26 13:07:47 /arch/db1_2_4690.arc 88d1569c 88d1570b
4691 2009-09-26 13:08:00 /arch/db1_2_4691.arc 88d1570b 88d1ab09
4044 2009-09-26 15:27:32 /arch/db1_1_4044.arc 88d1ab06 88d1ab0d
4045 2009-09-26 15:27:35 /arch/db1_1_4045.arc 88d1ab0d 88d25091
4692 2009-09-26 15:40:36 /arch/db1_2_4692.arc 88d1ab09 88d1ab77
4693 2009-09-26 15:40:39 /arch/db1_2_4693.arc 88d1ab77 88d25094
4046 2009-09-26 22:24:07 /arch/db1_1_4046.arc 88d25091 88d250db
4047 2009-09-26 22:24:19 /arch/db1_1_4047.arc 88d250db 88d2515e
4048 2009-09-26 22:24:29 /arch/db1_1_4048.arc 88d2515e 88d25167
4049 2009-09-26 22:24:41 /arch/db1_1_4049.arc 88d25167 88d25cac
4694 2009-09-26 22:37:13 /arch/db1_2_4694.arc 88d25094 88d25147
4695 2009-09-26 22:37:25 /arch/db1_2_4695.arc 88d25147 88d2515b
4696 2009-09-26 22:37:33 /arch/db1_2_4696.arc 88d2515b 88d2516a
4697 2009-09-26 22:37:47 /arch/db1_2_4697.arc 88d2516a 88d25ca9
4050 2009-09-26 22:41:57 /arch/db1_1_4050.arc 88d25cac 88d25cde
4698 2009-09-26 22:55:01 /arch/db1_2_4698.arc 88d25ca9 88d25dcf
4699 2009-09-26 22:55:19 /arch/db1_2_4699.arc 88d25dcf 88dbd27e
set linesize 170 pagesize 10000
alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
col name for a30
col first_change for a10
col next_change for a10
select max(first_time) from v$archived_log
where first_time < to_date('200909251900','yyyymmddhh24mi'); --这里的时间为错误发生时估计的最早时间。
select sequence#,first_time,name,to_char(first_change#,'xxxxxxxx') first_change,
to_char(next_change#,'xxxxxxxx') next_change
from v$archived_log
where first_time >=to_date('200909251707','yyyymmddhh24mi')
order by 2;--这里的时间为前一SQL的max(first_time)结果
SEQUENCE# FIRST_TIME NAME FIRST_CHAN NEXT_CHANG
---------- ------------------- ------------------------------ ---------- ----------
4039 2009-09-25 17:07:10 /arch/db1_1_4039.arc 88ce7eff 88d1457c
4040 2009-09-26 12:24:52 /arch/db1_1_4040.arc 88d1457c 88d1459f
4041 2009-09-26 12:25:22 /arch/db1_1_4041.arc 88d1459f 88d156a4
4688 2009-09-26 12:37:59 /arch/db1_2_4688.arc 88d1457f 88d1464a
4689 2009-09-26 12:38:27 /arch/db1_2_4689.arc 88d1464a 88d1569c
4042 2009-09-26 12:54:44 /arch/db1_1_4042.arc 88d156a4 88d157e7
4043 2009-09-26 12:54:56 /arch/db1_1_4043.arc 88d157e7 88d1ab06
4690 2009-09-26 13:07:47 /arch/db1_2_4690.arc 88d1569c 88d1570b
4691 2009-09-26 13:08:00 /arch/db1_2_4691.arc 88d1570b 88d1ab09
4044 2009-09-26 15:27:32 /arch/db1_1_4044.arc 88d1ab06 88d1ab0d
4045 2009-09-26 15:27:35 /arch/db1_1_4045.arc 88d1ab0d 88d25091
4692 2009-09-26 15:40:36 /arch/db1_2_4692.arc 88d1ab09 88d1ab77
4693 2009-09-26 15:40:39 /arch/db1_2_4693.arc 88d1ab77 88d25094
4046 2009-09-26 22:24:07 /arch/db1_1_4046.arc 88d25091 88d250db
4047 2009-09-26 22:24:19 /arch/db1_1_4047.arc 88d250db 88d2515e
4048 2009-09-26 22:24:29 /arch/db1_1_4048.arc 88d2515e 88d25167
4049 2009-09-26 22:24:41 /arch/db1_1_4049.arc 88d25167 88d25cac
4694 2009-09-26 22:37:13 /arch/db1_2_4694.arc 88d25094 88d25147
4695 2009-09-26 22:37:25 /arch/db1_2_4695.arc 88d25147 88d2515b
4696 2009-09-26 22:37:33 /arch/db1_2_4696.arc 88d2515b 88d2516a
4697 2009-09-26 22:37:47 /arch/db1_2_4697.arc 88d2516a 88d25ca9
4050 2009-09-26 22:41:57 /arch/db1_1_4050.arc 88d25cac 88d25cde
4698 2009-09-26 22:55:01 /arch/db1_2_4698.arc 88d25ca9 88d25dcf
4699 2009-09-26 22:55:19 /arch/db1_2_4699.arc 88d25dcf 88dbd27e
尝试找到数据被错误更新的时间点：
exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch/db1_1_4038.arc');
exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch/db1_1_4039.arc');
exec sys.dbms_logmnr.start_logmnr(options=>sys.dbms_logmnr.dict_from_online_catalog);
col sql_redo for a50
select scn,timestamp,username,sql_redo from v$logmnr_contents
where operation='UPDATE' and upper(sql_redo) like '%TBL_FORM_FORM%'
and sql_redo like '%SGS0900021BNc10%' --这个值是UPDATE时某一列被更新后的值，用在这里便于查找。
order by scn,timestamp;
exec sys.dbms_logmnr.end_logmnr;
exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch/db1_1_4038.arc');
exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch/db1_1_4039.arc');
exec sys.dbms_logmnr.start_logmnr(options=>sys.dbms_logmnr.dict_from_online_catalog);
col sql_redo for a50
select scn,timestamp,username,sql_redo from v$logmnr_contents
where operation='UPDATE' and upper(sql_redo) like '%TBL_FORM_FORM%'
and sql_redo like '%SGS0900021BNc10%' --这个值是UPDATE时某一列被更新后的值，用在这里便于查找。
order by scn,timestamp;
exec sys.dbms_logmnr.end_logmnr;
很不幸的是，没有找着需要的数据。再往后找了几个日志，也没找着。
如果一直找下去，显然会消耗比较长的时间，业务也已经停止了。不过可以用一种简单的方法来查找数据被错误更新发生的时间：一个比较大的表，通常段头后面的那个块，也就是存储那个表的数据的第1个块，通常是很少更新的，至少当时恢复的那个表是这样一种情况。我们可以通过数据块中ITL上的事务SCN来满足我们的要求。
SQL> select tablespace_name,extent_id,file_id,block_id,blocks
from dba_extents where owner='XXX'
and segment_name='TBL_FORM_FORM'
order by extent_id;
TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------------- ---------- ---------- ---------- -------
XXXX 0 16 25481 128
XXXX 1 17 23433 128
XXXX 2 18 21385 128
XXXX 3 19 19977 128
XXXX 4 16 23945 128
XXXX 5 17 8585 128
XXXX 6 18 14217 128
XXXX 7 19 18825 128
SQL> alter system dump datafile 16 block 25482;
System altered.
Start dump data blocks tsn: 4 file#: 16 minblk 25482 maxblk 25482
buffer tsn: 4 rdba: 0x0400638a (16/25482)
scn: 0x0000.88e21027 seq: 0x02 flg: 0x00 tail: 0x10270602
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump: 0x0400638a
Object id on Block? Y
seg/obj: 0x40d8 csc: 0x00.88e20c40 itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0010.011.0006ed74 0x03c002a0.2f48.07 C--- 0 scn 0x0000.88d7af30
0x02 0x0012.019.000027e0 0x03c00ede.05de.42 C--- 0 scn 0x0000.44e2ee39
SQL> select tablespace_name,extent_id,file_id,block_id,blocks
from dba_extents where owner='XXX'
and segment_name='TBL_FORM_FORM'
order by extent_id;
TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BLOCKS
---------------- ---------- ---------- ---------- -------
XXXX 0 16 25481 128
XXXX 1 17 23433 128
XXXX 2 18 21385 128
XXXX 3 19 19977 128
XXXX 4 16 23945 128
XXXX 5 17 8585 128
XXXX 6 18 14217 128
XXXX 7 19 18825 128
SQL> alter system dump datafile 16 block 25482;
System altered.
Start dump data blocks tsn: 4 file#: 16 minblk 25482 maxblk 25482
buffer tsn: 4 rdba: 0x0400638a (16/25482)
scn: 0x0000.88e21027 seq: 0x02 flg: 0x00 tail: 0x10270602
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump: 0x0400638a
Object id on Block? Y
seg/obj: 0x40d8 csc: 0x00.88e20c40 itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0010.011.0006ed74 0x03c002a0.2f48.07 C--- 0 scn 0x0000.88d7af30
0x02 0x0012.019.000027e0 0x03c00ede.05de.42 C--- 0 scn 0x0000.44e2ee39
从上面的结果可以看到，数据块的ITL中，最新的事务其SCN为88d7af30，正处于最后一个归档日志的first_change#和last_change#之间，即88d25dcf和88dbd27e之间，难不成这个错误是今天早上才发生的？于是我挖掘最后1个归档日志，结果发生错误的确是发生在早上，也就是我开始进行恢复操作之前半个小时。
既然错误并没有发生太久，同时这个系统也允许一定的数据丢失，那就使用flashback query，得到UPDATE操作之前的数据即可。
create table tbl_form_form_new
as select * from tbl_form_form
as of timestamp to_date('2009-09-27 09:08:00','yyyy-mm-dd hh24:mi:ss');
--当然这里也可以按SCN进行闪回。
create table tbl_form_form_new
as select * from tbl_form_form
as of timestamp to_date('2009-09-27 09:08:00','yyyy-mm-dd hh24:mi:ss');
--当然这里也可以按SCN进行闪回。
幸运的是，这次闪回查询成功了。看起来足够大的UNDO表空间还是有好处，至少我已经有数次用闪回查询来恢复数据。
相关推荐
-
oracle drop table(表)数据恢复方法
复制代码 代码如下: --查看数据库回收站 select object_name,original_name,partition_name,type,ts_name,createtime,droptime from recyclebin; --恢复 FLASHBACK TABLE 表名 TO BEFORE DROP; 此举 可以恢复表结构,同时 数据也恢复了 必须9i或10g以上版本支持,flashback无法恢复全文索引
-
Oracle误删除表数据后的数据恢复详解
Oracle误删除表数据后的恢复详解 测试环境: SYSTEM:IBM AIX 5L Oracle Version:10gR2 1. undo_retention参数的查询与修改 使用show parameter undo命令查看当前的数据库参数undo_retention设置. 显示如下: SQL> show parameter undo NAME TYPE VAL
-
oracle误drop/update操作后的数据恢复测试
1.drop表,如何进行恢复 复制代码 代码如下: create table etl (id number); insert into etl values (1); commit; drop table etl; 如果drop table etl purge --就不能进行恢复 下面进行表的恢复: (1)介绍视图进行恢复:DBA_RECYCLEBIN SQL> SELECT OBJECT_NAME,ORIGINAL_NAME,CAN_UNDROP,CAN_PURGE FROM DBA_RECY
-
最简单的Oracle数据恢复 select as of使用方法
You perform a Flashback Query by using a SELECT statementwith an AS OF clause.You use a flashback query to restrieve data as it existed at some time in the past.The query explicitly references a past time by menasof timestamp or SCN.It returns commit
-
oracle误删数据恢复方法小结
如果用户误删/更新了数据后,作为用户并没有什么直接的方法来进行恢复,他们必须求助DBA来对数据库进行恢复,到了Oracle9i,这一个难堪局面有所改善.Or(www.jb51.net)acle 9i中提供了一项新的技术手段--闪回查询,用户使用闪回查询可以及时取得误操作前的数据,并可以针对错误进行相应的恢复措施,而这一切都无需DBA干预 因为一时手贱,生产上的数据被我给delete掉了. 用的是delete语句,然后很迅速的还给commit了 下面这两个语句: ALTER TABLE table
-
记一次Oracle数据恢复过程
事情的起因是,一个应用升级后,某一个操作导致一个表的几个列全部被更新为同一值(忍不住又要唠叨测试的重要性).这样的错误居然出现在应用代码中,显然是重大的BUG.那个是罪魁祸首的SQL,UPDATE语句,其WHERE条件仅仅只有一个where 1=1. 系统的维护人员称是星期五出的错,发现出错是在星期天,也就是我恢复数据的日期,与声称的出错时间已经隔了将近2天.开始尝试用flashback query恢复数据,报ORA-01555错误,此路不通.维护人员说,星期五之前的RMAN备份已经被删除了(又
-
Oracle安装过程中物理内存检查及临时temp空间不足问题解决
物理内存 – 此先决条件将测试系统物理内存总量是否至少为 922MB (944128.0KB). 预期值 : N/A 实际值 : N/A 错误列表: – 可用物理内存 PRVF-7531 : 无法在节点上执行物理内存检查 – Cause: 无法在指示的节点上执行物理内存检查. – Action: 确保可以访问指定的节点并可以查看内存信息. 可用物理内存 – 此先决条件将测试系统可用物理内存是否至少为 50MB (51200.0KB). 预期值 : N/A 实际值 : N/A 错误列表: – PR
-
Windows10 x64安装、配置Oracle 11g过程记录(图文教程)
备注:本想在自己电脑上安装个oracle练习用,但是害怕安装过程中出现问题,而oracle的卸载又是出了名的麻烦,所以用虚拟机搭建了一个跟本机一样的系统,同时记录下安装的每一步. 环境: windows10系统 最好先安装jre或jdk(此软件用来打开oracle自带的可视化操作界面,不装也没关系:可以安装plsql,或者直接用命令行操作) 1.oracle下载 * 下载地址:http://www.oracle.com/technetwork/database/enterprise-editio
-
PLSQL连接oracle数据库过程图解
换电脑,重新装了PLSQL,连接oracle数据库. 1.下载Instant Client, 下载地址:https://www.oracle.com/database/technologies/instant-client/downloads.html 本人刚好有之前版本,路径为 E:\Program Files\instantclient_10_2 2.打开PLSQL,点取消,然后弹出PLSQL主界面,点击菜单栏的"工具"--"首选项",设置Oracle主目录和O
-
浅谈oracle SCN机制
SCN(System Change Number)作为oracle中的一个重要机制,在数据恢复.Data Guard.Streams复制.RAC节点间的同步等各个功能中起着重要作用.理解SCN的运作机制,可以帮助你更加深入地了解上述功能. 在理解SCN之前,我们先看下oracle事务中的数据变化是如何写入数据文件的: 1.事务开始: 2.在buffer cache中找到需要的数据块,如果没有找到,则从数据文件中载入buffer cache中: 3.事务修改buffer cache的数据块,该数据
-
CentOS 7.4下安装Oracle 11.2.0.4数据库的方法
在Linux下安装Oracle数据库是一件较为麻烦的事情. 由于Linux的安装过程中可能会选择不同的安装包,会导致Oracle安装过程中缺失或多一些软件包,很难一次性的安装成功.所以,本文详细记录了Oracle在Linux上的安装过程,以供参考. 本环境仅供软件开发和测试环境使用,并不适合用于生产环境. Oracle官方支持的Linux发行版本有RedHat和Oracle Linux,所以,我们在CentOS(7.4)下安装Oracle(11gR2)时,还需要做一些特别的准备工作. 本文的Ce
-
Oracle数据库中ora-12899错误的解决方法
在使用ORACLE的过程中,会出现各种各样的问题,各种各样的错误,其中ORA-12899就是前段时间我在将数据导入到我本地机器上的时候一直出现的问题.不过还好已经解决了这个问题,现在分享一下,解决方案; 出现ORA-12899,是字符集引起的,中文在UTF-8中占3个字节,ZHS16GBK中占2个字节,而源dmp文件字符集是ZHS16GBK库里倒出来的数据,现在要导入到目标字符集为UTF-8的库里,所以会出现ORA-12899 其实只要修改一下ORACLE 的字符集就可以很好的解决这个问题; 但
-
Oracle数据更改后出错的解决方法
在使用Oracle的过程中我们给系统创建了两个用户:com和comtest.前者存放的是正式库数据,后者存放的测试库数据.它们都有一个taw_rm_user表,存放了使用该系统的用户基本信息,于是就是把其中的password字段全部改成了123456. DMP备份文件创建后,经过一段时间创建了几个新的用户,并且有些旧的用户的其他信息也已经更改了.但是需要把旧用户的密码恢复到从前,直接把备份文件中的taw_rm_user表导入com用户下是肯定不行的.经过分析后,得到了一个解决方案.大致思路是:
-
Oracle数据库性能优化技术开发者网络Oracle
正在看的ORACLE教程是:Oracle数据库性能优化技术开发者网络Oracle.介绍:细处着手,巧处用功.高手和菜鸟之间的差别就是:高手什么都知道,菜鸟知道一些.电脑小技巧收集最新奇招高招,让你轻松踏上高手之路. 摘要: Oracle数据库是当前应用最广泛的大型数据库之一,而其性优化直接关系到系统的运行效率.本文以数据库性能优化的基本原则为出发点,阐述了在数据库设计阶段如何避免竞争和如何优化数据访问,在数据库运行阶段如何从操作系统和数据库实例级别上调整内存和I/O来达到数据库性能优化的各种技