ORACLE 常见故障处理
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
故障解决：
a．不建议使用 blob 类型的表 b．如果非要使用 blob 类型，则要定期进行数据备份和清理，记录数不能太多 c．对 blob 类型的表的操作，在记录数多的情况下不能写的太频繁，会占用大量的系统资源
6 由于未对特大表（达到或超过 100 万条记录）定期做表分析导致数据库操作特别慢
故障现象：
7 由于空间不够导致插入数据时扩展索引失败
故障现象：
alert_zxin.log 日志将报扩展表空间失败的日志，zxcom.log 中有扩展索引失败的记录。
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 错误地在系统表空间上建无关的数据文件 23 ORACLE 客户端在 P4 上安装不成功 24 由于 LISTENER.ORA 或 TNSNAMES.ORA 配置问题导致网络问题 25 由于环境变量设置问题导致 VERSOIN 版本启动问题 26 用户数据、表破坏下的数据恢复 27 由于 OS 层问题导致数据库 ORA-600 错误
2 init 文件中 SGA 区设置太大，导致内存不够用，数据库和系统都挂死
故障现象： 操作系统无法使用 telnet 或 ftp 登录，数据库挂起，sqlplus 无法登录
故障原因： 只能通过维护台登录到主机（很有可能维护台也无法登录），如果可以登录，则在 aix 上使用 lsps –a 检 查 paging space 是否使用超过 50%，hpux 下可使用 vmstat 看内存是否已经很少。
故障解决： 如不可以登录，则强制关电重起机器以触发主备双机倒换；如果可以登录，则手工以 shutdown abort 方 式停止数据库引发双机倒换。 然后调整 initzxin.ora 文件中 SGA 区大小，主要是减少 db_block_buffers 的配置，如果物理内存小于 1G，建议该值配置为：1024*1024/4/4 注意同时调整主备机配置，然后做双机倒换是配置生效。
空间，而该临时表空间太小自动扩展，扩展受文件系统大小限制和 pctincrease 参数限制而失败时，将引 发数据库挂起。
故障解决： 将 oracle817 的补丁打到 8.1.7.4 手工扩充 zxin_temp 表空间并增加其所在文件系统大小 检查 zxin¬_temp 临时表空间的 pctincrease 的值，需要配置为 0
3 由于临时表空间无法扩展导致数据库被挂起
故障现象： 数据库挂起，sqlplus 无法登录，alert_zxin.log 中看：先是 zxin_temp 临时表空间扩展失败，数据库异 常退出
故障原因： 这是 ORACLE817 的一个 bug，当一个统计任务操作一个大表时，其临时数据使用了 zxin_temp 临时表
第二楼
第一种 数据库挂起故障
1 由于 archive 挂起导致数据库挂死
故障现象：
数据库挂起，sqlplus 无法登录，alert_zxin.log 中有如下信息报出： Sat Jul 13 21:48:01 2002 ARC0: Beginning to archive log# 1 seq# 61 Current log# 2 seq# 62 mem# 0: /zxindata/oracle/redolog/redo0log ARC0: Error 19504 creating archivelog file '/zxindata/zxinbak/arch/1_61.dbf' ARC0: Archiving not possible: error count exceeded ARC0: Failed to archive log# 1 seq# 61 ARCH: Archival stopped, error occurred. Will continue retrying Sat Jul 13 21:48:01 2002 ORACLE Instance zxin - Archival Error ARCH: Connecting to console port... Sat Jul 13 21:48:01 2002 ORA-16014: log 1 sequence# 61 not archived, no available destinations ORA-00312: online log 1 thread 1: '/zxindata/oracle/redolog/redo01.log' ARCH: Connecting to console port... ARCH: ORA-16014: log 1 sequence# 61 not archived, no available destinations ORA-00312: online log 1 thread 1: '/zxindata/oracle/redolog/redo01.log' Sat Jul 13 21:50:37 2002 ARC0: Beginning to archive log# 1 seq# 61 ARC0: Archiving not possible: No primary destinations ARC0: Failed to archive log# 1 seq# 61
故障分类三 将导致数据库安装失败或打补丁失败的情况
28 由于环境变量或没有安装 MAKE 文件导致数据库安装失败 29 由于/TMP 等文件系统设置太小导致数据库无法正常安装 30 HPUX 上由于核心参数设置不对导致数据库无法正常启动 31 在 64 位的 ORACLE817 上打 32 的补丁失败 32 由于安装备机数据库时是使用的拷贝方式，所以导致在备机上安装补丁失败 33 由于安装 ORACLE 时错误地在$ORACLE_HOME 目录下创建 LINK，导致将打过补丁后的版本拷贝到 备机失败 34 ORACLE 下的字符集问题
4 由于未打补丁导致 RMAN 备份时将数据库挂起
故障现象：
数据库挂起，sqlplus 无法登录。由于原来使用 rman 备份方式，当这种故障发生时，数据库备份日志： dbak.log 中将有以下信息： RMAN-03022: compiling command: backup RMAN-03026: error recovery releasing channel resources RMAN-08031: released channel: ch1 RMAN-00571: ====================================================== RMAN-00569:========= ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571:=============================================== ===== RMAN-03002: failure during compilation of command RMAN-03013: command type: backup RMAN-06003: ORACLE error from target database: RMAN-20242: specification does not match any archivelog in the recovery catalog
故障原因： 是 ORACLE817 的一个 bug
故障解决： 将补丁打到 oracle8.1.7.4 就可以了。 另外建议将数据库备份改为 exp 方式
第三楼
第二种 数据库功能/性能异常
5 由于 BLOB 类型的表记录数太多操作又太频繁导致数据库效率急差
故障现象：
操作系统 CPU 占有率很高，数据库操作响应很慢。
故障原因：
一般是 archive 所在的文件系统满或无操作权限引起的。
故障解决： 检查/zxindata/zxinbak 文件系统，是否已经达到或接近 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 用户对/zxindata/zxinbak/arch 目录下文件有没有删除权限：ls –l /zxindata/zxinbak/arch 对 dba 组需要有可读可写权限 查数据库备份任务有没有正常执行：crontab –l 如果不存在 rman 或 exp 方式的数据库备份，则表示没 有执行数据库备份任务，需要加上 是否是/zxindata/zxinbak 文件系统太小，不符合备份和呼叫模型下的最小大小配置。 如果文件系统大小不能满足每天产生的 arch 日志和两个全备份的总空间，则需要扩展/zxindata/zxinbak 文件系统，aix 下可以直接扩，hpux 下则需要将该文件系统 umount 以后再扩
Oracle 常见故障
第一楼 目 录
故障分类一 数据库挂起故障Hale Waihona Puke Baidu
1 由于 ARCHIVE 挂起导致数据库挂死 2 NIT 文件中 SGA 区设置太大，导致内存不够用，数据库和系统都挂死 3 由于临时表空间无法扩展导致数据库被挂起 4 由于未打补丁导致 RMAN 备份时将数据库挂起
故障分类二 数据库功能/性能异常
故障原因： 这种故障发生时，数据库能登录也能操作，但响应时间很长，从日志中也看不出什么异常。所以只能使用 我们定制的 oratool 工具，先找出 CPU 占有率高的语句，再进一步分析，当时的情况是，发现 version 对一个有 blob 类型的表写很频繁，耗去了大量 CPU 资源，导致数据库总体性能下降。
执行某个存储过程或执行某个表的数据库操作时，操作系统 CPU 占有率明显升高，数据库操作响应很慢。 故障原因：
对一个数据量比较大的表（达到或超过 100 万），经过长期的读写操作后，其索引和数据分布没有及时更 新给数据库，导致读时性能下降。 故障解决：
对这种类型的表，需要写任务定期对表做分析，由于分析比较耗时和耗资源，建议在系统闲时做，频率不 能太高，如每月执行一次，分析可以使用 5%或 10%的抽样进行，如： analyze table table1 sample estimate statistics 5 percent;
a．不建议使用 blob 类型的表 b．如果非要使用 blob 类型，则要定期进行数据备份和清理，记录数不能太多 c．对 blob 类型的表的操作，在记录数多的情况下不能写的太频繁，会占用大量的系统资源
6 由于未对特大表（达到或超过 100 万条记录）定期做表分析导致数据库操作特别慢
故障现象：
7 由于空间不够导致插入数据时扩展索引失败
故障现象：
alert_zxin.log 日志将报扩展表空间失败的日志，zxcom.log 中有扩展索引失败的记录。
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 错误地在系统表空间上建无关的数据文件 23 ORACLE 客户端在 P4 上安装不成功 24 由于 LISTENER.ORA 或 TNSNAMES.ORA 配置问题导致网络问题 25 由于环境变量设置问题导致 VERSOIN 版本启动问题 26 用户数据、表破坏下的数据恢复 27 由于 OS 层问题导致数据库 ORA-600 错误
2 init 文件中 SGA 区设置太大，导致内存不够用，数据库和系统都挂死
故障现象： 操作系统无法使用 telnet 或 ftp 登录，数据库挂起，sqlplus 无法登录
故障原因： 只能通过维护台登录到主机（很有可能维护台也无法登录），如果可以登录，则在 aix 上使用 lsps –a 检 查 paging space 是否使用超过 50%，hpux 下可使用 vmstat 看内存是否已经很少。
故障解决： 如不可以登录，则强制关电重起机器以触发主备双机倒换；如果可以登录，则手工以 shutdown abort 方 式停止数据库引发双机倒换。 然后调整 initzxin.ora 文件中 SGA 区大小，主要是减少 db_block_buffers 的配置，如果物理内存小于 1G，建议该值配置为：1024*1024/4/4 注意同时调整主备机配置，然后做双机倒换是配置生效。
空间，而该临时表空间太小自动扩展，扩展受文件系统大小限制和 pctincrease 参数限制而失败时，将引 发数据库挂起。
故障解决： 将 oracle817 的补丁打到 8.1.7.4 手工扩充 zxin_temp 表空间并增加其所在文件系统大小 检查 zxin¬_temp 临时表空间的 pctincrease 的值，需要配置为 0
3 由于临时表空间无法扩展导致数据库被挂起
故障现象： 数据库挂起，sqlplus 无法登录，alert_zxin.log 中看：先是 zxin_temp 临时表空间扩展失败，数据库异 常退出
故障原因： 这是 ORACLE817 的一个 bug，当一个统计任务操作一个大表时，其临时数据使用了 zxin_temp 临时表
第二楼
第一种 数据库挂起故障
1 由于 archive 挂起导致数据库挂死
故障现象：
数据库挂起，sqlplus 无法登录，alert_zxin.log 中有如下信息报出： Sat Jul 13 21:48:01 2002 ARC0: Beginning to archive log# 1 seq# 61 Current log# 2 seq# 62 mem# 0: /zxindata/oracle/redolog/redo0log ARC0: Error 19504 creating archivelog file '/zxindata/zxinbak/arch/1_61.dbf' ARC0: Archiving not possible: error count exceeded ARC0: Failed to archive log# 1 seq# 61 ARCH: Archival stopped, error occurred. Will continue retrying Sat Jul 13 21:48:01 2002 ORACLE Instance zxin - Archival Error ARCH: Connecting to console port... Sat Jul 13 21:48:01 2002 ORA-16014: log 1 sequence# 61 not archived, no available destinations ORA-00312: online log 1 thread 1: '/zxindata/oracle/redolog/redo01.log' ARCH: Connecting to console port... ARCH: ORA-16014: log 1 sequence# 61 not archived, no available destinations ORA-00312: online log 1 thread 1: '/zxindata/oracle/redolog/redo01.log' Sat Jul 13 21:50:37 2002 ARC0: Beginning to archive log# 1 seq# 61 ARC0: Archiving not possible: No primary destinations ARC0: Failed to archive log# 1 seq# 61
故障分类三 将导致数据库安装失败或打补丁失败的情况
28 由于环境变量或没有安装 MAKE 文件导致数据库安装失败 29 由于/TMP 等文件系统设置太小导致数据库无法正常安装 30 HPUX 上由于核心参数设置不对导致数据库无法正常启动 31 在 64 位的 ORACLE817 上打 32 的补丁失败 32 由于安装备机数据库时是使用的拷贝方式，所以导致在备机上安装补丁失败 33 由于安装 ORACLE 时错误地在$ORACLE_HOME 目录下创建 LINK，导致将打过补丁后的版本拷贝到 备机失败 34 ORACLE 下的字符集问题
4 由于未打补丁导致 RMAN 备份时将数据库挂起
故障现象：
数据库挂起，sqlplus 无法登录。由于原来使用 rman 备份方式，当这种故障发生时，数据库备份日志： dbak.log 中将有以下信息： RMAN-03022: compiling command: backup RMAN-03026: error recovery releasing channel resources RMAN-08031: released channel: ch1 RMAN-00571: ====================================================== RMAN-00569:========= ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571:=============================================== ===== RMAN-03002: failure during compilation of command RMAN-03013: command type: backup RMAN-06003: ORACLE error from target database: RMAN-20242: specification does not match any archivelog in the recovery catalog
故障原因： 是 ORACLE817 的一个 bug
故障解决： 将补丁打到 oracle8.1.7.4 就可以了。 另外建议将数据库备份改为 exp 方式
第三楼
第二种 数据库功能/性能异常
5 由于 BLOB 类型的表记录数太多操作又太频繁导致数据库效率急差
故障现象：
操作系统 CPU 占有率很高，数据库操作响应很慢。
故障原因：
一般是 archive 所在的文件系统满或无操作权限引起的。
故障解决： 检查/zxindata/zxinbak 文件系统，是否已经达到或接近 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 用户对/zxindata/zxinbak/arch 目录下文件有没有删除权限：ls –l /zxindata/zxinbak/arch 对 dba 组需要有可读可写权限 查数据库备份任务有没有正常执行：crontab –l 如果不存在 rman 或 exp 方式的数据库备份，则表示没 有执行数据库备份任务，需要加上 是否是/zxindata/zxinbak 文件系统太小，不符合备份和呼叫模型下的最小大小配置。 如果文件系统大小不能满足每天产生的 arch 日志和两个全备份的总空间，则需要扩展/zxindata/zxinbak 文件系统，aix 下可以直接扩，hpux 下则需要将该文件系统 umount 以后再扩
Oracle 常见故障
第一楼 目 录
故障分类一 数据库挂起故障Hale Waihona Puke Baidu
1 由于 ARCHIVE 挂起导致数据库挂死 2 NIT 文件中 SGA 区设置太大，导致内存不够用，数据库和系统都挂死 3 由于临时表空间无法扩展导致数据库被挂起 4 由于未打补丁导致 RMAN 备份时将数据库挂起
故障分类二 数据库功能/性能异常
故障原因： 这种故障发生时，数据库能登录也能操作，但响应时间很长，从日志中也看不出什么异常。所以只能使用 我们定制的 oratool 工具，先找出 CPU 占有率高的语句，再进一步分析，当时的情况是，发现 version 对一个有 blob 类型的表写很频繁，耗去了大量 CPU 资源，导致数据库总体性能下降。
执行某个存储过程或执行某个表的数据库操作时，操作系统 CPU 占有率明显升高，数据库操作响应很慢。 故障原因：
对一个数据量比较大的表（达到或超过 100 万），经过长期的读写操作后，其索引和数据分布没有及时更 新给数据库，导致读时性能下降。 故障解决：
对这种类型的表，需要写任务定期对表做分析，由于分析比较耗时和耗资源，建议在系统闲时做，频率不 能太高，如每月执行一次，分析可以使用 5%或 10%的抽样进行，如： analyze table table1 sample estimate statistics 5 percent;