ORACLE故障处理Word格式文档下载.docx
《ORACLE故障处理Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《ORACLE故障处理Word格式文档下载.docx（12页珍藏版）》请在冰豆网上搜索。
日期：
2001年12月
密级：
公开资料内部资料保密资料机密资料
状态：
初稿讨论稿发布
版本声明
宏智科技股份有限公司@2001
2001年版本所有，保留一切权利
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文的部分或全部，并不得以任何形式传播。
Copyright@2001byWholewiseSci.&
Tech.Co.,Ltd.
AllRightReserved.
NopartofthisdocumentmaybereproducedortransmittedinanyformorbyanymeanswithoutpriorwrittenconsentofWholewiseSci.&
Tech.Co.,Ltd.
目录
1.Oracle常见故障处理方法5
1.1SQL语句错误5
1.2一般错误5
1.3严重错误6
1.4内部错误8
1.5其他错误10
2.ORACLE常见性能问题及其处理10
2.1检测系统资源情况11
2.2收集数据库运行信息13
2.3检测应用运行情况14
1.Oracle常见故障处理方法
在ORACLE的使用过程中，我们会经常遇到一些ORACLE产生的错误，本人按照自己的想法将ORACLE错误类型进行简单划分，并就各种类型出现比较频繁的错误代码做出分析，希望能够帮助大家找到一个合理解决这些错误的方法。
本文主要不是想告诉大家怎样去解决一个具体的故障，而是希望大家能够在系统出现问题时，能够有的放矢，而不是无从下手；
同时希望大家能够掌握故障处理的基本思路，避免造成数据丢失的严重后果，确保数据的安全。
另外，在真正的应用中，可能遇到各种各样的问题，希望大家都能够一起进行故障处理方式方法的积累，共同提高大家的水平。
1.1SQL语句错误
SQL语句错误指的是由于SQL语句语法错误所导致的错误，出现类似错误时均有直接的提示错误的地方，因此不做详述。
这类错误的处理可参考《SQL*PlusUserGuideandreference》。
1.2一般错误
一般错误包括诸如表空间无法扩展、由于数据库初始化参数设置问题等导致的客户端无法登录或应用无法正常运行等等。
在进行数据库故障时应需要检查以下内容：
Ø
检查数据库错误日志。
ORACLE数据库后台出现错误时，数据库的日志文件alert$SID.log文件将详细地记录ORACLE错误代码及错误原因，但对于应用程序出错则不提供任何错误记录。
使用OS命令（如IBM的errpt、COMPAQ的dia/uerf）进行故障检测，确认是否由于OS的错误导致ORACLE故障，检查OS错误日志。
使用ipcs命令检查信号量和共享内存是否分配正常
检查UNIX空间使用情况及内存、CPU资源使用情况
检查数据库相关文件属性
检查tnsnames.ora、listener.ora、init.ora、config.ora等配置文件
检查数据库环境变量是否正确
ORACLE数据库提供了一个简单的ORACLE故障检测命令，$oerroraerror_no，通过这个命令可以很方便地判断出故障原因；
同时这个命令还提供了一个故障解决的建议，通过它可以方便的进行故障处理。
（注：
ORACLE的故障信息库保存在$ORACLE_HOME/rdbms/mesg目录下）
例1：
在ORACLE错误日志中出现ORA-1542错误，处理方式：
$oerrora1542
01542,00000,"
tablespace'
%s'
isoffline,cannotallocatespaceinit"
//*Cause:
Triedtoallocatespaceinanofflinetablespace
//*Action:
Bringthetablespaceonlineorcreatetheobjectin
//othertablespace
通过oerr命令我们可以清楚的了解到由于表空间处于offline状态，因而故障解决方法就是online相应的表空间。
例2：
ORA-01652错误
$oerrora1652
……
//Cause:
Failedtoallocateextentfortempsegmentintablespace
//Action:
UsetheALTERTABLESPACEADDDATAFILEstatementtoaddoneormorefilestothespecifiedtablespaceorcreatetheobjectinanothertablespace.
通过oerr命令我们知道由于无法扩展临时表空间导致应用出错，解决方法是增加临时表空间大小或指定更大的临时表空间。
一般来说系统管理人员可以通过监控应用运行情况、数据库性能指标，及时调整数据库的初始化参数（如dml_locks、open_cursors、open_links等）、数据据库表空间大小、数据库对象的存储策略以避免出现以上错误影响系统正常运行。
1.3严重错误
严重故障主要包括数据库无法正常启动、数据库出现坏块、数据库需要进行恢复等等。
对于数据库的故障处理，最重要的事情是保证数据的安全！
因此在进行这种类型的数据库故障处理前，必须注意以下几点：
●如果数据库已经处于打开状态，不要随意关闭数据库；
甚至如果某个用户语句已经登录数据库，不要随意退出
●保留$ORACLE_BASE/admin/$SID/bdump/alert$SID.log文件中错误信息及与错误信息相对应的trace文件（$ORACLE_BASE/admin/$SID/udump/*.trc）
●分析alert.log文件中出现的主要错误
●根据实际情况确定是否对数据库进行物理备份（包括数据库控制文件、重做日志文件、回滚表空间、用户数据表空间，临时表空间不需要进行备份）
●故障处理从简单到复杂进行，不要一开始就采用诸如增加ORACLE隐含参数如_corrupted_rollback_segment等试图强行打开数据库
●故障处理完毕后，可能需要对数据库进行再次备份
●使用增加某些隐含参数强制打开数据库后，可能需要重建数据库。
例如：
ORA-01578错误（一般伴随着ORA-01110、ORA-01109等错误）
$oerrora1578
//Cause:
Thegivendatablockwascorrupted,probablyduetoprogramerrors
//Action:
Trytorestorethesegmentcontainingthegivendatablock,Thismayinvolvedroppingthesegmentandrecreatingit,Ifthereisatracefile,reportthemessagesrecordedinittocustomersupport.
该错误是ORACLE认为一个数据块可能被破坏而发生的，通常引起该错误的原因有以下几种：
I/O的硬件或firmware损坏
操作系统I/O或cache故障
内存或页交换出错（例如ORA-01578错误伴随ORA-00600[3374]则表明内存出错，通过重新启动主机可能可以解决故障）
部分数据文件被覆盖、试图访问未格式化块、磁盘修复或其他原因
该错误的最佳解决方法（数据库运行在归档模式下）是恢复备份的数据文件及控制文件，执行recover操作。
如果数据库运行在非归档模式下或数据库没有进行良好的备份，则：
●查看log以及trace文件，检查是否有其他错误发生
●定位错误
sql>
select*fromv$datafilewherefile#=<
F>
;
selectowner,segment_name,segment_typefromdba_extents
>
wherefile_id=<
and<
B>
between
block_idandblock_id+blocks-1;
基于返回的segment_type：
-segment类型为temporary、cache或无返回值，检查SQL语句
-segment类型为rollbacksegment，则数据库需要恢复
-segment类型为index，检查其所在的表，重建索引即可
-仍然出现1578错误，数据库需要恢复
-segment类型为表，拯救表中的数据。
●分析一个实体是否有永久性数据破坏，建议以下语句多执行一两次，有助于鉴别该错误是永久性的（磁盘物理损坏）还是随机性的（内存或硬件错误所引起）。
analyzetabletable.namevalidatestructurecascade;
analyzetableclusternamevalidatestructurecascade;
●出现类似错误后需要及时进行数据的恢复（可以采用创建临时表并插入损坏的块前/后的数据或设置skip_corrupted标志忽略损坏数据块并导出数据的方式进行数据恢复），具体数据恢复方式可参见《ORACLE故障处理手册》等书，在此不做详述。
●尤其值得注意的是，ORA-1578错误90%以上都是由于硬件故障所造成，频繁出现类似故障应重点从操作系统上对系统进行检测。
1.4内部错误
ORACLE内部错误包括ORA-00600错误及ORA-07445错误等。
同样的，我们可以采用oerr命令查看具体的错误原因：
$oerrora600
00600,00000,"
internalerrorcode,arguments:
[%s],[%s],……[%s],[%s],[%s]"
ThisisthegenericinternalerrornumberforOracleprogram
//exceptions.Thisindicatesthataprocesshasencounteredan
//exceptionalcondition.
Reportasabug-thefirstargumentistheinternalerrornumber
一般来说，有些的ORA-00600错误是由ORACLE软件的bug所导致，因此对于这样的错误需要及时联系ORACLE技术支持工程师（也可以上Metalink站点进行查询，开iTAR），并将错误日志文件及相应的trace文件Mail给ORACLE技术支持工程师。
对于这种类型的ORA-00600错误，一个简单的处理方式就是打补丁，将数据库升级到一个稳定的版本，另外建议屏蔽某些ORACLE特性，诸如MTS（MultiThreadServer）。
但也有部分错误是由数据库内部的表或索引（包括应用的）结构被损坏所或其他原因所造成。
ORA-600[12700]表示执行SQL语句时对应的某些实体（表/索引）损坏；
该错误的处理方法为：
●修改init$ORACLE_SID.ora文件，增加如下几行：
event=“10210tracenamecontextforeverlevel10”
event=“10211tracenamecontextforeverlevel10”
event=“10231tracenamecontextforeverlevel10
●执行以下语句：
analyzetable/index/cluster[name]validatestructure;
●如果怀疑是数据字典损坏，则不能采用以上的方法对表进行分析，因为在某些平台上执行以上操作将引起系统瘫痪，执行如下存储过程：
DBMS_UTILITY.ANALYZE_SCHEMA
在对数据库进行读写操作时出现错误：
ORA-00600:
internalerrorcode,arguments:
[4519],[6711],[2],…表示执行SQL语句时的对应的实体数据块[6711]的结构被破坏所引起；
●执行如下的package进行分析：
svrmgrl>
selectdbms_utility.data_block_address_file（6711）fromdual;
selectdbms_utility.data_block_address_block（6711）fromdual;
查找其对应的block_id和file_id。
●通过如下的sql命令查找出被破坏的实体类型、owner等：
selectsegment_name,segment_type,owner
fromdba_extents
wherefile_id=file#andblock#between
●如果被破坏的对象并非系统表或索引，则可以通过对该数据库对象进行备份后重新创建实体的方法进行；
如果出现的错误为系统的表或索引则需要根据实际情况进行处理
例3：
在update某一张表的时候出现如下错误：
ORA-00600：
[13013][5003]
（1）[3993]
（2）[38883]（3）[]，该错误是这张表及其对应的索引数据块不一致，其中
（1）表示Passcount
（2）表示code（3）表示address（修改行的block#）；
该错误的处理方式是：
执行analyzetabletable_namevalidatestructurecascade，然后可以尝试drop该索引；
但如果执行后的结果没有出现任何错误，则可能是ORACLE的bug。
因此，在出现ORA-00600错误时，可以查看该错误所对应的trace文件，如果发现若干个trace文件中均报在对某张表进行操作时出现ORA-00600错误，则可以尝试着对该表进行分析：
analyzetablescott.empvalidatestructurecascade;
1.5其他错误
所谓的其他错误指的是一些不产生错误号的故障，诸如数据库挂起、响应速度缓慢等等，这些问题可能是由于数据库参数调整、数据库物理设计、应用设计问题所导致，也有可能是数据库本身的问题。
这些问题将在“ORACLE常见性能问题及其处理”中进行讨论。
2.ORACLE常见性能问题及其处理
一般来说，我们经常碰到客户的系统管理员说出现了“系统性能缓慢”、“数据库没有响应”等问题，而也许有些问题客户的系统管理员只是简单的重新启动主机然后“故障”就消失了，有些则一直存在，希望下文能给大家在处理这类问题时有所帮助。
一般来说，系统性能调整需要从多个角度进行调整，包括操作系统、数据库（包括数据库物理设计等）、应用多个方面进行调整，同时要在系统运行过程中进行持续监控才能了解到系统的瓶颈所在，在处理类似问题时间才能有的放矢，得心应手。
以下就从这几个方面谈谈如何进行这方面“故障”的处理。
2.1检测系统资源情况
unix操作系统提供了一些监控系统运行情况的命令（如vmstat、iostat、sar、top）或工具（如pmgr），通过这些命令/工具能够轻易的看出系统的资源使用情况，以下以HP-UX为例进行简单说明：
1．CPU使用情况检测
#sar110
17:
36:
09%usr%sys%wio%idle
10663400
11653500
17643600
18722800
19811900
由此可知目前系统的CPU资源负荷极重，导致系统运行速度缓慢，性能下降。
当然，出现类似问题可能是由于CPU处理能力无法满足系统的需求，也可能是应用或其他原因引起。
对于前者，可能需要通过扩容方式进行解决，对于后者，还需要从其他方面进行检查。
2．检查IO使用情况
#iostat1
c4t0d0302232.41.0
c4t1d04599138.21.0
c4t0d034119.21.0
c4t1d04025156.61.0
由此可知目前c4t1d0磁盘上io操作较多，但结合sar的输出结果（wio为0），因此可以认为IO不是系统的瓶颈所在。
3．检查系统内存使用情况
4．检查最占用系统资源的程序
#top
System:
zz186aTueJul1717:
35:
342001
Loadaverages:
2.35,2.43,2.41
215processes:
205sleeping,10running
Cpustates:
CPULOADUSERNICESYSIDLEBLOCKSWAITINTRSSYS
02.4570.3%0.0%29.7%0.0%0.0%0.0%0.0%0.0%
12.2667.3%0.0%32.7%0.0%0.0%0.0%0.0%0.0%
-----------------------------------------------
avg2.3568.3%0.0%31.7%0.0%0.0%0.0%0.0%0.0%
Memory:
261440K（107324K）real,230548K（108508K）virtual,218956KfreePage#1/20
CPUTTYPIDUSERNAMEPRINISIZERESSTATETIME%WCPU%CPUCOMMAND
0?
16023oracle2402020420K1456Krun3644:
3249.8449.76zz186
15998oracle2412020404K1408Krun3500:
3645.0544.97zz186
1?
14595oracle2412020244K1280Krun2848:
5541.8141.73zz186
由此可知道应用程序占用了大量的CPU及内存资源，应当从应用角度对系统进行分析，确定是否由于应用问题导致系统响应缓慢。
5．其他
对于数据库出现类似“故障”的情况下，还需要检查交换区空间使用情况（交换区空间不足将导致客户端无法正常登录等异常情况）、磁盘空间使用情况（磁盘空间不足将导致数据库挂起等）、Cluster运行情况等。
2.2收集数据库运行信息
1．如果由2.1检测出系统运行极其繁忙，则可以考虑使用ORACLE数据库提供的两个简单脚本（utlbstat.sql/utlestat.sql）用以收集数据库运行信息，通过分析运行这两个脚本生成的report.txt文件可以了解数据库的一些基本信息，包括缓冲区命中率、磁盘IO分布等，可以对ORACLE初始化参数、表/索引存储策略的调整提出一些建议。
svrmgrl>
@?
/rdbms/admin/utlbstat.sql
执行该语句30分钟左右后，
/rdbms/admin/utlestat.sql
将生成一个名为report.txt文件，分析该文件：
StatisticTotalPerTransactPerLogonPerSecond
tablescans（longtables）595.1913.22.96
tablescans（shorttables）4209713.71935.4967.79
EventNameCountTotalTimeAvgTime
SQL*Netmessagetodblink192020
enqueue39732630.67
这表明数据库中对大表的全表扫描较多，建议通过分析应用确认是否可以通过修改SQL语句或增加索引以减少大表的全表扫描（对大表的全表扫描将增加大量的IO开销）；
同时小表的全表扫描非常多，建议将最经常进行全表扫描的小表放到cache中以减少IO开销。
另外，数据库等待waitevent中“enqueue”等待在数据库事务处理的等待时间中占了很大的比例，说明数据库中有大量的锁存在。
应检查系统中锁的类型，如果锁的类型为TM（DMLenqueue），考虑在外键上创建索引。
2．如果由2.1检测出系统较为空闲，则应首先检查数据库的V$SESSION_WAIT试图，查看数据库在等待什么：
svrmgrl>
select*fromv$session_waitwhereeventnotlike‘SQL%’;
…bufferbusywait
…DFSenqueuelockacquistition
…lockelementwaits
由（bufferbusywait）可知，目前系统正在等待IO，可以检查系统IO忙闲程度，如果系统IO很闲，检查数据库参数如“db_block_lru_latch”并进行相应调整。
2.3检测应用运行情况
若由2.1检测出部分ORACLE进程长时间占用大量的CPU资源，则应考虑对应用进行跟踪，ORACLE提供了一个非常实用的包用以进行应用的跟踪分析，具体使用步骤如下：
svrmgrl>
altersystemsettimed_statistics=true;
检测出最占用CPU资源的ORACLE进程的sid和serial#：
selectsid,serial#fromv$sessionwherepaddr=
>
（selectaddrfromv$processwherespid=&
SPID）;
执行如下
升级会员 