一位DBA或多或少遇到过ORA-1578、ORA-7445、ORA-600等错误，这些迹象表明，这是大部分DBA都很痛恨的症状：损坏。然而Oracle数据库结构中的损坏并不是经常发生，但是当它发生的时候必须立刻处理。寻找损坏的原因，并采用积极措施确保不再发生次生危害。
一位DBA多多少少的遇到过ORA-1578、ORA-7445、ORA-600等错误，这些迹象表明，这是大部分DBA都很痛恨的症状：损坏。然而Oracle数据库结构中的损坏并不是经常发生，但是当它发生的时候必须立刻处理。寻找损坏的原因，并采用积极措施确保不再发生次生危害。
一、预防、检测和修复损坏
首先，重要的是区分两种损坏的类型：内存损坏和数据块损坏。
ORA-7445,通常表示内存损坏，这个错误的根本原因有很多，它可能是由数据服务器的DRAM、I/O控制器内存，甚至是磁盘驱动器的内存缓存的故障起的，这种类型的错误，细的多次测试来确定根本原因，甚至可能需要适当的硬件技术人员进行干预，诊断隔离和修复问题的最终根源。
ORA-600或ORA-1578错误通常表示数块或内存缓冲区，逻辑或物理上的损坏，损坏意味着数据库不能正确地识别块儿或缓冲区，可能块头已经被损，或者它的实际大小不再匹配其预期的大小。逻辑上的损坏意味着即使块或缓冲区结构仍然完成，但其内容已经是混乱的，并且对数据库来说已经无法辨别这些问题。由于与这些问题主要是Oracle DBA的权限范围内，因此将重点讨论如何预防、检测和修复这种类型的损坏。
预防：聪明的DBA花时间来预测问题，遵循推荐的最佳实践，包括避免数字硬件和网络的单点故障，使用像OEM12c cloud control这样的工具对硬件和数据库设置适当的监控，并为特定的初始化参数设置适当的值，限制或消除数据库损坏。
检测：当用户报告在他的屏幕上出现一个奇怪的错误信息时，才会去检测数据库损坏，通常情况下应对相应的数据库告警日志进行仔细的搜索，查找与数据库损坏相匹配的ora-178错误。但是在应用程序错误之外，也可以通过以下方式是否损坏：1、定期执行RMAN备份。2、对数据库、表空间或数据文件执行RMan Backup vaildate命令，也可以加上check logical子句来识别逻辑损坏。3对指定的数据库段使用DBMS_REPAIR包。4、使用数据库验证工具对指定的数据文件执行验证，如DBverify。
这些情况下，V$Database_Block_Corruption动态视图会记录被损坏块的信息，可以利用这些信息来修复被损坏的块。
修复：检测到损坏oracle dba的工作，就是尽快修复损坏，修复损坏的合适方法，取决于检测到损坏类型，对象对数据库应用程序的重要性，甚至是已经实现的特定灾难恢复环境，包含N年前数据的分区表中，最早的历史分区中的一个损坏的数据库块与同一表中最热分区中的块相比，显然不那么紧迫。
二、处理内存损坏
当将快读取到oracle缓冲区缓存时，oracle后台进程会验证从磁盘读取的块。后台进程将数据库块头，布的Inc和sEQ与尾部的Inc和sEQ结构相比较，确保块儿的版本完全相同。这个验证可以防止Oracle数据库从磁盘读取到包含损坏块头的数据块。即使这样，仍然有可能发生内存损坏，可能的因素如下：1、Oracle软件的bug。
2、操作系统的bug。
3、非Oracle程序写入已经被oracle使用的内存地址。
4、硬件问题。
预防：Oracle数据库块不必要损坏的最好方法之一是将初始化参数BD_Block_Checksum设置为推荐值Full。Oracle数据库将先验证块在逻辑上的一致性 ，然后在将其写到磁盘上。但是请注意，如果应用程序工作负载严重偏向DML，那么可能会造成高达10%的性能损失，因此这个块检查需要进行额外的验证处理。从Oracle 11g开始，可以更简单地设置初始化参数DB_ULTRA_SAFE到合适的值防止损坏，该参数有三个值：
1、设置为OFF，DB_CLOCK_CHECKING、DB_BLOCK_CHECKSUM、DB_LOST_WRITE_PROTECT参数将被停用（如果需要可以单独设置）。
2、设置为DATA_ONLY，那么将DB_CLOCK_CHECKING设置为MEDIUM，将DB_LOST_WRITE_PROTECT设置为TYPICAL，将DB_BLOCK_CHECKSUM设置为FULL。
3、设置为DATA_AND_INDEX,那么将DB_CLOCK_CHECKING和DB_BLOCK_CHECKSUM设置为FULL，将DB_LOST_WRITE_PROTECT设置为TYPICAL。
检测：通过监控数据库实例告警日志中的ORA-600错误通常会检测到内存损坏：但是当数据库应用程序用户意外收到ORA-600的错误或将于内存损坏相关的错误信息报告给DBA时才可能被检测到。
修复：重新启动数据库时是消除某些内存错误一种潜在方法，Oracle Hanganalyze实用工具是收集更多信息的优秀工具，而且在打开SR（oracle service request）以解决内存损坏问题时，Oracle支持人员也需要更详细的信息。收集Hanganalyze信息方式有两种：SQL*PLUS和Oradebug。
以SQL*PLUS调用Hanganalyze为例演示：在数据库挂起时，收集数据库性能问题有关信息的最好方法之一就是使用Hanganalyze
步骤如下：
1、以SYSDBA身份打开一个SQLPLUS会话，然后执行下面的命令
alter session set events 'immediate trace name hanganalyze level 3';
2、等待一分钟然后在执行同样的命令
alter session set events 'immediate trace name hanganalyze level 3';
3、再等待一分钟然后在执行同样的命令
alter session set events 'immediate trace name hanganalyze level 3';
4、再等待一分钟，然后执行命令并设置另一个事件
alter session set events 'immediate trace name systemstate level 266';
5、再等待一分钟，然后执行同样的命令
alter session set events 'immediate trace name systemstate level 266';
6、再等待一分钟，然后执行同样的命令
alter session set events 'immediate trace name systemstate level 266';
7、退出SQLPLUS会话，收集数据库USER_DUMP目录中的所有跟踪文件。
使用Hanganalyze而不能持久的SQL*PLUS连接，如果数据库发生挂起，并且通过SQL*PLUS无法登陆到数据库，那么可以使用下面方法
1、使用以下命令登录
sqlplus -prelim as sysdba
2、设置会话的PID
oradebug setmypid
3、设置会话为unlimit
oradebug unlimit
4、执行Hanganalyze命令
oradebug hanganalyze 3
5、等3分钟再执行命令
oradebug hanganalyze 3
6、再等3分钟再执行一次命令
oradebug hanganalyze 3
7、再等3分钟然后执行一下命令
oradebug dump systemstate 10
8、现在等7分钟然后执行一下命令
oradebug dump systemstate 10
9、再等7分钟然后执行一下命令
oradebug dump systemstate 10
10、取消跟踪停止会话，将user_dump_dest目录中的相关文件进行分析。
注意：如果分析RAC数据库，使用oradebug setinst all来捕获所有实例的信息。
下一篇继续讲处理逻辑损坏和介质损坏。
