Oracle 常见故障处理.docx

1、Oracle 常见故障处理Oracle 常见故障第一楼 目 录故障分类一 数据库挂起故障1 由于ARCHIVE挂起导致数据库挂死2 NIT文件中SGA区设置太大，导致内存不够用，数据库和系统都挂死3 由于临时表空间无法扩展导致数据库被挂起4由于未打补丁导致RMAN备份时将数据库挂起故障分类二 数据库功能/性能异常5由于BLOB类型的表记录数太多操作又太频繁导致数据库效率急差6由于未对特大表（达到或超过100万条记录）定期做表分析导致数据库操作特别慢7由于空间不够导致插入数据时扩展索引失败8由于REDOLOG破坏导致数据库异常9由于控制文件被破坏导致数据库无法正常启动10由于数据文件丢失或破坏导

2、致数据库无法正常启动11由于空间参数设置不合理导致扩展表空间、索引等失败12由于时间格式的环境变量设置问题导致话单无法入库13由于大事务未使用大回滚段导致事务挂起14由于数据库连接数太多导致服务器进程数多或内存耗尽15由于使用了MTS方式，导致数据库操作特别慢（包括备份）16由于存在一个大事务操作，导致数据库性能特别差或产生频繁日志切换17由于没有COMMIT，导致数据库表被锁住18索引创建不合理，导致数据库查询特别慢19 由于BUFFER参数设置不合理导致EXP失败20由于EXP不向上兼容，语言不兼容，导致不同版本、不同字符集的数据库无法导入21 由于创建表空间时误将其创建在以本地管理，导致

3、在表空间上的所有对象无法修改其存储参数22 错误地在系统表空间上建无关的数据文件23 ORACLE客户端在P4上安装不成功24由于LISTENER.ORA或TNSNAMES.ORA配置问题导致网络问题25由于环境变量设置问题导致VERSOIN版本启动问题26用户数据、表破坏下的数据恢复27 由于OS层问题导致数据库ORA-600错误故障分类三 将导致数据库安装失败或打补丁失败的情况28 由于环境变量或没有安装MAKE文件导致数据库安装失败29 由于/TMP等文件系统设置太小导致数据库无法正常安装30 HPUX上由于核心参数设置不对导致数据库无法正常启动31 在64位的ORACLE817上打32

4、的补丁失败32由于安装备机数据库时是使用的拷贝方式，所以导致在备机上安装补丁失败33由于安装ORACLE时错误地在$ORACLE_HOME目录下创建LINK，导致将打过补丁后的版本拷贝到备机失败34 ORACLE下的字符集问题第二楼第一种 数据库挂起故障1 由于archive挂起导致数据库挂死故障现象： 数据库挂起，sqlplus无法登录，alert_zxin.log中有如下信息报出：Sat Jul 13 21:48:01 2002ARC0: Beginning to archive log# 1 seq# 61Current log# 2 seq# 62 mem# 0: /zxindata/

5、oracle/redolog/redo0logARC0: Error 19504 creating archivelog file /zxindata/zxinbak/arch/1_61.dbfARC0: Archiving not possible: error count exceededARC0: Failed to archive log# 1 seq# 61ARCH: Archival stopped, error occurred. Will continue retryingSat Jul 13 21:48:01 2002ORACLE Instance zxin - Archiv

6、al ErrorARCH: Connecting to console port.Sat Jul 13 21:48:01 2002ORA-16014: log 1 sequence# 61 not archived, no available destinationsORA-00312: online log 1 thread 1: /zxindata/oracle/redolog/redo01.logARCH: Connecting to console port.ARCH:ORA-16014: log 1 sequence# 61 not archived, no available de

7、stinationsORA-00312: online log 1 thread 1: /zxindata/oracle/redolog/redo01.logSat Jul 13 21:50:37 2002ARC0: Beginning to archive log# 1 seq# 61ARC0: Archiving not possible: No primary destinationsARC0: Failed to archive log# 1 seq# 61故障原因： 一般是archive所在的文件系统满或无操作权限引起的。故障解决：检查/zxindata/zxinbak文件系统，是否

8、已经达到或接近100%，另外确定其对oracle 用户有可写权限。如果文件系统已经满，请执行手工删除/zxindata/zxinbak/arch下的arch文件使用sqlplus /nolog登录，执行：SQL alter system archive log start;进一步检查/zxindata/zxinbak文件系统为什么满：查zxin10用户下的checkpsfs.sh oracle任务有没有执行：crontab l |grep checkpsfs，看是否有.checkpsfs.sh oracle.的返回，如没有，表示定期检查空间是否满的任务没有执行，需要启动该任务查zxin10用户

9、对/zxindata/zxinbak/arch目录下文件有没有删除权限：ls l /zxindata/zxinbak/arch 对dba组需要有可读可写权限查数据库备份任务有没有正常执行：crontab l如果不存在rman或exp方式的数据库备份，则表示没有执行数据库备份任务，需要加上是否是/zxindata/zxinbak文件系统太小，不符合备份和呼叫模型下的最小大小配置。如果文件系统大小不能满足每天产生的arch日志和两个全备份的总空间，则需要扩展/zxindata/zxinbak文件系统，aix下可以直接扩，hpux下则需要将该文件系统umount以后再扩2 init文件中SGA区设置

10、太大，导致内存不够用，数据库和系统都挂死故障现象：操作系统无法使用telnet或ftp登录，数据库挂起，sqlplus无法登录故障原因：只能通过维护台登录到主机（很有可能维护台也无法登录），如果可以登录，则在aix上使用lsps a 检查paging space是否使用超过50%，hpux下可使用vmstat 看内存是否已经很少。故障解决：如不可以登录，则强制关电重起机器以触发主备双机倒换；如果可以登录，则手工以shutdown abort方式停止数据库引发双机倒换。然后调整initzxin.ora文件中SGA区大小，主要是减少db_block_buffers的配置，如果物理内存小于1G，建议

11、该值配置为：1024*1024/4/4注意同时调整主备机配置，然后做双机倒换是配置生效。3 由于临时表空间无法扩展导致数据库被挂起故障现象：数据库挂起，sqlplus无法登录，alert_zxin.log中看：先是zxin_temp临时表空间扩展失败，数据库异常退出故障原因：这是ORACLE817的一个bug，当一个统计任务操作一个大表时，其临时数据使用了zxin_temp临时表空间，而该临时表空间太小自动扩展，扩展受文件系统大小限制和pctincrease参数限制而失败时，将引发数据库挂起。故障解决：将oracle817的补丁打到8.1.7.4手工扩充zxin_temp表空间并增加其所在文件

12、系统大小检查zxin¬_temp临时表空间的pctincrease的值，需要配置为04由于未打补丁导致RMAN备份时将数据库挂起故障现象：数据库挂起，sqlplus无法登录。由于原来使用rman备份方式，当这种故障发生时，数据库备份日志：dbak.log中将有以下信息：RMAN-03022: compiling command: backupRMAN-03026: error recovery releasing channel resourcesRMAN-08031: released channel: ch1RMAN-00571: =RMAN-00569:= ERROR MESSA

13、GE STACK FOLLOWS =RMAN-00571:=RMAN-03002: failure during compilation of commandRMAN-03013: command type: backupRMAN-06003: ORACLE error from target database: RMAN-20242: specification does not match any archivelog in the recovery catalog故障原因： 是ORACLE817的一个bug故障解决： 将补丁打到oracle8.1.7.4就可以了。 另外建议将数据库备份改

14、为exp方式第三楼第二种 数据库功能/性能异常5由于BLOB类型的表记录数太多操作又太频繁导致数据库效率急差故障现象： 操作系统CPU占有率很高，数据库操作响应很慢。故障原因：这种故障发生时，数据库能登录也能操作，但响应时间很长，从日志中也看不出什么异常。所以只能使用我们定制的oratool工具，先找出CPU占有率高的语句，再进一步分析，当时的情况是，发现version对一个有blob类型的表写很频繁，耗去了大量CPU资源，导致数据库总体性能下降。故障解决： a不建议使用blob类型的表b如果非要使用blob类型，则要定期进行数据备份和清理，记录数不能太多c对blob类型的表的操作，在记录数多

15、的情况下不能写的太频繁，会占用大量的系统资源6由于未对特大表（达到或超过100万条记录）定期做表分析导致数据库操作特别慢故障现象：执行某个存储过程或执行某个表的数据库操作时，操作系统CPU占有率明显升高，数据库操作响应很慢。故障原因： 对一个数据量比较大的表（达到或超过100万），经过长期的读写操作后，其索引和数据分布没有及时更新给数据库，导致读时性能下降。故障解决：对这种类型的表，需要写任务定期对表做分析，由于分析比较耗时和耗资源，建议在系统闲时做，频率不能太高，如每月执行一次，分析可以使用5%或10%的抽样进行，如：analyze table table1 sample estimate

16、statistics 5 percent;7由于空间不够导致插入数据时扩展索引失败故障现象：alert_zxin.log日志将报扩展表空间失败的日志，zxcom.log中有扩展索引失败的记录。故障原因：一般是表所在的表空间不够，空间扩展失败的情况造成的。故障解决：手工扩展表空间所在的文件系统，扩展表空间如果是表空间的pctincrease设置的不是0，则将其改为0必要的时候需要rebuild一下扩展索引失败的索引8由于redolog破坏导致数据库异常故障现象：如果是数据库启动情况下redolog被破坏，则alert_zxin.log中会报如下错误：ORA-00313: open failed

17、for members of log group 2 of thread 1ORA-00312: online log 2 thread 1: /zxindata/oracle/zxin/redo0logORA-27037: unable to obtain file status将导致数据库操作异常。sqlplus可以登录如果是启动时候redolog损坏，将报：ORA-00313: 无法打开日志组 1 (线程 1) 的成员ORA-00312: 联机日志 1 线程 1: /zxindata/oracle/zxin/redo01.log故障原因：redolog破坏，一般是由于：人为误删或物理损坏

18、发生了主备倒换，备机的共享VG信息不全故障解决：人为误删或物理损坏如果未启动数据库，则启动到mount状态，重建日志： (如第1组日志有问题)alter database drop logfile group 1;alter database add logfile group 1 /zxindata/oracle/redolog/redo01.log size 250M ;alter database open;如果数据库启动着，则查看一下损坏文件是否是活动(active)的日志：select * from v$log;如果是激活的，则进行日志切换：alter system switch l

19、ogfile;如果不是激活的，则执行重建：alter database drop logfile group 1;alter database add logfile group 1 /zxindata/oracle/redolog/redo01.log size 250M ;发生了主备倒换，备机的共享VG信息不全将共享VG信息导入到备机，并修改共享文件系统和裸设备属性，使其对oracle用户具有读写权限9由于控制文件被破坏导致数据库无法正常启动故障现象：数据库操作将异常，sqlplus可以登录。故障原因：control文件被物理损坏或人为损坏。一般会报：ORA-00210/ ORA-0020

20、2/ORA-27041/ORA-27037等错误，所以数据库事务将挂起故障解决：a.只要CONTROL_FILE中还有好的control文件，则只要将其拷贝多份就可以了b.如果以前做过备份，不能再使用该备份控制文件，因为control文件和数据文件会不一致。启动时报：ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项SQL alter database open resetlogs;ORA-01152: 文件 1 没有从完备的旧备份中恢复ORA-01110: 数据文件 1: /zxindata/oracle/zxin/system01.dbfc.

21、只要丢失了所有的备份或修改maxlogfiles或修改数据库名等情况则要重新创建一个control file，方式如下：startup mountalter database backup controlfile to trace;alter database open;到$udump目录下查看最新的文件中包含两份重建controlfile 的语句，其一是online logs都完好的情况下进行数据库完全恢复的情况其二是online logs损坏，则所有的在线日志都将丢失，所有的备份都将失效。10由于数据文件丢失或破坏导致数据库无法正常启动故障现象：一般会导致操作到与该文件有关的数据都将失败，

22、一般报：ORA-01110/ ORA-01116/ ORA-27041等错误，严重一点的报ORA-03113后数据库异常退出故障原因：故障解决：如果只是将数据文件挪了位置，则只要将其mv到原来的位置即可如果确实损坏了，建议使用数据库备份进行恢复。具体恢复时，可以尝试使用：手工创建数据文件自动恢复模式，如果不行，只能使用表空间全部恢复方式了。11由于空间参数设置不合理导致扩展表空间、索引等失败故障现象：数据库表空间或索引扩展失败。故障原因：可能是表空间的storage参数设置的不合理引起的。故障解决：我们一般要求使用如下storage参数：STORAGE ( INITIAL 20K NEXT 2

23、0K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0 )12由于时间格式的环境变量设置问题导致话单无法入库故障现象：在zxcom.log报时间格式问题导致话单插入失败。导致话单既要到bill文件中故障原因：跟zxin10用户的NLS_DATE_FORMAT参数设置不正确有关故障解决：需要将zxin10用户下.profile文件中NLS_DATE_FORMAT设置为：NLS_DATE_FORMAT=YYYY.MM.DD HH24:MI:SS13由于大事务未使用大回滚段导致事务挂起故障现象：大事务运行失败，表现为表空间用满（ORA-01560错误），

24、回滚段扩展到达参数MAXEXTENTS的值（ORA-01628）。故障原因：回滚段设置的太小故障解决：由于一个事务只能使用一个回滚段来存放它的回滚信息，所以建议给大事务创建专用会滚段创建时将回滚段表空间设置的大一点；增加MAXEXTENTS的值。14由于数据库连接数太多导致服务器进程数多或内存耗尽故障现象：使用ps ef检查时有很多oracle进程（包含local关键字），使用内存检查命令看可用内存已经很少。故障原因：使用DEDICATED方式连接到数据库的客户端一般在服务器端都对应一个进程，该进程将消耗34M的内存空间。 如果客户端连接数比较多，则内存将耗尽，进程数也将达到系统极限或数据库极

25、限。故障解决：增加系统的硬件配置，如增加CPU或扩内存增加系统最大进程数限制，aix和hpux下都有方法设置增加oracle进程数，在init文件中的processes参数项15由于使用了MTS方式，导致数据库操作特别慢（包括备份）故障现象：使用MTS连接方式的数据库操作将比较慢，尤其是系统资源吃紧的情况下。故障原因：智能网前期对smap等客户端的策略是使用MTS（共享进程）解决方案，后发现该方案不可行，主要是该连接方式下的数据库操作性能太差。故障解决：共享进程只能支持更多的并发用户访问数据库，但不能提高执行速度, 所以我们商用局中已经取消了这种方式。具体可通过检查initzxin.ora中的

26、配置确认。应该不包含任何含mts关键字的配置16由于存在一个大事务操作，导致数据库性能特别差或产生频繁日志切换故障现象：数据库性能下降，观察alert_zxin.log发现切换日志很频繁故障原因：肯定存在一个与呼叫无关的大事务在不停的运行，导致产生大量日志，引起日志切换。故障解决：使用oratool工具中的sp_who找出活动sql语句通过命令找出消耗cpu、IO资源最大的10条语句查出该语句操作的表的数据量和读写频率，检查是否有应用类逻辑性异常并给予纠正。17由于没有commit，导致数据库表被锁住故障现象：操作某个表的记录时长时间无响应，通过sdf进行的数据库操作则表现为超时，导致sdf进

27、程run too too long故障原因：一般跟该表被锁住有关故障解决：使用oratool工具中的sp_lock命令查看该表是否有锁检查是否在某个SQL语句中对该表进行事务类操作时，没有使用commit，这种情况一般发生在手工通过sqlplus修改数据的场合，sdf不会出现及时进行commit或rollback，解除表锁，如果不能解除的话，则将与该锁有关的进程强制杀掉。18索引创建不合理，导致数据库查询特别慢故障现象：表现为查询特别慢，如果是通过sdf操作，返回超时或触发：sdf run too too long故障原因：有可能是在表的数据量比较大的情况下，该表的索引设置不合理造成的。故障解

28、决：请使用explain plan查看其查询计划，看是否使用了全表扫描或不适合的索引，据此调整索引或查询语句。19 由于buffer参数设置不合理导致exp失败故障现象：使用exp导出某个表不成功故障原因：跟buffer设置有关故障解决：一般要求设置比较大的buffer进行exp备份，但当物理内存不够的情况下，buffer设置要合理，这种情况下，可尝试不设置buffer进行备份20由于exp不向上兼容，语言不兼容，导致不同版本、不同字符集的数据库无法导入故障现象：进行imp导入时报数据格式不正确，数据导入失败故障原因：目前了解816/817数据库导出的格式不兼容，但oracle9i可以向下兼容

29、，导出和导入环境的字符集不一致，也不能完成导入，但字符集一致、版本一致的数据库在不同的OS平台上可以互导。故障解决：保证数据库版本的一致性，保证字符集的一致。或使用其他工具。21 由于创建表空间时误将其创建在以本地管理，导致在表空间上的所有对象无法修改其存储参数故障现象：无法修改该表空间及在该表空间上创建的所有对象的storage参数。故障原因：只有在字典中管理的表空间才可以设置手工设置STORAGE参数故障解决：编辑initzxin.ora，修改参数compatible=”8.1.0” 修改成compatible=”8.1.6”,执行：$sqlplus sys/change_on_installsqlexec dbms_space_admin.Tablespace_Migrate_FROM_Local(ZXIN_BILL);sqlcommit;sqlexitc这样，表空间就从本地管理修改成DMT数据字典管理方式了，然后再手工修改表空间存储参数和对象存储参数即可22 错误地在系统表空间上建无关的数据文件故障现象：系统表空间上存在着无关的数据文件故障原因：错误地在系统表空间上建了无关的数据文件故障解决：如果是创建在OEM_REPOSITORY表空间上，则可以将该表空间删除后重建，注意不要再包含错建的数据文件