- 作者: 三十而立
- 时间：2009年10月13日 13:04:38
- 本文出自 “inthirties（三十而立）”博客，转载请务必注明作者和保留出处http://blog.csdn.net/inthirties/archive/2009/10/06/4635065.aspx
对于我们的性能优化来说，最坏的一种情况，就是在架构，需求，设计和实现的过程中都没有发现问题，而直到了上线或者是使用一段时间以后才发现性能问题。这个我已经也多次的提及过，和系统的问题和人生病一样，小病不看，到大病拖不下去了，来到医生动手术的时候，这里的解决方案是最局限的，解决成本也是最高额的，而且可以解决的问题也是最有局限性的。所以性能方面的考虑是每个生命周期都值得进行的，都是非常有意义的。对于上面的问题而已，到了DBA这里，基本上也就存在着或大或小的一些性能问题。
对于性能优化而言，我们应该从瓶颈处的分析着手，问题由大至小，由全面到具体。根据整体的性能报告先找到最严重的地方开始，有目标的进行，根据我们的针对性的目标，我们可能已经找到了一些需要分析的问题了。比如说，CPU和内存的使用过高，dead lock，IO的性能低下等大该的问题叻 。有了这个大概的方向，我们就可以针对性的开始我们的优化之举了，分析瓶颈的目的，就是找到正真的最大的性能发生问题的关键点，根据这个关键点进去，我们落实到每个具体的环节。对于一个性能的问题而言，最终的因素无非是 硬件和操作系统的局限，应用错误和数据库管理上的失误。 性能底下的原因无非就是这三个方面的组合而已，我们需要做的就是根据自己的经验，配合上适当的工具对这三个方面的原因进行甄别，找到正真的罪魁祸首。然后针对着进行调配和修改，从而达到优化的目的。
我们下面来具体看看这影响我们的性能的三个方面，以及我们用到的方法
1. 硬件和操作系统的局限 数据库安装在操作系统上.操作系统架构在硬件上，所以硬件直接的对我们的软件的性能造成影响。比如CPU的处理能力，物理内存的大小，网络的拓扑结构，存储的媒介，IO的读写能力这些对我们的整个的Oracle的数据库性能都有着相当大的影响。对于以上的一些硬件设备的状态，操作系统都提供了一定的系统工具，使我们能够行而有效的对之进行监控和管理。在linux和unix下，使用top，iostat，sysstat，vmstat，sar，df等一些系统监控的工具，我们可以很方便的对数据库的硬件状况进行监控和排查。除开硬件，我们操作系统的一些设置也会有一些影响，比如linux的一些内核参数，进程线程的控制参数，swap空间的大小，这些都一样对我们的性能造成影响。我们也可以根据针对性的工具进行排查和诊断。
2. 应用上的错误，对于应用上的错误，包括很多的方面，比如说，sql性能的低劣，大量的硬解析的消耗，过多的长事务，死锁，没有使用批处理等等，这些应用上的错误，多半是我们的设计者和程序员在自己的设计和实现的过程中，对性能的考虑过少导致的，对于这样的错误。我们可以直接的落实到点上，对发生性能低劣的地方进行优化。
3. 数据库管理上的失误 这里就是DBA本身的问题叻，缺少对数据库优化的经验，在数据库维护和管理的时候，没有进行有针对性的管理，比如分开IO，条带化，大表的分区，内存性能参数的设置。发现这样的问题的话，我们需要对数据库整体上进行rebuild，重新规划存储,重新规划内存和启动参数，规划出更好性能的结构。
对于甄别上面不同原因造成的性能问题，Oracle提供了一个强大的性能分析工具，statspack，这个性能分析工具，提供时间段的监控手段，达到对指定的时间段的Oracle数据库服务器的一个整体上的性能监控的目的，在statspack提供出来的性能报告里，能够找到很多重要的性能好坏的指标数据，，比如说数据库内存状况，负载情况，数据库的内存的命中率，sql的解析率，以及top sql，wait event等信息。根据这些信息，我们不仅有一个很全面的性能状况的了解，而且还可以根据其中的每个性能数据，深入下去，还是对上面提到的三个方面进行排查的依据和参考点。
在statspack报告里，包含了以上我们提到的很多影响数据库性能的因素的数据库统计，
比如我们可以在statspack里的顺着看到
引用:
DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
TOOWELL 3651869694 toowell 1 9.2.0.1.0 NO COMPUTERHJHSnap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 1 09-4月 -09 01:19:29 11 4.8
End Snap: 3 09-4月 -09 01:38:29 11 5.4
Elapsed: 19.00 (mins)
这里记载了整个监控时间的实例信息
引用:
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 1,000M Std Block Size: 8K
Shared Pool Size: 80M Log Buffer: 512KLoad Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 2,597.53 296,118.80
Logical reads: 13,379.84 1,525,301.30
Block changes: 11.10 1,265.50
Physical reads: 401.24 45,741.60
Physical writes: 0.81 92.30
User calls: 146.20 16,666.50
Parses: 29.77 3,394.30
Hard parses: 8.81 1,003.90
Sorts: 18.58 2,118.40
Logons: 1.60 182.60
Executes: 32.00 3,647.50
Transactions: 0.01% Blocks changed per Read: 0.08 Recursive Call %: 49.97
Rollback per transaction %: 0.00 Rows per Sort: 14.14Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.96 Redo NoWait %: 100.00
Buffer Hit %: 97.00 In-memory Sort %: 100.00
Library Hit %: 87.28 Soft Parse %: 70.42
Execute to Parse %: 6.94 Latch Hit %: 99.68
Parse CPU to Parse Elapsd %: 90.63 % Non-Parse CPU: 94.21Shared Pool Statistics Begin End
------ ------
Memory Usage %: 86.41 87.01
% SQL with executions>1: 58.56 45.56
% Memory for SQL w/exec>1: 53.48 45.47
这里记载了所有的内存状况的信息以及概要性的信息，这里我们可以看到命中率和内存的一些信息。
引用:
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
db file sequential read 271,910 587 64.06
db file scattered read 12,428 163 17.82
CPU time 99 10.75
buffer busy waits 6,024 59 6.45
control file sequential read 248 2 .25
-------------------------------------------------------------
Wait Events for DB: TOOWELL Instance: toowell Snaps: 1 -3
-> s - second
-> cs - centisecond - 100th of a second
-> ms - millisecond - 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
db file sequential read 271,910 0 587 2 ########
db file scattered read 12,428 0 163 13 1,242.8
log file parallel write 1,090 790 2 1 109.0
LGWR wait for redo copy 26 0 0 0 2.6
SQL*Net message from client 168,451 0 2,199 13 ########
virtual circuit status 38 38 1,135 29860 3.8
wakeup time manager 36 36 1,088 30218 3.6
SQL*Net message to client 168,451 0 0 0 ########
-------------------------------------------------------------
Background Wait Events for DB: TOOWELL Instance: toowell Snaps: 1 -3
-> ordered by wait time desc, waits desc (idle events last)Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
control file parallel write 369 0 2 6 36.9
control file sequential read 148 0 2 15 14.8
log file parallel write 1,090 790 2 1 109.0
db file scattered read 4 0 1 212 0.4
........
rdbms ipc message 3,234 2,424 5,145 1591 323.4
smon timer 4 4 984 ###### 0.4
-------------------------------------------------------------
以上我们可以看到我们的数据库的一些重要的等待事件，这些等待事件也是影响我们数据库性能的因素之一。
引用:
SQL ordered by Gets for DB: TOOWELL Instance: toowell Snaps: 1 -3
-> End Buffer Gets Threshold: 10000
-> Note that resources reported for PL/SQL includes the resources used by
all SQL statements called within the PL/SQL code. As individual SQL
statements are also reported, it is possible and valid for the summed
total % to exceed 100CPU Elapsd
Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
1,271,286 2 635,643.0 8.3 7.22 272.59 3380648538
Module: PL/SQL Developer
--m=2 --SELECT /*+ FIRST_ROWS */ * FROM ( SELECT A.*, rownum r F
ROM ( SELECT a.* FROM md_info_reg a, md_member_company b where a
.username=b.username and length(imageurl1)>5 and hits>-1 order
by a.id) A WHERE rownum <= 5 ) B WHERE r > 0 --m=1 SELECT /*+ F
IRST_ROWS */ * FROM ( SELECT A.*, rownum r FROM ( SELECT a.* FRO.........
这里是我们的性能低劣的sql的信息叻
Instance Activity Stats for DB: TOOWELL Instance: toowell Snaps: 1 -3
Statistic Total per Second per Trans
--------------------------------- ------------------ -------------- ------------
index fast full scans (full) 1,229 1.1 122.9
index fetch by key 1,216,953 1,067.5 121,695.3
index scans kdiixs1 75,366 66.1 7,536.6
leaf node 90-10 splits 8 0.0 0.8
leaf node splits 39 0.0 3.9
logons cumulative 1,826 1.6 182.6
......
Instance Activity Stats for DB: TOOWELL Instance: toowell Snaps: 1 -3
Statistic Total per Second per Trans
--------------------------------- ------------------ -------------- ------------
table scan rows gotten 579,397 508.2 57,939.7
table scans (long tables) 15 0.0 1.5
table scans (short tables) 1,366 1.2 136.6
transaction rol
lbacks 0 0.0 0.0
transaction tables consistent rea 0 0.0 0.0
transaction tables consistent rea 0 0.0 0.0
user calls 166,665 146.2 16,666.5
........
-------------------------------------------------------------
引用:
Tablespace IO Stats for DB: TOOWELL Instance: toowell Snaps: 1 -3
->ordered by IOs (Reads + Writes) descTablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
ECCHNFILE
284,200 249 2.6 1.6 15 0 6,024 9.8
UNDOTBS1
5 0 16.0 1.0 408 0 0 0.0
SYSTEM
61 0 26.4 1.1 257 0 0 0.0
PERFSTAT
60 0 6.7 1.0 243 0 0 0.0
-------------------------------------------------------------
File IO Stats for DB: TOOWELL Instance: toowell Snaps: 1 -3
->ordered by Tablespace, FileTablespace Filename
------------------------ ----------------------------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
ECCHNFILE D:/ORACLE/ORADATA/TOOWELL/ECCHNFILE.ORA
284,200 249 2.6 1.6 15 0 6,024 9.8PERFSTAT D:/ORACLE/USERDATA/PRESTAT.PHP
60 0 6.7 1.0 243 0 0SYSTEM D:/ORACLE/ORADATA/TOOWELL/SYSTEM01.DBF
61 0 26.4 1.1 257 0 0UNDOTBS1 D:/ORACLE/ORADATA/TOOWELL/UNDOTBS01.DBF
5 0 16.0 1.0 408 0 0-------------------------------------------------------------
这里是物理和逻辑存储的IO状况
我们还可以在里面找到
Rollback Segment Stats for DB
Rollback Segment Storage for DB
Undo Segment Summary for DB
Latch Activity for DB
Dictionary Cache Stats for DB
Shared Pool Advisory for DB
SGA Memory Summary for DB
Resource Limit Stats for DB
这些方面的信息，statspack里的信息都是来自于数据库里的动态性能视图的，都是对性能反应的一些数据。对这些信息的分析，完全是可以给我们的性能针对提供很充分的依据的。
这篇文章仅仅给大家介绍的性能分析的方法和statspack的作用，还咩有涉及到具体的诊断手段，有关具体的诊断手段，欢迎大家继续关注inthirties的Oracle数据库性能优化专栏。
- 如果没有那句“三十而立”，三十岁的男人正可以轻轻松松
- 专业论坛 http://www.inthirties.com
- 技术博客 http://blog.csdn.net/inthirties
- 个人站点 http://blog.inthirties.com
- Oracle Mysql技术论坛| 打造实用的Oracle Mysql技术交流园地