标签归档:oracle 8恢复

2025年的Oracle 8.0.5数据库恢复

在10多年前恢复过几个Oracle 8.0版本的库
记录8.0.5数据库恢复过程
ORACLE 8.0.5 ORA-01207故障恢复
记录一次AIX 4.3.0+ORACLE 8.0.5恢复过程
没有想到在2025年的7月份还有朋友咨询8.0.5的库恢复case.心中一阵小激动,回想到当年的很多过往(在邮储的机房里面恢复从保险柜中拿出来的小带库恢复8.0.5的库,问领导bbed资料答复网上都有的失落,朋友给我发一个dul的激动,拿到oracle vpn畅游在oracle的internal资料库的爽快等等),感觉这个8.0.5的库不单是一个case,更是一种情怀,大环境的去o,也是一种大浪逝去留下的无奈,不过总的来说也算为Oracle已经奉献了最好的青春和精力,也挺自豪的.这次的库恢复本身不难,简单的总结下:
准备环境
把数据文件发给了我,准备win xp环境的虚拟机并安装8.0.5的库(安装版本要和数据库文件版本一致)
props


把数据文件,redo等拷贝到虚拟机中,并使用rename file方式重命名文件路径

SVRMGR> alter database rename file 'D:\ORANT\DATABASE\SYS1ORCL.ORA' to 'C:\805\SYS1ORCL.ORA';
语句已处理。
SVRMGR> alter database rename file 'D:\ORANT\DATABASE\USR1ORCL.ORA' to 'C:\805\USR1ORCL.ORA';
语句已处理。
SVRMGR> alter database rename file 'D:\ORANT\DATABASE\RBS1ORCL.ORA' to 'C:\805\RBS1ORCL.ORA';
语句已处理。
SVRMGR> alter database rename file 'D:\ORANT\DATABASE\TMP1ORCL.ORA' to 'C:\805\TMP1ORCL.ORA';
语句已处理。
SVRMGR> alter database rename file 'D:\DATA\OXFF01' to 'C:\805\OXFF01';
语句已处理。
………………
SVRMGR> alter database rename file 'D:\DATA\XFF15' to 'C:\805\XFF15';
语句已处理。
SVRMGR> alter database rename file 'D:\DATA\XFF16' to 'C:\805\XFF16';
语句已处理。

Thu Jul 10 00:05:41 2025
alter database rename file 'D:\ORANT\DATABASE\LOG4ORCL.ORA' to 'C:\805\LOG4ORCL.ORA'
Thu Jul 10 00:05:41 2025
Completed: alter database rename file 'D:\ORANT\DATABASE\LOG4
Thu Jul 10 00:05:41 2025
alter database rename file 'D:\ORANT\DATABASE\LOG3ORCL.ORA' to 'C:\805\LOG3ORCL.ORA'
Completed: alter database rename file 'D:\ORANT\DATABASE\LOG3
Thu Jul 10 00:05:41 2025
alter database rename file 'D:\ORANT\DATABASE\LOG2ORCL.ORA' to 'C:\805\LOG2ORCL.ORA'
Completed: alter database rename file 'D:\ORANT\DATABASE\LOG2
Thu Jul 10 00:05:43 2025
alter database rename file 'D:\ORANT\DATABASE\LOG1ORCL.ORA' to 'C:\805\LOG1ORCL.ORA'
Completed: alter database rename file 'D:\ORANT\DATABASE\LOG1

尝试recover数据库

SVRMGR> recover database;
ORA-00283: ??????????
ORA-01122: ?????29????
ORA-01110: ????29?'C:\805\XFF15'
ORA-01200: 974848?????????2048000??????

报ORA-01200错误,比较明显29号文件本身大小应该是2048000个block,但是现在只有974848个

2025-06-30  11:30     4,194,306,048 XFF14
2022-06-30  09:02     1,996,490,752 XFF15
2022-06-30  09:02     4,194,306,048 XFF16

明显该XFF15文件大小和文件头记录的不匹配,对文件头进行修改(或者修改文件大小)类似处理方法:
bbed处理ORA-01200故障
记录一次ORA-01200完美恢复
ORA-01122 ORA-01200故障处理
ORA-1200/ORA-1207数据库恢复

BBED> map
 File: XFF15 (0)
 Block: 1                                     Dba:0x00000000
------------------------------------------------------------
 Data File Header

 struct kcvfh, 360 bytes                    @0

 ub4 tailchk                                @2044


BBED> p kcvfhhdr.kccfhfsz
ub4 kccfhfsz                                @44       0x001f4000  为16进制===>>等同10进制的2048000

继续尝试恢复并打开数据库

SVRMGR> recover database;
完成介质的恢复。
SVRMGR> alter database open;
语句已处理。
SVRMGR>

由于29号文件部分丢失,导出数据遭遇ORA-08103错误
模拟普通ORA-08103并解决
模拟极端ORA-08103并解决
数据库启动ORA-08103故障恢复
数据库打开遭遇ORA-08103故障处理
ORA-01092 ORA-00604 ORA-08103故障处理
ORA-8103


对于这种错误,可以按照行的方式使用plsql进行逐行抽取,但是由于涉及的表比较多,比较麻烦,我这里直接使用dul对其进行抽取异常表
dul

然后把导出来的dmp,结合dul恢复出来的异常表数据,整合到一起,完成本次8.0.5的数据库恢复
下次遇到该版本不知道是什么时候,截个图纪念下
8.0.5

发表在 Oracle备份恢复 | 标签为 , , | 留下评论

oracle 8.1.6因断电无法启动恢复

接到一个oralce 8.1.6的数据库恢复请求,由于断电之后,系统无法正常恢复,通过尝试recover datafile报错如下

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production
PL/SQL Release 8.1.6.0.0 - Production
CORE	8.1.6.0.0	Production
TNS for 32-bit Windows: Version 8.1.6.0.0 - Production
NLSRTL Version 3.4.1.0.0 - Production
Tue Oct 16 14:17:01 2018
Media Recovery Datafile: 1
Media Recovery Start
Media Recovery Log 
Recovery of Online Redo Log: Thread 1 Group 1 Seq 146597 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO01.LOG
Tue Oct 16 14:17:02 2018
Errors in file D:\Oracle\admin\orcl\udump\ORA03040.TRC:
ORA-00600: internal error code, arguments: [kcoapl_blkchk], [1], [30547], [6101], [], [], [], []

Tue Oct 16 14:17:03 2018
Errors in file D:\Oracle\admin\orcl\udump\ORA03040.TRC:
ORA-01578: ORACLE data block corrupted (file # 1, block # 30547)
ORA-01110: data file 1: 'D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF'
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kcoapl_blkchk], [1], [30547], [6101], [], [], [], []

Tue Oct 16 14:17:03 2018
Errors in file D:\Oracle\admin\orcl\udump\ORA03040.TRC:
ORA-00314: log 2 of thread 1, expected sequence# 146598 doesn't match 146415
ORA-00312: online log 2 thread 1: 'D:\ORACLE\ORADATA\ORCL\REDO02.LOG'

这里可以获取到两个信息:1)system文件可能有坏块,导致数据库recover的时候报ORA-600 kcoapl_blkchk错误,2)数据库的redo可能异常了,由于8i数据库默认redo 10m,在业务繁忙时候切换较为频繁,而文件系统的cache导致redo信息比较老,而数据文件需要redo比较新,从而无法正常恢复成功。比较明显对于当前这样的情况只能是屏蔽数据一致性,强制拉库

ARC0: media recovery disabled
Tue Oct 16 14:17:39 2018
SMON: enabling cache recovery
Tue Oct 16 14:17:39 2018
Errors in file D:\Oracle\admin\orcl\udump\ORA02256.TRC:
ORA-00600: internal error code, arguments: [2662], [1], [1712082681], [1], [1712107587], [8388610], [], []

Tue Oct 16 14:17:41 2018
Errors in file D:\Oracle\admin\orcl\udump\ORA02256.TRC:
ORA-00600: internal error code, arguments: [2662], [1], [1712082682], [1], [1712107587], [8388610], [], []
ORA-00600: internal error code, arguments: [2662], [1], [1712082681], [1], [1712107587], [8388610], [], []

Tue Oct 16 14:17:43 2018
Errors in file D:\Oracle\admin\orcl\udump\ORA02256.TRC:
ORA-00600: internal error code, arguments: [2662], [1], [1712082682], [1], [1712107587], [8388610], [], []
ORA-00600: internal error code, arguments: [2662], [1], [1712082681], [1], [1712107587], [8388610], [], []

Tue Oct 16 14:17:45 2018
Errors in file D:\Oracle\admin\orcl\udump\ORA02256.TRC:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [1], [1712082682], [1], [1712107587], [8388610], [], []
ORA-00600: internal error code, arguments: [2662], [1], [1712082681], [1], [1712107587], [8388610], [], []

ORA-600 2662这个错误比较常见,直接推数据库scn,启动库

Tue Oct 16 16:09:11 2018
Errors in file D:\Oracle\admin\orcl\bdump\orclSMON.TRC:
ORA-00600: internal error code, arguments: [4193], [29469], [29477], [], [], [], [], []

Recovery of Online Redo Log: Thread 1 Group 3 Seq 1 Reading mem 0
  Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO03.LOG
Tue Oct 16 16:09:12 2018
Errors in file D:\Oracle\admin\orcl\bdump\orclSMON.TRC:
ORA-01595: error freeing extent (3) of rollback segment (2))
ORA-00600: internal error code, arguments: [4193], [29469], [29477], [], [], [], [], []

Tue Oct 16 16:09:13 2018
Completed: ALTER DATABASE OPEN
Tue Oct 16 16:12:06 2018
CREATE ROLLBACK SEGMENT nrbs1 TABLESPACE rbs

Tue Oct 16 16:12:06 2018
Errors in file D:\Oracle\admin\orcl\udump\ORA02252.TRC:
ORA-00600: internal error code, arguments: [4194], [79], [38], [], [], [], [], []

错误比较明显ORA-600 4194,而且已经告知是由于rollback segment 2异常,通过屏蔽回滚段,open数据库,删除老回滚段,创建新回滚段(8i无undo自动管理)

SQL> startup
ORACLE instance started.

Total System Global Area 1549432076 bytes
Fixed Size                    70924 bytes
Variable Size             500707328 bytes
Database Buffers         1048576000 bytes
Redo Buffers                  77824 bytes
Database mounted.
Database opened.

SQL> drop rollback segment "RBS1";

Rollback segment dropped.

SQL> drop rollback segment "RBS2";

Rollback segment dropped.

SQL> drop rollback segment "RBS3";

Rollback segment dropped.

SQL> drop rollback segment "RBS4";

Rollback segment dropped.

SQL> drop rollback segment "RBS5";

Rollback segment dropped.

SQL> drop rollback segment "RBS6";

Rollback segment dropped.

SQL> CREATE ROLLBACK SEGMENT nrbs1 TABLESPACE rbs;

Rollback segment created.

SQL> CREATE ROLLBACK SEGMENT nrbs2 TABLESPACE rbs;

Rollback segment created.

SQL> CREATE ROLLBACK SEGMENT nrbs3 TABLESPACE rbs;

Rollback segment created.

SQL> CREATE ROLLBACK SEGMENT nrbs4 TABLESPACE rbs;

Rollback segment created.

SQL> CREATE ROLLBACK SEGMENT nrbs5 TABLESPACE rbs;

Rollback segment created.

SQL> CREATE ROLLBACK SEGMENT nrbs6 TABLESPACE rbs;

Rollback segment created.

SQL> CREATE ROLLBACK SEGMENT nrbs7 TABLESPACE rbs;

Rollback segment created.

客户安排导出导入,至此该库恢复完成

发表在 非常规恢复 | 标签为 , , , | 评论关闭