eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« SAP的 XI_AF_MSG 消息表优化及清理 | Blog首页 | SAP系统 SYSFAIL 失败TCPSBUILD 案例一则 »

ORA-27069 文件数据块损坏 数据库恢复一则

在Oracle数据库中,不同平台上存在的种种限制,可能导致数据库异常,我认为这是Oracle数据库的不足,这些确定性的约束,应当在软件中体现出来,并且应当能够进行一定程度的避免,当然可能要 付出一点代价。

在客户的Windows 2000 Server + Oracle 8.1.7 环境中,遭遇到文件越界( > 16G ),导致读写失败的案例。
出现的错误是这样的:
Mon Mar 07 17:10:39 2011
Thread 1 cannot allocate new log, sequence 431517
Checkpoint not complete
  Current log# 3 seq# 431516 mem# 0: H:\ORADATA\ORACLE\REDO01.LOG
Mon Mar 07 17:10:41 2011
KCF: write/open error block=0x1fd8d0 online=1
     file=8 H:\ORADATA\ORACLE\SMARTDATA.DBF
     error=27069 txt: 'OSD-04026: 无效的参数经过. (OS 2087120)'
Automatic datafile offline due to write error on
file 8: H:\ORADATA\ORACLE\SMARTDATA.DBF
KCF: write/open error block=0x1fc85a online=0
     file=8 H:\ORADATA\ORACLE\SMARTDATA.DBF
     error=27069 txt: 'OSD-04026: 无效的参数经过. (OS 2082906)'
KCF: write/open error block=0x1ff405 online=0
     file=8 H:\ORADATA\ORACLE\SMARTDATA.DBF
     error=27069 txt: 'OSD-04026: 无效的参数经过. (OS 2094085)'
KCF: write/open error block=0x1ff398 online=0
     file=8 H:\ORADATA\ORACLE\SMARTDATA.DBF
     error=27069 txt: 'OSD-04026: 无效的参数经过. (OS 2093976)'
KCF: write/open error block=0x1ff406 online=0
     file=8 H:\ORADATA\ORACLE\SMARTDATA.DBF
     error=27069 txt: 'OSD-04026: 无效的参数经过. (OS 2094086)'

数据库的 db_block_size 是 8192 ,计算下来 Block 2087120 的大小是 15.9234619140625 G,在文件扩展超过16G之后,数据库直接崩溃,文件Offline,无法正常完成Recover。

在以前的很多案例中,出现的情况多数是临时表空间扩展越界,而这个案例中,是数据文件的问题,这显然是无法轻易解决的。

在 打开数据库时,这个文件会置为Recover模式,不能读取,SMON的事务恢复将遇到错误:
Mon Mar 07 17:48:44 2011
SMON: enabling tx recovery
ORACLE Instance oracle (pid = 6) - Error 376 encountered while recovering transaction (3, 43) on object 114260.
Mon Mar 07 17:48:44 2011
Errors in file E:\oracle\admin\oracle\bdump\oracleSMON.TRC:
ORA-00376: file 8 cannot be read at this time
ORA-01110: data file 8: 'H:\ORADATA\ORACLE\SMARTDATA.DBF'

在这种模式下采取强制手段是可以打开数据库的,但是肯定会损失部分数据。

用户拥有有效的备份,通过备份,恢复丢失的文件,应用归档日志,可以将更改向前推进,但是最终还是会到达文件扩展超过16GB的时间点:
ORA-00279: change 234566155 generated at 03/07/2011 17:10:39 needed for thread 1
ORA-00289: suggestion : H:\ORADATA\ORACLE\ARCHIVE\ORACLET001S31516.ARC
ORA-00280: change 234566155 for thread 1 is in sequence #431516
ORA-00278: log file 'H:\ORADATA\ORACLE\ARCHIVE\ORACLET001S31515.ARC' no longer
needed for this recovery


ORA-00283: recovery session canceled due to errors
ORA-01115: IO error reading block from file 8 (block # 2097138)
ORA-01110: data file 8: 'H:\ORADATA\ORACLE\SMARTDATA.DBF'
ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file
OSD-04026: 无效的参数经过. (OS 2097138)


ORA-01112: media recovery not started

最后选择恢复到故障点之前,将数据库Resetlogs打开,完成不完全恢复。

以下是RMAN恢复的简单语句:
RMAN> run
2> {
3> allocate channel d9 type disk;
4>
5> restore datafile 8;
6> }

RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: d9
RMAN-08500: channel d9: sid=20 devtype=DISK

RMAN-03022: compiling command: restore

RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel d9: starting datafile backupset restore
RMAN-08502: set_count=25432 set_stamp=745119263 creation_time=07-MAR-11
RMAN-08089: channel d9: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00008 to H:\ORADATA\ORACLE\SMARTDATA.DBF
RMAN-08023: channel d9: restored backup piece 1
RMAN-08511: piece handle=I:\ORABAK\FULL_745119263 tag=null params=NULL
RMAN-08024: channel d9: restore complete
RMAN-08031: released channel: d9

RMAN>

在完成恢复后还遇到ORA-04031的错误:
*** 2011-03-10 11:32:53.968
ksedmp: internal or fatal error
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 4032 bytes of shared memory ("shared pool","java/lang/StringSYS","joxlod: in ehe","ioc_allocate_pal")
ORA-06512: at "SYS.DBMS_JAVA", line 0
ORA-06512: at line 2
*** 2011-03-10 11:33:37.921
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [26599], [1], [226], [], [], [], [], []
Current SQL statement for this session:
BEGIN
 dbms_java.server_shutdown
; END;
----- PL/SQL Call Stack -----
  object      line  object
  handle    number  name
1c82905c         0  package body SYS.DBMS_JAVA
1c775bd0         2  anonymous block
----- Call Stack Trace -----

这是由于数据库启动时,JAVA的触发器导致错误,而关闭数据库时,由于 dbms_java.server_shutdown 过程调用,又会出现ORA-600 26599错误,这个问题,可以通过设置初始化参数 _SYSTEM_TRIG_ENABLED=FALSE 来暂时关闭,之后可以通过如下脚本来重建触发器:
create or replace trigger aurora$server$shutdown
before shutdown on database call dbms_java.server_shutdown
/
这可以参考MOS Note:271370.1 。

这个案例给我们两点启示:
1.备份决定生死,保有有效备份是系统安全的第一条基本原则。
2.了解数据库的限制,通过一些守则规避问题是防止步入麻烦的捷径

   >>比如,在某些系统下,我们要警惕 4G ,16G ,32G等边界线。



历史上的今天...
    >> 2016-03-11文章:
    >> 2009-03-11文章:
    >> 2008-03-11文章:
    >> 2007-03-11文章:

无觅

By eygle on 2011-03-11 08:17 | Comments (4) | Backup&Recovery | 2754 |

4 Comments

"选择恢复到故障点之前"
然后再通过添加几个小于16G的文件吗?

这是文件系统的系统,,不是数据库的限制.


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com