AI 助理
备案控制台
开发者社区 数据库 文章 正文

偷梁换柱 | 无备份情况下的数据恢复实践（二）

2018-03-21 3412
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
日志服务 SLS，月写入数据量 50GB 1个月
简介：

数据恢复实践（一）中，我们了解到在 Windows 的11.2.0.1的环境中恢复过程比较顺利，那么接下来的测试，是我遇到更加复杂的情况：系统表空间保护两个不连续的系统文件；恢复过程中出现 ORA 错误及数据字典不匹配的情况。我借助了一些非常规的手段规避这些问题，达到数据拯救的目的。

概述

这个数据拯救的测试中，环境更加复杂：旧数据库异常关闭；旧数据库仅剩下三个数据文件，其中两个属于系统表空间且文件号不连续，其它文件，诸如控制文件、在线日志文件、UNDO 表空间文件、临时表空间及其它数据文件都已丢失。因此在数据恢复过程中也遇到更多的问题。

同样，需要先获得数据库版本、数据库名称和原始的数据文件位置及大小等信息，设置 SID 和密码。

以下为参数文件内容：

_allow_resetlogs_corruption = true 

control_files = (/opt/oracle/oradata/ORA10R2/control/ora_control1, 

/opt/oracle/oradata/ORA10R2/control/ora_control2, 

/opt/oracle/oradata/ORA10R2/control/ora_control3) 

db_name = ORA10R2 

db_domain = "" 

db_block_size = 8192 

undo_management = manual 

undo_tablespace = '' 

UNDO_RETENTION = 900 

nls_language = "AMERICAN" 

nls_territory = "AMERICA" 

user_dump_dest = /opt/oracle/admin/ORA10R2/udump 

background_dump_dest = /opt/oracle/admin/ORA10R2/bdump 

core_dump_dest = /opt/oracle/admin/ORA10R2/cdump 

sga_max_size = 200M 

sga_target = 200M

然后创建新库：

SQL> CREATE DATABASE ORA10R2 

USER SYS IDENTIFIED BY oracle 

USER SYSTEM IDENTIFIED BY oracle 

LOGFILE GROUP 1 

('/opt/oracle/oradata/ORA10R2/onlinelog/redo01.log') SIZE 20M, 

GROUP 2 

('/opt/oracle/oradata/ORA10R2/onlinelog/redo02.log') SIZE 20M, 

GROUP 3 

('/opt/oracle/oradata/ORA10R2/onlinelog/redo03.log') SIZE 20M 

MAXLOGFILES 5 

MAXLOGMEMBERS 5 

MAXLOGHISTORY 1 

MAXDATAFILES 100 

MAXINSTANCES 1 

CHARACTER SET US7ASCII 

NATIONAL CHARACTER SET AL16UTF16 

DATAFILE 

'/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_system_200m' SIZE 180M REUSE 

--, 

'/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_system_02' SIZE 200M REUSE 

EXTENT MANAGEMENT LOCAL 

SYSAUX DATAFILE 

'/opt/oracle/oradata/ORA10R2/datafile/sysaux01' SIZE 100M 

DEFAULT TEMPORARY TABLESPACE tempts1 

TEMPFILE 

'/opt/oracle/oradata/ORA10R2/datafile/temp01' SIZE 20M 

--UNDO TABLESPACE undotbs1 

--DATAFILE '/opt/oracle/oradata/ORA10R2/datafile/undotbs01' 

--SIZE 500M AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED ; 

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 

Database created.

因为我们旧的系统表空间中有两个不连续的数据文件，因此我们需要想办法创建出相应文件号的数据文件。

首先，我们用 BBED 可以看到第二个

数据文件的文件号：

BBED> p kcvfh 

... 

ub2 kccfhfno @52 0x0008 

...

为了让新的系统文件号为8，我们需

要创建几个临时的数据文件提高文件

号,然后再添加新的系统文件：

SQL> create tablespace test datafile 

'/opt/oracle/oradata/ORA10R2/datafile/test3' size 10M, 

'/opt/oracle/oradata/ORA10R2/datafile/test4' size 10M, 

'/opt/oracle/oradata/ORA10R2/datafile/test5' size 10M, 

'/opt/oracle/oradata/ORA10R2/datafile/test6' size 10M, 

'/opt/oracle/oradata/ORA10R2/datafile/test7' size 10M; 

alter tablespace system add datafile '/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_system_02' size 200M; 

DROP TABLESPACE test INCLUDING CONTENTS AND DATAFILES; 



Tablespace created. 



SQL> 

Tablespace altered. 



SQL> 

Tablespace dropped.

如果这里我们按照之前11g 的过程继续操作，将会遇到大量错误，诸如 ORA-00600 [4000], ORA-01555, ORA-01111, ORA-01173, ORA-00600 [4049] 等等。经过深入分析，发现导致这些错误的最终原因是：一致性读。

因为新库创建后，其 Checkpoint SCN 非常小，因此在 Bootstrap 过程中读取系统数据字典数据块时，与数据块上的 ITL 中 scn 比较，发现需要进行一致性回滚，因而会读取回滚段数据，但这些回滚段通常都是不存在，因此会导致以上诸多错误的出现。

当然，这也产生了一个疑问：为什么在 11g 的恢复过程没有发生这些问题？通过对比发现，在11g 的恢复过程中，NID 操作重新设置了系统文件中的 Checkpoint SCN，使其恢复为其原来的 SCN。因为我们已经将其文件头替换为新文件的文件头，因此我猜测 NID 过程中读取了数据字典中 SCN 信息，并重写的文件头。从 nid 过程抛出的 ORA-00600 错误也可以看到，它调用了系统的内部包完成 ID 修改过程。

但在10g 的 NID 过程，并没有修改 SCN，因此需要我们手动提高 SCN。

这里，我使用了隐含参数_minimum_giga_scn。设置该参数，我们需要观察 alert log，因为数值太小不会成功，日志中出现以下记录。

Current SCN is not changed: _minimum_giga_scn (scn 274877906944) is too small

我们这里设置_minimum_giga_scn = 1024，重启数据库，alert 日志提示设置成功。

Advancing SCN to 1099511627776 according to _minimum_giga_scn

接下来重命名新系统文件，拷贝旧数

据文件到当前数据文件目录：

[oracle@server1 ORA10R2]$ mv datafile/ORA10R2_system_200m datafile/ORA10R2_system_200m_new 

[oracle@server1 ORA10R2]$ mv datafile/ORA10R2_system_02 datafile/ORA10R2_system_02_new 

[oracle@server1 ORA10R2]$ cp ../ORA10R2_COPY/datafile/ORA10R2_system_200m ./datafile/ 

[oracle@server1 ORA10R2]$ cp ../ORA10R2_COPY/datafile/ORA10R2_system_02 ./datafile/ 

[oracle@server1 ORA10R2]$ cp ../ORA10R2_COPY/datafile/ORA10R2_example_50m ./datafile/

然后执行 nid 修改数据库 ID（不过我认

为这一步在这里已经不重要了）：

[oracle@server1 ORA10R2]$ nid target=sys/oracle 



DBNEWID: Release 10.2.0.1.0 - Production on Tue Mar 19 00:44:33 2013 

... ... 

Database ID for database ORA10R2 changed to 4153675250. 

All previous backups and archived redo logs for this database are unusable. 

Database has been shutdown, open database with RESETLOGS option. 

Succesfully changed database ID. 

DBNEWID - Completed succesfully.

重建控制文件，并恢复、OPEN 

RESETLOGS：

SQL> CREATE CONTROLFILE REUSE DATABASE ORA10R2 RESETLOGS NOARCHIVELOG 

MAXLOGFILES 5 

MAXLOGMEMBERS 5 

MAXDATAFILES 100 

MAXINSTANCES 1 

MAXLOGHISTORY 292 

LOGFILE 

GROUP 1 '/opt/oracle/oradata/ORA10R2/onlinelog/redo01.log' SIZE 20M, 

GROUP 2 '/opt/oracle/oradata/ORA10R2/onlinelog/redo02.log' SIZE 20M, 

GROUP 3 '/opt/oracle/oradata/ORA10R2/onlinelog/redo03.log' SIZE 20M 

DATAFILE 

'/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_system_200m' SIZE 180M 

, '/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_system_02' SIZE 200M 

--, '/opt/oracle/oradata/ORA10R2/datafile/sysaux01' size 100M 

--, '/opt/oracle/oradata/ORA10R2/datafile/undotbs01' 

CHARACTER SET US7ASCII 

; 

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 

Control file created. 



SQL> recover database using backup controlfile until cancel; 

ORA-00279: change 1099511627897 generated at 03/19/2013 00:43:31 needed for 

thread 1 

ORA-00289: suggestion : /opt/oracle/product/10.2.0/db/dbs/arch1_2_810434521.dbf 

ORA-00280: change 1099511627897 for thread 1 is in sequence #2 



Specify log: {<RET>=suggested | filename | AUTO | CANCEL} 

cancel 

Media recovery cancelled. 

SQL> alter database open resetlogs; 

alter database open resetlogs 

* 

ERROR at line 1: 

ORA-01092: ORACLE instance terminated. Disconnection forced

数据库打开失败，从 alert 日志看到错误内容为：

ORA-01177: data file does not match dictionary - probably old incarnation 

ORA-01110: data file 1: '/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_system_200m'
再次执行恢复和打开过程，并启动 10046 事件跟踪，从跟踪内容中看 到引起该错误的语句及等待事件： 

PARSING IN CURSOR #2 len=122 dep=1 uid=0 oct=3 lid=0 tim=1331710783410619 hv=1330125001 ad='2c3341c8' 

select blocks,NVL(ts#,-1),status$,NVL(relfile#,0),maxextend,inc, crscnwrp,crscnbas,NVL(spare1,0) from file$ where file#=:1 

END OF STMT 

PARSE #2:c=0,e=300,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1331710783410615 

BINDS #2: 

kkscoacd 

Bind#0 

oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 

oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 

kxsbbbfp=b71e3928 bln=22 avl=02 flg=05 

value=1 

EXEC #2:c=1000,e=574,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1331710783411304 

WAIT #2: nam='db file sequential read' ela= 14 file#=1 block#=258 blocks=1 obj#=-1 tim=1331710783411361 

WAIT #2: nam='db file sequential read' ela= 10 file#=1 block#=114 blocks=1 obj#=-1 tim=1331710783411419 

... 

ORA-01177: data file does not match dictionary - probably old incarnation 

ORA-01110: data file 1: '/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_system_200m'

显然，启动进程读取了数据字典 file$ 的数据（第114块数据块），再与数据文件头中的信息对比，存在不匹配数据，则抛出1777 错误。

处理1777错误前，我们启动 mount 状态，并做文件恢复。

SQL> startup mount 

SQL> recover datafile 1 

Media recovery complete. 

SQL> recover datafile 8 

Media recovery complete.

用 bbed 打开114号数据块，即file$的数据块，查看第一条记录，即文件1的数据。

BBED> set file 1 block 114 

FILE# 1 

BLOCK# 114 

BBED> p *kdbr[0] 

BBED> x /rnnnnnnnnnnnnnnnnnnnnnnnnnnn 

rowdata[678] @8153 

------------ 

flag@8153: 0x2c (KDRHFL, KDRHFF, KDRHFH) 

lock@8154: 0x00 

cols@8155: 11 



col 0[2] @8156: 1 -- FILE# 

col 1[2] @8159: 2 -- STATUS$ 

col 2[4] @8162: 23040 -- BLOCKS 

col 3[1] @8167: 0 -- TS# 

col 4[2] @8169: 1 -- RELFILE# 

col 5[1] @8172: 0 -- MAXEXTEND 

col 6[1] @8174: 0 -- INC 

col 7[1] @8176: 0 -- CRSCNWRP 

col 8[2] @8178: 8 -- CRSCNBAS 

col 9[0] @8181: *NULL* -- OWNERINSTANCE 

col 10[5] @8182: 4194306 -- SPARE1

再打开文件头，可以发现 create scn (CRSCNWRP, CRSCNBAS) 不匹配。

BBED> set file 1 block 1 

BBED> map 

BBED> p kcvfh 

struct kcvfh, 676 bytes @0 

struct kcvfhbfh, 20 bytes @0 

ub1 type_kcbh @0 0x0b 

ub1 frmt_kcbh @1 0xa2 

ub1 spare1_kcbh @2 0x00 

... 

struct kcvfhcrs, 8 bytes @100 

ub4 kscnbas @100 0x00000006 -- CRSCNBAS 

ub2 kscnwrp @104 0x0000 -- CRSCNWRP 

... 

struct kcvfhckp, 36 bytes @484 

struct kcvcpscn, 8 bytes @484 

ub4 kscnbas @484 0x00006fa4 -- CKPCNBAS 

ub2 kscnwrp @488 0x0100 -- CKPCNWRP 

...

要规避这个问题，就需要使数据字典中的数据与文件头中的信息一致。这里我修改了数据字典当中的数据。

用 dump 函数看我们需要写入什么数据：

SQL> select dump(6,16) from dual; 



DUMP(8,16) 

----------------- 

Typ=2 Len=2: c1,7

然后用 BBED 修改该记录：

BBED> set file 1 block 114 

BBED> dump offset 8178 count 4 

BBED> modify /x 02c107ff 

BBED> sum apply

接下来避免8号文件出现同样错误，同样修改其记录。

8号文件头数据：

struct kcvfhcrs, 8 bytes @100 

ub4 kscnbas @100 0x00001c64 

ub2 kscnwrp @104 0x0000

数据字典数据：

col 0[2] @7478: 8 

col 1[2] @7481: 2 

col 2[3] @7484: 25600 

col 3[1] @7488: 0 

col 4[2] @7490: 8 

col 5[1] @7493: 0 

col 6[1] @7495: 0 

col 7[1] @7497: 0 

col 8[4] @7499: 140113 

col 9[0] @7504: *NULL* 

col 10[5] @7505: 33554434

Dump 结果：

SQL> select dump(7268,16) from dual; 



DUMP(7268,16) 

--------------------- 

Typ=2 Len=3: c2,49,45 



SQL> select dump(140113,16) from dual; 



DUMP(140113,16) 

--------------------- 

Typ=2 Len=4: c3,f,2,e

再用 BBED 修改。 
BBED> dump offset 7499 count 6 

BBED> modify /x 04c24945 

BBED> sum apply

修改完成后，开启数据库成功，并读取出旧数据库中数据字典内容：

SQL> alter database open; 



Database altered. 



SQL> select file_id, tablespace_name from dba_data_files where tablespace_name like '%EXAMPLE%'; 



FILE_ID TABLESPACE_NAME 

---------- ------------------------------ 

4 EXAMPLE 



SQL> select file#, name from v$datafile where file#=4; 



FILE# NAME 

---------- -------------------------------------------------------------------------------- 

4 /opt/oracle/product/10.2.0/db/dbs/MISSING00004

重命名数据文件：

SQL> ALTER DATABASE RENAME FILE '/opt/oracle/product/10.2.0/db/dbs/MISSING00004' TO '/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_example_50m'; 



Database altered.

重新恢复数据库，使数据文件 ONLINE：

SQL> shutdown 

... ... 

SQL> recover database until cancel; 

Media recovery complete. 

SQL> ALTER DATABASE DATAFILE '/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_example_50m' ONLINE; 



Database altered. 



SQL> alter database open resetlogs; 

alter database open resetlogs 

* 

ERROR at line 1: 

ORA-01122: database file 4 failed verification check 

ORA-01110: data file 4: '/opt/oracle/oradata/ORA10R2/datafile/ORA10R2_example_50m' 

ORA-01206: file is not part of this database - wrong database id

在打开数据库时，抛错，指示加入的数据文件的数据库 ID 不匹配。

通过其他文件可以看到当前数据库的 DBID：

BBED> set file 1 block 1 

FILE# 1 

BLOCK# 1 



BBED> p kcvfh 

... 

ub4 kccfhdbi @28 0xf7940df2 

... 

BBED> dump offset 28 count 4 

File: /opt/oracle/oradata/ORA10R2/datafile/ORA10R2_system_200m (1) 

Block: 1 Offsets: 28 to 31 Dba:0x00400001 

------------------------------------------------------------------------ 

f20d94f7

通过 BBED 修改 ID： 
BBED> set file 4 block 1 

FILE# 4 

BLOCK# 1 



BBED> p kcvfh 

... 

ub4 kccfhdbi @28 0xb9888c45 

... 

BBED> dump offset 30 count 2 

File: /opt/oracle/oradata/ORA10R2/datafile/ORA10R2_example_50m (4) 

Block: 1 Offsets: 30 to 31 Dba:0x01000001 

------------------------------------------------------------------------ 

88b9 

BBED> modify /x 94f7 

File: /opt/oracle/oradata/ORA10R2/datafile/ORA10R2_example_50m (4) 

Block: 1 Offsets: 30 to 31 Dba:0x01000001 

------------------------------------------------------------------------ 

94f7 

BBED> dump offset 28 count 4 

File: /opt/oracle/oradata/ORA10R2/datafile/ORA10R2_example_50m (4) 

Block: 1 Offsets: 28 to 31 Dba:0x01000001 

------------------------------------------------------------------------ 

f29d94f7 

BBED> modify /x f20d 

File: /opt/oracle/oradata/ORA10R2/datafile/ORA10R2_example_50m (4) 

Block: 1 Offsets: 28 to 31 Dba:0x01000001 

------------------------------------------------------------------------ 

f20d94f7 



BBED> sum apply 

Check value for File 4, Block 1: 

current = 0x4460, required = 0x4460

再次启动，成功！

SQL> alter database open resetlogs; 



Database altered.

创建临时表空间，修改用户： 
SQL> CREATE TEMPORARY TABLESPACE temp2 TEMPFILE '/opt/oracle/oradata/ORA10R2/datafile/temp02' size 100M; 



Tablespace created. 



SQL> select 'ALTER USER '||username||' TEMPORARY TABLESPACE TEMP2;' from dba_users; 



'ALTERUSER'||USERNAME||'TEMPORARYTABLESPACETEMP2;' 

--------------------------------------------------------------------- 

ALTER USER STMADMIN TEMPORARY TABLESPACE TEMP2; 

... ... 



SQL> ALTER USER STMADMIN TEMPORARY TABLESPACE TEMP2; 

... ... 

User altered.
用 EXP 导出数据： 
[oracle@server1 ORA10R2]$ exp system/oracle tablespaces=EXAMPLE file=resecue.dat log=resecue.log 

... ... 

. . exporting table USR_MV 11 rows exported 

. exporting referential integrity constraints 

. exporting triggers 

Export terminated successfully without warnings.

数据已经成功拯救出来。

不过，这两个测试都是在实验环境当中的，实际情况可能更为复杂。这个恢复方法只能视为一根救命稻草，真正能保证数据安全的还是完善的备份计划和容灾方案。


原文发布时间为：2018-03-21

本文作者：黄玮

本文来自云栖社区合作伙伴“数据和云”，了解相关信息可以关注“数据和云”微信公众号

文章标签：
日志服务
关系型数据库
Oracle
数据库
SQL
数据库管理
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
技术小能手
目录
相关文章
1436047922066202
|
6月前
|
数据挖掘 Windows
【服务器数据恢复】服务器迁移数据时数据丢失的数据恢复案例
一台安装Windows操作系统的服务器。工作人员在迁移该服务器中数据时突然无法读取数据，服务器管理界面出现报错。经过检查发现服务器中一个lun的数据丢失。
1436047922066202
400 0
1436047922066202
|
6月前
|
存储 Oracle 关系型数据库
服务器数据恢复—北亚企安服务器数据恢复案例集锦
服务器数据恢复案例之服务器raid6中3个磁盘离线导致阵列崩溃的数据恢复案例 服务器数据恢复案例之服务器RAID5两个磁盘指示灯显示红色导致服务器崩溃的数据恢复案例 服务器数据恢复案例之服务器硬盘出现坏道/坏扇区离线导致服务器崩溃的数据恢复案例
1436047922066202
68 2
warmhearted
|
6月前
|
存储 安全 数据库
数据备份与恢复
数据备份与恢复
warmhearted
114 2
训练营小助手
|
存储 缓存 关系型数据库
备份与恢复 | 学习笔记
快速学习备份与恢复
训练营小助手
203 0
备份与恢复 | 学习笔记
带你读小助手
|
存储 Oracle 关系型数据库
备份与恢复实践 | 学习笔记
快速学习备份与恢复实践，介绍了备份与恢复实践系统机制， 以及在实际应用过程中如何使用。
带你读小助手
238 0
备份与恢复实践 | 学习笔记
带你读小助手
|
NoSQL MongoDB 数据库
备份与恢复|学习笔记
快速学习备份与恢复
带你读小助手
89 0
ebpf
|
存储 Unix BI
数据备份和恢复方案(1)
数据备份和恢复方案(1)
ebpf
243 0
技术小能手
|
存储 Oracle 关系型数据库
偷梁换柱 | 无备份情况下的数据恢复实践
技术小能手
2027 0
青夜之衫
|
数据库 关系型数据库 Oracle
关于备份和恢复的10个最佳实践
青夜之衫
1441 0
像教授
数据恢复
像教授
1159 0

热门文章

最新文章

  • 1
    Flutter之禅 内存优化篇
  • 2
    《Cadence 16.6电路设计与仿真从入门到精通》——2.4 Design Entry CIS原理图图形界面　
  • 3
    记一次对网络抖动经典案例的分析
  • 4
    国外成人网站xHamster大量用户信息黑市变卖，部分账号涉及英美政府官员
  • 5
    用户密码以BCrypt加密的方式来防范被破解
  • 6
    带你理清CPU，cache和存储器之间的逻辑运作
  • 7
    Git设置代理服务器
  • 8
    【DSW Gallery】PAI-DSW开通及授权
  • 9
    吐血整理：机器学习的30个基本概念，都在这里了（手绘图解）
  • 10
    MOSS站点的迁移(备份还原)
  • 1
    设计模式之 5 大创建型模式，万字长文深剖 ，近 30 张图解！
    49
  • 2
    《C++新特性：为多线程数据竞争检测与预防保驾护航》
    41
  • 3
    Kotlin - 区间与数组
    41
  • 4
    Kotlin - 参数与异常
    39
  • 5
    Kotlin - 运算符与中缀表达式
    34
  • 6
    Kotlin - 函数与Lambda表达式
    23
  • 7
    Kotlin - 分支与循环
    19
  • 8
    天气预报1天-中国气象局-地址查询版免费API接口教程
    21
  • 9
    《C++智能合约与区块链底层交互全解析：构建坚实的去中心化应用桥梁》
    19

    • 相关课程

    更多
  • 数据库备份DBS 产品功能介绍

    • 相关电子书

    更多
  • 数据库异地备份及不还原快速查询备份集最佳实践
  • 微信SQLite数据库损坏恢复实践
  • HBase 数据备份与恢复

    • 相关实验场景

    更多
  • 快照备份与恢复
  • MySQL数据库DTS迁移上云
  • Tair for Redis数据闪回：任意时间点数据恢复
  • PolarDB MySQL通过DMS恢复误操作数据
  • ECS数据管理实践-备份与恢复
    • 下一篇
    阿里云OSS设置跨域访问