恢复过程异常导致了ORA-600和ORA-7445错误

最新推荐文章于 2021-03-19 19:19:49 发布

ckawt40802

最新推荐文章于 2021-03-19 19:19:49 发布

阅读量308

点赞数

文章标签：数据库

在一次恢复过程中，由于恢复操作有误导致了打开数据库时报错。

错误发生在Oracle 11.1.0.6 RAC环境恢复到其他服务器的操作中。源数据库存储结构为VOLUMN CLUSTER MANAGER配置的裸设备，而目标数据库采用了ASM磁盘组。

在进行RAC数据库的恢复过程中，RESTORE命令使用SET NEWNAME命令，因此所有的数据文件的位置都进行了修改：

RMAN> run
2> {
3> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_system_1_1g' to '+data/rac11g/rac11g_system_1_1g';
4> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_sysaux_1_1g' to '+data/rac11g/rac11g_sysaux_1_1g';
5> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_undotbs1_1_4g' to '+data/rac11g/rac11g_undotbs1_1_4g';
6> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_undotbs2_1_4g' to '+data/rac11g/rac11g_undotbs2_1_4g';
7> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_users_1_4g' to '+data/rac11g/rac11g_users_1_4g';
8> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_ndmain_1_32g' to '+data/rac11g/rac11g_ndmain_1_32g';
9> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_ndmain_2_32g' to '+data/rac11g/rac11g_ndmain_2_32g';
10> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_ndmain_3_32g' to '+data/rac11g/rac11g_ndmain_3_32g';
11> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_ndmain_4_32g' to '+data/rac11g/rac11g_ndmain_4_32g';
12> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_ndmain_5_32g' to '+data/rac11g/rac11g_ndmain_5_32g';
13> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_ndmain_6_32g' to '+data/rac11g/rac11g_ndmain_6_32g';
14> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_undotbs1_2_32g' to '+data/rac11g/rac11g_undotbs1_2_32g';
15> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_undotbs2_2_32g' to '+data/rac11g/rac11g_undotbs2_2_32g';
16> set newname for datafile '/dev/vx/rdsk/datavg/rac11g_perfstat_1_8g' to '+data/rac11g/rac11g_perfstat_1_8g';
17> restore database;
18> switch datafile all;
19> }

executing command: SET NEWNAME

Starting restore at 05-SEP-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=641 instance=rac11g1 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to +DATA/rac11g/rac11g_system_1_1g
channel ORA_DISK_1: restoring datafile 00002 to +DATA/rac11g/rac11g_sysaux_1_1g
channel ORA_DISK_1: restoring datafile 00003 to +DATA/rac11g/rac11g_undotbs1_1_4g
channel ORA_DISK_1: restoring datafile 00004 to +DATA/rac11g/rac11g_undotbs2_1_4g
channel ORA_DISK_1: restoring datafile 00005 to +DATA/rac11g/rac11g_users_1_4g
channel ORA_DISK_1: restoring datafile 00006 to +DATA/rac11g/rac11g_ndmain_1_32g
channel ORA_DISK_1: restoring datafile 00007 to +DATA/rac11g/rac11g_ndmain_2_32g
channel ORA_DISK_1: restoring datafile 00008 to +DATA/rac11g/rac11g_ndmain_3_32g
channel ORA_DISK_1: restoring datafile 00009 to +DATA/rac11g/rac11g_ndmain_4_32g
channel ORA_DISK_1: restoring datafile 00010 to +DATA/rac11g/rac11g_ndmain_5_32g
channel ORA_DISK_1: restoring datafile 00011 to +DATA/rac11g/rac11g_ndmain_6_32g
channel ORA_DISK_1: restoring datafile 00012 to +DATA/rac11g/rac11g_undotbs1_2_32g
channel ORA_DISK_1: restoring datafile 00013 to +DATA/rac11g/rac11g_undotbs2_2_32g
channel ORA_DISK_1: restoring datafile 00014 to +DATA/rac11g/rac11g_perfstat_1_8g
channel ORA_DISK_1: reading from backup piece +DATA/backup/01jpk0bj_1_1
channel ORA_DISK_1: piece handle=+DATA/backup/01jpk0bj_1_1 tag=TAG20080902T204539
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 01:03:09
Finished restore at 05-SEP-08

datafile 1 switched to datafile copy
input datafile copy RECID=15 STAMP=664645295 file name=+DATA/rac11g/rac11g_system_1_1g
datafile 2 switched to datafile copy
input datafile copy RECID=16 STAMP=664645295 file name=+DATA/rac11g/rac11g_sysaux_1_1g
datafile 3 switched to datafile copy
input datafile copy RECID=17 STAMP=664645295 file name=+DATA/rac11g/rac11g_undotbs1_1_4g
datafile 4 switched to datafile copy
input datafile copy RECID=18 STAMP=664645295 file name=+DATA/rac11g/rac11g_undotbs2_1_4g
datafile 5 switched to datafile copy
input datafile copy RECID=19 STAMP=664645295 file name=+DATA/rac11g/rac11g_users_1_4g
datafile 6 switched to datafile copy
input datafile copy RECID=20 STAMP=664645295 file name=+DATA/rac11g/rac11g_ndmain_1_32g
datafile 7 switched to datafile copy
input datafile copy RECID=21 STAMP=664645295 file name=+DATA/rac11g/rac11g_ndmain_2_32g
datafile 8 switched to datafile copy
input datafile copy RECID=22 STAMP=664645295 file name=+DATA/rac11g/rac11g_ndmain_3_32g
datafile 9 switched to datafile copy
input datafile copy RECID=23 STAMP=664645295 file name=+DATA/rac11g/rac11g_ndmain_4_32g
datafile 10 switched to datafile copy
input datafile copy RECID=24 STAMP=664645296 file name=+DATA/rac11g/rac11g_ndmain_5_32g
datafile 11 switched to datafile copy
input datafile copy RECID=25 STAMP=664645296 file name=+DATA/rac11g/rac11g_ndmain_6_32g
datafile 12 switched to datafile copy
input datafile copy RECID=26 STAMP=664645296 file name=+DATA/rac11g/rac11g_undotbs1_2_32g
datafile 13 switched to datafile copy
input datafile copy RECID=27 STAMP=664645296 file name=+DATA/rac11g/rac11g_undotbs2_2_32g
datafile 14 switched to datafile copy
input datafile copy RECID=28 STAMP=664645296 file name=+DATA/rac11g/rac11g_perfstat_1_8g

下面在恢复之前应该首先通过SQLPLUS命令执行ALTER DATABASE RENAME FILE命令将日志文件的位置指向当前ASM磁盘组中的位置，但是在第一次恢复的时候没有进行这一步的操作，而选择了直接通过SQLPLUS进行了不完全的恢复：

SQL> recover database using backup controlfile;
ORA-00279: 更改 25937960 (在 08/26/2008 12:59:34 生成) 对于线程 1 是必需的
ORA-00289: 建议: +DATA/rac11g/1_528_660235173.dbf
ORA-00280: 更改 25937960 (用于线程 1) 在序列 #528 中

指定日志: {=suggested | filename | AUTO | CANCEL}
ORA-00279: 更改 25937960 (在 08/31/2008 02:05:23 生成) 对于线程 2 是必需的
ORA-00289: 建议: +DATA/rac11g/2_193_660235173.dbf
ORA-00280: 更改 25937960 (用于线程 2) 在序列 #193 中

指定日志: {=suggested | filename | AUTO | CANCEL}
+DATA/RAC11G/rac11g_redo2_2_1_1g
ORA-00283: 恢复会话因错误而取消
ORA-10878: parallel recovery slave died unexpectedly

ORA-01112: 未启动介质恢复

结果Oracle在恢复的过程中出现了错误，这个错误可能就是没有设置日志文件的正确位置造成的。

于是只好采用不完全恢复，并一点点的增加SCN，试图找到一个可以正常打开数据库的SCN：

SQL> recover database using backup controlfile until change 25937960;
ORA-00279: 更改 25937960 (在 08/26/2008 12:59:34 生成) 对于线程 1 是必需的
ORA-00289: 建议: +DATA/rac11g/1_528_660235173.dbf
ORA-00280: 更改 25937960 (用于线程 1) 在序列 #528 中

指定日志: {=suggested | filename | AUTO | CANCEL}
+DATA/RAC11G/rac11g_redo2_2_1_1g
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01152: 文件 1 没有从过旧的备份中还原
ORA-01110: 数据文件 1: '+DATA/rac11g/rac11g_system_1_1g'

ORA-01112: 未启动介质恢复

SQL> recover database using backup controlfile until change 25937968;
ORA-00279: 更改 25937963 (在 09/02/2008 20:45:39 生成) 对于线程 1 是必需的
ORA-00289: 建议: +DATA/rac11g/1_528_660235173.dbf
ORA-00280: 更改 25937963 (用于线程 1) 在序列 #528 中

指定日志: {=suggested | filename | AUTO | CANCEL}
ORA-00279: 更改 25937963 (在 08/31/2008 02:05:23 生成) 对于线程 2 是必需的
ORA-00289: 建议: +DATA/rac11g/2_193_660235173.dbf
ORA-00280: 更改 25937963 (用于线程 2) 在序列 #193 中

ORA-01112: 未启动介质恢复

SQL> recover database using backup controlfile until change 25937978;
ORA-00279: 更改 25937968 (在 09/02/2008 20:45:39 生成) 对于线程 1 是必需的
ORA-00289: 建议: +DATA/rac11g/1_528_660235173.dbf
ORA-00280: 更改 25937968 (用于线程 1) 在序列 #528 中

指定日志: {=suggested | filename | AUTO | CANCEL}
ORA-00279: 更改 25937968 (在 08/31/2008 02:05:23 生成) 对于线程 2 是必需的
ORA-00289: 建议: +DATA/rac11g/2_193_660235173.dbf
ORA-00280: 更改 25937968 (用于线程 2) 在序列 #193 中

指定日志: {=suggested | filename | AUTO | CANCEL}
+DATA/RAC11G/rac11g_redo2_2_1_1g
已应用的日志。
完成介质恢复。

在将SCN设置到25937978时，终于可以完成恢复操作，下面修改了REDO文件的位置，不过这个时候已经晚了：

SQL> alter database rename file '/dev/vx/rdsk/datavg/rac11g_redo1_1_1_1g' to '+DATA/RAC11G/rac11g_redo1_1_1_1g';
数据库已更改。
SQL> alter database rename file '/dev/vx/rdsk/datavg/rac11g_redo1_2_1_1g' to '+DATA/RAC11G/rac11g_redo1_2_1_1g';
数据库已更改。
SQL> alter database rename file '/dev/vx/rdsk/datavg/rac11g_redo2_2_1_1g' to '+DATA/RAC11G/rac11g_redo2_2_1_1g';
数据库已更改。
SQL> alter database rename file '/dev/vx/rdsk/datavg/rac11g_redo2_2_2_1g' to '+DATA/RAC11G/rac11g_redo2_2_2_1g';
数据库已更改。

于是尝试打开数据库的时候，就出现了错误：

SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-03113: 通信通道的文件结束
进程 ID: 3550
会话 ID: 326 序列号: 48

重新进入数据库，进行检查：

SQL> conn / as sysdba
已连接。
SQL> select instance_name, status from v$instance;

INSTANCE_NAME STATUS
---------------- ------------
rac11g1 OPEN

SQL> select count(*) from ndmain.cat_product;
select count(*) from ndmain.cat_product
*
第 1 行出现错误:
ORA-01219: 数据库未打开: 仅允许在固定表/视图中查询

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01531: 实例已打开数据库

SQL> shutdown immediate
ORA-03113: 通信通道的文件结束
进程 ID: 3245
会话 ID: 639 序列号: 28

SQL> conn / as sysdba
已连接。
SQL> shutdown immediate
ORA-01012: not logged on
SQL> conn / as sysdba
已连接到空闲例程。
SQL> startup
ORA-01081: cannot start already-running ORACLE - shut it down first
SQL> conn / as sysdba
已连接到空闲例程。
SQL> shutdown immediate
ORA-24324: 未初始化服务句柄
ORA-24323: 不允许此值
ORA-01089: 正在执行立即关闭 - 不允许进行任何操作
SQL> conn / as sysdba
已连接到空闲例程。
SQL> shutdown abort
ORACLE 例程已经关闭。

从上面已经可以看出，数据库处于一种奇怪的不一致状态，从实例状态看，数据库已经处于打开状态，而数据库本身目前却又没有完全打开，因为这时不能访问V$以外的表，可是尝试ALTER DATABASE OPEN，数据库又报错，实例已经打开。关闭数据库的时候也出现了ORA-3113错误，最终只能使用SHUTDOWN ABORT来强行关闭。

检查后台的alert文件，发现Oracle出现了ORA-600和ORA-7445错误：

Errors in file /data/oracle/diag/rdbms/rac11g/rac11g1/trace/rac11g1_ora_3550.trc (incident=19313):
ORA-00600: \304\332\262\277\264\355\316\363\264\372\302\353, \262\316\312\375: [kclfget_3], [], [], [], [], [], [], []
Incident details in: /data/oracle/diag/rdbms/rac11g/rac11g1/incident/incdir_19313/rac11g1_ora_3550_i19313.trc
Exception [type: SIGBUS, Invalid address alignment] [ADDR:0x4250000000043E86] [PC:0x10178BEB8, kcldle()+3096]
Errors in file /data/oracle/diag/rdbms/rac11g/rac11g1/trace/rac11g1_ora_3550.trc (incident=19314):
ORA-07445: \263\366\317\326\322\354\263\243\264\355\316\363: \272\313\320\304\327\252\264\242 [kcldle()+3096] [SIGBUS] [ADDR:0x42500
00000043E86] [PC:0x10178BEB8] [Invalid address alignment] []
ORA-00600: \304\332\262\277\264\355\316\363\264\372\302\353, \262\316\312\375: [kclfget_3], [], [], [], [], [], [], []
Incident details in: /data/oracle/diag/rdbms/rac11g/rac11g1/incident/incdir_19314/rac11g1_ora_3550_i19314.trc
ARC0: Archiving disabled thread 2 sequence 1
Instance recovery: looking for dead threads
Instance recovery: lock domain invalid but no dead threads
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0xCA8800000007BBD7] [PC:0x1018E7B40, {empty}]

重新启动，发现数据库可以顺利的启动：

SQL> startup
ORACLE 例程已经启动。

Total System Global Area 1.7108E+10 bytes
Fixed Size                  2101632 bytes
Variable Size            3814182528 bytes
Database Buffers         1.3288E+10 bytes
Redo Buffers                4431872 bytes
数据库装载完毕。
数据库已经打开。

而此后的访问也未出现任何的问题。查询了对应的ORA-600和ORA-7445错误，发现找不到类似的情况，基本上可以确定，数据库打开时的报错以及后台600和7445错误的引发都与不完全恢复过程有关。

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

转载于:http://blog.itpub.net/4227/viewspace-450441/

ckawt40802

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
恢复过程异常导致了ORA-600和ORA-7445错误

在一次恢复过程中，由于恢复操作有误导致了打开数据库时报错。错误发生在Oracle 11.1.0.6 RAC环境恢复到其他服务器的操作中。源数据库存储结构为VOLUMN CLUSTER MANAGER配置的裸设备，...
复制链接

扫一扫