Oracle诊断案例-Spfile案例一则

Transcription

1 ITPUB 第 1 页科技技术新动力

2 本期内容导读 Oracle 诊断案例 -Spfile 案例一则 By Eygle 本文通过一个 UNDO 表空间丢失的案例, 详细的介绍了怎样通过使用 spfile 来解决问题, 而无需再手工修改 pfile 文件从而减少了犯错的可能 Oracle 诊断案例 -SGA 与 Swap 之一 By Eygle Oracle 数据库问题的解决从来就离不开操作系统, 很多时候我们必须通过 操作系统一级的手段来诊断并解决问题 通过本文的介绍会使您对这点有更 深刻的认识和理解 Oracle 诊断案例 -SGA 与 Swap 之二 By Eygle SGA 设置不当很容易引起的数据库异常, 问题本身并不复杂, 所以这一类 问题应该在数据库规划和建设阶段就避免掉 ORACLE 诊断事件及深入解析 事件 By wanghai,liyongdong Oracle 为 RDBMS 提供了多种的诊断工具, 诊断事件 (Event) 是其中一 种常用 好用的方法, 它使 DBA 可以方便的转储数据库各种结构及跟踪特 定事件的发生 用 events 跟踪解决不能创建物化视图一例 By Fenng 本文作者通过一个统计系统的数据同步案例, 详尽分析了如何用 events 跟踪解决不能创建物化视图, 相信对读者受益匪浅 ITPUB 第 2 页科技技术新动力

3 ORA-1157 错误解决手册 By coolly ORA-1157, "cannot identify/lock data file %s - see DBWR trace file" 这个问题相信不少人都遇到过, 看看本文的作者是怎样分析和 解决的吧, 或许您能从中悟出不少东西 一条 sql 导致数据库整体性能下降的诊断和解决的全过程 By biti_rainy 一条编写不当的 SQl 语句足可以使数据库性能极具下降, 使 DBA 焦头烂额, 通过本文希望能引起大家的重视 修改 fet$ 基表, 结合碎片案例实战 By logzgh 本文介绍了怎样通过修改 fet$ 基表来解决表空间碎片过多的问题, 此方法 虽直接有效但存在一定风险, 建议对 Oracle 有深刻了解后, 方可尝试 ITPUB 第 3 页科技技术新动力

4 ITPUB 技术丛书第三册 深入浅出 Oracle-DBA 入门 进阶与诊断案例 即将由人民邮电出版社出版 作者 : 盖国强 (eygle) 内容简介 : 本书分为 9 章, 具体结构划分如下 第一章 : 数据库的启动和关闭, 从基础入手, 讲解 Oracle 数据库的启动和关闭, 并深入探讨数据库启动关闭的核心本质及内部处理 ITPUB 第 4 页科技技术新动力

5 第二章 : 参数及参数文件, 这一部分从 Oracle 启动必需的参数文件入手, 讲解 重要参数 参数文件对于 Oracle 的作用, 并结合 RAC 环境,Oracle10g 环境 介绍参数文件等的不断改进和变迁 第三章 : 数据字典, 深入到数据库的核心, 全面了解数据字典的机制和重要性 第四章 : 内存管理,Oracle 的内存管理非常重要, 本章就 SGA PGA 的管理进 行探讨, 并深入介绍 Oracle 内存管理技术在 Oracle8i/9i/10g 不同版本中的变 迁 第五章 :Buffer Cache 与 Shared Pool 原理, 本章深入介绍了 Buffer Cache 和 Shared Pool 的原理, 并涉及闩锁和热点块等深入话题 第六章 : 重做, 重做机制是 Oracle 恢复的保障, 本章针对 Oracle 的重做机制 进行探讨, 并涉及重做的内部原理及工作机制 第七章 : 回滚与撤销, 回滚和事务密切相关, 本章从基础出发, 介绍 Oracle 的 回滚机制, 进而深入研究和探讨回滚机制的内部操作及 ORA 错误等相 关知识 第八章 : 等待事件, 等待事件在数据库性能诊断中起着极为重要的作用, 在不同 版本中,Oracle 一直在不断加强等待事件的功能, 本章从等待事件入手, 进一 步讲解数据库性能诊断和优化知识 第九章 : 性能诊断与 SQL 优化, 这一章是实践的总结, 通过一些实践的案例, 介绍一种思路和方法给大家, 解决问题是学习的最终目的 关于本书 根据 Gartner 公司的最新统计数据, 在 2005 年,Oracle 数据库以 48.6% 的 市场占有率继续稳居关系数据库市场的首位, 在过去这一年中, 国内的 Oracle ITPUB 第 5 页科技技术新动力

6 从业市场和学习环境都有了很大的发展和进步, 市场进一步规范和成熟, 从事数 据库管理工作的朋友们也越来越多 为了让更多进入 Oracle 领域的朋友能够快速了解和掌握 Oracle 技术, 让具备一定经验和积累的 Oracle 从业人员继续深入学习, 作者倾力撰写了本书 本书作者活跃于国内著名 Oracle 技术论坛 ITPUB( 并全力打造国内最具影响力的个人 Oracle 技术站点 Eygle.com ( 本书从基础出发, 逐层深入, 并结合实际工作中的诊断案例进行全面讲解, 力图从点到面, 让读者对每个主题都有深入的了解和认识 本书是 ITPUB 技术丛书的第三本, 在 Oracle 数据库 DBA 专题技术精粹 和 Oracle 数据库性能优化 二书出版的 2 年多以来,ITPUB 和 Oracle 市场都有了长足的发展, 希望本书的出现能为读者带来更深入的技术知识和更多的实践经验 本书特点 目前市场上的 Oracle 书籍普遍存在的问题是模式单一, 要么只讲基础知识, 要么侧重代码编程实例, 要么针对具体的版本特性 ( Oracle8i/Oracle9i/Oracle10g 等 ), 要么缺少实践应用检验, 很少能对 Oracle 相关知识进行全面深入讲解 本书针对这些问题, 从基础知识入手, 再进行深入研究, 结合性能调整 诊断案例实践, 将 Oracle 知识全面 系统 深入的展现给读者 ; 本书内容更涉及 Oracle8i/Oracle9i/Oracle10g, 将 Oracle 的版本变化, 功能改进, 一以贯之的展现出来, 让大家看到这些变革的真正原因以及 Oracle 的不断技术创新, 通过真实案例的学习, 更可以加深大家对现实环境的了解, 从而提高实践能力 本书是作者多年实践工作的积累和总结, 各篇章更从 DBA 的成长历程入手, 引 导大家快速进入并深入 Oracle 知识的国度 本书继续贯彻了作者 由点到线再及面 的学习方法, 既可以让初学者参考学习, 又可以帮助具备一定基础的中级 DBA 进行进阶学习, 不同层次的学习者都能从 本书的不同内容中受益 ITPUB 第 6 页科技技术新动力

7 本书的读者对象 本书适用于打算进入 Oracle 领域的初学者, 也适用于具备一定数据库基础 打 算深入学习 Oracle 技术的数据库从业人员, 尤其适用于入门 进阶以及希望深 入研究 Oracle 技术的数据库管理人员 ; 本书也可以作为各大中专院校相关专业的教学辅导和参考用书, 或作为相关培训 机构的培训教材 ITPUB 第 7 页科技技术新动力

8 本期目录 Oracle 诊断案例 -Spfile 案例一则... 9 Oracle 诊断案例 -SGA 与 Swap 之一 Oracle 诊断案例 -SGA 与 Swap 之二 ORACLE 诊断事件及深入解析 事件 用 events 跟踪解决不能创建物化视图一例 ORA-1157 错误解决手册 一条 sql 导致数据库整体性能下降的诊断和解决全过程 修改 fet$ 基表, 结合碎片案例实战 ITPUB 第 8 页科技技术新动力

9 Oracle 诊断案例 -Spfile 案例一则 作者 :Eygle 情况说明 : 系统 :SUN Solaris8 数据库版本 :9203 问题描述 : 工程人员报告, 数据库在重新启动时无法正常启动. 检查发现 UNDO 表空间丢失. 问题诊断及解决过程如下 : 1. 登陆系统检查 alert.log 文件 检查 alert.log 文件是通常是我们诊断数据库问题的第一步 SunOS 5.8 login: root Password: Last login: Thu Apr 1 11:39:16 from Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001 You have new mail. # su - oracle bash-2.03$ cd $ORACLE_BASE/admin/*/bdump bash-2.03$ vi *.log "alert_gzhs.log" 7438 lines, characters Sat Feb 7 20:30: Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 SCN scheme 3 Using log_archive_dest parameter default value LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up ORACLE RDBMS Version: System parameters with non-default values: processes = 150 ITPUB 第 9 页科技技术新动力

10 timed_statistics = TRUE shared_pool_size = large_pool_size = java_pool_size = control_files = /u01/oradata/gzhs/control01.ctl, /u02/oradata/gzhs/control02.ctl, /u03/oradata/gzhs/control03.ctl db_block_size = 8192 db_cache_size = compatible = log_archive_start = TRUE log_archive_dest_1 = LOCATION=/u06/oradata/gzhs/arch log_archive_format = %t_%s.dbf db_file_multiblock_read_count= 16 fast_start_mttr_target = 300 undo_management = AUTO undo_tablespace = UNDOTBS1 undo_retention = remote_login_passwordfile= EXCLUSIVE db_domain = instance_name = gzhs dispatchers = (PROTOCOL=TCP) (SERVICE=gzhsXDB) job_queue_processes = 10 hash_join_enabled = TRUE background_dump_dest = /oracle/admin/gzhs/bdump user_dump_dest = /oracle/admin/gzhs/udump core_dump_dest = /oracle/admin/gzhs/cdump sort_area_size = db_name = gzhs open_cursors = 300 star_transformation_enabled= FALSE query_rewrite_enabled = FALSE pga_aggregate_target = aq_tm_processes = 1 PMON started with pid=2 DBW0 started with pid=3 LGWR started with pid=4 CKPT started with pid=5 SMON started with pid=6 ITPUB 第 10 页科技技术新动力

11 "alert_gzhs.log" 7438 lines, characters USER: terminating instance due to error Instance terminated by USER, pid = ORA-1092 signalled during: ALTER DATABASE OPEN... Thu Apr 1 11:11: Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 SCN scheme 3 Using log_archive_dest parameter default value LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up ORACLE RDBMS Version: System parameters with non-default values: processes = 150 timed_statistics = TRUE shared_pool_size = large_pool_size = java_pool_size = control_files = /u01/oradata/gzhs/control01.ctl, /u02/oradata/gzhs/control02.ctl, /u03/oradata/gzhs/control03.ctl db_block_size = 8192 db_cache_size = compatible = log_archive_start = TRUE log_archive_dest_1 = LOCATION=/u06/oradata/gzhs/arch log_archive_format = %t_%s.dbf db_file_multiblock_read_count= 16 fast_start_mttr_target = 300 undo_management = AUTO undo_tablespace = UNDOTBS1 undo_retention = remote_login_passwordfile= EXCLUSIVE db_domain = instance_name = gzhs dispatchers = (PROTOCOL=TCP) (SERVICE=gzhsXDB) job_queue_processes = 10 hash_join_enabled = TRUE background_dump_dest = /oracle/admin/gzhs/bdump ITPUB 第 11 页科技技术新动力

12 user_dump_dest = /oracle/admin/gzhs/udump core_dump_dest = /oracle/admin/gzhs/cdump sort_area_size = db_name = gzhs open_cursors = 300 star_transformation_enabled= FALSE query_rewrite_enabled = FALSE pga_aggregate_target = aq_tm_processes = 1 PMON started with pid=2 DBW0 started with pid=3 LGWR started with pid=4 CKPT started with pid=5 SMON started with pid=6 RECO started with pid=7 CJQ0 started with pid=8 Thu Apr 1 11:11: starting up 1 shared server(s)... QMN0 started with pid=9 Thu Apr 1 11:11: starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'... ARCH: STARTING ARCH PROCESSES ARC0 started with pid=12 ARC0: Archival started ARC1 started with pid=13 Thu Apr 1 11:11: ARCH: STARTING ARCH PROCESSES COMPLETE Thu Apr 1 11:11: ARC0: Thread not mounted Thu Apr 1 11:11: ARC1: Archival started ARC1: Thread not mounted Thu Apr 1 11:11: ALTER DATABASE MOUNT Thu Apr 1 11:11: Successful mount of redo thread 1, with mount id Thu Apr 1 11:11: Database mounted in Exclusive Mode. ITPUB 第 12 页科技技术新动力

13 Completed: ALTER DATABASE MOUNT Thu Apr 1 11:11: alter database open Thu Apr 1 11:11: Beginning crash recovery of 1 threads Thu Apr 1 11:11: Started first pass scan Thu Apr 1 11:11: Completed first pass scan 1 redo blocks read, 0 data blocks need recovery Thu Apr 1 11:11: Started recovery at Thread 1: logseq 177, block 2, scn Recovery of Online Redo Log: Thread 1 Group 3 Seq 177 Reading mem 0 Mem# 0 errs 0: /u01/oradata/gzhs/redo03.log Thu Apr 1 11:11: Completed redo application Thu Apr 1 11:11: Ended recovery at Thread 1: logseq 177, block 3, scn data blocks read, 0 data blocks written, 1 redo blocks read Crash recovery completed successfully Thu Apr 1 11:11: LGWR: Primary database is in CLUSTER CONSISTENT mode Thread 1 advanced to log sequence 178 Thread 1 opened at log sequence 178 Current log# 1 seq# 178 mem# 0: /u01/oradata/gzhs/redo01.log Successful open of redo thread 1. Thu Apr 1 11:11: ARC0: Evaluating archive log 3 thread 1 sequence 177 Thu Apr 1 11:11: ARC0: Beginning to archive log 3 thread 1 sequence 177 Creating archive destination LOG_ARCHIVE_DEST_1: '/u06/oradata/gzhs/arch/1_177.dbf' Thu Apr 1 11:11: SMON: enabling cache recovery ARC0: Completed archiving log 3 thread 1 sequence 177 Thu Apr 1 11:11: Errors in file /oracle/admin/gzhs/udump/gzhs_ora_27781.trc: ORA-30012: \263\267\317\373\261\355\277\325\274\344 'UNDOTBS1' ITPUB 第 13 页科技技术新动力

14 \262\273\264\346\324\332\273\362\300\340\320\315\262\273\325\375\310\ 267 Thu Apr 1 11:11: Error happened during db open, shutting down database USER: terminating instance due to error Instance terminated by USER, pid = ORA-1092 signalled during: alter database open... :q... 在警报日志末尾显示了数据库在 Open 状态因为错误而异常终止. 2. 尝试重新启动数据库 bash-2.03$ sqlplus "/ as sysdba" SQL*Plus: Release Production on 星期四 4 月 1 11:43: Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. 已连接到空闲例程 SQL> startup ORACLE 例程已经启动 Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes 数据库装载完毕 ORA-01092: ORACLE 例程终止 强行断开连接... 工程人员报告的问题重现. 3. 检查数据文件 ITPUB 第 14 页科技技术新动力

15 bash-2.03$ cd /u01/ oradata/gzhs bash-2.03$ ls -l total rw-r oracle dba Apr 1 11:44 UNDOTBS2.dbf -rw-r oracle dba Apr 1 11:44 WAP12_BILLINGDETAIL.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN10.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN11.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN2.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN3.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN4.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN5.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN6.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN7.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN8.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MAIN9.dbf -rw-r oracle dba Apr 1 11:44 WAP12_MVIEW.dbf -rw-r oracle dba Mar 24 17:15 WAP12_TEMP1.dbf... 发现存在文件 UNDOTBS2.dbf 4. mount 数据库, 检查系统参数 bash-2.03$ sqlplus "/ as sysdba" SQL*Plus: Release Production on 星期四 4 月 1 11:46: Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. 已连接到空闲例程 SQL> SQL> SQL> startup mount; ORACLE 例程已经启动 ITPUB 第 15 页科技技术新动力

16 Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes 数据库装载完毕 SQL> select name from v$datafile; NAME /u01/oradata/gzhs/system01.dbf /u01/oradata/gzhs/cwmlite01.dbf /u01/oradata/gzhs/drsys01.dbf /u01/oradata/gzhs/example01.dbf /u01/oradata/gzhs/indx01.dbf /u01/oradata/gzhs/odm01.dbf /u01/oradata/gzhs/tools01.dbf /u01/oradata/gzhs/users01.dbf /u01/oradata/gzhs/xdb01.dbf... /u01/oradata/gzhs/undotbs2.dbf 已选择 23 行 SQL> SQL> show parameter undo NAME TYPE VALUE undo_management string AUTO undo_retention integer undo_suppress_errors boolean FALSE undo_tablespace string UNDOTBS1 SQL> show parameter spfile NAME TYPE VALUE ITPUB 第 16 页科技技术新动力

17 spfile string 发现系统没有使用 spfile, 而初始化参数设置的 undo 表空间为 UNDOTBS1 5. 检查参数文件 bash-2.03$ cd $ORACLE_HOME/dbs bash-2.03$ ls init.ora initgzhs.ora initgzhs.ora.old orapwgzhs initdw.ora initgzhs.ora.hurray lkgzhs snapcf_gzhs.f bash-2.03$ vi initgzhs.ora "initgzhs.ora" [Incomplete last line] 105 lines, 3087 characters #################################################### # Copyright (c) 1991, 2001, 2002 by Oracle Corporation #################################################### ########################################### # Archive ########################################### log_archive_dest_1='location=/u06/oradata/gzhs/arch' log_archive_format=%t_%s.dbf log_archive_start=true ########################################### # Cache and I/O ########################################### db_block_size=8192 db_cache_size= ITPUB 第 17 页科技技术新动力

18 db_file_multiblock_read_count=16 ########################################### # Cursors and Library Cache ########################################### open_cursors= ########################################### # System Managed Undo and Rollback Segments ########################################### undo_management=auto undo_retention=10800 undo_tablespace=undotbs1 :q!... 这个设置是极其可疑的. 怀疑参数文件和实际数据库设置不符. 6. 再次检查 alert 文件 查找对于 UNDO 表空间的操作 第一部分, 创建数据库时的信息 : Sat Feb 7 20:30: CREATE DATABASE gzhs MAXINSTANCES 1 MAXLOGHISTORY 1 MAXLOGFILES 5 MAXLOGMEMBERS 3 MAXDATAFILES 100 DATAFILE '/u01/oradata/gzhs/system01.dbf' SIZE 500M REUSE AUTOEXTEND ON NEXT ITPUB 第 18 页科技技术新动力

19 10240K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE '/u01/oradata/gzhs/temp01.dbf' SIZE 1000M REUSE AUTOEXTEND ON NEXT 250M MAXSIZE UNLIMITED UNDO TABLESPACE "UNDOTBS1" DATAFILE '/u01/oradata/gzhs/undotbs01.dbf' SIZE 1000M REUSE AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED CHARACTER SET ZHS16GBK NATIONAL CHARACTER SET AL16UTF16 LOGFILE GROUP 1 ('/u01/oradata/gzhs/redo01.log') SIZE 256M, GROUP 2 ('/u01/oradata/gzhs/redo02.log') SIZE 256M, GROUP 3 ('/u01/oradata/gzhs/redo03.log') SIZE 256M... 注意, 这也是 OCP 教材上提到的两种创建 UNDO 表空间的方式之一 第二部分, 发现创建 UNDOTBS2 的记录信息 : Wed Mar 24 20:20: /* OracleOEM */ CREATE UNDO TABLESPACE "UNDOTBS2" DATAFILE '/u01/oradata/gzhs/undotbs2.dbf' SIZE 1024M AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED Wed Mar 24 20:22: Created Undo Segment _SYSSMU11$ Created Undo Segment _SYSSMU12$ Created Undo Segment _SYSSMU13$ Created Undo Segment _SYSSMU14$ Created Undo Segment _SYSSMU15$ Created Undo Segment _SYSSMU16$ Created Undo Segment _SYSSMU17$ Created Undo Segment _SYSSMU18$ Created Undo Segment _SYSSMU19$ Created Undo Segment _SYSSMU20$ Completed: /* OracleOEM */ CREATE UNDO TABLESPACE "UNDOTBS2" Wed Mar 24 20:24: Undo Segment 11 Onlined ITPUB 第 19 页科技技术新动力

20 Undo Segment 12 Onlined Undo Segment 13 Onlined Undo Segment 14 Onlined Undo Segment 15 Onlined Undo Segment 16 Onlined Undo Segment 17 Onlined Undo Segment 18 Onlined Undo Segment 19 Onlined Undo Segment 20 Onlined Successfully onlined Undo Tablespace 15. Undo Segment 1 Offlined Undo Segment 2 Offlined Undo Segment 3 Offlined Undo Segment 4 Offlined Undo Segment 5 Offlined Undo Segment 6 Offlined Undo Segment 7 Offlined Undo Segment 8 Offlined Undo Segment 9 Offlined Undo Segment 10 Offlined Undo Tablespace 1 successfully switched out.... 第三部分, 新的 UNDO 表空间被应用 Wed Mar 24 20:24: ALTER SYSTEM SET undo_tablespace='undotbs2' SCOPE=MEMORY; 我们发现问题就在这里, 创建了新的 UNDO 表空间以后, 因为使用的是 pfile 文件, 修改的只对当前 实例生效, 操作人员忘记了修改 pfile 文件. 如果使用 spfile, 缺省的修改范围是 both, 会同时修改 spfile 文件, 就可以避免以上问题的出现. 第四部分, 删除了 UNDOTBS1 的信息 ITPUB 第 20 页科技技术新动力

21 Wed Mar 24 20:25: /* OracleOEM */ DROP TABLESPACE "UNDOTBS1" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS Wed Mar 24 20:25: Deleted file /u01/oradata/gzhs/undotbs01.dbf Completed: /* OracleOEM */ DROP TABLESPACE "UNDOTBS1" INCLUDI... 这样再次重新启动数据库的时候, 问题出现了,pfile 中定义的 UNDOTBS1 找不到了, 而且操作实 在很久以前, 没人能回忆起来, 甚至无法得知是什么人的操作 7. 更改 pfile, 启动数据库 修改 undo 表空间 ########################################### # System Managed Undo and Rollback Segments ########################################### undo_management=auto undo_retention=10800 undo_tablespace=undotbs2... bash-2.03$ sqlplus "/ as sysdba" SQL*Plus: Release Production on 星期四 4 月 1 11:55: Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. 连接到 : Oracle9i Enterprise Edition Release bit Production With the Partitioning, OLAP and Oracle Data Mining options ITPUB 第 21 页科技技术新动力

22 JServer Release Production SQL> select * from v$version; BANNER Oracle9i Enterprise Edition Release bit Production PL/SQL Release Production CORE Production TNS for Solaris: Version Production NLSRTL Version Production SQL> exit 从 Oracle9i Enterprise Edition Release bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release Production 中断开 bash-2.03$ 在这里我们可以看到, 使用 spfile 可以免去手工修改 pfile 文件的麻烦, 减少了犯错的可能 既然 Oracle9i 给我们提供了这个新特性, 就值得我们学习使用它. 编者注 : 您可以通过以下连接参与关于本文的讨论, 直接和作者对话 : 或 ITPUB 第 22 页科技技术新动力

23 Oracle 诊断案例 -SGA 与 Swap 之一 作者 :Eygle 案例描述 : 用户报告, 服务器启动一段时间以后, 无法建立数据库连接 重新启动几分钟以后, 再次无法连接 系统无法正常使用. 1. 登陆系统 SunOS 5.8 login: root Password: Last login: Tue Mar 23 13:56:59 from Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001 You have new mail. 2.su 为 Oracle 用户 检查启动的 Oracle 进程 发现后台进程正常, 有一定量的用户连接 wapplatform:/>su - oracle Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001 You have new mail. /export/home1/oracle>ls admin codesyndealt31 exp.sh local.cshrc local.profile oraclebak oui v6_database app exp.log jre local.login nsmail oradata swan export/home1/oracle>cd admin /export/home1/oracle/admin>ps -ef grep ora oracle :58:36 pts/3 0:00 grep ora oracle :58:31 pts/4 0:00 vi alert_hswapdb.log oracle :58:34? 0:00 oraclehswapdb (LOCAL=NO) oracle :56:57? 0:00 ora_p007_hswapdb ITPUB 第 23 页科技技术新动力

24 oracle :56:57? 0:00 ora_p006_hswapdb oracle :57:03? 0:01 oraclehswapdb (LOCAL=NO) oracle :57:09? 0:00 oraclehswapdb (LOCAL=NO) oracle :56:57? 0:00 ora_p003_hswapdb oracle :56:57? 0:00 ora_p005_hswapdb oracle :56:56? 0:00 ora_p001_hswapdb oracle :56:57? 0:00 ora_p004_hswapdb oracle :56:56? 0:00 ora_p000_hswapdb oracle :08:25 pts/2 0:00 -ksh oracle :56:56? 0:00 ora_p002_hswapdb oracle :58:23? 0:00 oraclehswapdb (LOCAL=NO) oracle :57:23? 0:00 oraclehswapdb (LOCAL=NO) oracle :56:42? 0:02 ora_qmn0_hswapdb oracle :57:40? 0:01 oraclehswapdb (LOCAL=NO) oracle :56:42? 0:00 ora_s000_hswapdb oracle :56:41? 0:01 ora_lgwr_hswapdb oracle :56:42? 0:00 ora_cjq0_hswapdb oracle :47:47 pts/4 0:00 -ksh oracle :56:42? 0:01 ora_smon_hswapdb oracle :55:14 pts/1 0:00 -ksh oracle :56:42? 0:00 ora_d000_hswapdb oracle :56:42? 0:00 ora_reco_hswapdb oracle :56:41? 0:00 ora_ckpt_hswapdb oracle :56:41? 0:00 ora_dbw0_hswapdb oracle :57:04? 0:49 ora_j000_hswapdb oracle :05:11 pts/5 0:00 -ksh oracle :57:41? 0:00 oraclehswapdb (LOCAL=NO) oracle :56:29? 0:00 oraclehswapdb (LOCAL=NO) oracle :55:34? 0:00 /export/home1/oracle/app/bin/tnslsnr LISTENER -inherit oracle :21:56 pts/5 0:00 sqlplus /nolog oracle :56:41? 0:00 ora_pmon_hswapdb oracle :58:31 pts/3 0:00 -ksh /export/home1/oracle/admin>ps -ef grep ora_ oracle :58:42 pts/3 0:00 grep ora_ oracle :56:57? 0:00 ora_p007_hswapdb oracle :56:57? 0:00 ora_p006_hswapdb oracle :56:57? 0:00 ora_p003_hswapdb oracle :56:57? 0:00 ora_p005_hswapdb oracle :56:56? 0:00 ora_p001_hswapdb ITPUB 第 24 页科技技术新动力

25 oracle :56:57? 0:00 ora_p004_hswapdb oracle :56:56? 0:00 ora_p000_hswapdb oracle :56:56? 0:00 ora_p002_hswapdb oracle :56:42? 0:02 ora_qmn0_hswapdb oracle :56:42? 0:00 ora_s000_hswapdb oracle :56:41? 0:01 ora_lgwr_hswapdb oracle :56:42? 0:00 ora_cjq0_hswapdb oracle :56:42? 0:01 ora_smon_hswapdb oracle :56:42? 0:00 ora_d000_hswapdb oracle :56:42? 0:00 ora_reco_hswapdb oracle :56:41? 0:00 ora_ckpt_hswapdb oracle :56:41? 0:00 ora_dbw0_hswapdb oracle :57:04? 0:51 ora_j000_hswapdb oracle :56:41? 0:00 ora_pmon_hswapdb 3. 检查 Alert.log 警报日志文件 /export/home1/oracle/admin>ls hswapdb /export/home1/oracle/admin>cd * /export/home1/oracle/admin/hswapdb>ls bdump cdump create pfile udump /export/home1/oracle/admin/hswapdb>cd bdump /export/home1/oracle/admin/hswapdb/bdump> /export/home1/oracle/admin/hswapdb/bdump>ls -l *.log -rw-r--r-- 1 oracle dba Mar 23 13:57 alert_hswapdb.log /export/home1/oracle/admin/hswapdb/bdump>vi *.log "alert_hswapdb.log" lines, characters (115 null) Tue Jun 24 21:17: Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 SCN scheme 3 Using log_archive_dest parameter default value LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up ORACLE RDBMS Version: ITPUB 第 25 页科技技术新动力

26 System parameters with non-default values: processes = 400 timed_statistics = TRUE shared_pool_size = large_pool_size = java_pool_size = control_files = /export/home1/oracle/oradata/hswapdb/control01.ctl, /export/home1/oracle/oradata/hswapdb/control02.ctl, /export/home1/oracle/oradata/hswapdb/control03.ctl db_block_size = 8192 db_cache_size = compatible = db_file_multiblock_read_count= 16 fast_start_mttr_target = 300 undo_management = AUTO undo_tablespace = UNDOTBS1 undo_retention = remote_login_passwordfile= EXCLUSIVE db_domain = eygle.com instance_name = hswapdb dispatchers = (PROTOCOL=TCP) (SERVICE=hswapdbXDB) job_queue_processes = 10 hash_join_enabled = TRUE background_dump_dest = /export/home1/oracle/admin/hswapdb/bdump user_dump_dest = /export/home1/oracle/admin/hswapdb/udump core_dump_dest = /export/home1/oracle/admin/hswapdb/cdump sort_area_size = db_name = hswapdb open_cursors = 300 star_transformation_enabled= FALSE query_rewrite_enabled = FALSE pga_aggregate_target = aq_tm_processes = 1... Tue Mar 23 13:40: skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 ITPUB 第 26 页科技技术新动力

27 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 11, op = fork, loc = skgpspawn5 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 Tue Mar 23 13:42: skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 Tue Mar 23 13:55: Starting ORACLE instance (normal) Shutting down instance: further logons disabled Tue Mar 23 13:56: Shutting down instance (abort) License high water mark = 26 Instance terminated by USER, pid = Tue Mar 23 13:56: Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 SCN scheme 3 Using log_archive_dest parameter default value LICENSE_MAX_USERS = 0 SYS auditing is disabled Starting up ORACLE RDBMS Version: System parameters with non-default values: processes = 400 timed_statistics = TRUE shared_pool_size = large_pool_size = java_pool_size = control_files = /export/home1/oracle/oradata/hswapdb/control01.ctl, /export/home1/oracle/oradata/hswapdb/control02.ctl, /export/home1/oracle/oradata/hswapdb/control03.ctl db_block_size = 8192 db_cache_size = compatible = db_file_multiblock_read_count= 16 ITPUB 第 27 页科技技术新动力

28 fast_start_mttr_target = 300 undo_management = AUTO undo_tablespace = UNDOTBS1 undo_retention = remote_login_passwordfile= EXCLUSIVE db_domain = eygle.com instance_name = hswapdb dispatchers = (PROTOCOL=TCP) (SERVICE=hswapdbXDB) remote_dependencies_mode = SIGNATURE job_queue_processes = 10 hash_join_enabled = TRUE background_dump_dest = /export/home1/oracle/admin/hswapdb/bdump user_dump_dest = /export/home1/oracle/admin/hswapdb/udump core_dump_dest = /export/home1/oracle/admin/hswapdb/cdump sort_area_size = db_name = hswapdb open_cursors = 300 star_transformation_enabled= FALSE parallel_automatic_tuning= TRUE query_rewrite_enabled = FALSE pga_aggregate_target = aq_tm_processes = 1 PMON started with pid=2 DBW0 started with pid=3 LGWR started with pid=4 CKPT started with pid=5 SMON started with pid=6 RECO started with pid=7 CJQ0 started with pid=8 QMN0 started with pid=9 Tue Mar 23 13:56: starting up 1 shared server(s)... Tue Mar 23 13:56: starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'... Tue Mar 23 13:56: ALTER DATABASE MOUNT Tue Mar 23 13:56: Successful mount of redo thread 1, with mount id ITPUB 第 28 页科技技术新动力

29 Tue Mar 23 13:56: Database mounted in Exclusive Mode. Completed: ALTER DATABASE MOUNT Tue Mar 23 13:56: Current log# 2 seq# 2136 mem# 0: /export/home1/oracle/oradata/hswapdb/redo02.log Successful open of redo thread 1. Tue Mar 23 12:24: SMON: enabling cache recovery Tue Mar 23 12:24: Undo Segment 1 Onlined Undo Segment 2 Onlined Undo Segment 3 Onlined Undo Segment 4 Onlined Undo Segment 5 Onlined Undo Segment 6 Onlined Undo Segment 7 Onlined Undo Segment 8 Onlined Undo Segment 9 Onlined Undo Segment 10 Onlined Successfully onlined Undo Tablespace 1. Tue Mar 23 12:24: SMON: enabling tx recovery Tue Mar 23 12:24: Database Characterset is ZHS16GBK Tue Mar 23 12:25: SMON: Parallel transaction recovery tried Tue Mar 23 12:25: replication_dependency_tracking turned off (no async multimaster replication found) Completed: ALTER DATABASE OPEN Tue Mar 23 12:28: /* OracleOEM */ ALTER DATABASE DATAFILE '/export/home1/oracle/oradata/hswapdb/users01.dbf' RESIZE K Tue Mar 23 12:28: ORA-3297 signalled during: /* OracleOEM */ ALTER DATABASE DATAFILE '/export/h... Tue Mar 23 12:28: /* OracleOEM */ ALTER DATABASE DATAFILE '/export/home1/oracle/oradata/hswapdb/users01.dbf' RESIZE K ORA-3297 signalled during: /* OracleOEM */ ALTER DATABASE DATAFILE '/export/h... Tue Mar 23 12:28: ITPUB 第 29 页科技技术新动力

30 /* OracleOEM */ ALTER DATABASE DATAFILE '/export/home1/oracle/oradata/hswapdb/users01.dbf' RESIZE K Tue Mar 23 12:28: ORA-3297 signalled during: /* OracleOEM */ ALTER DATABASE DATAFILE '/export/h... Tue Mar 23 13:40: skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 11, op = fork, loc = skgpspawn5 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 Tue Mar 23 13:42: skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3 :q 发现数据库多次重起, 并记录了部分错误信息 该提示说明数据库无法 spawn a new session. quote Yong Huang's comment: The number in "skgpspawn failed:category = 27142" is probably ORA error: $ oerr ora , 0000, "could not create new process" // *Cause: OS system call // *Action: check errno and if possible increase the number of processes OSD (OS-dependent) errors are almost always shown as an skg... error (probably means "system, kernel generic"). I don't know what "depinfo = 12" means. 4. 尝试连接数据库 收到错误信息, 无法连接数据库 ITPUB 第 30 页科技技术新动力

31 $ sqlplus "/ as sysdba" SQL*Plus: Release Production on 星期二 3 月 23 14:14: Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. ERROR: ORA-12540: TNS: 超出内部限制请输入用户名 : ERROR: ORA-12540: TNS: 超出内部限制请输入用户名 : ERROR: ORA-12540: TNS: 超出内部限制 SP2-0157: 在 3 次尝试之后无法 CONNECT 到 ORACLE, 退出 SQL*Plus 内部限制超过, 通常说明某些系统资源不足. 5. 检查监听器 发现部分连接被拒绝 /export/home1/oracle>lsnrctl services LSNRCTL for Solaris: Version Production on 23-3 月 :37:23 Copyright (c) 1991, 2002, Oracle Corporation. All rights reserved. 正在连接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC))) 服务摘要.. 服务 "PLSExtProc" 包含 1 个例程 例程 "PLSExtProc", 状态 UNKNOWN, 包含此服务的 1 个处理程序... 处理程序 : "DEDICATED" 已建立 :0 已被拒绝 :0 LOCAL SERVER 服务 "hswapdb.eygle.com" 包含 2 个例程 例程 "hswapdb", 状态 UNKNOWN, 包含此服务的 1 个处理程序... 处理程序 : "DEDICATED" 已建立 :6 已被拒绝 :0 LOCAL SERVER 例程 "hswapdb", 状态 READY, 包含此服务的 1 个处理程序... 处理程序 : ITPUB 第 31 页科技技术新动力

32 "DEDICATED" 已建立 :21 已拒绝 :6 状态 :ready LOCAL SERVER 服务 "hswapdbxdb.eygle.com" 包含 1 个例程 例程 "hswapdb", 状态 READY, 包含此服务的 1 个处理程序... 处理程序 : "D000" 已建立 :0 已被拒绝 :0 当前 : 0 最大 : 972 状态 : ready DISPATCHER <machine: wapplatform, pid: 25839> (ADDRESS=(PROTOCOL=tcp)(HOST=wapplatform)(PORT=32869)) 命令执行成功 在 listener.log 中找到了相关错误信息 23-3\324\ :19:40 * (CONNECT_DATA=(SID=hswapdb)(CID=(PROGRAM=C:\WINNT\Microsoft.NET\Framework\v \aspnet_wp.e xe)(host=swan)(user=system))) * (ADDRESS=(PROTOCOL=tcp)(HOST= )(PORT=1291)) * establish * hswapdb * TNS-12500: TNS\243\272\274\340\314\375\306\367\316\264\304\334\306\364\266\257\327\250\323\3 03\265\304\267\376\316\361\306\36 7\275\370\263\314 TNS-12540: TNS\243\272\263\254\263\366\304\332\262\277\274\253\317\336\317\336\326\306 TNS-12560: TNS: \320\255\322\351\312\312\305\344\306\367\264\355\316\363 TNS-00510: \263\254\263\366\304\332\262\277\274\253\317\336\317\336\326\306 Solaris Error: 12: Not enough space 23-3\324\ :19:50 * (CONNECT_DATA=(SID=hswapdb)(CID=(PROGRAM=C:\Program Files\PLSQL Developer\PLSQLDev.exe)(HOST=SW AN)(USER=Administrator))) * (ADDRESS=(PROTOCOL=tcp)(HOST= )(PORT=1292)) * establish * hswapdb * TNS-12500: TNS\243\272\274\340\314\375\306\367\316\264\304\334\306\364\266\257\327\250\323\3 03\265\304\267\376\316\361\306\36 ITPUB 第 32 页科技技术新动力

33 7\275\370\263\314 TNS-12540: TNS\243\272\263\254\263\366\304\332\262\277\274\253\317\336\317\336\326\306 TNS-12560: TNS: \320\255\322\351\312\312\305\344\306\367\264\355\316\363 TNS-00510: \263\254\263\366\304\332\262\277\274\253\317\336\317\336\326\306 Solaris Error: 12: Not enough space /export/home1/oracle/app/network/log>grep -w 12 /usr/include/sys/errno.h #define ENOMEM 12 /* Not enough core quote Yong Huang's comment: $ grep -w 12 /usr/include/sys/errno.h #define ENOMEM 12 /* Not enough core */ Here "core" means memory, including real RAM memory and swap space. 6. 退出 Oracle 用户检查 检查系统日志信息, 发现大量失败的 su 操作 有 swap 区不足的报告 /export/home1/oracle/admin/hswapdb/bdump>exit wapplatform:/>dmesg 2004 年 03 月 23 日星期二 14 时 00 分 32 秒 CST Mar 22 22:52:36 wapplatform elfexec: [ID kern.notice] ps: Cannot find ^?ELF^A^B^A Mar 22 22:53:00 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 22:53:09 wapplatform elfexec: [ID kern.notice] w: Cannot find ^?ELF^A^B^A Mar 22 22:53:53 wapplatform last message repeated 4 times Mar 22 22:56:28 wapplatform elfexec: [ID kern.notice] ipnat: Cannot find ^?ELF^B^B^A Mar 22 22:58:00 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 22:59:54 wapplatform elfexec: [ID kern.notice] ipnat: Cannot find ^?ELF^B^B^A Mar 22 23:02:26 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file ITPUB 第 33 页科技技术新动力

34 system full Mar 22 23:03:00 wapplatform last message repeated 1 time Mar 22 23:08:00 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:08:34 wapplatform elfexec: [ID kern.notice] ipnat: Cannot find ^?ELF^B^B^A Mar 22 23:10:27 wapplatform last message repeated 3 times Mar 22 23:11:49 wapplatform elfexec: [ID kern.notice] ipnat: Cannot find ^?ELF^B^B^A Mar 22 23:11:52 wapplatform last message repeated 1 time Mar 22 23:13:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:18:01 wapplatform last message repeated 1 time Mar 22 23:23:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:28:01 wapplatform last message repeated 1 time Mar 22 23:33:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:38:01 wapplatform last message repeated 1 time Mar 22 23:43:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:48:01 wapplatform last message repeated 1 time Mar 22 23:53:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:58:01 wapplatform last message repeated 1 time Mar 23 00:00:00 wapplatform ufs: [ID kern.notice] NOTICE: realloccg /export/home1: file system full Mar 23 00:00:00 wapplatform sendmail[3075]: [ID mail.crit] My unqualified host name (wapplatform) unknown; sleeping for retry Mar 23 00:01:00 wapplatform sendmail[3075]: [ID mail.alert] unable to qualify my own domain name (wapplatform) -- using short name Mar 23 00:02:36 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 23 00:03:02 wapplatform last message repeated 1 time Mar 23 00:08:02 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full... ITPUB 第 34 页科技技术新动力

35 Mar 23 10:18:15 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 23 10:20:41 wapplatform ufs: [ID kern.notice] NOTICE: realloccg /export/home1: file system full Mar 23 10:20:47 wapplatform last message repeated 1 time Mar 23 10:23:15 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 23 10:24:38 wapplatform ufs: [ID kern.notice] NOTICE: realloccg /export/home1: file system full Mar 23 10:24:43 wapplatform last message repeated 1 time Mar 23 10:24:55 wapplatform ufs: [ID kern.notice] NOTICE: realloccg /export/home1: file system full Mar 23 10:25:06 wapplatform last message repeated 2 times Mar 23 11:09:31 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3118 (su) Mar 23 11:09:39 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3121 (su) Mar 23 11:10:48 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3137 (su) Mar 23 11:18:02 wapplatform sshd[3620]: [ID auth.error] error: grantpt: Not enough space Mar 23 11:18:02 wapplatform sshd[3620]: [ID auth.error] error: session_pty_req: session 0 alloc failed Mar 23 11:18:43 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3636 (su) Mar 23 11:19:47 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3672 (su) Mar 23 11:20:20 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3694 (su) Mar 23 11:22:23 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3736 (sshd) Mar 23 11:23:17 wapplatform tmpfs: [ID kern.warning] WARNING: /tmp: File system full, swap space limit exceeded Mar 23 11:23:40 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3804 (su) Mar 23 11:23:40 wapplatform last message repeated 8 times Mar 23 11:23:56 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3806 (ps) Mar 23 11:23:56 wapplatform last message repeated 12 times ITPUB 第 35 页科技技术新动力

36 Mar 23 11:24:01 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3808 (w) Mar 23 11:24:01 wapplatform last message repeated 8 times Mar 23 13:40:56 wapplatform su: [ID auth.crit] 'su root' failed for root on /dev/pts/2 Mar 23 13:46:26 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid (sqlplus) Mar 23 13:49:18 wapplatform su: [ID auth.crit] 'su oracle' failed for root on /dev/pts/6 Mar 23 13:54:03 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid (su) Mar 23 13:54:08 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid (su) 现在基本可以判断是交换区的问题, 当然和 Oracle SGA 设置有关. 7. 检查系统内存及交换区使用 /export/home1/oracle/admin/hswapdb/bdump>exit wapplatform:/>dmesg 2004 年 03 月 23 日星期二 14 时 00 分 32 秒 CST Mar 22 22:52:36 wapplatform elfexec: [ID kern.notice] ps: Cannot find ^?ELF^A^B^A Mar 22 22:53:00 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 22:53:09 wapplatform elfexec: [ID kern.notice] w: Cannot find ^?ELF^A^B^A Mar 22 22:53:53 wapplatform last message repeated 4 times Mar 22 22:56:28 wapplatform elfexec: [ID kern.notice] ipnat: Cannot find ^?ELF^B^B^A Mar 22 22:58:00 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 22:59:54 wapplatform elfexec: [ID kern.notice] ipnat: Cannot find ^?ELF^B^B^A Mar 22 23:02:26 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:03:00 wapplatform last message repeated 1 time Mar 22 23:08:00 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:08:34 wapplatform elfexec: [ID kern.notice] ipnat: Cannot find ITPUB 第 36 页科技技术新动力

37 ^?ELF^B^B^A Mar 22 23:10:27 wapplatform last message repeated 3 times Mar 22 23:11:49 wapplatform elfexec: [ID kern.notice] ipnat: Cannot find ^?ELF^B^B^A Mar 22 23:11:52 wapplatform last message repeated 1 time Mar 22 23:13:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:18:01 wapplatform last message repeated 1 time Mar 22 23:23:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:28:01 wapplatform last message repeated 1 time Mar 22 23:33:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:38:01 wapplatform last message repeated 1 time Mar 22 23:43:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:48:01 wapplatform last message repeated 1 time Mar 22 23:53:01 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 22 23:58:01 wapplatform last message repeated 1 time Mar 23 00:00:00 wapplatform ufs: [ID kern.notice] NOTICE: realloccg /export/home1: file system full Mar 23 00:00:00 wapplatform sendmail[3075]: [ID mail.crit] My unqualified host name (wapplatform) unknown; sleeping for retry Mar 23 00:01:00 wapplatform sendmail[3075]: [ID mail.alert] unable to qualify my own domain name (wapplatform) -- using short name Mar 23 00:02:36 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 23 00:03:02 wapplatform last message repeated 1 time Mar 23 00:08:02 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full... Mar 23 10:18:15 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 23 10:20:41 wapplatform ufs: [ID kern.notice] NOTICE: realloccg /export/home1: file system full Mar 23 10:20:47 wapplatform last message repeated 1 time ITPUB 第 37 页科技技术新动力

38 Mar 23 10:23:15 wapplatform ufs: [ID kern.notice] NOTICE: alloc: /export/home1: file system full Mar 23 10:24:38 wapplatform ufs: [ID kern.notice] NOTICE: realloccg /export/home1: file system full Mar 23 10:24:43 wapplatform last message repeated 1 time Mar 23 10:24:55 wapplatform ufs: [ID kern.notice] NOTICE: realloccg /export/home1: file system full Mar 23 10:25:06 wapplatform last message repeated 2 times Mar 23 11:09:31 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3118 (su) Mar 23 11:09:39 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3121 (su) Mar 23 11:10:48 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3137 (su) Mar 23 11:18:02 wapplatform sshd[3620]: [ID auth.error] error: grantpt: Not enough space Mar 23 11:18:02 wapplatform sshd[3620]: [ID auth.error] error: session_pty_req: session 0 alloc failed Mar 23 11:18:43 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3636 (su) Mar 23 11:19:47 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3672 (su) Mar 23 11:20:20 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3694 (su) Mar 23 11:22:23 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3736 (sshd) Mar 23 11:23:17 wapplatform tmpfs: [ID kern.warning] WARNING: /tmp: File system full, swap space limit exceeded Mar 23 11:23:40 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3804 (su) Mar 23 11:23:40 wapplatform last message repeated 8 times Mar 23 11:23:56 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3806 (ps) Mar 23 11:23:56 wapplatform last message repeated 12 times Mar 23 11:24:01 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid 3808 (w) Mar 23 11:24:01 wapplatform last message repeated 8 times Mar 23 13:40:56 wapplatform su: [ID auth.crit] 'su root' failed for root on /dev/pts/2 Mar 23 13:46:26 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap ITPUB 第 38 页科技技术新动力

39 space to grow stack for pid (sqlplus) Mar 23 13:49:18 wapplatform su: [ID auth.crit] 'su oracle' failed for root on /dev/pts/6 Mar 23 13:54:03 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid (su) Mar 23 13:54:08 wapplatform genunix: [ID kern.warning] WARNING: Sorry, no swap space to grow stack for pid (su) 现在基本可以判断是交换区的问题, 当然和 Oracle SGA 设置有关. 7. 检查系统内存及交换区使用 $ top last pid: 25456; load averages: 0.67, 0.70, :10:03 93 processes: 91 sleeping, 2 on cpu CPU states: 72.7% idle, 14.9% user, 2.7% kernel, 9.7% iowait, 0.0% swap Memory: 1024M real, 34M free, 752M swap in use, 10M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND oracle M 631M cpu/2 8: % oracle oracle M 630M sleep 0: % oracle oracle M 628M sleep 0: % oracle oracle K 1736K cpu/0 0: % top oracle M 630M sleep 0: % oracle oracle M 628M sleep 0: % oracle oracle M 626M sleep 0: % oracle oracle M 7208K sleep 0: % tnslsnr oracle M 624M sleep 0: % oracle oracle M 628M sleep 0: % oracle oracle M 628M sleep 0: % oracle oracle M 628M sleep 0: % oracle oracle M 628M sleep 0: % oracle oracle M 628M sleep 0: % oracle oracle M 628M sleep 0: % oracle ITPUB 第 39 页科技技术新动力

40 发现物理内存仅为 1G,free 部分为 34M, 交换区使用了 752M, 仅 10M free 系统内存严重不足,Swap 区不足 8. 检查数据库的 SGA 设置 发现 SGA 设置为 : bytes 接近 600M wapplatform:/>su - oracle Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001 You have new mail. /export/home1/oracle>sqlplus "/ as sysdba" SQL*Plus: Release Production on 星期二 3 月 23 14:02: Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. 连接到 : Oracle9i Enterprise Edition Release bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release Production SQL> show sga Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes SQL> 对于 RAM 小于 1G 的系统,Dedicated 模式下,Oracle 的 SGA 一般不应超过 1/2 物理内存. 9. 第一步调整 减小 SGA, 为系统保留足够的内存. 10. 增加 swap 区 wapplatform:/>df -k 文件系统千字节用了可用容量挂接在 /dev/dsk/c0t1d0s % / /dev/dsk/c0t2d0s % /usr ITPUB 第 40 页科技技术新动力

41 /proc % /proc fd % /dev/fd mnttab % /etc/mnttab /dev/dsk/c0t1d0s % /var swap % /var/run swap % /tmp /dev/dsk/c0t1d0s % /opt /dev/dsk/c0t2d0s % /export/home /dev/dsk/c2t1d0s % /export/home2 /dev/dsk/c0t3d0s % /export/home1 /dev/dsk/c0t1d0s % /usr/openwin /export/home/wapgw/luke % /home/wap wapplatform:/var/swap>cd /export/home1 wapplatform:/export/home1>ls TT_DB lost+found oracle oracli9 wapplatform:/export/home1>mkdir swap wapplatform:/export/home1>cd swap wapplatform:/export/home1/swap>mkfile -v 1g swapfile1 swapfile bytes wapplatform:/export/home1/swap>id uid=0(root) gid=1(other) wapplatform:/export/home1/swap>swap -a /export/home1/swap/swapfile1 wapplatform:/export/home1/swap>swap -s 总数 : 分配了 k 字节 + 保留 k = 已使用 k, k 可用 11. 连接测试 系统恢复正常, 问题解决 wapplatform:/export/home1/swap>su - oracle Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001 You have new mail. /export/home1/oracle>sqlplus "/ as sysdba" SQL*Plus: Release Production on 星期四 3 月 25 11:56: Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. 连接到 : ITPUB 第 41 页科技技术新动力

42 Oracle9i Enterprise Edition Release bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release Production SQL> exit 从 Oracle9i Enterprise Edition Release bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release Production 中断开 /export/home1/oracle>top last pid: 5372; load averages: 0.25, 0.22, :57: processes: 137 sleeping, 9 zombie, 2 on cpu CPU states: 98.8% idle, 0.2% user, 0.7% kernel, 0.2% iowait, 0.0% swap Memory: 1024M real, 17M free, 824M swap in use, 934M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 5363 root K 1736K sleep 0: % top 5370 oracle M 469M sleep 0: % oracle 5366 oracle M 469M sleep 0: % oracle 5341 oracle K 1736K cpu/2 0: % top 5372 oracle M 3288K cpu/3 0: % oracle 1288 oracle M 468M sleep 5: % oracle 607 root K 2312K sleep 1: % mibiisa oracle M 7208K sleep 0: % tnslsnr 1278 oracle M 466M sleep 0: % oracle 374 root K 2888K sleep 0: % nscd 1280 oracle M 466M sleep 0: % oracle 5361 root K 680K sleep 0: % sleep 5362 root K 680K sleep 0: % sleep 5469 root K 1176K sleep 30: % monithttp 4167 oracle M 471M sleep 29: % oracle 问题总结 : Oracle 数据库问题的解决从来就离不开操作系统 很多时候我们必须通过操作系统一级的手段来诊断并解决问题. 关于操作系统 ITPUB 第 42 页科技技术新动力

43 一般 Swap 区的推荐值为 2XRAM 如果 Ram 很大, 不一定非要把 Swap 设置为 2xSwap 但是通常至少设置 Swap = Ram 如果 Swap 区过小, 在系统繁忙期间 产生大量交换无法换到磁盘, 就会出现问题. 如本案例就是这样 另外, 如果系统 Ram 较小 通常设置 SGA < 1/2 Ram 要为 Server process 及 OS 保留足够的内存空间. 编者注 : 您可以通过以下连接参与关于本文的讨论, 直接和作者对话 : 或 ITPUB 第 43 页科技技术新动力

44 Oracle 诊断案例 -SGA 与 Swap 之二 作者 :Eygle 案例描述 : 这是一个大型生产系统问题出现时系统累计大量用户进程用户请求得不到及时响应, 新的进程不断尝试建立连接连接数很快被用完 数据库版本 : 操作系统 :Solaris8 1. 检查 alert 文件 日志中记录如下错误信息, 说明磁盘异步 IO 出现问题 : WARNING: aiowait timed out 2 times Tue Aug 26 15:33: WARNING: aiowait timed out 2 times Tue Aug 26 15:33: WARNING: aiowait timed out 2 times Tue Aug 26 15:33: WARNING: aiowait timed out 2 times Tue Aug 26 15:33: WARNING: aiowait timed out 2 times Tue Aug 26 15:33: WARNING: aiowait timed out 1 times Tue Aug 26 15:33: ITPUB 第 44 页科技技术新动力

45 WARNING: aiowait timed out 1 times Tue Aug 26 15:33: WARNING: aiowait timed out 1 times Tue Aug 26 15:33: WARNING: aiowait timed out 1 times Tue Aug 26 15:33: WARNING: aiowait timed out 1 times Tue Aug 26 15:33: WARNING: aiowait timed out 1 times... 我们知道在 SUN 的某些版本上异步 IO 存在问题 而异步 IO 缺省是打开的 SQL> show parameter disk_a NAME TYPE VALUE disk_asynch_io boolean TRUE 针对此问题, 我们停用了数据库的异步 IO 写入 2. 共享内存问题 3. alert 文件中还记录了以下错误信息 : Tue Aug 26 21:37: WARNING: EINVAL creating segment of size 0x fix shm parameters in /etc/system or equivalent ITPUB 第 45 页科技技术新动力

46 该信息说明内核参数设置过小或者和 SGA 不匹配 我们检查 system 配置文件 $ cat /etc/system... set shmsys:shminfo_shmmax= set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=200 set shmsys:shminfo_shmseg=200 set semsys:seminfo_semmap=1024 set semsys:seminfo_semmni=2048 set semsys:seminfo_semmns=2048 set semsys:seminfo_semmnu=2048 set semsys:seminfo_semume=200 set semsys:seminfo_semmsl=2048 我们发现最大共享内存设置仅有 4G 4. 检查 SGA 设置 5. SQL*Plus: Release Production on 星期二 8 月 26 21:46: Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to: Oracle9i Enterprise Edition Release bit Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release Production SQL> show sga Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes ITPUB 第 46 页科技技术新动力

47 我们发现 SGA 设置接近 7G, 这也就是步骤 2 中错误提示出现的原因 4. 交换区问题 我们用 top 工具检查系统运行状况 # /usr/local/bin/top last pid: 16899; load averages: 0.82, 0.81, :49: processes:1228 sleeping, 1 running, 1 on cpu CPU states: 50.1% idle, 7.4% user, 8.6% kernel, 33.9% iowait, 0.0% swap Memory: 8192M real, 118M free, 12G swap in use, 11G swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND oracle M 6408M sleep 0: % oracle oracle M 6410M sleep 0: % oracle 251 root K 1944K sleep 126: % picld oracle M 6411M sleep 0: % oracle root K 2248K cpu/1 0: % top oracle M 6410M sleep 0: % oracle oracle M 6409M sleep 0: % oracle oracle M 6409M sleep 0: % oracle oracle M 6409M sleep 0: % oracle oracle M 6410M sleep 0: % oracle oracle M 6412M sleep 0: % oracle oracle M 6411M sleep 0: % oracle oracle M 6409M sleep 0: % oracle oracle M 6408M sleep 0: % oracle oracle M 6408M sleep 0: % oracle Memory: 8192M real, 118M free, 12G swap in use, 11G swap free 我们发现系统仅有 8G RAM, 物理内存仅有 118M 可用 现在 SWAP 区使用了 12G ITPUB 第 47 页科技技术新动力

48 我们初步作出以下判断 : SGA 设置过大 ( 将近 7G) 导致运行时产生大量交换 大量 SWAP 交换进而引发磁盘问题这也就应该是我们第一步看到 WARNING: aiowait timed out 1 times 的原因 大量交换导致数据库性能急剧下降 进而导致用户请求得不到快速响应, 堵塞 累积, 直至数据库失去响应 5. 解决方案 此问题主要是由于 SGA 设置不当引起, 我们马上缩小了 SGA 设置 : SQL> show sga Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes 此时, 数据库减少了交换, 达到了稳定运行, 用户请求可以得到快速响应 问题解决完成. 6. 系统状态 调整后系统运行状况 : $ top last pid: 12745; load averages: 0.46, 0.79, :22:49 ITPUB 第 48 页科技技术新动力

49 228 processes: 227 sleeping, 1 on cpu CPU states: 92.3% idle, 5.0% user, 1.6% kernel, 1.1% iowait, 0.0% swap Memory: 8192M real, 3817M free, 4015M swap in use, 15G swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND oracle M 22M sleep 0: % oracle oracle M 22M sleep 0: % oracle oracle M 21M sleep 0: % oracle oracle M 22M sleep 0: % oracle oracle M 22M sleep 0: % oracle oracle M 21M sleep 0: % oracle 265 root K 1920K sleep 3: % picld oracle M 20M sleep 0: % oracle oracle K 1760K cpu/3 0: % top oracle M 16M sleep 0: % oracle oracle M 16M sleep 0: % oracle oracle M 16M sleep 0: % oracle 7606 oracle M 6928K sleep 0: % tnslsnr oracle M 16M sleep 0: % oracle oracle M 16M sleep 0: % oracle 该系统调整完以后, 一直稳定运行至今. 一点总结 : 这个案例和前面我提到的另外一个极其相似, 同样都是 SGA 设置不当引起的数据库问题, 本身并不 复杂, 这一类问题应该在数据库规划和建设阶段就避免掉. 其时, 该问题对我更像是个心理测试, 当所有老板都站在你背后的时候, 你能否冷静快速的找到并 解决问题. 编者注 : 您可以通过以下连接参与关于本文的讨论, 直接和作者对话 : 或 ITPUB 第 49 页科技技术新动力

50 ORACLE 诊断事件及深入解析 事件 作者 :wanghai,liyongdong 整理 :vongates Oracle 为 RDBMS 提供了多种的诊断工具, 诊断事件 (Event) 是其中一种常用 好用的方法, 它使 DBA 可以 方便的转储数据库各种结构及跟踪特定事件的发生. 一 Event 的通常格式及分类 1 通常格式如下 : EVENT="< 事件名称 >< 动作 >< 跟踪项目 >< 范围限定 >" 2 Event 分类 诊断事件大体上可以分为四类 : a. 转储类事件 : 它们主要用于转储 Oracle 的一些结构, 例如转储一下控制文件 数据文件头等内容 b. 捕捉类事件 : 它们用于捕捉一些 Error 事件的发生, 例如捕捉一下 ORA 发生时一些 Rdbms 信息, 以判断是 Bug 还是其它原因引起的这方面的问题 c. 改变执行途径类事件 : 它们用于改主一些 Oracle 内部代码的执行途径, 例如设置 将会使 Smon 进 程不去合并那些 Free 的空间 d. 跟踪类事件 : 这们用于获取一些跟踪信息以用于 Sql 调优等方面, 最典型的便是 了, 将会对 Sql 进 行跟踪 3 说明 : a. 如果 immediate 放在第一个说明是无条件事件, 即命令发出即转储到跟踪文件 b. trace name 位于第二 三项, 除它们外的其它限定词是供 Oracle 内部开发组用的 c. level 通常位于 1-10 之间 (10046 有时用到 12),10 意味着转储事件所有的信息 例如当转储控制文件 时,level1 表示转储控制文件头, 而 level 10 表明转储控制文件全部内容 ITPUB 第 50 页科技技术新动力

51 d. 转储所生成的 trace 文件在 user_dump_dest 初始化参数指定的位置 二 说一说设置的问题了可以在 init.ora 中设置所需的事件, 这将对所有会话期打开的会话进行跟踪, 也可以用 alter session set event 等方法设置事件跟踪, 这将打开正在进行会话的事件跟踪 1 在 init.ora 中设置跟踪事件的方法 a. 语法 EVENT= event 语法,level n :event 语法,level n b. 举例 event= trace name context forever,level 10 c. 可以这样设置多个事件 : EVENT="\ trace name context forever, level 10:\ trace name context forever, level 10" 2 通过 Alter session/system set events 这种方法举个例子大家就明白了 Example: Alter session set events immediate trace name controlf level 10 ; Alter session set events immediate trace name blockdump level ; (*) 在 oracle8x 及之上的版本也有这样的语句 : Alter system dump datafile 13 block 15; 实现的功能与 (*) 是类似的 3 使用 DBMS_SYSTEM.SET_EV 的方法 a. 过和定义如下 DBMS_SYSTEM.SET_EV( SI Binary_integer, SE Binary_integer, EV Binary_integer, LE Binary_integer, NM Binary_integer); SI: 即 v$session 中的 sid SE: 即 v$session 中的 serial# EV: 要设置的事件 LE: 要设置事件的级别 NM: 名称 b. 举个例子, 以 为例 SQL> EXECUTE SYS.DBMS_SYSTEM.SET_EV(sid,serial#,10046,12,''); ITPUB 第 51 页科技技术新动力

52 4 使用 Oradebug 来设置诊断事件的方法同样举个例子大家就明白了 : a. 找到 spid SQL>select username, sid, serial#, paddr from v$session where username='qiuyb'; USERNAME SID SERIAL# PADDR HRB C AD8 SQL>SELECT ADDR,PID,SPID FROM V$PROCESS WHERE ADDR= C AD8'; ADDR PID SPID C AD b. 设置事件, 以 为例 sqlplus /nolog SQL>connect / as sysdba; SQL>oradebug setospid 4835 SQL>oradebug unlimit -- 不限制转储文件的大小 SQL> oradebug event trace name context forever,level 设置事件进行 sql 跟踪 SQL> oradebug event trace name context off -- 关闭跟踪注意不要用 oradug 去跟踪 oracle 的 smon,pmon 等几个进程, 操作不当可能会杀掉这几个后台进和引起宕库 三 你可能的问题 1 我如何知道在系统中设置了哪些 event? 回答 : a. 如果你的事件是在 init.ora 中设置的可以用 SQL>show parameter event; 来查看 b. Michael R.Ault 给的 SQL serveroutput on size declare event_level number; begin for i in loop sys.dbms_system.read_ev(i,event_level); if (event_level > 0) then dbms_output.put_line('event ' to_char(i) ' set at level ' to_char(event_level)); end if; end loop; end; / 2 在 oracle9i 中使用 spfile 的那种如何设置诊断事件呢? 回答 : 简单,Alter system 命令就可以完成 alter system set event='10046 trace name context forever, level 12' scope=spfile; ITPUB 第 52 页科技技术新动力

53 重启一下就生效了 3 坏了, 我的 9i 设置完诊断事件, 起不来了, 报 ORA 错怎么办? 回答 : 那你一定是在使用 Alter system 时把某一项写错了, 比如把 context 写成了 conetxt 了, 可以做如下的解决 : a. 由 spfile 生成 pfile SQL>create pfile from spfile; File created. b. 编辑 pfile 以修正错误 Change... *.event='10046 trace name conetxt forever, level 12' -to- *.event='10046 trace name context forever, level 12' c. 用 pfile 启动 SQL>startup pfile=/... d. 重新生成 SPFILE. SQL>create spfile from pfile; File created. 不同事件 level 有不同的意思例如 : level 1: 跟踪 sql 语句, 包括解析 执行 提取 提交和回滚等 level 4: 包括变量的详细信息 level 8: 包括等待事件 level 12: 包括绑定变量与等待事件 我们可以通过下面的语句在 SQLPLUS 中来得到可用 Oracle 诊断事件列表 SET SERVEROUTPUT ON DECLARE err_msg VARCHAR2(120); BEGIN dbms_output.enable ( ); FOR err_num IN LOOP err_msg := SQLERRM (-err_num); IF err_msg NOT LIKE '%Message ' err_num ' not found%' THEN dbms_output.put_line (err_msg); ITPUB 第 53 页科技技术新动力

54 / END IF; END LOOP; END; 通常事件不需要 Oracle Support, 例如 : 1 分析数据文件块, 转储数据文件 n 的块 m alter system dump datafile n block m 2 分析日志文件 alter system dump logfile logfilename; 3 分析控制文件的内容 alter session set events 'immediate trace name CONTROLF level 10' 4 分析所有数据文件头 alter session set events 'immediate trace name FILE_HDRS level 10' 5 分析日志文件头 alter session set events 'immediate trace name REDOHDR level 10' 6 分析系统状态, 最好每 10 分钟一次, 做三次对比 alter session set events 'immediate trace name SYSTEMSTATE level 10' 7 分析进程状态 alter session set events 'immediate trace name PROCESSSTATE level 10' 8 分析 Library Cache 的详细情况 alter session set events 'immediate trace name library_cache level 10' 深入解析 事件 你是否想知道一句 sql 语句如何执行, 它是否走索引, 是否采用不同得驱动表, 是否用 nestloop join,hash join..? 这一切对你是否很神秘呢? 或许你会说 execution plan 能看到这些东西, 但是你是否清楚 execution plan 是如何得到? 这篇文章就是给出了隐藏在 execution plan 底下的具体实现 事件 事件是 oracle 提供的用于跟踪 sql 语句成本计算的内部事件, 它能记载 CBO 模式下 oracle 优化器如何计算 sql 成本, 生成相应的执行计划 如何设置 事件设置本 session 的 开启 : Alter session set events trace name context forever[,level {1/2}] ; 关闭 : Alter session set events trace name context off ; 设置其他 session 的 开启 : SYS.DBMS_SYSTEM.SET_EV (<sid>, <serial#>, 10053, {1 2}, '') 关闭 : ITPUB 第 54 页科技技术新动力

55 SYS.DBMS_SYSTEM.SET_EV (<sid>, <serial#>, 10053,0, '') 跟其他跟踪事件不同,10053 提供了两个跟踪级别, 但是级别 2 的跟踪信息比级别 1 少 ( 其他跟踪事件如 跟踪级别越高信息越多 ), 跟踪信息将被记录到 user_dump_dest 目录底下 注意, 要实现跟踪必须满足两个条件 :sql 语句必须被 hard parse 并且必须使用 CBO 优化器模式 如果 sql 语句已经被 parse 过, 那么 不生成跟踪信息 如果你使用 RULE 优化器, 那么 也不会生成跟踪信息 跟踪内容跟踪文件包括 6 部分 :Sql 语句优化器相关参数基本统计信息基本表访问成本综合计划特殊功能的成本重计算这篇文章将会涉及到前 4 项和一部分第 5 项的内容, 我们将会用以下语句作为例子 : select dname, ename from emp, dept where emp.deptno = dept.deptno and ename = :b1 sql 语句 : 这部分是整个跟踪文件里最容易理解的部分, 包括了所执行的 sql 语句, 如果你采用 RULE 模式优化器, 那么除了这一部分外将不会有多余信息出现在跟踪文件里 优化器相关参数 : 记载了所有影响成本计算的参数 *************************************** PARAMETERS USED BY THE OPTIMIZER ******************************** OPTIMIZER_FEATURES_ENABLE = OPTIMIZER_MODE/GOAL = Choose OPTIMIZER_PERCENT_PARALLEL = 0 HASH_AREA_SIZE = HASH_JOIN_ENABLED = TRUE HASH_MULTIBLOCK_IO_COUNT = 0 OPTIMIZER_SEARCH_LIMIT = 5 PARTITION_VIEW_ENABLED = FALSE _ALWAYS_STAR_TRANSFORMATION = FALSE _B_TREE_BITMAP_PLANS = FALSE STAR_TRANSFORMATION_ENABLED = FALSE _COMPLEX_VIEW_MERGING = FALSE _PUSH_JOIN_PREDICATE = FALSE PARALLEL_BROADCAST_ENABLED = FALSE OPTIMIZER_MAX_PERMUTATIONS = OPTIMIZER_INDEX_CACHING = 0 OPTIMIZER_INDEX_COST_ADJ = 100 QUERY_REWRITE_ENABLED = TRUE ITPUB 第 55 页科技技术新动力

56 QUERY_REWRITE_INTEGRITY = ENFORCED _INDEX_JOIN_ENABLED = FALSE _SORT_ELIMINATION_COST_RATIO = 0 _OR_EXPAND_NVL_PREDICATE = FALSE _NEW_INITIAL_JOIN_ORDERS = FALSE _OPTIMIZER_MODE_FORCE = TRUE _OPTIMIZER_UNDO_CHANGES = FALSE _UNNEST_SUBQUERY = FALSE _PUSH_JOIN_UNION_VIEW = FALSE _FAST_FULL_SCAN_ENABLED = TRUE _OPTIM_ENHANCE_NNULL_DETECTION = TRUE _ORDERED_NESTED_LOOP = FALSE _NESTED_LOOP_FUDGE = 100 _NO_OR_EXPANSION = FALSE _QUERY_COST_REWRITE = TRUE QUERY_REWRITE_EXPRESSION = TRUE _IMPROVED_ROW_LENGTH_ENABLED = TRUE _USE_NOSEGMENT_INDEXES = FALSE _ENABLE_TYPE_DEP_SELECTIVITY = TRUE _IMPROVED_OUTERJOIN_CARD = TRUE _OPTIMIZER_ADJUST_FOR_NULLS = TRUE _OPTIMIZER_CHOOSE_PERMUTATION = 0 _USE_COLUMN_STATS_FOR_FUNCTION = FALSE _SUBQUERY_PRUNING_ENABLED = TRUE _SUBQUERY_PRUNING_REDUCTION_FACTOR = 50 _SUBQUERY_PRUNING_COST_FACTOR = 20 _LIKE_WITH_BIND_AS_EQUALITY = FALSE _TABLE_SCAN_COST_PLUS_ONE = FALSE _SORTMERGE_INEQUALITY_JOIN_OFF = FALSE _DEFAULT_NON_EQUALITY_SEL_CHECK = TRUE _ONESIDE_COLSTAT_FOR_EQUIJOINS = TRUE DB_FILE_MULTIBLOCK_READ_COUNT = 32 SORT_AREA_SIZE = 基本统计信息 : 下一部分是所有表和索引的基本统计信息基本统计信息包括 表 : Trace label dba_tables column ITPUB 第 56 页科技技术新动力

57 CDN NUM_ROWS 表记录数 NBLKS BLOCKS 高水位以下的 block 数 TABLE_SCAN_CST 全表扫描的 I/O 成本 AVG_ROW_LEN AVG_ROW_LEN 平均行长 索引 : Trace label dba_indexes column Index#, col# 索引号及表列号 LVLS BLEVEL BTREE 索引高度 #LB LEAF_BLOCKS 索引叶块数 #DK DISTINCT_KEYS 不重复索引关键字 LB/K AVG_LEAF_BLOCKS_PER_KEY 叶块 / 关键字 DB/K AVG_DATA_BLOCKS_PER_KEY 数据块 / 关键字 CLUF CLUSTERING_FACTOR 索引聚合因子 *************************************** BASE STATISTICAL INFORMATION *********************** Table stats Table: DEPT Alias: DEPT TOTAL :: CDN: 16 NBLKS: 1 TABLE_SCAN_CST: 1 AVG_ROW_LEN: Index stats INDEX#: COL#: 1 TOTAL :: LVLS: 0 #LB: 1 #DK: 16 LB/K: 1 DB/K: 1 CLUF: 1 *********************** Table stats Table: EMP Alias: EMP TOTAL :: CDN: 7213 NBLKS: 85 TABLE_SCAN_CST: 6 AVG_ROW_LEN: Index stats INDEX#: COL#: 1 TOTAL :: LVLS: 1 #LB: 35 #DK: 7213 LB/K: 1 DB/K: 1 CLUF: 4125 INDEX#: COL#: 2 TOTAL :: LVLS: 1 #LB: 48 #DK: 42 LB/K: 1 DB/K: 36 CLUF: 1534 INDEX#: COL#: 8 TOTAL :: LVLS: 1 #LB: 46 #DK: 12 LB/K: 3 DB/K: 34 CLUF: 418 *************************************** 基本表访问成本 : 这里开始 CBO 将会计算单表访问的成本 单表访问路径 SINGLE TABLE ACCESS ITPUB 第 57 页科技技术新动力

58 PATH...1 Column: ENAME Col#: 2 Table: EMP Alias: EMP...2 NDV: 42 NULLS: 0 DENS: e TABLE: EMP ORIG CDN: 7213 CMPTD CDN: Access path: tsc Resc: 6 Resp: Access path: index (equal)...6 INDEX#: TABLE: EMP...7 CST: 39 IXSEL: e+000 TBSEL: e BEST_CST: 6.00 PATH: 2 Degree: 我们看一下上面是什么意思 首先 CBO 列出了 ename 列的统计信息 ( 第 2,3 行 ), 这些统计信息来自 dba_tab_columns 列的统计信息和 dba_tab_columns 中对应的列名如下 Trace label dba_tables column NDV NUM_DISTINCT 列的不重复值数 NULLS NUM_NULLS 列的空行数 DENS DENSITY 列密度, 没有直方图的情况下 = 1/NDV LO LOW_VALUE 列的最小值 ( 只对数字列 ) HI HIGH_VALUE 列的最大值 ( 只对数字列 ) 第 4 行出现了表的行数 ORIG CDN 和计算过的行数 CMPTD CDN (computed cardinality). 计算公司如下, CMPTD CDN = ORIG CDN * FF 在这里 FF 表示过滤因子 (Filter Factor) 我们稍后再来看 FF 是什么及如何计算的 第 5 行表示了全表扫描的成本 这里的成本是 62, 是由 NBLKS 和 db_file_multi_block_read_count 初始化参数计算出来的. 第 6-8 行是索引访问的成本 第 9 行是总结了以上信息并选出了最优的访问路径为全表扫描, 成本为 6 表扫描成本让我们来看一下全表扫描成本 (tsc) 是如何计算的这里有其他两个大表的基本统计信息 TOTAL :: CDN: NBLKS: 4339 TABLE_SCAN_CST: 265 AVG_ROW_LEN: 272 ITPUB 第 58 页科技技术新动力

59 TOTAL :: CDN: NBLKS: 8975 TABLE_SCAN_CST: 548 AVG_ROW_LEN: 151 你可能曾经看到过全表扫描成本 = 访问的块数目 / db_file_multi_block_read_count. 看起来这个等式很有意义因为 oracle 在做全表扫描时每个 I/O 请求将会读取 db_file_multi_block_read_count 个块 但是, 我们计算以上统计信息得到 NBLKS / TABLE_SCAN_CST = 4339 / 265 = db_file_multi_block_read_count( 这里的值是 32, 可以看前面参数那一页 ) 另外一个表为 NBLKS / TABLE_SCAN_CST = 8975 / 548 = 全表扫描成本和 db_file_multi_block_read_count CBO 将会根据 NBLKS 和 db_file_multiblock_read_count 来估计全表扫描成本, 但是 db_file_multiblock_read_count 通常会被打上折扣 实际上我们可以认为等式会是 TABLE_SCAN_CST = NBLKS / k 我们来看一下 k 和 db_file_multiblock_read_count 究竟有什么规律可寻 我们来做一个实验, 使用不同的 db_file_multiblock_read_count 值 4, 6,8, 12,16, 24,32 来测试 过滤因子 (FF) 为了理解索引访问成本我们需要了解一下过滤因子 过滤因子是一个介于 0 和 1 之间的数字, 反映了记录的可选择性 如果一个列有 10 种不同的值, 我们需要查询等于其中某一个值的记录时, 如果这 10 种值平均分布的话, 你将得到 1/10 的行数 如果没有直方图, 过滤因子为 FF = 1/NDV = density 再来看一下过滤因子和查询条件的关系不使用绑定变量的情况 : predicate Filter factor c1 = value 1/c1.num_distinct4 c1 like value 1/c1.num_distinct c1 > value (Hi - value) / (Hi - Lo) c1 >= value (Hi - value) / (Hi - Lo) + c1 < value (value - Lo) / (Hi - Lo) c1 <= value (value - Lo) / (Hi - Lo) + c1 between val1 and val2 (val2 val1) / (Hi - Lo) + 使用绑定变量的情况 (8i): predicate Filter factor col1 = :b1 col1.density col1 {like > >= < <=} :b1 {5.0000e-02 col1. col1 between :b1 and :b e-02 * e- 包含 and 和 or 的情况 : ITPUB 第 59 页科技技术新动力

60 predicate Filter factor predicate 1 and predicate 2 FF1 * FF2 predicate 1 or predicate 2 FF1 + FF2 FF1 * FF2 索引访问成本 : 现在我们知道了聚合因子的概念, 我们再来看一看索引访问的成本 SINGLE TABLE ACCESS PATH...1 Column: ENAME Col#: 2 Table: EMP Alias: EMP...2 NDV: 42 NULLS: 0 DENS: e TABLE: EMP ORIG CDN: 7213 CMPTD CDN: Access path: tsc Resc: 6 Resp: Access path: index (equal)...6 INDEX#: TABLE: EMP... 7 CST: 39 IXSEL: e+000 TBSEL: e BEST_CST: 6.00 PATH: 2 Degree: 我们来看 6-8 行, 这里表示了索引访问的成本 第 6 行表示这里采取索引 equal 的方法来访问, 再来回忆一下索引的基本统计信息 INDEX#: COL#: 2 TOTAL :: LVLS: 1 #LB: 48 #DK: 42 LB/K: 1 DB/K: 36 CLUF: 1534 根据索引成本计算公式 blevel + FF*leaf_blocks + FF*clustering_factor e-002-2* e-002-2*1534 = = 这里的 FF 就等于 TBSEL=DENS=2.3810e-002, 由于我们的查询条件为 ename = :b1 所以得出 FF 为 ENAME 列的 DENS, 其实索引访问方式的成本计算公式 Unique scan blevel+1 Fast full scan leaf_blocks / k ( k = x ) ITPUB 第 60 页科技技术新动力

61 Index-only blevel + FF*leaf_blocks 让我们用别的例子证明一下索引成本计算, 语句为 select from tbl a where a.col#1 = :b1 and a.col#12 = :b2 and a.col#8 = :b3 索引和列的基本统计数据如下 INDEX# COL# LVLS #LB #DK LB/K DB/K CLUF , ,12, ,1,4, ,12, ,2,33,4,5, Col#: 1 NDV: 10 NULLS: 0 DENS: e Col#: 12 NDV: 8 NULLS: 0 DENS: e-001 Col#: 8 NDV: 33 NULLS: 0 DENS: e-001 Access path: index (scan)... 1 INDEX#: 8418 CST: IXSEL: e-002 TBSEL: e Access path: index (equal)... 3 INDEX#: CST: 7209 IXSEL: e+000 TBSEL: e Access path: index (scan)... 5 INDEX#: 8416 CST: IXSEL: e-001 TBSEL: e 个索引中, 索引 (#8417 and #8419) 将不会被考虑因为他们的首列不出现在查询条件中. INDEX# 8418 索引包含的 3 个列中只有 2 列出现在查询条件中, 所以只用 2 列的 DENS 来计算过滤因子 FF = e-001 * e-001= e-002 cost = lvl + FF*#LB + FF*clustering factor ITPUB 第 61 页科技技术新动力

62 = ,000*1.2500e *1.2500e-002 = = INDEX# 索引包含的 3 列都出现在查询条件中, 用 3 列的 DENS 计算过滤因子 FF = e-001 * e-001 * e-001 = e-003 cost = lvl + FF*#LB + FF*clustering factor = ,600*3.7879e ,890,275*3.7879e-003 = = INDEX# 8416 索引包含的 3 个列中只有 1 列出现在查询条件中, 所以只用 1 列的 DENS 来计算过滤因子 FF = e-001 cost = lvl + FF*#LB + FF*clustering factor = ,800*1.0000e ,900*1.0000e-001 = = 虽然索引 8416 只有一列出现在查询条件中, 但是它的成本还是低于索引 8418, 因为它的聚合因子 (clustering factor) 比较低, 所以统计出来成本也比较低 关于聚合因子可以参考 oracle 官方文档 综合计划 : 这一部分开始是 最大的一部分, 在这里 CBO 会评估各种 JOIN 方式及顺序的成本 1. NL - NESTED LOOP JOIN join cost = cost of accessing outer table + (row number of outer table * cost of accessing inner table ) 2. SM SORT MERGE JOIN join cost = (cost of accessing outer table + outer sort cost) + (cost of accessing inner table + inner sort cost) 3. HA HASH JOIN join cost = (cost of accessing outer table) + (cost of building hash table) + (cost of accessing inner table ) JOIN ORDER [N] Join order[1]: DEPT [DEPT] EMP [EMP] Now joining: EMP [EMP] ******* JOINS NL NL Join... 1 Outer table: cost: 1 cdn: 16 rcz: 13 resp: ITPUB 第 62 页科技技术新动力

63 1...2 Inner table: EMP... 3 Access path: tsc Resc: Join resc: 97 Resp: Access path: index (join stp)... 6 INDEX#: TABLE: EMP... 7 CST: 39 IXSEL: e+000 TBSEL: e Join resc: 625 resp: Access path: index (join index)...10 INDEX#: TABLE: EMP...11 CST: 37 IXSEL: e+000 TBSEL: e Join resc: 593 resp: Access path: and-equal...14 CST: Join resc: 305 resp: Join cardinality: 172 = outer (16) * inner (172) * sel (6.2500e-002) [flag=0]...17 Best NL cost: 97 resp: 第 1 行为 JOIN 方式第 2 行为驱动表的成本, 行数, 行大小 这里的行数为 16, 平均行长原本为 20, 但是因为 DEPT 表包含 (DEPTNO, DEPT, and LOC)3 列但仅有 DEPTNO,DEPT 等 2 列需要被 join, 所以计算后平均行长为 16, 所以在这里也被称为 low row size. 第 3 行到 16 行通过 NL JOIN 的成本计算公式, 计算出几种不同 join 方法的成本 ITPUB 第 63 页科技技术新动力

64 1. Tablescan of EMP at a cost of 6: cost = cost of outer + cardinality of outer * cost of inner = * 6 = 97 lines 3 to 5 2. Scan of index on ENAME at a cost of 39: cost = * 39 = 625 lines 6 to 9 3. Scan of index on DEPTNO at a cost of 37: cost = * 37 = 593 lines 10 to An and-equal access at a cost of 19: cost = * 19 = 305 lines 14 to 16 第 17 行 CBO 估算出这个 JOIN 结果集的记录数, 它将被最为下一次 join 的输入 它的计算公式为 Join cardinality:= outer * inner * join selectivity 而 join selectivity 为 join selectivity = 1/max[ NDV(t1.c1), NDV(t2.c2) ] * [ (card t1 - # t1.c1 NULLs) / card t1 ] * [ (card t2 - # t2.c2 NULLs) / card t2 ] Join cardinality 只会被用于 NL JOIN 中, 其他 JOIN 会采取不同办法 最后在 18 行,CBO 将会列出成本最低的 NL JOIN 的方法 JOINS - SM SM Join Outer table: resc: 1 cdn: 16 rcz: 13 deg: 1 resp: 1 Inner table: EMP resc: 6 cdn: 172 rcz: 9 deg: 1 resp: 6 SORT resource Sort statistics Sort width: 3 Area size: Degree: 1 Blocks to Sort: 1 Row size: 25 Rows: 16 Initial runs: 1 Merge passes: 1 Cost / pass: 2 Total sort cost: 2 SORT resource Sort statistics Sort width: 3 Area size: Degree: 1 Blocks to Sort: 1 Row size: 20 Rows: 172 Initial runs: 1 Merge passes: 1 Cost / pass: 2 Total sort cost: 2 Merge join Cost: 10 Resp: 10 SM Join (with index on outer) Access path: index (no sta/stp keys) INDEX#: TABLE: DEPT CST: 2 IXSEL: e+000 TBSEL: e+000 ITPUB 第 64 页科技技术新动力

65 Outer table: resc: 2 cdn: 16 rcz: 13 deg: 1 resp: 2 Inner table: EMP resc: 6 cdn: 172 rcz: 9 deg: 1 resp: 6 SORT resource Sort statistics Sort width: 3 Area size: Degree: 1 Blocks to Sort: 1 Row size: 20 Rows: 172 Initial runs: 1 Merge passes: 1 Cost / pass: 2 Total sort cost: 2 Merge join Cost: 10 Resp: 10 在 SM JOIN 中成本为 Cost of outer + cost of inner + sort cost for outer + sort cost for inner = = 11. 在这里 CBO 减去 1 所以最终等于 10 在第 2 个 SM JOIN 的方法下通过了已经排序的索引, 所以成本为 (no sort on outer) + 2 = 10. JOINS HA HA Join Outer table: resc: 1 cdn: 16 rcz: 13 deg: 1 resp: 1 Inner table: EMP resc: 6 cdn: 172 rcz: 9 deg: 1 resp: 6 Hash join one ptn: 1 Deg: 1 hash_area: 32 buildfrag: 33 probefrag: 1 ppasses: 2 Hash join Resc: 8 Resp: 8 Join result: cost: 8 cdn: 172 rcz: 22 根据 HA JOIN 公式, 计算出成本为 (cost of accessing outer table)+ (cost of building hash table)+ (cost of accessing inner table ) =1+6+1=8 所以在这里 HA JOIN 会被选做最优化的执行路径,SQL 语句将会最终走 HA JOIN. 多重 JOIN: 如果出现大于两个表进行 JOIN 的情况, 那么会有更多的 join 顺序被考虑,4 个表 join 的话会有 24 种 join 顺序,5 个表的话会有 120 个 join 顺序,n 个表会有 n! 个 join 顺序 由于估算每种 join 顺序都会耗费 cpu, 所以 oracle 用一个初始化参数 optimizer_max_permutations 来限制最大计算 join 顺序 若想了解多重 join 的更多信息, ITPUB 第 65 页科技技术新动力

66 请搜索相关 sql 调整的资料 结论 : 是一个很好的理解 CBO 工作机制的工具, 如果辅以 事件查看执行计划, 那么整个 sql 语句从解析到执行的过程都一目了然了 编者注 : 您可以通过以下连接参与关于本文的讨论, 直接和作者对话 : ITPUB 第 66 页科技技术新动力

67 用 events 跟踪解决不能创建物化视图一例 作者 :Fenng 最近在工作中, 需要从 DBlink 同步数据. 由于是一个小型的统计系统. 决定创建物化视图 (materialized view) 便于两边系统的数据同步. 远程系统是另一家公司维护的产品. 接口也是由他们提供. 按照接口标准创建 DBlink 后. 准备创建物化视图 : CREATE MATERIALIZED VIEW SUBSCRIPTION_TAB BUILD IMMEDIATE REFRESH complete START WITH SYSDATE NEXT trunc(sysdate) + 1 AS SELECT * FROM SUBSCRIPTION_TAB@SMGR; 不料想, 执行之后语句报告错误 : SQL> CREATE MATERIALIZED VIEW SUBSCRIPTION_TAB 2 BUILD IMMEDIATE 3 REFRESH complete START WITH SYSDATE NEXT trunc(sysdate) AS SELECT * FROM SUBSCRIPTION_TAB@SMGR; AS SELECT * FROM SUBSCRIPTION_TAB@SMGR * ERROR at line 4: ORA-00942: table or view does not exist SQL>desc SUBSCRIPTION_TAB@SMGR 发现输出正常. ITPUB 第 67 页科技技术新动力

68 检查远程接口对象 (SUBSCRIPTION_TAB) 属性 : 为正常的数据表. 发现该表无主键, 但是和 ORA 错误无关. 暂且不表. 查找 Metalink. 这种问题找这个最快了 搜索出来一堆的帖子, 归纳一下可能的原因 : 1 远程对象为同义词, 而对应的表无 mv log 2 global_name 的问题 3 Bug. 4 MLOG$_ 的问题. 要重新创建 MV log... n others 快刀斩乱麻加上猜测, 发现以上皆非 此过程花费时间若干, 眼睛花了好几回. 还有我们有最后一招 : set events '942 trace name errorstack level 10' 设定跟踪, SQL> alter session set max_dump_file_size = unlimited; Session altered. SQL> alter session set events '10046 trace name context forever, level 12'; Session altered. SQL> alter session set events '942 trace name errorstack level 10'; Session altered. SQL> CREATE MATERIALIZED VIEW SUBSCRIPTION_TAB 2 BUILD IMMEDIATE 3 REFRESH complete START WITH SYSDATE NEXT trunc(sysdate) + 1 ITPUB 第 68 页科技技术新动力

69 4 AS SELECT * FROM SUBSCRIPTION_TAB@SMGR; AS SELECT * FROM SUBSCRIPTION_TAB@SMGR * ERROR at line 4: ORA-00942: table or view does not exist... 此过程如果执行中如果提示用户无权限, 需要作适当的授权 然后找到我们的 Trace 文件 : [oracle@stat udump]$ ls -ltr... -rw oracle oracle May 13 18:23 stat_ora_1512.trc -rw oracle oracle May 13 18:26 stat_ora_1595.trc -rw oracle oracle May 13 18:27 stat_ora_1689.trc -rw oracle oracle May 13 18:31 stat_ora_1700.trc -rw-rw oracle oracle 1677 May 14 14:49 stat_ora_1046.trc -rw-rw oracle oracle 631 May 15 19:35 stat_ora_14864.trc -rw-rw oracle oracle 631 May 15 19:42 stat_ora_15187.trc -rw-rw oracle oracle 631 May 15 20:57 stat_ora_18540.trc -rw oracle oracle May 15 21:41 stat_ora_20358.trc //This one! 打开该文件, 看了半天, 没看太明白. 乱糟糟的一大堆内容, 头疼. 还是格式化一下再看 : [oracle@stat udump]$ tkprof stat_ora_20358.trc SNAPSHOT.sql 查看 SNAPSHOT.sql 这回内容还算清晰, 发现主要相关内容如下 : The following statements encountered a error during parse: SELECT * FROM "witsdba"."subscription_tab"@smgr.us.oracle.com Error encountered: ORA ITPUB 第 69 页科技技术新动力

70 SELECT FROM Error encountered: ORA SELECT * FROM "PUBLIC"."SUBSCRIPTION_TAB"@SMGR.US.ORACLE.COM Error encountered: ORA SELECT "PUBLIC"."SUBSCRIPTION_TAB"[email protected] FROM [email protected] Error encountered: ORA CREATE MATERIALIZED VIEW SUBSCRIPTION_TAB BUILD IMMEDIATE REFRESH complete START WITH SYSDATE NEXT trunc(sysdate) + 1 AS SELECT * FROM SUBSCRIPTION_TAB@SMGR [oracle@stat udump]$ tkprof stat_ora_20358.trc SNAPSHOT.sql SELECT * FROM "witsdba"."subscription_tab"@smgr.us.oracle.com... 先从这句下手, 从 sqlplus 命令中输入, 查询看看 : SQL> SELECT * FROM "witsdba"."subscription_tab"@smgr.us.oracle.com 2 / SELECT * FROM "witsdba"."subscription_tab"@smgr.us.oracle.com * ERROR at line 1: ORA-00942: table or view does not exist ORA-02063: preceding line from SMGR... Faint, 不太可能阿. ITPUB 第 70 页科技技术新动力

71 刚才 desc 不是还好好的么? 莫非是, 莫非是 witsdba 导的鬼? SQL> c/witsdba/witsdba 查询, 居然 OK. 抽取 dblink SMGR 的 ddl : CREATE DATABASE LINK SMGR CONNECT TO "witsdba" IDENTIFIED BY "mypasswd" USING 'smgr';... "witsdba"??!! 删掉, 重新创建. CREATE DATABASE LINK SMGR CONNECT TO WITSDBA IDENTIFIED BY "mypasswd" 'smgr' /... USING 执行 SQL, 创建物化试图. 一切正常 打扫战场, 做个总结 以上涉及到具体的表名字因为设计到安全问题均已经作了适当的处理 整个过程比较关键的还是 alter session set events '942 trace name errorstack level 10' 这 一步 ITPUB 第 71 页科技技术新动力

72 很多时候, 如果 DBA 在 Metalink 上提交一个 Tar 的话 Oracle 技术支持人员会要求用户按照一定 操作提交 Trace 文件 出于其他的原因 ( 开始还以为是个 Bug), 只好自己动手了 而且, 瞎猫碰上了死耗子, 碰巧解决 了问题 编者注 : 您可以通过以下连接参与关于本文的讨论, 直接和作者对话 : ITPUB 第 72 页科技技术新动力

73 ORA-1157 错误解决手册 作者 :coolyl 一. 错误描述 ORA-1157, "cannot identify/lock data file %s - see DBWR trace file" 引起的原因 : 因为数据文件已经在被使用了从而导致数据库的后台进程不能找到相应的数据文件或者不能锁定相应的数据文件, 这样数据库将禁止访问这些数据文件而其他的数据文件则没有影响 伴随这个错误操作系统将会提示是哪个数据文件不能被识别 ORA 错误一般和 ORA 错误一起出现, 往往还有操作系统级别上的错误, 例如 ORA-07360, 同时一个 DBWR 的 trace 文件会在 background_dump_dest 的目录下生成 例如, 在 Solaris 的平台上, 会有如下的错误信息显示 : ORA-01157: cannot identify/lock data file 5 - see DBWR trace file ORA-01110: data file 5: '/export/home/oracle/oradata/817/users01.dbf' 然后查看 DBWR 的 trace 文件内容, 会有如下的内容 : ORA-01157: cannot identify/lock data file 5 - see DBWR trace file ORA-01110: data file 5: '/export/home /Oracle/oradata/817/users01.dbf' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3 下面就几个容易产生 ORA-1157 错误的方面详细谈谈 : 二. 通常引起 ORA-1157 错误的原因和解决方法 如果你是使用 Oracle9i, 就用 SQLPLUS 代替 SVRMGRL 执行以下的命令 ITPUB 第 73 页科技技术新动力

74 1. 数据文件存在, 但是 Oracle 认不到它这种情况可能是在操作系统级上数据文件被重命名了或者移动到了一个新的分区或者位置, 这种情况比较简单, 只是需要将数据文件恢复成原始的数据文件名字或者重新命名数据文件到一个新的位置 / 目录就可以解决问题了 重新命名数据文件到一个新的位置 / 目录的方法 : A. 数据库是打开状态的 1) 查看那个数据文件所在的表空间还包含有哪些数据文件, 执行以下查询 : SELECT FILE_NAME, STATUS FROM DBA_DATA_FILES WHERE TABLESPACE_NAME = '<YOUR_TABLESPACE_NAME>'; 2) 确定所有数据文件的状态都是可用的 3) 把表空间变成只读表空间 : ALTER TABLESPACE <YOUR_TABLESPACE_NAME> READ ONLY; 4) 确定在数据字典中表空间是显示为只读的 : SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES WHERE TABLESPACE_NAME = '<YOUR_TABLESPACE_NAME>'; TABLESPACE_NAME STATUS <YOUR_TABLESPACE_NAME> READ ONLY 5) 用操作系统命令拷贝数据文件到一个新的位置, 拷贝完成后把整个表空间 OFFLINE, 这个时候用户是不能访问这个表空间的 : ITPUB 第 74 页科技技术新动力

75 ALTER TABLESPACE <YOUR_TABLESPACE_NAME> OFFLINE; 6) 重命名这个数据文件到一个新的位置了, 这个操作会自动的更新控制文件中的内容 : ALTER DATABASE RENAME FILE '/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF' TO '/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF'; 7)ONLINE 这个表空间 : ALTER TABLESPACE YOUR_TABLESPACE_NAME ONLINE; 8) 把这个表空间置成可读写的状态 : ALTER TABLESPACE YOUR_TABLESPACE_NAME READ WRITE; 9) 在操作系统级上删除原来旧的数据文件 B. 数据库是关闭状态的 1) 先正常关闭数据库 2) 用操作系统命令拷贝数据文件到一个新的位置 3) MOUNT 数据库, 这样将读取控制文件, 但是不会读取数据文件 : STARTUP MOUNT ITPUB 第 75 页科技技术新动力

76 4) 重命名这个数据文件到一个新的位置了, 这个操作会自动的更新控制文件中的内容 : ALTER DATABASE RENAME FILE '/FULL_PATH_OF_OLD_LOCATION/AND_DATAFILE_NAME.DBF' TO '/FULL_PATH_OF_NEW_LOCATION/AND_DATAFILE_NAME.DBF'; 5) 打开数据库 : ALTER DATABASE OPEN; 2. 数据文件不存在或者对于 Oracle 来说是不可用的 数据文件被物理的移走了或者损坏导致 Oracle 不能再认到了, 例如数据文件被截断或者覆盖了, 一 般会出现 ORA ORA-1157 的错误提示 : ORA-27046: file size is not a multiple of logical block size 这种情况下可以有两种选择去解决问题 : A. 重建数据文件所属的那个表空间这种方法比较适用于 USERS TEMP INDEX 表空间, 如果数据库是正常关闭的, 也就是说回滚段中没有激活的表空间事务, 也推荐使用这种方法 如果是 SYSTEM 表空间, 则要重建数据库了 具体步骤如下 : 1) MOUNT 数据库 : STARTUP MOUNT PFILE='<location_of_pfile>'; 2) OFFLINE DROP 数据文件 : ITPUB 第 76 页科技技术新动力

77 ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE DROP; 3) 打开数据库 : ALTER DATABASE OPEN; 4) 删除表空间 : DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS; 5) 重建表空间 : CREATE TABLESPACE <tablespace_name> DATAFILE '<datafile_full_path_name'> SIZE <required_size>; 6) 重建表空间中所有以前存在的对象 : 可以使用以前创建对象的脚本或者利用最近可用的 EXPORT DUMP 来重建以前存在的对象 B. 用正常的恢复过程去恢复数据文件这种方法比较适用于只读表空间或者那种不能用重建表空间的方法的 USERS 和 INDEX 表空间 如果是回滚段表空间, 那必须要求数据库是正常关闭的才能使用这个方法 如果是 SYSTEM 表空间, 并且备份和所有的归档日志都全的情况下, 强烈建议使用这种方法去恢复的, 但是如果是非归档方式, 则就只能利用当前所有的联机日志进行恢复了 在很多的情况下, 重建表空间是不可能的或者是非常费时费力的, 因此, 从备份和利用归档日志恢复数据文件是一种比较好的方法, 尤其是对于只读表空间来说, 因为没有数据的写入和更改, 因此直接用备份来恢复是最快最省事的 ITPUB 第 77 页科技技术新动力

78 具体步骤如下 : 1) 从备份中恢复丢失或者损坏的数据文件 2) MOUNT 数据库 : STARTUP MOUNT PFILE='<location_of_pfile>'; 3) 执行以下的查询 : SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE# FROM V$LOG V1, V$LOGFILE V2 WHERE V1.GROUP# = V2.GROUP#; 这个查询将列出所有联机重做日志以及它们所代表的 SEQUENCE 和 FIRST CHANGE NUMBER. 4) 如果数据库是非归档状态下的, 执行以下的查询 : SELECT FILE#, CHANGE# FROM V$RECOVER_FILE; 如果 CHANGE# 大于最小的联机重做日志文件的 FIRST_CHANGE#, 那么数据文件可以被恢复, 记住恢复数据文件的时候要应用所有的联机重做日志文件, 然后到第 5 步 如果 CHANGE# 小于最小的联机重做日志文件的 FIRST_CHANGE#, 那么这个数据文件将不能被恢复了, 那么只能从最近的数据库全备份恢复或者重建这个数据文件所属的表空间了 5) 恢复数据文件 : RECOVER DATAFILE '<full_path_file_name>'; ITPUB 第 78 页科技技术新动力

79 6) 确认所有的归档日志都被应用了直至出现 "Media recovery complete" 的提示信息, 如果 Oracle 提示有一个不存在的归档日志文件, 那么就可能要应用所有的联机重做日志文件来恢复直至出现 "Media recovery complete" 的提示信息 7) 打开数据库 : ALTER DATABASE OPEN; 3. 数据库临时表空间的数据文件的丢失当数据库的临时表空间的数据文件丢失也会引起 ORA 的错误 因为数据库对临时表空间的数据文件不会发生检查点, 所以这个时候数据库照样能够打开 这种情况下的解决方法是逻辑上删除临时表空间的数据文件, 并且重新增加一个新的临时表空间的数据文件 例如 : SELECT * FROM DBA_OBJECTS ORDER BY OBJECT_NAME; select * from dba_objects order by object_name; * ERROR at line 1: ORA-01157: cannot identify/lock data file 5 - see DBWR trace file ORA-01110: data file 5: '/Oracle/oradata/temp01.dbf' ALTER DATABASE TEMPFILE /Oracle/oradata/temp01.dbf DROP; SELECT TABLESPACE_NAME,FILE_NAME FROM DBA_TEMP_FILES; ALTER TABLESPACE TEMP ADD TEMPFILE /Oracle/oradata/temp01.dbf SIZE 100M; 三. 由于操作系统的问题或者第三方软件的问题导致 ORA 错误 1. 当使用 vxfddstat 去访问快速 I/O 或者其它的应用, 会获得 "Cannot open file" 的错误, 而 Oracle 会返回如下的错误 : ORA-01157: cannot identify data file 1 - file not found ORA-01110: data file 1: '<filename>' ITPUB 第 79 页科技技术新动力

80 这个时候用户应该去联系 Veritas 的技术支持, 技术支持网站网址为 2. 在 HP-UNIX 的机器上, 如果系统核心参数 nflock 设置不是足够大的时候, 这样可能会使 Oracle 不能锁定所需要的数据文件而导致错误 : ORA-27086: skgfglk: unable to lock file - already in use 或者错误 : ORA-01157: cannot identify/lock data file 4 - see DBWR trace file ORA-0110: data file 4: '/Oracle/oradata/user01.dbf' ORA-27041: unable to open file HP-UX Error: 23: File table overflow Additional information: 2 或者错误 : ORA-07445: exception encountered: core dump [%s] [%s] [%s] [%s] [%s] [%s] ORA-01110: data file %s: '%s' ORA-01242: data file suffered media failure: database in NOARCHIVELOG mode ORA-01115: IO error reading block from file %s (block # %s) ORA-27041: unable to open file HP-UX Error: 23: File table overflow Additional information: 3 解决这个问题的方法是增大相关的核心参数 :( 建议以下的配置 ) nproc 4096 Max Number of Processes nfile Max Number of Open Files nflocks 4096 Max Number of File Locks 3. 如果 Oracle 需要的数据文件被其他进程锁定的条件下也会导致这个错误 例如 : 备份软件将可能锁定要备份的数据文件 在 WINDOWS 上可能会有如下的错误 : ITPUB 第 80 页科技技术新动力

81 ORA-01157: signalled during alter database open ORA-01157: can not identify datafile <datafile id> ORA-01110: datafile <datafile id> path and filename of datafile ORA-27047: Unable to read header of file <datafile id> OSD-04006: Read file failure Error 33: process can not access file 操作系统错误 33 是一个 error_lock_violation, 表明一部分数据文件被 WINDOWS 的其他进程锁定了 或者错误 : ORA cannot identify datafile <name> - file not found ORA datafile <name>: <str> ORA sfifi: error identifying file OSD-4006(OS 203) - The System could not find the environment option that was entered 在 ALERT 文件中将会同时出现以下的错误 : ORA IO error reading block from file %s (block # %s) ORA datafile <name>: <str> ORA sfrfb: error reading from file OSD-4006(OS 203) - The System Could not find the environment option that was entered 或者错误 : ORA data file suffered media failure: database in NOARCHIVELOG mode ORA IO error writing block to file <name> block # <num> ORA sfqio: error reading or writing to disk OSD-4016(OS 33) - The process cannot access the file because another process has locked a portion of the file ITPUB 第 81 页科技技术新动力

82 另外还可能会出现以下错误 : KCF: write/open error dba=0x703473d block=0x3473d online=1 file=7 E:\Oracle\data\grec\crecind2.dbf error=9211 txt: 'OSD-4008 : WriteFile error (OS 203) - The System Could not find the environment option that was entered 某些情况下 ALERT 文件中会出现 : Instance terminating due to error Instance terminated by <background process> PID=XXX 或者 : <background process> TERMINATING INSTANCE DUE TO ERROR 472 ORA PMON process terminated with error 在 WINDOWS 的事件查看器中可以看到以下事件 : 23 Error ReadFile() failure 25 Error WriteFile() failure 如果这是个冷备份, 那就要等冷备份完成后启动数据库或者结束冷备份启动数据库 对于备份软件, 最好都配置成不要锁定打开的数据文件的备份方式 这种情况的解决方法是手工的清除在数据文件上的锁 : 1) 运行 ps -ef grep <SID>, 查出在数据文件上已经存在的进程 2) 运行 kill 9 进程 ID 4. 使用 WINDOWS 的 FILE MANAGER 拷贝 Oracle 的数据文件的时候也会引起 ORA 的错误 ITPUB 第 82 页科技技术新动力

83 例如文件名大于通常用的 8.3 格式, 如果文件名大于 8 个字符或者你的扩展名大于 3 个字符就会引起这个错误 要避免这个错误, 在 WINDOWS 下拷贝文件不要用 FILE MANAGER, 最好使用浏览器去拷贝文件, 如果已经使用 FILE MANAGER, 那么对于长文件名的文件会自动加上一个 ~, 这样要重新命名拷贝的文件为原来的文件名字 5. 使用网络应用工具也可能会引起 ORA 的错误 在一些网络工具的使用操作中要求对数据文件进行加锁, 如果由于实例错误或者主机的问题可能会 导致这些锁会一直的存在, 这种情况下需要系统管理员手工的去释放这些锁 6. 如果 Oracle 的数据文件被一个其他的用户恢复也可能引起 ORA 的错误 在 Oracle 的数据文件被恢复之后,Oracle 数据库认不到恢复后的数据文件, 因此错误 ORA-1157 (cannot identify datafile - file not found) 就可能发生 : 数据文件在操作系统上是否存在 SELECT * FROM V$DATAFILE 查看数据文件的正确路径 ALTER SYSTEM CHECK DATAFILE 是否成功 使用 BACKUP CONTROLFILE TO TRACE 查看数据文件的正确路径 一般出现这种问题有可能是操作系统上的权限问题, 首先查看数据文件的权限, 当数据文件被其他 用户恢复的时候可能权限就变了, 可能 Oracle 用户就不能访问了, 这样就要对恢复后的数据文件修 改权限和属主 7. ULIMIT 设置的值不够大也可能会引起 ORA 的错误 在 DBWR 的跟踪文件中会有 ORA-1157 和 ORA 的错误 : ORA-01157: cannot identify/lock data file N - see DBWR trace file ORA-01110: data file 1: '<filename>' ORA-27092: skgfofi: size of file exceeds file size limit of the process Additional information: xxxxx Additional information: yyyyy ITPUB 第 83 页科技技术新动力

84 Oracle8.1.7 对于打开数据库会执行很严格的在操作系统的上的 ULIMIT 的检查, 如果文件大小的限制 不够大, 则数据库就会打不开, 出现以上的错误 因此就要增大 ULIMIT: ULIMIT -f <require_size_of_file_in_os_blocks>; 四. 在移植过程中出现 ORA 的错误 1. 如果使用移植工具把 Oracle7 数据库升级到 Oracle8i 数据库, 当执行数据库转换的时候有可能会 出现以下的错误 : ORA-1157 cannot identify datafile <name> - file not found ORA-1110 datafile <name>: <str> 移植工具首先使用 Oracle7 的控制文件去创建一个 CONVERT.ORA 文件, 当增加一个新的表空间或者新的数据文件如果新增数据文件没有包含全路径, 导致在 CONVERT.ORA 文件中就没有数据文件路径正确的指向 解决方法一是要修改 %Oracle_home%\rdbmsxx\convert.ora 下的 CONVERT.ORA 文件中的数据文件的路径为正确的路径, 然后重新执行数据库转换 解决方法二是先用备份恢复 Oracle7 的数据库, 然后重新创建控制文件, 修改数据文件的路径为正确的路径, 然后重新执行移植过程 2. 使用移植工具把数据库 Oracle7.3.X 移植到 Oracle8.1.X, 可能会出现以下错误 : ORA-01157: cannot identify/lock data file 2 - see DBWR tracefile ORA-01110: data file 2: '/oradata/v734/users01.dbf' ORA-27046: file size is not a multiple of logical block size Additional information:1 一般是数据文件从裸设备 dd 到文件系统中, 数据文件的大小不是严格的 Oracle Block Size 的整数倍 ITPUB 第 84 页科技技术新动力

85 造成的 例如 : file size = bytes Oracle block size = 8092 bytes 解决方法一是把数据文件 RESIZE 到一个 Oracle Block Size 的整数倍 : ALTER DATABASE DATAFILE '<filename>' RESIZE <VALUE IN KB OR MB>; - the integer should be a multiple of 8 in our example - 解决方法二 : 1) 使用 dbfsize 命令去获取数据文件的在数据库中的大小 : dbfsize <file_name> 2) 查看数据文件在操作系统上的大小 : ls -lt <file_name> 3) 使用 MOD 函数对比 1) 和 2) 的值, 得出余数 4) 确定数据库已经关闭了, 然后使用 dd 命令 例如 : 操作系统上的文件大小是 bytes, 使用 dbfsize 得出的结果是 byte blocks, 那么使用以下命令 : dd if=<some_name>bs=4096 count= NB: count= (1 for recovering from this problem) ITPUB 第 85 页科技技术新动力

86 mv <some_file> to <file_name> 5) startup nomount alter database convert; 五. 其他一些可能产生 ORA 错误的原因 1. 控制文件的突然中断引起 ORA 的错误 A. 一种可能的原因是在控制文件中的文件名的结尾处有一个空格 可以使用 'ALTER DATABASE BACKUP CONTROLFILE TO TRACE' 命令, 然后在初始化参数 user_dump_dest 所指向的目录下面查找相应的 TRACE 文件, 查看控制文件的内容 例如 : '/home/d/oracle/oradata/ecn/rdx02.dbf ' <-- corrupt '/home/d/oracle/oradata/ecn/rdx02.dbf' <-- non-corrupt 这种情况下用好的控制文件代替坏了的控制文件, 并修改初始化参数文件中的 CONTROL_FILES 参数, 去掉坏了的控制文件 如果所有的控制文件都损坏了, 那就需要重建控制文件了 重建控制文件的方法 : 1) 以 SYS 用户登陆, 执行 ALTER DATABASE BACKUP CONTROLFILE TO TRACE; 2) 生成的 TRACE 文件在 USER_DUMP_DEST 的目录下, 然后查看一下 USER_DUMP_DEST 的具体目录路径 : SELECT VALUE FROM V$PARAMETER WHERE NAME= USER_DUMP_DEST ; 或者 SHOW PARAMETER USER_DUMP_DEST; ITPUB 第 86 页科技技术新动力

87 3) 找出相应的 TRACE 文件, 最简单的找正确的 TRACE 文件的方法是看 TRACE 文件的创建时间, 然后修 改 TRACE 文件保存成一个 SQL 脚本, 例如 : STARTUP NOMOUNT CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS NOARCHIVELOG MAXLOGFILES 5 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 1 MAXLOGHISTORY 453 LOGFILE GROUP 1 'D:\ORACLE\ORADATA\ORCL\REDO01.LOG' SIZE 1M, GROUP 2 'D:\ORACLE\ORADATA\ORCL\REDO02.LOG' SIZE 1M, GROUP 3 'D:\ORACLE\ORADATA\ORCL\REDO03.LOG' SIZE 1M DATAFILE 'D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF', 'D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF', 'D:\ORACLE\ORADATA\ORCL\OEM_REPOSITORY.DBF' CHARACTER SET ZHS16GBK ; 4) 关闭数据库 : SHUTDOWN IMMEDIATE; 5) 对数据库做一个全库的冷备份 6) 利用操作系统命令将原来的控制文件移走 7) 在 SQLPLUS 中以 SYS 用户运行刚刚保存的那个脚本 8) 打开数据库 ITPUB 第 87 页科技技术新动力

88 2. 在 STANDBY 方式下, 如果主数据库增加了表空间或者数据文件, 而从数据库中没有手工增加的话 也会出现 ORA 的错误 3.RMAN 恢复会在 ALERT.LOG 中产生 FAKE 引起 ORA 的错误 在 RMAN 的恢复操作中, 在 ALERT.LOG 中会产生以下的错误 : ORA-01157: cannot identify/lock data file N - see DBWR trace file ORA-01110: data file N: '<filename>' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory 产生这种错误的原因主要是因为在 RMAN 恢复之前数据文件已经被删除 编者注 : 您可以通过以下连接参与关于本文的讨论, 直接和作者对话 : ITPUB 第 88 页科技技术新动力

89 一条 sql 导致数据库整体性能下降 的诊断和解决的全过程 作者 :biti_rainy 今天早上一来, 数据库 load 就比往常高了许多 想想数据库唯一的变化是昨天早上我曾经重新分析过数据库对象 发现数据库 load 很高, 首先看 top 发现没有特别异常的进程, 在数据库中适时抓取正在运行的 sql 也没发现异常 ( 通常运行时间非常短的 sql 是不能被抓取到的 ) 询问相关应用程序人员, 最近没有变动 检查应用程序日志发现今天早上跟往常也没有过多登陆和操作 基本上可以圈定是在数据库服务器本身上面 但是这个时候我还没有办法确定到底是哪个应用的哪个查询的问题, 因为数百个进程的几十台 server 连着, 我不能去及时的追踪 打算等到 10 点过去后, 抽取 8/9/10 高峰期的整点的 statspack 出来, 跟上星期的这个时间产生的报告对比看看 通过对比报告我们发现 CPU TIME 今天一小时内增加了大约 1200 秒 (2,341-1,175 ) 这是一个重大的变化, 很显然是两种可能 1: 今天过多地执行了某些 sql 2: 某些 sql 的执行计划发生变化导致 cpu 使用过多 Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time CPU time 2, db file sequential read 387,534 2, global cache cr request 745, log file sync 98, log file parallel write 96, Event Waits Time (s) Ela Time db file sequential read 346,851 1, CPU time 1, global cache cr request 731, log file sync 90, db file scattered read 37, ITPUB 第 89 页科技技术新动力

90 接下来我对比了 sql 部分内容, 发现 Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value ,899,606 47, Module: /home/oracle/alitalksrv/config/../../alitalksrv/ SELECT login_id, to_char(gmt_create, 'YYYY-MM-DD HH24:MI:SS') from IM_BlackList where black_id = :b1 这条 sql 出现在了今天报告的前列, 而以往的报告中该 sql 根本不排在 buffer gets 前面位置, 显然这条 sql 消耗了大约 秒 cpu time. 检查原来的报告 Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value ,937 47, Module: /home/oracle/alitalksrv/config/../../alitalksrv/ SELECT login_id, to_char(gmt_create, 'YYYY-MM-DD HH24:MI:SS') from IM_BlackList where black_id = :b1 我们发现只消耗了 7.39 秒的 cpu time 到这个时候我基本可以断定, 是由于这个 sql 没有走索引而走了全表扫描 但是为什么会走全表扫描呢, 这是一个问题, 接下来我检查了表的索引 : SQL> select index_name,column_name from user_ind_columns where table_name = 'IM_BLACKLIST'; IM_BLACKLIST_PK LOGIN_ID IM_BLACKLIST_PK BLACK_ID IM_BLACKLIST_LID_IND BLACK_ID 很显然存在着 black_id 的单独的索引, 应该正常使用才对 于是我在生产库上执行这个 sql 一看, 却发现走了全表扫描 为此我到一个周六的 standby 的 opren read only 的数据库上查询了一下该索引字段的 histogram( 这个时候昨天早上分析对象的日志还没有被应用过去 ) sys@ocn> select COLUMN_NAME,ENDPOINT_NUMBER, ENDPOINT_VALUE, ENDPOINT_ACTUAL_VALUE from dba_histograms 2 where table_name = 'IM_BLACKLIST' and column_name = 'BLACK_ID'; ITPUB 第 90 页科技技术新动力

91 COLUMN_NAME ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_ACTUAL_VALUE BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 ITPUB 第 91 页科技技术新动力

92 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+36 然后对比了一下当前的 histograms COLUMN_NAME ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_ACTUAL_VALUE BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 ITPUB 第 92 页科技技术新动力

93 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+35 BLACK_ID E+36 我们发现原来的 histograms 值分布比较均匀, 而昨天分析后的值分布就有一些地方是集中的, 参考上面红色部分 于是我再做了个 dump 对比, 昨天分析之前 通过 alter session set events '10053 trace name context forever'; 然后执行相关的 sql 再去看 trace 文件 ITPUB 第 93 页科技技术新动力

94 Table stats Table: IM_BLACKLIST Alias: IM_BLACKLIST TOTAL :: CDN: NBLKS: 374 AVG_ROW_LEN: Index stats INDEX NAME: IM_BLACKLIST_LID_IND COL#: 2 TOTAL :: LVLS: 1 #LB: 219 #DK: LB/K: 1 DB/K: 2 CLUF: INDEX NAME: IM_BLACKLIST_PK COL#: 1 2 TOTAL :: LVLS: 1 #LB: 304 #DK: LB/K: 1 DB/K: 1 CLUF: _OPTIMIZER_PERCENT_PARALLEL = 0 *************************************** SINGLE TABLE ACCESS PATH Column: BLACK_ID Col#: 2 Table: IM_BLACKLIST Alias: IM_BLACKLIST NDV: NULLS: 0 DENS: e-05 NO HISTOGRAM: #BKT: 1 #VAL: 2 TABLE: IM_BLACKLIST ORIG CDN: ROUNDED CDN: 3 CMPTD CDN: 3 Access path: tsc Resc: 38 Resp: 38 Access path: index (equal) Index: IM_BLACKLIST_LID_IND TABLE: IM_BLACKLIST RSC_CPU: 0 RSC_IO: 4 IX_SEL: e+00 TB_SEL: e-05 Skip scan: ss-sel 0 andv ss cost table io scan cost 38 Access path: index (no sta/stp keys) Index: IM_BLACKLIST_PK TABLE: IM_BLACKLIST RSC_CPU: 0 RSC_IO: 309 IX_SEL: e+00 TB_SEL: e-05 BEST_CST: 4.00 PATH: 4 Degree: 1 *************************************** OPTIMIZER STATISTICS AND COMPUTATIONS *************************************** GENERAL PLANS *********************** Join order[1]: IM_BLACKLIST [IM_BLACKLIST] Best so far: TABLE#: 0 CST: 4 CDN: 3 BYTES: 75 Final: CST: 4 CDN: 3 RSC: 4 RSP: 4 BYTES: 75 IO-RSC: 4 IO-RSP: 4 CPU-RSC: 0 CPU-RSP: 0 这是昨天分析之后的 SINGLE TABLE ACCESS PATH Column: BLACK_ID Col#: 2 Table: IM_BLACKLIST Alias: IM_BLACKLIST NDV: NULLS: 0 DENS: e-03 HEIGHT BALANCED HISTOGRAM: #BKT: 75 #VAL: 75 TABLE: IM_BLACKLIST ORIG CDN: ROUNDED CDN: 83 CMPTD CDN: 83 Access path: tsc Resc: 38 Resp: 38 Access path: index (equal) Index: IM_BLACKLIST_LID_IND TABLE: IM_BLACKLIST RSC_CPU: 0 RSC_IO: 65 IX_SEL: e+00 TB_SEL: e-03 Skip scan: ss-sel 0 andv ss cost table io scan cost 38 Access path: index (no sta/stp keys) ITPUB 第 94 页科技技术新动力

95 Index: IM_BLACKLIST_PK TABLE: IM_BLACKLIST RSC_CPU: 0 RSC_IO: 384 IX_SEL: e+00 TB_SEL: e-03 BEST_CST: PATH: 2 Degree: 1 *************************************** OPTIMIZER STATISTICS AND COMPUTATIONS *************************************** GENERAL PLANS *********************** Join order[1]: IM_BLACKLIST [IM_BLACKLIST] Best so far: TABLE#: 0 CST: 38 CDN: 83 BYTES: 2407 Final: CST: 38 CDN: 83 RSC: 38 RSP: 38 BYTES: 2407 IO-RSC: 38 IO-RSP: 38 CPU-RSC: 0 CPU-RSP: 0 我发现分析之前之后全表扫描 cost 都是 38, 但是分析之后的根据索引扫描却成为了 65, 而分析之前是 4 很显然是由于这个查询导致昨天早上分析之后走了全表扫描 于是我再对表进行了分析, 只不过这次我没有分析索引字段, 而是 analyze table im_blacklist compute statistics; 这样之后,dbms_histograms 中信息只剩下 COLUMN_NAME ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_ACTUAL_VALUE GMT_CREATE GMT_MODIFIED LOGIN_ID E+35 BLACK_ID E+35 GMT_CREATE GMT_MODIFIED LOGIN_ID E+35 BLACK_ID E+36 再执行该 sql, 就走了索引, 从而使得数据库的 load 降了下来 分析这整个过程中, 我无法知道 oracle 的走索引 cost 65 是怎么计算出来的, 当然是跟 histograms 有关, 但计算方法我却是不清楚的 这条 sql 是 bind var, 但是却走了全表扫描, 这是由于 920 中数据库在对 bind var 的 sql 进行第一次解析的时候去 histograms 中窥视了数据分布从而根据 cost 选择了 FTS 然后后面继续执行的 sql 呢, 则不论是否该走索引, 都走了 FTS 这是 920 这个版本的特性的弊病 也就是说, 这有偶然性因素的存在 但是对于这个表, 我做了分析 ( 不分析索引字段 ) 之后不存在 histograms, 则 sql 无论如何都走了索引扫描 ITPUB 第 95 页科技技术新动力

96 编者注 : 您可以通过以下连接参与关于本文的讨论, 直接和作者对话 : ITPUB 第 96 页科技技术新动力

97 修改 fet$ 基表, 结合碎片案例实战 作者 :logzgh 背景 : OS:AIX ORACLE: compatible:8.1.0 一计费系统, 有个数据字典管理的表空间有 170 多 G 客户已将其中的数据全部迁移到一个新的 local 管理的表空间 ( 还剩一个临时段 ), 打算将这个表空间 drop 掉 但是已偿试了两个晚上, 都无法 drop 掉 于是空间十分紧张, 急需要将这个表空间释放出来 检查这个表空间的碎片, 吓了一跳, 居然有 124 万多个 怪不得整个晚上都无法 drop 掉 ( 为了不影响 业务, 只能是晚上 drop, 白天必须停止 ) 一时间, 脑海里面冒出以下几个思路 : 1. 修改 fet$ 基表, 结合碎片 2.alter tablespace... coalesce; 3. 将表空间由字典转换成 local 4. 将每个数据文件 resize 首先偿试一个晚上 coalesce 但是第二天来的时候, 一个晚上才结合了 1 万多个碎片 这样的速度是 无法接受的 中午时分试了一下 Resize, 也是很慢 不过我估计一个晚上还是能做几个数据文件的 resize. 偿试将表空间转换成 local, 但是不幸的是需要 compatible 为 以上 当时数据库是从低版本升 上来的,compatible 一直没有调高, 这样调高有可能引响业务 所以也不敢轻易地调整 ITPUB 第 97 页科技技术新动力

98 剩下是修改 fet$ 基表 oracle 结合碎片的思路其实是挺简单的, 将连续的碎片结合成一块, 修改 length 长度即可 这个表空间有 43 个文件, 那个临时段占用了 5 个文件 其余 38 个文件都是空的, 那么在 fet$ 表中应该 就是一条记录,block# 为 2,length 为数据文件的 blocks-1 这样首先将这个表空间 offline 掉, 这个表空间在 fet$ 表中的数据就不会发生改变了 首先处理那 38 个空闲文件 : 首先查找完全空闲的数据文件及其 blocks 的总数 : select file_id,file_name,bytes/1024/1024,blocks-1 from dba_data_files where tablespace_name='tb_cdr' and file_id not in (select file_id from dba_extents where tablespace_name='tb_cdr') 手工修改 fet$ 基表 : delete fet$ where ts#=13 and block# > 2 and file#=14 ; delete fet$ where ts#=13 and block# > 2 and file#=18 ; delete fet$ where ts#=13 and block# > 2 and file#=24 ; delete fet$ where ts#=13 and block# > 2 and file#=25 ; delete fet$ where ts#=13 and block# > 2 and file#=26 ; delete fet$ where ts#=13 and block# > 2 and file#=27 ; delete fet$ where ts#=13 and block# > 2 and file#=28 ; delete fet$ where ts#=13 and block# > 2 and file#=41 ; delete fet$ where ts#=13 and block# > 2 and file#=42 ; delete fet$ where ts#=13 and block# > 2 and file#=43 ; delete fet$ where ts#=13 and block# > 2 and file#=44 ; delete fet$ where ts#=13 and block# > 2 and file#=54 ; delete fet$ where ts#=13 and block# > 2 and file#=55 ; ITPUB 第 98 页科技技术新动力

99 delete fet$ where ts#=13 and block# > 2 and file#=58 ; delete fet$ where ts#=13 and block# > 2 and file#=60 ; delete fet$ where ts#=13 and block# > 2 and file#=61 ; delete fet$ where ts#=13 and block# > 2 and file#=63 ; delete fet$ where ts#=13 and block# > 2 and file#=64 ; delete fet$ where ts#=13 and block# > 2 and file#=66 ; delete fet$ where ts#=13 and block# > 2 and file#=67 ; delete fet$ where ts#=13 and block# > 2 and file#=72 ; delete fet$ where ts#=13 and block# > 2 and file#=73 ; delete fet$ where ts#=13 and block# > 2 and file#=76 ; delete fet$ where ts#=13 and block# > 2 and file#=77 ; delete fet$ where ts#=13 and block# > 2 and file#=78 ; delete fet$ where ts#=13 and block# > 2 and file#=79 ; delete fet$ where ts#=13 and block# > 2 and file#=80 ; delete fet$ where ts#=13 and block# > 2 and file#=81 ; delete fet$ where ts#=13 and block# > 2 and file#=83 ; delete fet$ where ts#=13 and block# > 2 and file#=106; delete fet$ where ts#=13 and block# > 2 and file#=107; delete fet$ where ts#=13 and block# > 2 and file#=108; delete fet$ where ts#=13 and block# > 2 and file#=109; delete fet$ where ts#=13 and block# > 2 and file#=110; delete fet$ where ts#=13 and block# > 2 and file#=111; delete fet$ where ts#=13 and block# > 2 and file#=123; delete fet$ where ts#=13 and block# > 2 and file#=124; delete fet$ where ts#=13 and block# > 2 and file#=125; length 为数据文件的 blocks 数量减 1: update fet$ set length= where ts#=13 and block#=2 and file#=14 ; update fet$ set length= where ts#=13 and block#=2 and file#=18 ; update fet$ set length= where ts#=13 and block#=2 and file#=24 ; update fet$ set length= where ts#=13 and block#=2 and file#=25 ; update fet$ set length= where ts#=13 and block#=2 and file#=26 ; ITPUB 第 99 页科技技术新动力

100 update fet$ set length= where ts#=13 and block#=2 and file#=27 ; update fet$ set length= where ts#=13 and block#=2 and file#=28 ; update fet$ set length= where ts#=13 and block#=2 and file#=41 ; update fet$ set length= where ts#=13 and block#=2 and file#=42 ; update fet$ set length= where ts#=13 and block#=2 and file#=43 ; update fet$ set length= where ts#=13 and block#=2 and file#=44 ; update fet$ set length= where ts#=13 and block#=2 and file#=54 ; update fet$ set length= where ts#=13 and block#=2 and file#=55 ; update fet$ set length= where ts#=13 and block#=2 and file#=58 ; update fet$ set length= where ts#=13 and block#=2 and file#=60 ; update fet$ set length= where ts#=13 and block#=2 and file#=61 ; update fet$ set length= where ts#=13 and block#=2 and file#=63 ; update fet$ set length= where ts#=13 and block#=2 and file#=64 ; update fet$ set length= where ts#=13 and block#=2 and file#=66 ; update fet$ set length= where ts#=13 and block#=2 and file#=67 ; update fet$ set length= where ts#=13 and block#=2 and file#=72 ; update fet$ set length= where ts#=13 and block#=2 and file#=73 ; update fet$ set length= where ts#=13 and block#=2 and file#=76 ; update fet$ set length= where ts#=13 and block#=2 and file#=77 ; update fet$ set length= where ts#=13 and block#=2 and file#=78 ; update fet$ set length= where ts#=13 and block#=2 and file#=79 ; update fet$ set length= where ts#=13 and block#=2 and file#=80 ; update fet$ set length= where ts#=13 and block#=2 and file#=81 ; update fet$ set length= where ts#=13 and block#=2 and file#=83 ; update fet$ set length= where ts#=13 and block#=2 and file#=106; update fet$ set length= where ts#=13 and block#=2 and file#=107; update fet$ set length= where ts#=13 and block#=2 and file#=108; update fet$ set length= where ts#=13 and block#=2 and file#=109; update fet$ set length= where ts#=13 and block#=2 and file#=110; update fet$ set length= where ts#=13 and block#=2 and file#=111; update fet$ set length= where ts#=13 and block#=2 and file#=123; update fet$ set length= where ts#=13 and block#=2 and file#=124; update fet$ set length= where ts#=13 and block#=2 and file#=125; 这样处理完后, 这个表空间还有 16 万个碎片 针对那些有数据的数据文件一样手工结合, 跳过那些有数据的块 查找 dba_extents, 找出那个临时 ITPUB 第 100 页科技技术新动力

101 段所占用的块号和块数 ===== 4 号文件 delete fet$ where ts#=13 and file#=4 and block# >2 and block# < ; update fet$ set length= where ts#=13 and file#=4 and block#=2; delete fet$ where ts#=13 and file#=4 and block# > ; update fet$ set length= where ts#=13 and file#=4 and block#=344195; ===== 10 号文件 delete fet$ where ts#=13 and file#=10 and block# >2 and block# < ; update fet$ set length= where ts#=13 and file#=10 and block#=2; delete fet$ where ts#=13 and file#=10 and block# >2 and block# > ; update fet$ set length= where ts#=13 and file#=10 and block#=288867; ===== 13 号文件 delete fet$ where ts#=13 and file#=13 and block# >2 and block# < 30298; update fet$ set length=30296 where ts#=13 and file#=13 and block#=2; delete fet$ where ts#=13 and file#=13 and block# >2 and block# > 30318; update fet$ set length= where ts#=13 and file#=13 and block#=30318; ===== ITPUB 第 101 页科技技术新动力

102 68 号文件 delete fet$ where ts#=13 and file#=68 and block# >2 and block# < ; update fet$ set length= where ts#=13 and file#=68 and block#=2; ==== 69 号文件 delete fet$ where ts#=13 and file#=69 and block# >2 and block# < ; update fet$ set length= where ts#=13 and file#=69 and block#=2; delete fet$ where ts#=13 and file#=69 and block# >2 and block# > ; update fet$ set length= where ts#=13 and file#=69 and block#=182438; 这样处理完后, 直接 drop tablespace, 很快就搞定了 编者注 : 您可以通过以下连接参与关于本文的讨论, 直接和作者对话 : ITPUB 第 102 页科技技术新动力

103 关于杂志 ITPub 免费电子杂志于 2001 年 1 月 1 日创刊 电子杂志是 ITPUB 一系列活动之一, 我们的目的是让更多的人了解 IT 技术, 让更多的人从中 得到知识 电子杂志需要得到大家的支持, 请把你们看到的 学到的 想到的记录下来发给我们 : mailto:[email protected] 或者相关斑竹, 所有受到你们帮助的会员们会感谢您! 我们一起建设属于自己的免费电子杂志! ITPUB, 信息技术新动力! 络 版权归各位作者所有, 如需转载, 请联系 mailto:[email protected], 我们会与作者联 制作人员 主编 / 定稿 / 排版 : Way(ITPub 成员, mailto:[email protected]) 审稿 : Eygle(ITPub 成员, mailto:[email protected] ) 编辑的话 本人第一次担当此项工作, 由于经验不足难免有些地方不尽人意, 还请大家谅解 感谢本次投稿的各位作者! 感谢各位版主的大力支持与信任! 愿这份读物能在炎炎夏日给您送去一丝惬意! ITPUB 第 103 页科技技术新动力