如何选择合适的数据库性能工具

大数据分析相关的有很多方面的应用 企业内部来说 是采集基于历史的数据作为未来的分析参考 企业外部来说 包括企业的情报搜集 企业负面的发现和处理等 企业外部的 一般会用网络信息的采集系统 根据用户自定义的任务配置

Interpretation

在处理性能问题时，我们最关注的是数据库正在等待什么。

当进程因为某些原因不能进行 *** 作时，它需要等待。花费时间最多的等待事件是我们最需要关注的，因为降低它，我们能够获得最大的好处。

AWR报告中的"Top 5 Timed Events"部分就提供了这样的信息，可以让我们只关注主要的问题。

•

Top 5 Timed Events

正如前面提到的，"Top 5 Timed Events"是AWR报告中最重要的部分。它指出了数据库的sessions花费时间最多的等待事件，如下：

Top 5 Timed Events Avg %Total

~~~~~~~~~~~~~~~~~~ wait Call

Event Waits Time (s) (ms) Time Wait Class

------------------------------ ------------ ----------- ------ ------ ----------

db file scattered read 10,152,564 81,327 8 296 User I/O

db file sequential read 10,327,231 75,878 7 276 User I/O

CPU time 56,207 205

read by other session 4,397,330 33,455 8 122 User I/O

PX Deq Credit: send blkd 31,398 26,576 846 97 Other

-------------------------------------------------------------

Top 5 Events部分包含了一些跟Events（事件）相关的信息。它记录了这期间遇到的等待的总次数，等待所花费的总时间，每次等待的平均时间；这一部分是按照每个Event占总体call time的百分比来进行排序的。

根 据Top 5

Events部分的信息的不同，接下来我们需要检查AWR报告的其他部分，来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据

库中的并发用户数进行评估。如：10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题；10个用户引起的1000万次的等待事件比

10,000个用户引起的相同的等待要更有问题。

就像上面的例子，将近60%的时间是在等待IO相关的事件。

• 事件"db file scattered read"一般表明正在做由全表扫描或者index fast full scan引起的多块读。

• 事件"db file sequential read"一般是由不能做多块读的 *** 作引起的单块读（如读索引）

其他20%的时间是花在使用或等待CPU time上。过高的CPU使用经常是性能不佳的SQL引起的（或者这些SQL有可能用更少的资源完成同样的 *** 作）；对于这样的SQL，过多的IO *** 作也是一个症状。关于CPU使用方面，我们会在之后讨论。

在以上基础上，我们将调查是否这个等待事件是有问题的。若有问题，解决它；若是正常的，检查下个等待事件。

过多的IO相关的等待一般会有两个主要的原因：

• 数据库做了太多的读 *** 作

• 每次的IO读 *** 作都很慢

Top 5 Events部分的显示的信息会帮助我们检查：

• 是否数据库做了大量的读 *** 作：

上面的图显示了在这段时间里两类读 *** 作都分别大于1000万，这些 *** 作是否过多取决于报告的时间是1小

时或1分钟。我们可以检查AWR报告的elapsed time如果这些读 *** 作确实是太多了，接下来我们需要检查AWR报告中 SQL

Statistics 部分的信息，因为读 *** 作都是由SQL语句发起的。

• 是否是每次的IO读 *** 作都很慢：

上面的图显示了在这段时间里两类读 *** 作平均的等待时间是小于8ms的

至于8ms是快还是慢取决于底层的硬件设备；一般来讲小于20ms的都可以认为是可以接受的。

我们还可以在AWR报告"Tablespace IO Stats"部分得到更详细的信息

Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15

-> ordered by IOs (Reads + Writes) desc

Tablespace

------------------------------

Av Av Av Av Buffer Av Buf

Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)

-------------- ------- ------ ------- ------------ -------- ---------- ------

TS_TX_DATA

14,246,367 283 76 46 145,263,880 2,883 3,844,161 83

USER

204,834 4 107 10 17,849,021 354 15,249 98

UNDOTS1

19,725 0 30 10 10,064,086 200 1,964 49

AE_TS

4,287,567 85 54 67 932 0 465,793 37

TEMP

2,022,883 40 00 58 878,049 17 0 00

UNDOTS3

1,310,493 26 46 10 941,675 19 43 00

TS_TX_IDX

1,884,478 37 73 10 23,695 0 73,703 83

>SYSAUX

346,094 7 56 39 112,744 2 0 00

SYSTEM

101,771 2 79 35 25,098 0 653 27

如上图，我们关心Av Rd(ms)的指标。如果它高于20ms并且同时有很多读 *** 作的，我们可能要开始从OS的角度调查是否有潜在的IO问题。

1，在第一个图choose monitor engine中选择sitescope，然后在在Monitored Server Machines区域点击Add可以选择本地或者其他机器的sitescope，如果sitescope启用了account的验证，也要写上相应的用户名密码。

2，在Resource Measurements on:IP区域点击添加，d出对话框

3，输入信息

至此就可以监控oracle了。

以上就是关于如何选择合适的数据库性能工具全部的内容，包括:如何选择合适的数据库性能工具、如何使用AWR报告来诊断数据库性能问题、如何在loadrunner中监控oracle数据库性能测试等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！