oracle数据库一次意外宕机的分析处理实记(ora-1578)

《oracle数据库一次意外宕机的分析处理实记(ora-1578)》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、一个安静的下午，测试环境中一台装有ORACLE数据库的ATX小机因意外断电而导致其上的oracle数据库宕机了。由于是测试环境，安排了一个工程师过去解决了，具体是这样解决的：首先重启了小机服务器，启动完后，发现oracle所在的/app@录没有mount上。然后通过smittyfs修复了一下，mount上了app,再接着启动orac1e就起来了。事后搜集了system,txt系统日志（通过eirpt-a获得）和alert_soa.log以及oracle的跟踪日志trc,分析trcH志看到如下：/app/orac1e/product/10.2.0/admi

2、n/soa/bdump/soa_mmon_307366・trcOracleDatabaselOgEnterpriseEditionRelease10.2.0.4.0一64bitProductionWiththePartitioning,OLAP,DataMiningandRealApplicationTestingoptionsORACLEHOME=/app/oracle/product/10.2.0Systemname:ATXNodename:data2Release:3Version:5Machine:00CE993C4C00Instancename

3、:soaRedothreadmountedbythisinstanee:1Orac1eprocessnumber:11Unixprocesspid:307366,image:oracle@data2(MMON)***2013-03-0114:06:10.308***SERVICENAME:(SYS$BACKGROUND)2013-03-0114:06:10.212***SESSIONID:(161.1)2013-03-0114:06:10.212Hexdumpof(file3,block49259)Dumpofmemoryfrom0x07000000C5

4、934000to0x07000000659360007000000C593400006A2000000C0C06B0178F61400000104[k.x]7000000C593401045A30000010A00250000224D0178F614[E%..x.・]7000000C5934020000000001F02320000C0C06900010003[2....i....]又观察另两个文件，发现有较多0RA-1578报错和DISKOPERATIONERROR。分析：一般在进行CLUSTER双机切换、意外断电或其它情况下，有时会发生某个共享盘MO

5、UNT不上的情况，需要使用FSCK对共亨盘进行修复，然后再MOUNT.当修复完成后，顺利的话数据库对以直接起来，否则在数据库启动过程中就会报出〃数据块损坏，无法启动数据库〃的现象。此吋，我们可以根据不同的数据块损坏类型，检测并修复错误并确定解决问题的方案。一、数据块损坏产生原因:1.硬件问题（磁盘控制器问题或磁盘本身故障问题）2.物理级的数据块损坏（通常由前一原因造成）3、逻辑的数据块损坏二、坏块的原理分析：Oracle的数据块有固定的格式和结构，分三层：Cachelayer、Transactionlayer和Data1ayer.对数据块进行读写操作时，

6、做一致性检查：-Blocktype-DBA-Sen-Headerandtai1发现不一致，标记为坏块。坏块有两种：物理坏块和逻辑坏块。坏块产生的影响：数据字典表、回滚段表、临时段和用户数据表和索引。三、确定故障原因与对应的解决办法：1、查看alert,log文件中，还有无其它ORA-的错误，如果报错指向不同磁盘的文件，则是磁盘控制器的问题，查看V$DATAFTLE,看有哪些文件位于该控制器下，需要查找磁盘控制器（一般控制器有两个A控和B控）是否正常。2、如果报错指向相同磁盘的不同文件，则是磁盘的问题，筒要查看磁盘有无报警，有无报错等。3、如果指向相同磁盘

7、的同一个文件，则可以执行以下语句查找文件名：SELECTSEGMENT_NAME,SEGMENT_TYPEFROMDBA_EXTENTSWHEREFILE_ID=<文件号〉AND<块号〉BETWEENBLOCKIDANDBLOCKID+BLOCKS-1;其中，文件号与块号在报错日志中可以查到，如果该查询持续指向某表或索引，则重建它们即可。4、如果文件是SYSTEM表空间，或处于NOARCHIVELOG模式，在数据库还在运行状态时，EXP导出全部数据，重建库，再IMP灌入新库即可。5、如果数据库处于ARCHIVELOG模式，可以使用DBV校验坏块，然后通过

8、RMAN来修复坏块，成功后启动数据库。或者另一种方案关闭数据库，如果不能关闭数据