欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

记一次Oracle 19c redo误删除的故障恢复 [ORA-00742 ORA-00312 没有归档]

程序员文章站 2022-03-09 14:27:43
...

现场工程师晚上处理磁盘空间满的问题时,误删除了redo日志文件,又自己进行了一些尝试性操作,具体不可表。我接到 CASE 时告警信息 ORA-00742 ORA-00312。
记一次Oracle 19c redo误删除的故障恢复 [ORA-00742 ORA-00312 没有归档]
该数据库没有开归档,没有备份,尝试把数据库拉起来吧。做操作之前备份数据库相关文件(数据文件,控制文件,参数文件等)

首先尝试 resetlogs 开库,如果数据库状态一致是有可能直接起来的。

recover database until cancel;
recover database using backup controlfile until cancel;
alter database open resetlogs;

无法实例恢复,报了一堆错误,大体如下:

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get
error below ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/oradata/ora19c/system01.dbf’


ORA-00279: change 3721457 generated at 01/16/2020 10:22:39 needed for
thread 1 ORA-00289: suggestion :
/opt/oracle/product/19c/dbhome_1/dbs/arch1_7_1029838537.dbf ORA-00280:
change 3721457 for thread 1 is in sequence #7


ORA-00308: cannot open archived log
‘/opt/oracle/product/19c/dbhome_1/dbs/arch1_7_1029838537.dbf’
ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such
file or directory Additional information: 7


ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data
file 1: ‘/oradata/ora19c/system01.dbf’

尝试使用隐含参数拉起数据库

-- 创建 pfile
create pfile='/tmp/pfile' from spfile;
vim /tmp/pfile
-- 增加以下两行
_allow_resetlogs_corruption='TRUE'
_allow_error_simulation=TRUE

-- 使用 pfile 启动数据库
startup mount pfile='/tmp/pfile'
alter database open resetlogs;

_allow_resetlogs_corruption 参数会屏蔽 resetlogs 开库时的一些不一致,容易导致数据不一致的问题,不到万不得已不推荐使用。

根据经验,到这一步很多库就可以拉起了,但是这次故障并没有能够拉起。继续进行尝试

重建控制文件

oradebug setmypid
alter database backup controlfile to trace;
oradebug tracefile_name

使用 oradebug 获取控制文件创建语句,根据 trace 中的创建语句重建控制文件。
重建控制文件后,再次尝试 resetlogs 打开数据库,依旧报错

alter database open resetlogs;

报错信息如下:

ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [kcbzib_kcrsds_1], [], [], [], [], [], [], [], [], [], [], []
Process ID: 25421
Session ID: 9 Serial number: 12233

推 SCN

vim /tmp/pfile
event="21307096 trace name context forever, level 3"

shut immediate
startup nomount pfile='/tmp/pfile'
-- 再次重建控制文件
create controlfile …

-- 使用 /oradata/TDB/redo01.log 进行实例恢复
recover database using backup controlfile until cancel;
ORA-00279: change 2040639 generated at 01/16/2020 15:29:21 needed for thread 1
ORA-00289: suggestion :
/opt/oracle/product/19c/dbhome_1/dbs/arch1_1_1029857358.dbf
ORA-00280: change 2040639 for thread 1 is in sequence #1

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oradata/ora19c/redo01.log
Log applied.
Media recovery complete.

-- 实例恢复成功,使用 resetlogs 开库
alter database open resetlogs;

成功打开数据库,一般到这里就可以迁移数据了,可是这次又遇到一个问题

ORA-00600 : internal error code, arguments: [4194] [55] [41]

重建UNDO表空间解决这个问题

create undo tablespace UNDOTBS2 datafile '/oradata/ora19c/undotbs02.dbf' size 2G;
drop tablespace undotbs1;

vim /tmp/pfile
undo_management='MANUAL'
undo_tablespace='UNDOTBS2'

-- 使用 pfile重启数据库
shut immediate
startup pfile='/tmp/pfile'

-- 添加临时表空间文件
alter tablespace temp add tempfile '/oradata/ora19c/temp01.dbf' reuse;

此时数据库可以正常访问了,使用数据泵将数据进行逻辑迁移。

总结

这次故障算是比较曲折的,整体处理可以分为以下几步:

  • 修改隐含参数
  • 重建控制文件
  • 推进SCN
  • 重建UNDO
  • 数据泵迁移