Oracle-常见故障处理

Oracle常见故障第一楼目录故障分类一数据库挂起故障1由于ARCHIVE挂起导致数据库挂死2NIT文件中SGA区设置太大，导致内存不够用，数据库和系统都挂死3由于临时表空间无法扩展导致数据库被挂起4由于未打补丁导致RMAN备份时将数据库挂起故障分类二数据库功能/性能异常5由于BLOB类型的表记录数太多操作又太频繁导致数据库效率急差6由于未对特大表（达到或超过100万条记录）定期做表分析导致数据库操作特别慢7由于空间不够导致插入数据时扩展索引失败8由于REDOLOG破坏导致数据库异常9由于控制文件被破坏导致数据库无法正常启动10由于数据文件丢失或破坏导致数据库无法正常启动11由于空间参数设置不合理导致扩展表空间、索引等失败12由于时间格式的环境变量设置问题导致话单无法入库13由于大事务未使用大回滚段导致事务挂起14由于数据库连接数太多导致服务器进程数多或内存耗尽15由于使用了MTS方式，导致数据库操作特别慢（包括备份）16由于存在一个大事务操作，导致数据库性能特别差或产生频繁日志切换17由于没有COMMIT，导致数据库表被锁住18索引创建不合理，导致数据库查询特别慢19由于BUFFER参数设置不合理导致EXP失败20由于EXP不向上兼容，语言不兼容，导致不同版本、不同字符集的数据库无法导入21由于创建表空间时误将其创建在以‘本地管理’，导致在表空间上的所有对象无法修改其存储参数22错误地在系统表空间上建无关的数据文件23ORACLE客户端在P4上安装不成功24由于LISTENER.ORA或TNSNAMES.ORA配置问题导致网络问题25由于环境变量设置问题导致VERSOIN版本启动问题26用户数据、表破坏下的数据恢复27由于OS层问题导致数据库ORA-600错误故障分类三将导致数据库安装失败或打补丁失败的情况28由于环境变量或没有安装MAKE文件导致数据库安装失败29由于/TMP等文件系统设置太小导致数据库无法正常安装30HPUX上由于核心参数设置不对导致数据库无法正常启动31在64位的ORACLE817上打32的补丁失败32由于安装备机数据库时是使用的拷贝方式，所以导致在备机上安装补丁失败33由于安装ORACLE时错误地在$ORACLE_HOME目录下创建LINK，导致将打过补丁后的版本拷贝到备机失败34ORACLE下的字符集问题第二楼第一种数据库挂起故障1由于archive挂起导致数据库挂死故障现象：数据库挂起，sqlplus无法登录，alert_zxin.log中有如下信息报出：SatJul1321:48:012002ARC0:Beginningtoarchivelog#1seq#61Currentlog#2seq#62mem#0:/zxindata/oracle/redolog/redo0logARC0:Error19504creatingarchivelogfile'/zxindata/zxinbak/arch/1_61.dbf'ARC0:Archivingnotpossible:errorcountexceededARC0:Failedtoarchivelog#1seq#61ARCH:Archivalstopped,erroroccurred.WillcontinueretryingSatJul1321:48:012002ORACLEInstancezxin-ArchivalErrorARCH:Connectingtoconsoleport...SatJul1321:48:012002ORA-16014:log1sequence#61notarchived,noavailabledestinationsORA-00312:onlinelog1thread1:'/zxindata/oracle/redolog/redo01.log'ARCH:Connectingtoconsoleport...ARCH:ORA-16014:log1sequence#61notarchived,noavailabledestinationsORA-00312:onlinelog1thread1:'/zxindata/oracle/redolog/redo01.log'SatJul1321:50:372002ARC0:Beginningtoarchivelog#1seq#61ARC0:Archivingnotpossible:NoprimarydestinationsARC0:Failedtoarchivelog#1seq#61故障原因：一般是archive所在的文件系统满或无操作权限引起的。故障解决：检查/zxindata/zxinbak文件系统，是否已经达到或接近100%，另外确定其对oracle用户有可写权限。如果文件系统已经满，请执行手工删除/zxindata/zxinbak/arch下的arch文件使用sqlplus/nolog登录，执行：SQLaltersystemarchivelogstart;进一步检查/zxindata/zxinbak文件系统为什么满：查zxin10用户下的checkpsfs.shoracle任务有没有执行：crontab–l|grepcheckpsfs，看是否有...checkpsfs.shoracle...的返回，如没有，表示定期检查空间是否满的任务没有执行，需要启动该任务查zxin10用户对/zxindata/zxinbak/arch目录下文件有没有删除权限：ls–l/zxindata/zxinbak/arch对dba组需要有可读可写权限查数据库备份任务有没有正常执行：crontab–l如果不存在rman或exp方式的数据库备份，则表示没有执行数据库备份任务，需要加上是否是/zxindata/zxinbak文件系统太小，不符合备份和呼叫模型下的最小大小配置。如果文件系统大小不能满足每天产生的arch日志和两个全备份的总空间，则需要扩展/zxindata/zxinbak文件系统，aix下可以直接扩，hpux下则需要将该文件系统umount以后再扩2init文件中SGA区设置太大，导致内存不够用，数据库和系统都挂死故障现象：操作系统无法使用telnet或ftp登录，数据库挂起，sqlplus无法登录故障原因：只能通过维护台登录到主机（很有可能维护台也无法登录），如果可以登录，则在aix上使用lsps–a检查pagingspace是否使用超过50%，hpux下可使用vmstat看内存是否已经很少。故障解决：如不可以登录，则强制关电重起机器以触发主备双机倒换；如果可以登录，则手工以shutdownabort方式停止数据库引发双机倒换。然后调整initzxin.ora文件中SGA区大小，主要是减少db_block_buffers的配置，如果物理内存小于1G，建议该值配置为：1024*1024/4/4注意同时调整主备机配置，然后做双机倒换是配置生效。3由于临时表空间无法扩展导致数据库被挂起故障现象：数据库挂起，sqlplus无法登录，alert_zxin.log中看：先是zxin_temp临时表空间扩展失败，数据库异常退出故障原因：这是ORACLE817的一个bug，当一个统计任务操作一个大表时，其临时数据使用了zxin_temp临时表空间，而该临时表空间太小自动扩展，扩展受文件系统大小限制和pctincrease参数限制而失败时，将引发数据库挂起。故障解决：将oracle817的补丁打到8.1.7.4手工扩充zxin_temp表空间并增加其所在文件系统大小检查zxin¬_temp临时表空间的pctincrease的值，需要配置为04由于未打补丁导致RMAN备份时将数据库挂起故障现象：数据库挂起，sqlplus无法登录。由于原来使用rman备份方式，当这种故障发生时，数据库备份日志：dbak.log中将有以下信息：RMAN-03022:compilingcommand:backupRMAN-03026:errorrecoveryreleasingchannelresourcesRMAN-08031:releasedchannel:ch1RMAN-00571:======================================================RMAN-00569:=========ERRORMESSAGESTACKFOLLOWS===============RMAN-00571:====================================================RMAN-03002:failureduringcompilationofcommandRMAN-03013:commandtype:backupRMAN-06003:ORACLEerrorfromtargetdatabase:RMAN-20242:specificationdoesnotmatchanyarchivelogintherecoverycatalog故障原因：是ORACLE817的一个bug故障解决：将补丁打到oracle8.1.7.4就可以了。另外建议将数据库备份改为exp方式第三楼第二种数据库功能/性能异常5由于BLOB类型的表记录数太多操作又太频繁导致数据库效率急差故障现象：操作系统CPU占有率很高，数据库操作响应很慢。故障原因：这种故障发生时，数据库能登录也能操作，但响应时间很长，从日志中也看不出什么异常。所以只能使用我们定制的oratool工具，先找出CPU占有率高的语句，再进一步分析，当时的情况是，发现version对一个有blob类型的表写很频繁，耗去了大量CPU资源，导致数据库总体性能下降。故障解决：a．不建议使用blob类型的表b．如果非要使用blob类型，则要定期进行数据备份和清理，记录数不能太多c．对blob类型的表的操作，在记录数多的情况下不能写的太频繁，会占用大量的系统资源6由于未对特大表（达到或超过100万条记录）定期做表分析导致数据库操作特别慢故障现象：执行某个存储过程或执行某个表的数据库操作时，操作系统CPU占有率明显升高，数据库操作响应很慢。故障原因：对一个数据量比较大的表（达到或超过100万），经过长期的读写操作后，其索引和数据分布没有及时更新给数据库，导致读时性能下降。故障解决：对这种类型的表，需要写任务定期对表做分析，由于分析比较耗时和耗资源，建议在系统闲时做，频率不能太高，如每月执行一次，分析可以使用5%或10%的抽样进行，如：analyzetabletable1sampleestimatestatistics5percent;7由于空间不够导致插入数据时扩展索引失败故障现象：alert_zxin.log日志将报扩展表空间失败的日志，zxcom.log中有扩展索引失败的记录。故障原因：一般是表所在的表空间不够，空间扩展失败的情况造成的。故障解决：手工扩展表空间所在的文件系统，扩展表空间如果是表空间的pctincrease设置的不是0，则将其改为0必要的时候需要rebuild一下扩展索引失败的索引8由于redolog破坏导致数据库异常故障现象：如果是数据库启动情况下redolog被破坏，则alert_zxin.log中会报如下错误：ORA-00313:openfailedformembersofloggroup2ofthread1ORA-00312:onlinelog2thread1:'/zxindata/oracle/zxin/redo0log'ORA-27037:unabletoobtainfilestatus将导致数据库操作异常。sqlplus可以登录如果是启动时候redolog损坏，将报：ORA-00313:无法打开日志组1(线程1)的成员ORA-00312:联机日志1线程1:'/zxindata/oracle/zxin/redo01.log'故障原因：redolog破坏，一般是由于：人为误删或物理损坏发生了主备倒换，备机的