ORACLE日常维护故障定位故障排除培训手册操作指南.doc

ORACLE 日常维护/故障定位/故障排除 培训手册/操作指南 智能网开发部智能网开发部 二零零四年五月 2 页 第 2 页 目目录录 目目录录2 2 第一章、日常维护第一章、日常维护 3 3 一、每天的工作.3 二、每周的工作（对需要进行的数据库的改动部分，一般都有相关的操作规范和技术通知， 请勿手工操作） .5 三、每月的工作（对于数据库修改部分，一般都通过任务执行，请勿手工操作）.6 第二章、故障定位、故障排除第二章、故障定位、故障排除 6 6 一、数据库挂起故障.6 2.1 由于ARCHIVE挂起导致数据库挂死.6 2.2 INIT文件中 SGA 区设置太大，导致内存不够用，数据库和系统都挂死.8 2.3 由于临时表空间无法扩展导致数据库被挂起8 2.4 由于未打补丁导致 RMAN 备份时将数据库挂起 8 二、数据库功能/性能异常.9 2.5 由于 BLOB 类型的表记录数太多操作又太频繁导致数据库效率急差 9 2.6 由于未对特大表（达到或超过 100 万条记录）定期做表分析导致数据库操作特别慢 9 2.7 由于空间不够导致插入数据时扩展索引失败 9 2.8 由于REDOLOG破坏导致数据库异常 .10 2.9 由于控制文件被破坏导致数据库无法正常启动 10 2.10 由于数据文件丢失或破坏导致数据库无法正常启动 11 2.11 由于空间参数设置不合理导致扩展表空间、索引等失败 11 2.12 由于时间格式的环境变量设置问题导致话单无法入库 12 2.13 由于大事务未使用大回滚段导致事务挂起 12 2.14 由于数据库连接数太多导致服务器进程数多或内存耗尽 12 2.15 由于使用了 MTS 方式，导致数据库操作特别慢（包括备份） 12 2.16 由于存在一个大事务操作，导致数据库性能特别差或产生频繁日志切换 13 2.17 由于没有COMMIT，导致数据库表被锁住13 2.18 索引创建不合理，导致数据库查询特别慢 13 2.19 由于BUFFER参数设置不合理导致EXP失败13 2.20 由于EXP不向上兼容，语言不兼容，导致不同版本、不同字符集的数据库无法导入14 2.21 由于创建表空间时误将其创建在以本地管理，导致在表空间上的所有对象无法修改 其存储参数 .14 2.22 错误地在系统表空间上建无关的数据文件14 2.23 ORACLE客户端在P4 上安装不成功15 2.24 由于LISTENER.ORA或TNSNAMES.ORA配置问题导致网络问题15 2.25 由于环境变量设置问题导致 VERSOIN 版本启动问题 16 3 页 第 3 页 2.26 用户数据、表破坏下的数据恢复 16 2.27 由于OS层问题导致数据库 ORA-600 错误.17 三、将导致数据库安装失败或打补丁失败的情况.17 2.28 由于环境变量或没有安装MAKE文件导致数据库安装失败17 2.29 由于/TMP等文件系统设置太小导致数据库无法正常安装17 2.30 HPUX 上由于核心参数设置不对导致数据库无法正常启动.17 2.31 在 64 位的ORACLE817 上打 32 的补丁失败18 2.32 由于安装备机数据库时是使用的拷贝方式，所以导致在备机上安装补丁失败 18 2.33 由于安装ORACLE时错误地在$ORACLE_HOME 目录下创建LINK，导致将打过补丁后的版本拷 贝到备机失败 .18 2.34 ORACLE下的字符集问题 .18 第一章、日常维护第一章、日常维护 ORACLE 数据库管理员应按如下方式对 ORACLE 数据库系统做定期监控： (1). 每天对 ORACLE 数据库的运行状态 , 日志文件 , 备份情况 , 数据 库的空间使用情况 , 系统资源的使用情况进行检查 , 发现并解决问题。 (2). 每周对数据库对象的空间扩展情况 , 数据的增长情况进行监控 , 对数据 库做健康检查 , 对数据库对象的状态做检查。 (3). 每月对表和索引等进行 Analyze, 检查表空间碎片 , 寻找数据库性能调 整的机会 , 进行数据库性能调整 , 提出下一步空间管理计划。对 ORACLE 数 据库状态进行一次全面检查。 一、一、每天的工作每天的工作 (1). 确认所有的 INSTANCE 状态正常 登陆到所有数据库或例程 , 检测 ORACLE 后台进程 : $ps ef|grep ora (2). 检查文件系统的使用（剩余空间） 。如果文件系统的剩余空间小于 20% ，需删除不用 的文件以释放空间。 尤其是/zxindata/zxinbak 文件系统的空间，该文件系统存放 archive 日志和数据库备份，一定要保证空间足够 4 页 第 4 页 $df k (3). 检查日志文件和 trace 文件记录 alert 和 trace 文件中的错误。 连接到每个需管理的系统 a.使用 telnet b.对每个数据库 ,cd 到 bdump 目录 , 通常是 $ORACLE_BASE/admin/bdump c.使用 Unix tail 命令来查看 alert_.log 文件 d.如果发现任何新的 ORA- 错误 , 记录并解决 (4). 检查数据库当日备份的有效性。 对 RMAN 备份方式 : 检查第三方备份工具的备份日志以确定备份是否成功 对 EXPORT 备份方式 : 检查 exp 日志文件以确定备份是否成功 对其他备份方式 : 检查相应的日志文件 (5). 使用 DBA studio 检查数据文件的状态记录状态不是“ online” 的数据文件，如有 非online的数据文件，请记录并反馈。 命令行方式： Select file_name from dba_data_files where status=OFFLINE (6). 使用 DBA studio 检查表空间的使用情况 命令行方式： SELECT tablespace_name, max_m, count_blocks free_blk_cnt, sum_free_m,to_char(100*sum_free_m/sum_m, 99.99) | % AS pct_free FROM ( SELECT tablespace_name,sum(bytes)/1024/1024 AS sum_m FROM dba_data_files GROUP BY tablespace_name), ( SELECT tablespace_name AS fs_ts_name, max(bytes)/1024/1024 AS max_m, count(blocks) AS count_blocks, sum(bytes/1024/1024) AS sum_free_m FROM dba_free_space GROUP BY tablespace_name ) WHERE tablespace_name = fs_ts_name (7). 使用 DBA studio 检查剩余表空间 命令行方式： SELECT tablespace_name, sum ( blocks ) as free_blk , trunc ( sum ( bytes ) /(1024*1024) ) as free_m, max ( bytes ) / (1024) as big_chunk_k, count (*) as num_chunks FROM dba_free_space GROUP BY tablespace_name; (8). 检查数据库性能，记录数据库的 cpu 使用、 IO 、 buffer 命中率等等 ，如发现异 常，请记录并反馈 使用 vmstat,iostat, top 等命令 5 页 第 5 页 (9). 其他日常出现问题的处理。 二、二、每周的工作（每周的工作（对需要进行的数据库的改动部分，一般都有相关的操作规范对需要进行的数据库的改动部分，一般都有相关的操作规范 和技术通知，请勿手工操作和技术通知，请勿手工操作） (1). 检查数据库对象的空间扩展情况 根据本周每天的检查情况找到空间扩展很快的数据库对象 , 并采取相 应的措施 - 删除历史数据 ，如对 bill 表进行定期的备份，对三个月前的数据进行定期清理 - 如表空间不够，可使用如下方式扩表空间 alter tablespace add datafile size - 调整数据对象的存储参数 (要求 pctincrease 参数设置为 0) next extent pct_increase (2). 监控数据量的增长情况 根据本周每天的检查情况找到记录数量增长很快的数据库对象 , 并采 取相应的措施 - 删除历史数据 - 扩表空间 alter tablespace add datafile size (3). 系统健康检查 检查以下内容 : init.ora controlfile redo log file archiving tablespace(system,temporary,tablespace fragment) datafiles(autoextend,location) object(number of extent,next extent,index) rollback segment logging 6 页 第 6 页 (2). 检查表空间碎片 根据本月每周的检查分析数据库碎片情况 , 找到相应的解决方法 (3). 寻找数据库性能调整的机会 比较每天对数据库性能的监控报告 , 确定是否有必要对数据库性能进行调整 (4). 数据库性能调整 如有必要 , 进行性能调整 (5). 提出下一步空间管理计划 根据每周的监控 , 提出空间管理的改进方法 第二章、故障定位、故障排除第二章、故障定位、故障排除 根据我们在实际商用系统中碰到问题，我们例举了如下常见故障和解决方法。 一、一、数据库挂起故障数据库挂起故障 2.12.1 由于由于 archivearchive 挂起导致数据库挂死挂起导致数据库挂死 故障现象： 数据库挂起，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/redo02.log 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 7 页 第 7 页 故障原因： 一般是 archive 所在的文件系统满或无操作权限引起的。 故障解决： 检查/zxindata/zxinbak 文件系统，是否已经达到或接近 100%，另外确定其对 oracle 用 户有可写权限。 如果文件系统已经满，请执行 a 手工删除/zxindata/zxinbak/arch 下的 arch 文件 b 使用 sqlplus /nolog 登录，执行： SQL alter system archive log start; 进一步检查/zxindata/zxinbak 文件系统为什么满： a 查 zxin10 用户下的 checkpsfs.sh oracle 任务有没有执行：crontab l |grep checkpsfs，看是否有.checkpsfs.sh oracle.的返回，如没有，表示定期检查空间是 否满的任务没有执行，需要启动该任务 b 查 zxin10 用户对/zxindata/zxinbak/arch 目录下文件有没有删除权限：ls l /zxindata/zxinbak/arch 对 dba 组需要有可读可写权限 c 查数据库备份任务有没有正常执行：crontab l 如果不存在 rman 或 exp 方式的数据 库备份，则表示没有执行数据库备份任务，需要加上 d 是否是/zxindata/zxinbak 文件系统太小，不符合备份和呼叫模型下的最小大小配置。 如果文件系统大小不能满足每天产生的 arch 日志和两个全备份的总空间，则需要 扩展/zxindata/zxinbak 文件系统，aix 下可以直接扩，hpux 下则需要将该文件系统 umount 以后再扩 2.22.2 initinit 文件中文件中 SGASGA 区设置太大，导致内存不够用，数据库和系统都挂死区设置太大，导致内存不够用，数据库和系统都挂死 故障现象： 操作系统无法使用 telnet 或 ftp 登录，数据库挂起，sqlplus 无法登录 故障原因： 只能通过维护台登录到主机（很有可能维护台也无法登录） ，如果可以登录，则在 aix 上使用 lsps a 检查 paging space 是否使用超过 50%，hpux 下可使用 vmstat 看内存是否已 经很少。 故障解决： 如不可以登录，则强制关电重起机器以触发主备双机倒换；如果可以登录，则手工以 shutdown abort 方式停止数据库引发双机倒换。 然后调整 initzxin.ora 文件中 SGA 区大小，主要是减少 db_block_buffers 的配置，如果 物理内存小于 1G，建议该值配置为：1024*1024/4/4 注意同时调整主备机配置，然后做双机倒换是配置生效。 2.32.3 由于临时表空间无法扩展导致数据库被挂起由于临时表空间无法扩展导致数据库被挂起 故障现象： 数据库挂起，sqlplus 无法登录，alert_zxin.log 中看：先是 zxin_temp 临时表空间 扩展失败，数据库异常退出 8 页 第 8 页 故障原因： 这是 ORACLE817 的一个 bug，当一个统计任务操作一个大表时，其临时数据使用了 zxin_temp 临时表空间，而该临时表空间太小自动扩展，扩展受文件系统大小限制和 pctincrease 参数限制而失败时，将引发数据库挂起。 故障解决： a 将 oracle817 的补丁打到 b 手工扩充 zxin_temp 表空间并增加其所在文件系统大小 c 检查 zxin_temp 临时表空间的 pctincrease 的值，需要配置为 0 2.42.4 由于未打补丁导致由于未打补丁导致 RMANRMAN 备份时将数据库挂起备份时将数据库挂起 故障现象： 数据库挂起，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 故障解决： 将补丁打到 oracle 就可以了。 另外建议将数据库备份改为 exp 方式 二、二、数据库功能数据库功能/ /性能异常性能异常 2.52.5 由于由于 BLOBBLOB 类型的表记录数太多操作又太频繁导致数据库效率急差类型的表记录数太多操作又太频繁导致数据库效率急差 故障现象： 操作系统 CPU 占有率很高，数据库操作响应很慢。 故障原因： 这种故障发生时，数据库能登录也能操作，但响应时间很长，从日志中也看不出什么 异常。所以只能使用我们定制的 oratool 工具，先找出 CPU 占有率高的语句，再进一步分 析，当时的情况是，发现 version 对一个有 blob 类型的表写很频繁，耗去了大量 CPU 资源， 导致数据库总体性能下降。 9 页 第 9 页 故障解决： a不建议使用 blob 类型的表 b如果非要使用 blob 类型，则要定期进行数据备份和清理，记录数不能太多 c对 blob 类型的表的操作，在记录数多的情况下不能写的太频繁，会占用大量的系 统资源 2.62.6 由于未对特大表（达到或超过由于未对特大表（达到或超过 100100 万条记录）定期做表分析导致数据库操万条记录）定期做表分析导致数据库操 作特别慢作特别慢 故障现象： 执行某个存储过程或执行某个表的数据库操作时，操作系统 CPU 占有率明显升高，数 据库操作响应很慢。 故障原因： 对一个数据量比较大的表（达到或超过 100 万） ，经过长期的读写操作后，其索引和数 据分布没有及时更新给数据库，导致读时性能下降。 故障解决： 对这种类型的表，需要写任务定期对表做分析，由于分析比较耗时和耗资源，建议在 系统闲时做，频率不能太高，如每月执行一次，分析可以使用 5%或 10%的抽样进行，如： analyze table table1 sample estimate statistics 5 percent; 2.72.7 由于空间不够导致插入数据时扩展索引失败由于空间不够导致插入数据时扩展索引失败 故障现象： alert_zxin.log 日志将报扩展表空间失败的日志，zxcom.log 中有扩展索引失败的记录。 故障原因： 一般是表所在的表空间不够，空间扩展失败的情况造成的。 故障解决： a 手工扩展表空间所在的文件系统，扩展表空间 b 如果是表空间的 pctincrease 设置的不是 0，则将其改为 0 c 必要的时候需要 rebuild 一下扩展索引失败的索引 2.82.8 由于由于 redologredolog 破坏导致数据库异常破坏导致数据库异常 故障现象： 如果是数据库启动情况下 redolog 被破坏，则 alert_zxin.log 中会报如下错误： ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: /zxindata/oracle/zxin/redo02.log ORA-27037: unable to obtain file status 将导致数据库操作异常。sqlplus 可以登录 如果是启动时候 redolog 损坏，将报： ORA-00313: 无法打开日志组 1 (线程 1) 的成员 ORA-00312: 联机日志 1 线程 1: /zxindata/oracle/zxin/redo01.log 故障原因： 10 页 第 10 页 redolog 破坏，一般是由于： a 人为误删或物理损坏 b 发生了主备倒换，备机的共享 VG 信息不全 故障解决： a 人为误删或物理损坏 如果未启动数据库，则启动到 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 logfile; 如果不是激活的，则执行重建： alter database drop logfile group 1; alter database add logfile group 1 /zxindata/oracle/redolog/redo01.log size 250M ; b 发生了主备倒换，备机的共享 VG 信息不全 将共享 VG 信息导入到备机，并修改共享文件系统和裸设备属性，使其对 oracle 用户 具有读写权限 2.92.9 由于控制文件被破坏导致数据库无法正常启动由于控制文件被破坏导致数据库无法正常启动 故障现象： 数据库操作将异常，sqlplus 可以登录。 故障原因： control 文件被物理损坏或人为损坏。一般会报：ORA-00210/ ORA-00202/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.dbf c.只要丢失了所有的备份或修改 maxlogfiles 或修改数据库名等情况则要重新 创建一个 control file，方式如下： 1) startup mount 2) alter database backup controlfile to trace; 3) alter database open; 11 页 第 11 页 到$udump 目录下查看最新的文件中包含两份重建 controlfile 的语句， 其一是 online logs 都完好的情况下进行数据库完全恢复的情况 其二是 online logs 损坏，则所有的在线日志都将丢失，所有的备份 都将失效。 2.102.10 由于数据文件丢失或破坏导致数据库无法正常启动由于数据文件丢失或破坏导致数据库无法正常启动 故障现象： 一般会导致操作到与该文件有关的数据都将失败，一般报：ORA-01110/ ORA-01116/ ORA-27041 等错误，严重一点的报 ORA-03113 后数据库异常退出 故障原因： 故障解决： 如果只是将数据文件挪了位置，则只要将其 mv 到原来的位置即可 如果确实损坏了，建议使用数据库备份进行恢复。具体恢复时，可以尝试使用：手工 创建数据文件自动恢复模式，如果不行，只能使用表空间全部恢复方式了。 2.112.11 由于空间参数设置不合理导致扩展表空间、索引等失败由于空间参数设置不合理导致扩展表空间、索引等失败 故障现象： 数据库表空间或索引扩展失败。 故障原因： 可能是表空间的 storage 参数设置的不合理引起的。 故障解决： 我们一般要求使用如下 storage 参数： STORAGE ( INITIAL 20K NEXT 20K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0 ) 2.122.12 由于时间格式的环境变量设置问题导致话单无法入库由于时间格式的环境变量设置问题导致话单无法入库 故障现象： 在 zxcom.log 报时间格式问题导致话单插入失败。导致话单既要到 bill 文件中 故障原因： 跟 zxin10 用户的 NLS_DATE_FORMAT 参数设置不正确有关 故障解决： 需要将 zxin10 用户下.profile 文件中 NLS_DATE_FORMAT 设置为： NLS_DATE_FORMAT=“YYYY.MM.DD HH24:MI:SS“ 2.132.13 由于大事务未使用大回滚段导致事务挂起由于大事务未使用大回滚段导致事务挂起 故障现象： 大事务运行失败，表现为表空间用满（ORA-01560 错误） ，回滚段扩展到达参数 MAXEXTENTS 的值（ORA-01628） 。 故障原因： 回滚段设置的太小 故障解决： 12 页 第 12 页 a 由于一个事务只能使用一个回滚段来存放它的回滚信息，所以建议给大事务创建 专用会滚段 b 创建时将回滚段表空间设置的大一点；增加 MAXEXTENTS 的值。 2.142.14 由于数据库连接数太多导致服务器进程数多或内存耗尽由于数据库连接数太多导致服务器进程数多或内存耗尽 故障现象： 使用 ps ef 检查时有很多 oracle 进程（包含 local 关键字） ，使用内存检查命令看可用 内存已经很少。 故障原因： 使用 DEDICATED 方式连接到数据库的客户端一般在服务器端都对应一个进程，该进 程将消耗 34M 的内存空间。 如果客户端连接数比较多，则内存将耗尽，进程数也将达到 系统极限或数据库极限。 故障解决： a 增加系统的硬件配置，如增加 CPU 或扩内存 b 增加系统最大进程数限制，aix 和 hpux 下都有方法设置 c 增加 oracle 进程数，在 init 文件中的 processes 参数项 2.152.15 由于使用了由于使用了 MTSMTS 方式，导致数据库操作特别慢（包括备份）方式，导致数据库操作特别慢（包括备份） 故障现象： 使用 MTS 连接方式的数据库操作将比较慢，尤其是系统资源吃紧的情况下。 故障原因： 智能网前期对 smap 等客户端的策略是使用 MTS（共享进程）解决方案，后发现该方 案不可行，主要是该连接方式下的数据库操作性能太差。 故障解决： 共享进程只能支持更多的并发用户访问数据库，但不能提高执行速度, 所以我们商用 局中已经取消了这种方式。具体可通过检查 initzxin.ora 中的配置确认。应该不包含任何含 mts 关键字的配置 2.162.16 由于存在一个大事务操作，导致数据库性能特别差或产生频繁日志切换由于存在一个大事务操作，导致数据库性能特别差或产生频繁日志切换 故障现象： 数据库性能下降，观察 alert_zxin.log 发现切换日志很频繁 故障原因： 肯定存在一个与呼叫无关的大事务在不停的运行，导致产生大量日志，引起日志切换。 故障解决： a 使用 oratool 工具中的 sp_who 找出活动 sql 语句 b 通过命令找出消耗 cpu、IO 资源最大的 10 条语句 查出该语句操作的表的数据量和读写频率，检查是否有应用类逻辑性异常并给予纠正。 13 页 第 13 页 2.172.17 由于没有由于没有 commitcommit，导致数据库表被锁住，导致数据库表被锁住 故障现象： 操作某个表的记录时长时间无响应，通过 sdf 进行的数据库操作则表现为超时，导致 sdf 进程 run too too long 故障原因： 一般跟该表被锁住有关 故障解决： a 使用 oratool 工具中的 sp_lock 命令查看该表是否有锁 b 检查是否在某个 SQL 语句中对该表进行事务类操作时，没有使用 commit，这种情 况一般发生在手工通过 sqlplus 修改数据的场合，sdf 不会出现 c 及时进行 commit 或 rollback，解除表锁，如果不能解除的话，则将与该锁有关的 进程强制杀掉。 2.182.18 索引创建不合理，导致数据库查询特别慢索引创建不合理，导致数据库查询特别慢 故障现象： 表现为查询特别慢，如果是通过 sdf 操作，返回超时或触发：sdf run too too long 故障原因： 有可能是在表的数据量比较大的情况下，该表的索引设置不合理造成的。 故障解决： 请使用 explain plan 查看其查询计划，看是否使用了全表扫描或不适合的索引，据此调 整索引或查询语句。 2.192.19 由于由于 bufferbuffer 参数设置不合理导致参数设置不合理导致 expexp 失败失败 故障现象： 使用 exp 导出某个表不成功 故障原因： 跟 buffer 设置有关 故障解决： 一般要求设置比较大的 buffer 进行 exp 备份，但当物理内存不够的情况下，buffer 设 置要合理，这种情况下，可尝试不设置 buffer 进行备份 2.202.20 由于由于 expexp 不向上兼容，语言不兼容，导致不同版本、不同字符集的数据库不向上兼容，语言不兼容，导致不同版本、不同字符集的数据库 无法导入无法导入 故障现象： 进行 imp 导入时报数据格式不正确，数据导入失败 故障原因： 目前了解 816/817 数据库导出的格式不兼容，但 oracle9i 可以向下兼容，导出和导入环 境的字符集不一致，也不能完成导入，但字符集一致、版本一致的数据库在不同的 OS 平 台上可以互导。 故障解决： 保证数据库版本的一致性，保证字符集的一致。或使用其他工具。 14 页 第 14 页 2.212.21 由于创建表空间时误将其创建在以由于创建表空间时误将其创建在以本地管理本地管理，导致在表空间上的所有，导致在表空间上的所有 对象无法修改其存储参数对象无法修改其存储参数 故障现象： 无法修改该表空间及在该表空间上创建的所有对象的 storage 参数。 故障原因： 只有在字典中管理的表空间才可以设置手工设置 STORAGE 参数 故障解决： a 编辑 initzxin.ora，修改参数 compatible=”8.1.0” 修改成 compatible=”8.1.6”, 执行：$sqlplus sys/change_on_install sqlexec dbms_space_admin.Tablespace_Migrate_FROM_Local(ZXIN_BILL); sqlcommit; b sqlexit c这样，表空间就从本地管理修改成 DMT 数据字典管理方式了，然后再手工修改 表空间存储参数和对象存储参数即可 2.222.22 错误地在系统表空间上建无关的数据文件错误地在系统表空间上建无关的数据文件 故障现象： 系统表空间上存在着无关的数据文件 故障原因： 错误地在系统表空间上建了无关的数据文件 故障解决： a 如果是创建在 OEM_REPOSITORY 表空间上，则可以将该表空间删除后重建，注 意不要再包含错建的数据文件 b 如果是其他系统表空间，可以使用： alter database datafile . resize to 1M; 命令尽量减少空间浪费。 2.232.23 oracleoracle 客户端在客户端在 p4p4 上安装不成功上安装不成功 故障现象： 奔四的机器无法安装 oracle8i 客户端 故障原因： oracle8i 的一个 bug 故障解决： 1、将 ORACLE 软件拷贝到硬盘。 2、将 硬盘目录文件stageComponentsoracle.swd.jre0/1 DataFilesExpandedjrewin32binsymcjit.dll 的文件改名为 symcjit.old 3.从installwin32 目录下运行 SETUP.exe 文件进行安装。 2.242.24 由于由于 listener.oralistener.ora 或或 tnsnames.oratnsnames.ora 配置问题导致网络问题配置问题导致网络问题 故障现象： lsnrctl start 启动数据库网络服务不成功；使用 tnsping 无法 ping 通数据库服务器；sdf 无法登录数据库 故障原因： 15 页 第 15 页 listener.ora 或 tnsnames.ora 配置不正确 故障解决： 请按如下模板配置 listener.ora： LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = version_svc)(PORT = 1521) (ADDRESS = (PROTOCOL = TCP)(HOST = version_svc)(PORT = 1522) (address= (protocol=ipc) (key=extproc) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = zxin) (ORACLE_HOME = /home/oracle/oracle81) (SID_NAME = zxin) ) (SID_DESC = (SID_NAME = extzxin) (ORACLE_HOME = /home/oracle/oracle81) (PROGRAM = extproc) ) ) 请按如下模板配置 tnsnames.ora： ZXIN = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = version_svc)(PORT = 1522) ) (CONNECT_DATA = (SERVICE_NAME = zxin) ) ) zx10_40_57_163= (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = version_svc)(PORT = 1522) ) (CONNECT_DATA = (SERVICE_NAME = zxin) (SERVER = DEDICATED) ) 16 页 第 16 页 ) extproc_connection_data= (description= (address=(protocol=ipc)(key=extproc) (connect_data= (sid=extzxin) 2.252.25 由于环境变量设置问题导致由于环境变量设置问题导致 VERSOINVERSOIN 版本启动问题版本启动问题 故障现象： 如果没有正确配置 ORACLE 环境变量，将导致 version 启动时 sdf 进程无法正常启动 或无法正常连接数据库 故障原因： 请按要求配置 zxin10 用户与 ORACLE 相关的环境变量 故障解决： 请检查 $ORACLE_HOME、$ORACLE_BASE、$LIBPATH、$SHLIB_PATH、$LD_LIBRARY_PA TH 等环境变量是否正确。 2.262.26 用户数据、表破坏下的数据恢复用户数据、表破坏下的数据恢复 故障现象： 某一个用户的所有数据或单个表的数据全部丢失，无法读取相关数据 故障原因： 由于人为误操作或硬件问题导致用户数据或单个表的数据全部丢失 故障解决： 使用 imp 命令将备份出的数据恢复（注意，只能恢复到备份时间点） 对于单表恢复的命令为： imp system/manager fromuser=zxin touser= zxin tables=oper_dbuser file=zxindb.dmp 对于整个用户数据丢失恢复的情况 将该用户删除重建： drop user zxin CASCADE; create user zxin defaule tablespace . temporary tablespace; 然后使用 imp 导入： imp system/manager fromuser=zxin touser= zxin file=zxindb.dmp 2.272.27 由于由于 osos 层问题导致数据库层问题导致数据库 ORA-600ORA-600 错误错误 故障现象： 启动数据库时报： ORA-600 故障原因： ORA-600 错误一般跟 os 层的错误有关，比如文件、内存、I/O 问题、硬件故障 故障解决： 碰到此类错误，请检查： a 所做的操作 b 目前 os 层有没有各类报错 17 页 第 17 页 c 解决 os 层问题后再重试 d 如果还是不行，只能重装系统，重装数据库 三、三、将导致数据库安装失败或打补丁失败的情况将导致数据库安装失败或打补丁失败的情况 2.282.28 由于环境变量或没有安装由于环境变量或没有安装 makemake 文件导致数据库安装失败文件导致数据库安装失败 故障现象： 安装 oracle 时进行到 link 阶段时报：找不到 make 文件 故障原因： 没有安装包含 make 文件的软件包 故障解决： 安装包含 make 文件的软件包后重试。 （aix 下的软件包为：bos.adt.base） 2.292.29 由于由于/tmp/tmp 等文件系统设置太小导致数据库无法正常安装等文件系统设置太小导致数据库无法正常安装 故障现象： 安装 oracle 时进行到 link 阶段时，在进行某个模块的 make 时报错，查看文件系统大 小，发现/tmp 文件系统已满 故障原因： /tmp 文件系统已满 故障解决： 请安装前保证/tmp 文件系统有 500M 剩余空间 2.302.30 HPUXHPUX 上由于核心参数设置不对导致数据库无法正常启动上由于核心参数设置不对导致数据库无法正常启动 故障现象： oracle 安装到 Link 阶段时报错 故障原因： hpux 上安装 oracle 数据库时，一定要先调整好核心参数再安装，否则将无法成功安装 故障解决： 按照安装手册调整 hpux 的核心参数（一般是通过 setup 脚本做的，无需手工配置，请 检查 setup 是否成功执行并成功修改了核心参数） 2.312.31 在在 6464 位的位的 oracle817oracle817 上打上打 3232 的补丁失败的补丁失败 故障现象： 安装补丁时，在 Link 阶段报错，通过安装日志检查，发现连接的动态库是 32 位的 故障原因： 补丁也分 oracle817（64 位）和 oracle817（32 位）的，请下载和打补丁时注意一一匹 配。 故障解决： 将打补丁前的 oracle817 备份文件恢复，选择匹配的补丁重新安装。 2.322.32 由于安装备机数据库时是使用的拷贝方式，所以导致在备机上安装补丁失由于安装备机数据库时是使用的拷贝方式，所以导致在备机上安装补丁失 败败 故障现象： 在备机上使用 oracle 正常打补丁方式时报版本不对，无法正常打补丁。 18 页 第 18 页 故障原因： 由于外面大部分机器备机 oracle 的安装是通过从主机拷贝的方式完成的，而部分如/etc 目录下的文件没有同步到备机，所以导致 oracle 补丁安装程序读不到相关版本信息，无法 完成补丁安装。 故障解决： a 可以采取将主机打完补丁后将$ORACLE_HOME 目录拷贝到备机的方式 b 可以将/etc 下的 oratab 和 oraInst.loc 拷贝到备机，再重试补丁安装 2.332.33 由于安装由于安装 oracleoracle 时错误地在时错误地在$ORACLE_HOME$ORACLE_HOME 目录下创建目录下创建 linklink，导致将打过，导致将打过 补丁后的版本拷贝到备机失败补丁后的版本拷贝到备机失败 故障现象： 主机打完 oracle 补丁后，将主机$ORACLE_HOME 文件同步到备机时间非常长！ 故障原因： 使用 rcp 命令同步时，将导致 ln 下的东西拷双份 故障解决： 请检查主机上是否有不适合的 ln 连接，连接目标是一个目录（该目录下有大量文件） ， 检查连接的方法是： find . -type l -exec ls -l ; 2.342.34 oracleoracle 下的字符集问题下的字符集问题 故障现象： 一般中文、英文环境都可以将 oracle 服务器字符集安装成 ZHS16GBK。如果不小心装 成英文字符，则会无法输入中文字符 故障原因： 一般是手工建库的情况导致的，通过 crdb.sh 执行建库的，不存在这个问题。 故障解决： 1） 首先安装 oracle 的时候必须选择安装中文字符集的支持 2） 由于中文字符集是英文字符集的超集，所以如果已经安装英文数据库字符集的话，