| 出版日期：2002-03-04 总期号：1097 本年期号：14 |
|
 |
DBA的好帮手
Precise Indepth for Oracle试用手记 徐晨 初步印象 Precise公司的Indepth for Oracle采用客户/服务器架构。在数据库服务器端有个代理程序24×7天不间断地对生产环境持续的监控。客户端通过TCP/IP和服务器端通信。Indepth for Oracle 与众不同的是——不需要登录Oracle，就能够直接读取SGA和操作系统信息。这样保证了它能够以毫秒级的采样率采集数据，同时对Oracle没有任何负载，仅在峰值采样率下对操作系统占有3%-5%的CPU损耗。 安装及功能浏览 笔者尝试将Indepth for Oracle安装到电信综合营账的正式环境中（HPn4000 4CPU, Oracle8.1.7）。该产品并不像其他数据库性能优化工具需要提供数据库的TNS，说明它不用通过SQLNET和数据库连接。 做完安装前的准备工作后（如在UNIX上开一个用户和相应的设置等），随即就可安装客户端，通过客户端可以向服务器端进行安装。如需保存长期历史记录，服务器端需要一定的存储空间。服务器端代理程序安装完成，启动相应进程，监测就已经开始。 
通过客户端的Current Activity可以观察当前所有会话的运行状况；而利用Recent Activity、Performance Warehouse查看短期和长期的历史记录，找出某个时间段内发生的问题，根据历史状况，做出趋势判断，另外可以看到具体每个SQL语句的运行状况、系统资源的损耗与哪些SQL语句有关。 问题 经过采集一天的数据，该软件发现被测系统的资源损耗情况如下： 71% (433:32 小时) I/O wait 10%(63:23 小时) buffer wait 6.8%(41:21 小时)使用CPU 6.4%(39:03 hours)row lock wait 其他的5.8%消耗包括other host(16:41小时), redo log buffer( 16:31小时), memory( 6:11 小时)以及internal lock ( 2:39小时) 解决之道 显然，采集数据显示最大问题存在于I/O 等待。能发现问题，如何诊治才是高明之处。 通过关联数据文件选项，从众多数据文件可以发现大量I/O等待集中在rv1_data35和rv1_data34两个Oracle文件上。它们都属于INDEX表空间。首先，我们可以检查这两个文件是否在同一个物理设备上，虽然这两个文件在不同的逻辑卷上，但我们不知道这两个逻辑卷是否建立在同一个物理设备上（如使用的是EMC, HP XP的存储设备，Indepth for Oracle再加上其它选件可以看到此类信息）。 下一步通过其关联SQL语句选项，进行语句分析找出这两个文件中最活跃的对象是BILL_INDEX和I_USER_ID。特别是BILL_INDEX，因为BILL_TABLE本身大小只有427M(dirty_block 109534 * db_block_size 4096)，但它的索引BILL_INDEX已经将近达到了1G（extent size 20M * number of extent 49），所以造成不能有效地使用索引，读取过多无用的数据块，增加了I/O的负担。 针对以上两种情况，笔者重建BILL_INDEX和I_USER_ID，并分配到其他读写较为空闲设备上的Oracle文件中；利用Indepth for Oracle的模拟索引修改功能，进行增加、修改、删除索引的仿真处理，决定增加索引，以避免无谓的全表扫描。 小结 总的来说，Precise/Indepth for Oracle是一个非常不错的产品，有独特的采样技术、强大的扩展性（同时还可以看和数据库相关的操作系统的信息、ERP的性能信息、存储设备中物理设备的具体信息，还可以和J2EE结合……）。Precise/Indepth for Oracle提供了关联的性能信息，可以帮助我们迅速地找到问题的根源。 |
||||||||||||||||||||
