ORACLE数据库性能优化(转)

1 ORACLE 数据库性能优化数据库性能优化 转转 Technorati 标签 oracle 字体 小 中 大 打印 发表于 2004 10 27 13 54 作者 tangshan ph 来源 CNOUG 博客 首页 可以通过调整数据库应用程序 数据库和操作系统来增强 ORACLE 的性能 适当的调整 ORACLE 可以针对特定的应用程序和硬件配置获得较好的性能 性能调整要考虑响应时间 吞吐量 限制这 三个因素 依赖于应用的不同特性 对这三个因素的要求也不尽相同 对于 OLTP 来说 要求有较高的响应时 间 而对于 OLAP 来说 对吞吐量有较高的要求 系统的响应时间可分为服务时间和等待时间 对 于响应时间性能调整来说 就是缩短服务时间和等待时间 对于吞吐量性能调整来说 就是利用同 样的资源做更多的事情 缩短服务时间 较快的完成工作 缩短等待时间 象 CPU 内存 I O 能力 网络带宽等资源对减少服务时间和等待时间有很大影响 增加资源可能 会获得较高的吞吐量和较快的响应时间 系统性能以来于 可用资源的数量 请求资源的客户的数量 等待资源的时间 占用资源的时间 通常 应用程序的开发和设计对性能的影响最大 一旦应用程序被付诸实施 数据库管理员只能在 系统设计的限制之下进行基本的调整 性能调整包含了 10 个步骤 在此主要讨论象 CPU 内存 I O 能力 网络带宽等资源对性能的影响 并如何配置资源来提高系统的性能 首先要了解系统的运行情况 有几种工具可以用来获取表示系统性能的数据 能表示系统性能的数 据源有以下几种 数据卷 在线数据字典 操作系统工具 动态性能表 SQL 跟踪工具 报警日志 应用程序输出 用户 初始化参数文件 程序文本 设计 分析 字典 可比较数据 而能获得这些数据的可用工具主要有以下几种 动态性能视图 Oracle 利用一组动态性能视图来监控数据库 这些视图名以 V 开始 SYS 用户拥有这些视图 Oracle 与 SNMP Simple Network Management Protocol 支持 SNMP 使用户可以写 自己的工具和应用程序 解释计划 EXPLAIN PLAN EXPLAIN PLAN 是一个 SQL 语句 它能列出查询优化器选择 的存取路径 SQL 跟踪工具和 TKPROF SQL 跟踪工具以文本方式记录下语句在每个阶段的资源消耗 分 2 析 执行 获取结果 提交或回滚 TKPROF 汇总 SQL 跟踪工具所产生的文件 有选择的包含在 EXPLAIN PLAN 的输出里 脚本 Oracle 支持许多 PL SQL 包 它们可用于对数据库实例进行调整 例如 UTLBSTAT SQL UTLESTAT SQLUTLCHAIN SQL UTLDTREE SQL 和 UTLLOCKT SQL 应用程序注册 可以在数据库中记录下应用程序的名字和它执行的操作 这样管理员就可以根 据模块来跟踪性能 应用程序的名字和活动记录在 V SESSION 和 V SQLAREA 视图内 Oracle 企业管理器 它是一个用于管理 Oracle 环境的工具集 包括 Oracle Performance Manager 它获取 计算和显示数据库的性能数据 通过它可以监控 数据库 来从而有效地使用内存 最小化磁盘 I O 避免资源竞争 Oracle TopSessions 用于监控每个会话的活动 Oracle Trace 在 Oracle Performance Manager 和 Oracle TopSessions 采用抽样技术 定期的从数据库动态性能视图中收集数据 而 Oracle Trace 则根据预定义的事件来收集性能数据 Oracle Tablespace Manager 如果你怀疑数据库的性能问题来自表空间 可以使用该工具 检测和矫正这些问题 Oracle Expert 它提供自动的性能调整 由 Oracle Performance Manager Oracle TopSessions and Oracle Trace 检测出的问题可以在 Oracle Expert 中进行分析 Oracle 并行服务器管理 OPSM OPSM 是一个用于 Oracle 并行服务器的全面的管理方案 它通过开放的 client server 体系来管理异构环境中的多个数据库实例 一 一 优化 CPU 资源 确定 CPU 有关的问题 首先需要确定 CPU 是否足够大 在此方面主要通过以下三个方面来考虑 在空闲期间的 CPU 的利用率 在高峰期间的 CPU 的利用率 平均的 CPU 的利用率 如果怀疑 CPU 是系统性能的瓶颈 可以通过如下方法来确定 检查系统的 CPU 使用率 ORACLE 只统计 ORACLE 会话对 CPU 的使用情况 而系统中的任 何进程都使用 CPU 所以调整其他应用程序也有可能改善 ORACLE 的 CPU 性能 在 UNIX 系统中可以通过 sar u 命令来获得有关 CPU 使用情况的信息 一般情况下 如果 CPU 的空闲时间或 I O 等待时间接近于 0 说明 CPU 是瓶颈 在 WINDOWS NT 中 可以通过性能 监视器来获得有关 CPU 使用情况的信息 内存管理 Paging and Swapping 通过 UNIX 的 sar 或 vmstat 命令 以及 WINDOWS NT 中的性能监视器来分析发生分页和交换的原因 I O 管理 Thrashing 确保工作量适宜于内存的大小 避免过多的页交换 如果 CPU 花费时间 片的很大部分来确保程序可运行 则可能只有 50 的时间用于实际工作 Client Server Round Trips 一些隐含的消息发送会加重 CPU 的负担 应用程序经常产生一些消息在网络中来回传递 进程管理 Scheduling and Switching 操作系统可能会花费很多时间用于切换进程 检查是否 启动了大量的进程 Context Switching 进程的上下文切换同样会耗费大量的 CPU 时间 检查 ORACLE 使用 CPU 的使用率 有两个动态性能视图可以用于检查 ORCALE 的进程信息 V SYSSTAT 显示所有会话的 ORACLE CPU 的使用 V SESSTAT 显示每个会话的 ORACLE CPU 的使用 主要在如下几个方面考察 ORACLE CPU 的使用 重新分析 SQL 语句 低效率的 SQL 共享引起语句的重新分析 SELECT FROM V SYSSTAT WHERE NAME IN 3 parse time cpu parse time elapsed parse count hard SELECT SQL TEXT PARSE CALLS EXECUTIONS FROM V SQLAREA ORDER BY PARSE CALLS 效率低的 SQL 语句 低效率的 SQL 语句会消耗大量的 CPU 时间 SELECT BUFFER GETS EXECUTIONS SQL TEXT FROM V SQLAREA 读一致性 通过回滚段实现读一致性可能会需要大量的 CPU 时间 可通过增加回滚段的数量 来解决 解决办法 在已经达到 CPU 的最大限制和无法通过调整 CPU 来优化性能时 则必须考虑重新设计应用 可以 考虑迁移到不同的应用体系结构上 以获得适宜的 CPU 使用率 从单层结构迁移到两层结构 将一台机器上的客户和服务器分离 多层 使用较小的客户机 可以将一台机器上的多个客户分离到各个较小的客户机上 两层到三层 使用事务处理器 利用 ORACLE 的并行服务器 二 二 优化内存分配 对于在内存中的数据的访问要快于对磁盘的访问 所以内存优化的目的就是提高内存命中率 通常 在优化完应用和 SQL 语句后 才开始优化内存分配 内存的分配决定了磁盘 I O 的数量 如何解决内存分配问题 优化操作系统的内存需求 主要通过以下方法解决 减少内存页交换 确保 SGA 在内存中 为每个用户分配足够的内存 可能只有一些操作系统支持 优化 Redo 日志缓冲区 LOG BUFFER 参数用于控制 Redo 日志缓冲区 对于磁盘速度慢 CPU 快的计算机 Redo 日志缓冲区的使用可能会发生冲突 可适当增大 Redo 日志缓冲区的大小 一般 Redo 日志缓冲区只占 SGA 中很小的一部分 适当的增加即可提高很大的吞吐量 优化私有的 SQL 和 PL SQL 区 该优化主要有两部分工作 一个是区分不必要的重新分析调 用 另一个是减少不必要的重新分析调用 可以通过 SQL 跟踪工具 检查 V SQLAREA 视图来区 分不必要的重新分析调用 可以通过 HOLD CURSOR yes RELEASE CURSOR no MAXOPENCURSORS desired value 这三个属性来减少不必要的重新分析调用 优化共享池 SGA 的共享池部分由库高速缓存 字典高速缓存和某些用户和服务器会话信息 组成 库高速缓存包含分析和执行 SQL 语句 每个 SQL 语句的 SGA 共享部分为相应共享池中的内 存量 在此共享池中包含语句的分析树和执行计划 执行 SGA 优化的一个重要问题就是确保库高 速缓存足够大 以使 ORACLE 能在高速缓存中保持分析和执行计划 可以通过系统性能监视器或 者 v librarycache 视图查看库高速缓存的性能 字典高速缓存包含了有关数据库的数据字典信息 文件空间的可用性和对象权限 通过命中率 可以发现此字典高速缓存是否失效 可以通过系统性能监视器或者 V ROWCACHE 视图查看相关 数据 如果需要可通过 SHARED POOL SIZE 参数来增加缓冲池大小 优化排序缓冲区 如果都大量的排序动作 需要增加排序缓冲区的大小 可以通过 SORT AREA SIZE 参数实现 三 三 优化 I O 操作 I O 优化被安排在内存优化之后 通过内存的优化 可以是 I O 冲突减少 在此情况下 可以通过 一些调整以使 I O 性能进一步提高 对于新系统 应自顶向下分析 I O 需求 确定所需要的资源 而对于已存在的系统应采用自底向上 的方法 1 1 了解系统的磁盘数量 4 2 2 了解 ORACLE 使用的磁盘数量 3 3 了解应用系统的 I O 类型 4 4 了解 I O 操作是针对文件系统还是原始设备 5 5 了解对象在磁盘上的分布 可以通过如下方法检查 I O 问题 检查系统 I O 的使用 可以使用操作系统提供的工具来监视整个系统对磁盘文件的访问 可以 将大量访问磁盘的应用与 ORACLE 的相关文件分别存放 在 UNIX 系统中可以通过 sar d 来获 得有关数据 在 WINDOWS NT 中可通过性能监视器查看 检查 ORACLE 的 I O 的使用 对于 ORACLE 可以通过下列视图来获得相关的信息 File Type Where to Find Statistics Database Files V FILESTAT Log Files V SYSSTAT V SYSTEM EVENT V SESSION EVENT Archive Files V SYSTEM EVENT V SESSION EVENT Control Files V SYSTEM EVENT V SESSION EVENT 可以通过如下的方法来解决 I O 问题 减少磁盘竞争 磁盘竞争 当多个进程同时访问同一个磁盘时就会产生磁盘竞争 要减少高负荷磁盘的访问 可以将高访问量的文件移到低负荷的磁盘上 分离 Redo 日志文件和数据文件 ORACLE 总是经常的访问 Redo 日志文件和数据文件 将 二者放在一起 可能会增加磁盘冲突 条带化表数据 条带化 就是将一个大表的数据分布到不同磁盘的不同数据文件中 这样也可 以减少磁盘冲突 分离表和索引 这并不是必须的 由于索引和表的读取是串行的 也可以做到将表和索引放在 一起而不发生磁盘冲突 磁盘条带化 就是将一个大表的数据分布到不同磁盘的不同数据文件中 条带化允许不同的进 程同时访问一个表的不同部分 这尤其对随机访问一个表的多行很有帮助 条带化可以是磁盘的 I O 负载平衡 有两种条带化方法 手动方法 利用表空间以及分区表的方式 利用操作系统 RAID 避免动态空间管理 当对象创建后 ORACLE 会给对象分配对象 当后续的数据库操作需要额 外的空间时 ORACLE 会扩展该段 动态扩展对性能有损害 侦测动态扩展 动态扩展可引起 SQL 语句的递归调用 ORACLE 自己要发出一些 SQL 语句 可以通过 V SYSSTAT 视图来获得有关递归调用的信息 如果发现在应用程序运行时有大量的递 归调用 可以使用较大的扩展 分配扩展段 Extent 通过确定最大的对象的大小 选择合适的存储参数值 以时 ORACLE 分配的段可以满足存储的要求 四 四 优化网络 主要是保证网络的速度和网络上的流量 可以通过如下方法检查网络问题 可以通过 V SESSION EVENT V SESSION WAIT 和 V SESSTAT 视图来检查与网络延迟有关的信息 V SESSION EVENT 视图中的 AVERAGE WAIT 列表明了 ORACLE 等待的时间 V SESSION WAIT 视图中的 EVENT 列列出了正在等待的活动会话 V SESSION WAIT 视图描述了活动会话在等待什么 也可以看到收发的字节数 可通过以下方法解决网络问题 使用数组接口 用数组接口取代每次只取一行的做法 在一个网络来回中取多行要比取一行要有 5 效 使用预先启动的进程 在没有使用多线程服务器的情况下 如果有预先启动的进程 可以大大 缩短连接时间 调整会话数据单元缓冲区的大小 当有大量的数据要传输的时候 增加数据单元缓冲区的大小 会改善网络的性能 可以通过 ORACLE 网络管理器来定义数据单元缓冲区的大小 增加 Listener 队列的大小 通过增加 Listener 队列的大小 可以处理更多的请求 使用 TCP NODELAY 使用连接管理器 通过连接管理器可以使多个会话共享一个传输层连接 这样可以使进程处理 会话的数量增加 五 五 优化操作系统 操作系统性能问题主要是进程管理和内存管理 如果已经优化过 ORACLE 后 还希望得到更好的 性能 则需要优化操作系统 不过不能期望性能会有很大的提高 检测操作系统性能问题 从操作系统性能监视器中要获得的数据指标有以下几种 CPU 负载 检查系统运行在用户模式和系统模式的时间 设备队列 网络活动 排队 内存管理 页交换 解决操作系统问题 基于 UNIX 的系统 了解系统的 CPU 时间的花费比例 在用户模式是 60 75 的时间 在 系统模式下是 25 40 的时间 该比率表现了系统的底层问题 如过度的页交换 执行太多的 系统调用 进程太多 基于 NT 的系统 同基于 UNIX 的系统类似 只是监视工具更方便 六 六 优化资源竞争 当多个进程同时访问资源时会发生竞争 可以通过 V SYSTEM EVENT 视图来检查资源竞争 检测竞争问题 V RESOURCE LIMIT 视图 提供了当前和最大资源使用情况 V SYSTEM EVENT 视图 检查最高的平均等待时间 V LATCH 视图 检查 latch 的使用情况 V WAITSTAT 视图和 V SESSION WAIT 视图 等待缓冲区的时间 解决竞争问题 减少回滚段的竞争 可通过考察包含回滚段缓冲区的竞争来确定 可通过 V WAITSTAT 视图 来确定 可用下列语句获得数据 如果回滚段缓冲区的等待时间占总时间的 1 以上 则考虑创建 更多的回滚段 SELECT class count FROM v waitstat WHERE class IN system undo header system undo block undo header undo block 减少多线程服务器进程的竞争 包括减少分发进程和共享服务器进程的竞争 通过 V DISPATCHER 视图来获得有关分发进程的信息 SELECT network rotocol SUM busy SUM busy SUM idle Total Busy Rate FROM v dispatcher GROUP BY network 6 V QUEUE 视图分发进程的响应队列活动的有关信息 SELECT network rotocol DECODE SUM totalq 0 No Responses SUM wait SUM totalq hundredths of seconds Average Wait Time per Response FROM v queue q v dispatcher d WHERE q type DISPATCHER AND q paddr d paddr GROUP BY network 可以使用 ALTER SYSTEM 命令的 MTS DISPATCHERS 参数改变分发进程的数量 使用初始化 参数 MTS MAX DISPATCHERS 改变最大分发进程的数量 可以通过请求队列中的请求的数量来判断共享服务器进程的竞争 V QUEUE 视图包含了请求队列 中的活动的信息 SELECT DECODE totalq 0 No Requests wait totalq hundredths of seconds Average Wait Time Per Requests FROM v queue WHERE type COMMON ORACLE 在负载大的时候自动增加共享进程的数量 所以不可能手动改变它的值 但可以通过初始 化参数 MTS MAX SERVERS 来改变共享进程的数量的最大值 减少并行服务器进程的竞争 可通过 V PQ SYSSTAT 视图来确定适当的并行服务器进程的 数量 一般情况下 并行服务器的最大数量依赖于系统的处理能力 CPU I O 无法改变该值 但如果频繁启动和关闭服务器 可以考虑改变参数 PARALLEL MIN SERVERS 的值 可以周期 的检查 V PQ SYSSTAT 的值 以了解并行服务器的数量是否合适 SELECT FROM V PQ SYSSTAT WHERE statistic Servers Busy 减少 Redo 日志缓冲区闩的竞争 Redo 日志缓冲区很少会影响数据库的性能 可以通过 V SYSSTAT 视图的 REDO BUFFER ALLOCATION RETRIES 检查等待缓冲区的时间 SELECT name value FROM v sysstat WHERE name redo buffer allocation retries 可通过初始化参数 LOG BUFFER 改变缓冲区的大小 Oracle 10g 数据库中如何分析响应时间数据库中如何分析响应时间 在 Oracle10g 中 以前版本中比较难于获取的响应时间数据将会变得非常容易获取 在以前看来 为了尽量获得数据库的最佳性能 Oracle 的 DBA 们和性能分析专家一直很困难 获得系统以及用户会话活动的一致的响应时间数据 DBA 们面临的问题一直以来包括两个方 面 第一个方面是准确定位数据库或者用户会话究竟在哪里消耗了时间 第二个方面就是确定 用户体验的客观性质 7 在数据库中产生所有可能的行为和交互作用 这些任务都不是没有价值的 Oracle 等待接口 在之前的很早的 Oracle 数据库版本中开始介绍的 对于那些知道如何使用等待接口的管理员来 说这已经成为一个伟大的开始 即使它仍然缺乏告诉 DBA 系统或者用户会话是否有效的处理 了事务或者查询这个理想的能力 启用和钻研跟踪文件能够存储这个级别上的详细信息 但是 对于大多数超负荷工作管理大型数据库的 DBA 们 这个钻研是奢侈的而耗费时间的 幸运的是 那些将数据库升级到 Oracle10g 的 DBA 们将会发现找到主要的响应时间变得很容 易 可以允许一个非常好的图表来显示系统和会话级的响应时间数据 很重要的一点 Oracle 的 ADDM 提供了一个查看响应时间的方法 通过自动分析收集的统计信息 识别问题区域 甚至可以通过 Oracle 企业管理器网络控制的图形界面提供建议 此外 与我们这里讨论相关的是 Oracle10g 数据库的历史数据机制允许 DBA 们按时查看对响 应时间趋势的分析 这将有助于 DBA 们确定事务 系统的高峰时期 更好的定位那些拉长批处 理周期和 ETL 作业的进程和 SQL 语句 这里主要讨论用于系统 会话和 SQL 级别上那些历史机制的用途 系统层的响应时间分析 先来看看典型的几个经常问到 DBA 们的问题 通常来说 数据库运行的状况如何 用户体验感觉的平均响应时间是多少 什么行为是最影响整个响应时间的 上述问题在 Oracle10g 数据库之前对于 DBA 们来说是相当不好回答的 但是如果使用了最新 的 Oracle10g 数据库之后 这些数据信息将会很容易的被捕获到 首先 Oracle10g 数据库运行的状况如何这个问题可以通过下面的查询来获得 select METRIC NAME VALUE from SYS V SYSMETRIC 8 where METRIC NAME IN Database CPU Time Ratio Database Wait Time Ratio AND INTSIZE CSEC select max INTSIZE CSEC from SYS V SYSMETRIC METRIC NAME VALUE Database Wait Time Ratio 31 3499111 Database CPU Time Ratio 68 6500888 Oracle10g 数据库中的 V SYSMETRIC 视图中存在一些非常有用的响应时间数据 其中两个比 较重要的就是 Wait Time Ratio 和 Database CPU Time Ratio 上面的查询显示了数据库中最新的 关于这两个统计数据的快照 这将有助于帮助我们确定是否数据库正在经历着一个比较高的等 待百分率和瓶颈 数据库的 CPU Time Ratio 是由数据库中的 database time 的数值除以 CPU 的 数量 database time 定义为数据库消耗在用户级别调用所花费的时间 不包括实例的后台进 程活动所消耗的时间 比较高的值 90 95 以上 代表很少等待和瓶颈活动 因为各个系 统不同 这个阀值只能作为一个一般的规则来使用 还可以使用如下的查询来迅速查看最新一个小时的信息 看看数据库的总性能如何 select end time value from sys v sysmetric history where metric name Database CPU Time Ratio order by 1 END TIME VALUE 2007 1 24 2 3 21949216 2007 1 24 2 3 01443414 2007 1 24 2 9 75636353 9 2007 1 24 2 9 28581409 2007 1 24 2 43 3490481 2007 1 24 2 38 8366361 2007 1 24 2 32 0272511 2007 1 24 2 0 2007 1 24 2 22 9580733 2007 1 24 2 33 0615102 2007 1 24 2 43 1294933 可以从 V SYSMETRIC SUMMARY 视图中获得数据库整体性能效率的最大 最小和平均值 select CASE METRIC NAME WHEN SQL Service Response Time then SQL Service Response Time secs WHEN Response Time Per Txn then Response Time Per Txn secs ELSE METRIC NAME END METRIC NAME CASE METRIC NAME WHEN SQL Service Response Time then ROUND MINVAL 100 2 WHEN Response Time Per Txn then ROUND MINVAL 100 2 ELSE MINVAL 10 END MININUM CASE METRIC NAME WHEN SQL Service Response Time then ROUND MAXVAL 100 2 WHEN Response Time Per Txn then ROUND MAXVAL 100 2 ELSE MAXVAL END MAXIMUM CASE METRIC NAME WHEN SQL Service Response Time then ROUND AVERAGE 100 2 WHEN Response Time Per Txn then ROUND AVERAGE 100 2 ELSE AVERAGE END AVERAGE from SYS V SYSMETRIC SUMMARY where METRIC NAME in CPU Usage Per Sec CPU Usage Per Txn Database CPU Time Ratio Database Wait Time Ratio Executions Per Sec Executions Per Txn 11 Response Time Per Txn SQL Service Response Time User Transaction Per Sec ORDER BY 1 METRIC NAME MININUM MAXIMUM AVERAGE CPU Usage Per Sec 0 53 9947577 11 1603280 CPU Usage Per Txn 0 168 731666 24 8848615 Database CPU Time Ratio 0 87 1866295 35 8114730 Database Wait Time Ratio 0 90 7141859 64 1885269 Executions Per Sec 0 540 768348 114 852472 Executions Per Txn 0 1911 279 912779 Response Time Per Txn secs 0 3 88 0 66 SQL Service Response Time secs 0 0 0 User Transaction Per Sec 0 4 70183486 0 94469007 上面的查询包含了更多的详细的响应时间数据 DBA 们还需要收集在系统级别上的用户通讯 的平均响应时间 上面的查询给出了需要的结果 如果用户抱怨响应时间太慢 那么 DBA 就 应该查看 Response Time Per Txn 和 SQL Service Response Time 数据是否存在数据库问题 如果响应时间不在是那么渴求 那么 DBA 就会想了解究竟是什么类型的用户活动让数据库的 响应变得如此的慢 在 Oracle10g 数据库之前 这些信息 是比较难获取的 但是现在就变得非 常容易 执行如下查询 select case db stat name 12 when parse time elapsed then soft parse time else db stat name end db stat name case db stat name when sql execute elapsed time then time secs plsql time when parse time elapsed then time secs hard parse time else time secs end time secs case db stat name when sql execute elapsed time then round 100 time secs plsql time db time 2 when parse time elapsed then round 100 time secs hard parse time db time 2 else round 100 time secs db time 2 end pct time 13 from select stat name db stat name round value 1000000 3 time secs from sys v sys time model where stat name not in DB time background elapsed time background cpu time DB CPU select round value 1000000 3 db time from sys v sys time model where stat name DB time select round value 1000000 3 plsql time from sys v sys time model where stat name PL SQL execution elapsed time select round value 1000000 3 hard parse time from sys v sys time model where stat name hard parse elapsed time order by 2 desc DB STAT NAME TIME SECS PCT TIME sql execute elapsed time 65 644 89 7 14 hard parse elapsed time 26 661 36 43 PL SQL execution elapsed time 12 766 17 44 PL SQL compilation elapsed time 6 353 8 68 soft parse time 2 15 2 94 connection management call elapsed time 1 084 1 48 hard parse sharing criteria elapsed time 0 448 0 61 repeated bind elapsed time 0 026 0 04 failed parse elapsed time 0 009 0 01 hard parse bind mismatch elapsed time 0 002 0 RMAN cpu time backup restore 0 0 inbound PL SQL rpc elapsed time 0 0 sequence load elapsed time 0 0 Java execution elapsed time 0 0 failed parse out of shared memory elapsed time 0 0 可以在 V SYS TIME MODEL 视图中找到相应的主要花费时间处理的部分 然后就可以根据 这些来对数据库进行相应的调整 除了活动时间 DBA 也还想知道整体的等待时间 在 Oracle10g 数据库之前 DBA 必须查看 单独的等待事件来找出等待和瓶颈 现在 Oracle10g 数据库提供一个等待的概要机制 select WAIT CLASS 15 TOTAL WAITS round 100 TOTAL WAITS SUM WAITS 2 PCT WAITS ROUND TIME WAITED 100 2 TIME WAITED SECS round 100 TIME WAITED SUM TIME 2 PCT TIME from select WAIT CLASS TOTAL WAITS TIME WAITED from V SYSTEM WAIT CLASS where WAIT CLASS Idle select sum TOTAL WAITS SUM WAITS sum TIME WAITED SUM TIME from V SYSTEM WAIT CLASS where WAIT CLASS Idle order by 5 desc WAIT CLASS TOTAL WAITS PCT WAITS TIME WAITED SECS PCT TIME User I O 5748 61 71 67 57 65 79 Other 182 1 95 16 85 16 41 16 System I O 2975 31 94 11 27 10 97 Concurrency 114 1 22 6 76 6 58 Commit 61 0 65 0 22 0 21 Network 233 2 5 0 03 0 03 Application 2 0 02 0 0 这样就能非常容易的找出大部分的整体等待时间 如同响应时间数据一样 我们可以用下面的 查询来及时回顾最新的一个小时等待类型 select a sid b username a wait class a total waits round a time waited 100 2 time waited secs from sys v session wait class a sys v session b where b sid a sid and b username is not and a wait class Idle order by 5 desc 17 SID USERNAME WAIT CLASS TOTAL WAITS TIME WAITED SECS 38 SYS User I O 22 0 19 48 SYS User I O 15 0 12 38 SYS Network 21 0 01 48 SYS Network 24 0 38 SYS Application 2 0 这个时候 就可以检查标准的单独等待事件就如在以前版本的 Oracle 数据库中查询 V SESSION WAIT 和 V SESSION EVENT 视图 在 Oracle10g 数据库中 DBA 还将可以找出新的 等待类型在这两张视图中 如果需要找出以前哪个会话登录并且消耗了大部分的资源 你可以 使用下面的查询 下面的例子是查找午夜 12 点到 5 点的数据库活动 并且包括用户的 I O 等 待 select sess id username program wait event sess time round 100 sess time total time 2 pct time waited from select a session id sess id decode session type background session type c username username 18 a program program b name wait event sum a time waited sess time from sys v active session history a sys v event name b sys dba users c where a event b event and a user id c user id and sample time 22 JAN 07 12 00 00 AM and sample time 22 JAN 07 05 00 00 AM and b wait class User I O group by a session id decode session type background session type c username a program b name SQL 语句响应时间分析 在 Oracle9i 数据库中查看 SQL 语句的响应时间就变得比较容易了 现在在 Oracle10g 中 DBA 们拥有更多的工具可以帮助他们跟踪效率低下的数据库代码 以前可以用来查询的视图是 V SQLAREA 从 Oracle9i 开始 这个视图增加了 ELAPSED TIME 和 CPU TIME 两个列 这 极大的有助于去确定实际用户的 SQL 语句的执行经历 如果除以执行的次数列 EXECUTIONS 那么将得到平均每次执行这个 SQL 语句所用的平均时间 在 Oracle10g 数据 19 库中 V SQLAREA 视图中增加了 6 个新的和等待以及时间相关的列 APPLICATION WAIT TIME CONCURRENCY WAIT TIME CLUSTER WAIT TIME USER IO WAIT TIME PLSQL EXEC TIME JAVA EXE