ORACLE数据库一次意外宕机的分析处理实记.docxVIP

一个安静的下午，测试环境中一台装有ORACLE数据库的ATX小机因意外断电而导致其上的 oracle数据库宕机了。由于是测试环境，安排了一个工程师过去解决了，具体是这样解决 的：首先重启了小机服务器，启动完后，发现oracle所在的/app @录没有mount上。然后 通过smitty fs修复了一下，mount上了 app,再接着启动orac 1 e就起来了。 事后搜集了 system, txt系统日志（通过eirpt-a获得）和alert_soa. log以及oracle的跟 踪日志trc,分析trc H志看到如下： /app/orac1e/product/10. 2. 0/admin/soa/bdump/soa_mmon_307366? trc Oracle Database lOg Enterprise Edition Release 10.2.0.4.0 一 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options ORACLE HOME = /app/oracle/product/10. 2. 0 System name: ATX Node name: data2 Release: 3 Version: 5 Machine: 00CE993C4C00 Instance name: soa Redo thread mounted by this instanee: 1 Orac1e process number: 11 Unix process pid: 307366, image: oracle@data2 (MMON) *** 2013-03-01 14:06:10. 308 *** SERVICE NAME:(SYS$BACKGROUND) 2013-03-01 14:06:10.212 *** SESSION ID:(161. 1) 2013-03-01 14:06:10.212 Hex dump of (file 3, block 49259) Dump of memory from 05934000 to 0x0700000065936000 7000000C5934000 06A20000 00C0C06B 0178F614[ k. x ] 7000000C5934010 45A30000 010A0025 0000224D 0178F614 [E %.. x.?] 7000000C59340201F023200 00C0C069[ 2. ... i....] 又观察另两个文件，发现有较多0RA-1578报错和DISK OPERATION ERROR。 分析：一般在进行CLUSTER双机切换、意外断电或其它情况下，有时会发生某个共享盘MOUNT 不上的情况，需要使用FSCK对共亨盘进行修复，然后再MOUNT.当修复完成后，顺利的话数 据库对以直接起来，否则在数据库启动过程中就会报出〃数据块损坏，无法启动数据库〃的现 象。此吋，我们可以根据不同的数据块损坏类型，检测并修复错误并确定解决问题的方案。 一、数据块损坏产生原因: 硬件问题（磁盘控制器问题或磁盘本身故障问题） 物理级的数据块损坏（通常由前一原因造成） 3、 逻辑的数据块损坏 二、 坏块的原理分析： Oracle的数据块有固定的格式和结构，分三层：Cache layer、Transaction layer和Data 1 ayer. 对数据块进行读写操作时，做一致性检查： -Block type -DBA -Sen -Header and tai 1 发现不一致，标记为坏块。坏块有两种：物理坏块和逻辑坏块。坏块产生的影响：数据字 典表、回滚段表、临时段和用户数据表和索引。 三、 确定故障原因与对应的解决办法： 1、查看alert, log文件中，还有无其它ORA-的错误，如果报错指向不同磁盘的文件，则是 磁盘控制器的问题，查看V$DATAFTLE,看有哪些文件位于该控制器下，需要查找磁盘控制 器（一般控制器有两个A控和B控）是否正常。 2、 如果报错指向相同磁盘的不同文件，则是磁盘的问题，筒要查看磁盘有无报警，有 无报错等。 3、 如果指向相同磁盘的同一个文件，则可以执行以下语句查找文件名： SELECT SEGMENT_NAME, SEGMENT_TYPE FROM DBA_EXTENTS WHERE FILE_ID=文件号〉AND 块号〉BETWEEN BLOCK ID AND BLOCK ID+BLOCKS-1; 其中，文件号与块号