DBA工具_OTop

当我们在Linux/Unix下遇到CPU负荷很高时,经常会用"top"或"prstat"命令找出最耗CPU的进程. 对于Oracle数据库,如果我们能找出TOP会话,将在性能调优时发挥很大的作用. 虽然我们可以根据"top"或"prstat"命令的输出中找出PID, 然后从V$SESSION和V$PROCESS的关联中找出TOP会话,然而这样并不很方便. 我的问题是能不能很方便地找出TOP逻辑读或TOP物理读的会话?

OTop可以在5秒种内找出这些TOP会话. 在Oracle中有很多的视图保存了很多的统计信息. 这在Oracle性能调优时很有用,通过V$SESSION和V$SESSTAT的关联,我们可以根据任何一个统计类型排序找出TOP会话. 因而我们可以找出那个会话引起了最多的逻辑读或特理读. 从实际出发,我已经使用OTop很长一段时间了, 并助发现和解决了很多的性能很差的SQL语句, 这个工具的方便性和有用性超出了我当初的想像.

1,免费下载

• Windows/Linux/Solaris正式版

2, 安装与使用

OTop是一个非常有用的小工具, 要使用你必须安装Oracle客户端或服务端软件, 如果你需要连接到远程数据,还需要配置Oracle的客户端, 使用"-U"选项指定要连接的用户名, 程序会提示输入口令, 请给这个用户CREATE SESSION和SELECT_CATALOG_ROLE角色权限.

C:MYDULdulsrc>otop -h
AnySQL OPMon for Oracle, Release 2.0.0
(c) Copyright Lou Fangxin 2004/2005, all rights reserved.

Usage: otop -[option][value]
-H print help message
-U Oracle user name with select_catalog_role.
-S tns alias if remote database.
-T time interval (default 30 seconds, min 5, max 900)
-C number of top SQLs displayed (min 5, max 16384)
-Q run in quiet mode, write to file
-D directory of output file in quiet mode
-O Order by (GETS/CPUT/DISK/SORT/WAIT/REDO/EXEC)

下面是一个连接的例子:

在SQL*Plus中连接数据库如下
SQL> conn anysql/anysql@prod
Connected.
SQL> exit
则用otop时在命令行输入,提示密码时输入密码然后回车:
C:>otop -uanysql -sprod
Password:******

对于OTop, 默认报表简隔时间为5秒, 显示的TOP会话数为20, 默认的排序为逻辑读. 你可以用"-o"选项指定排序方式, 我预先定义了一些常用的编计值的简短编码,如下所示:

• DISK = physical reads
• GETS = consistent gets
• EXEC = execute count
• CPUT = CPU used by this session
• SORT = sorts (memory)
• REDO = redo size
• WAIT = enqueue waits
• SENT = bytes sent via SQL*Net to client

也可以用"-o"选项指定完整的统计名称.

3, 输出例子

Top Session ( 16:54:47 - 16:54:53 ) Order by gets
-Statistics (Per Second Value)------------------------------------------------------------------
0 logon 20 open cursors 441 user commits 0 user rollback
2399 user calls 264 CPU time 0 enqueue waits 12K db block gets
8605 consistent get 2009 physical reads 7113 DB blk Changes 271 physical write
0 DBWR buf scan 115 free buf req 0 Dirty buf ins 0 free buf ins
0 CR blk created 1918 Direct reads 2 Direct write 0 LOB phy read
0 LOB phy write 1196K redo size 2672 redo blk write 0 table direct
94K table scan 1590 table by rowid 14 Leaf Split 2 Leaf 9/1 Split
18 Total parse 0 Hard parse 1820 execute count 490K bytes SQL*Net
43 sort memory 0 sort disk

-Get/S--Mis/S--Slp/S-IGet/S-IMis/s-SGet/S--Latch------------------------------(Top Latch)-------
4315 42 0 0 0 42 redo allocation
1707 9 0 0 0 9 dml lock allocation
54K 7 0 111 0 0 cache buffers chains
3893 7 0 0 0 7 library cache
3331 2 0 0 0 2 library cache pin

---SID-Serial--VALUE--VAL/S------%---PrevSQL3---PrevSQL2---PrevSQL1----CurrSQL--Machine---------
1952 335 13K 842 4.50 2114476401 0 2114476401 0 hostname (username)
144 50207 2743 171 0.92 0 3499901456 2763144616 0 hostname (username)
1704 50987 2556 159 0.85 2820282212 3122001174 4271307775 0 hostname (username)
2640 16921 2439 152 0.81 0 3499901456 4029319376 0 hostname (username)
523 14943 2435 152 0.81 0 2642332362 2642308833 0 hostname (username)
2205 54499 2403 150 0.80 0 2148386017 0 4014542435 hostname (username)
1140 34817 2388 149 0.80 2763144616 0 0 181776708 hostname (username)
1944 59078 2020 126 0.67 529594293 1887935815 529594293 1887935815 hostname (username)
492 19541 2007 125 0.67 2642308833 0 4271307775 0 hostname (username)
3044 47832 1982 123 0.66 2763144616 0 1769575534 0 hostname (username)
2354 37867 1978 123 0.66 4271307775 0 1769575534 0 hostname (username)
4079 59088 1938 121 0.65 0 2148386017 2642308833 0 hostname (username)
3970 44308 1875 117 0.63 2642308833 0 2763144616 0 hostname (username)
1878 61350 1767 110 0.59 4159058828 0 1677309757 1692078697 hostname (username)
2942 33935 1737 108 0.58 0 4014542435 2642308833 0 hostname (username)
1234 35048 1684 105 0.56 0 3499901456 0 3499901456 hostname (username)
2310 21974 1601 100 0.53 0 1040255361 0 2642332362 hostname (username)
3311 20567 1594 99 0.53 2642308833 0 2763144616 0 hostname (username)
3973 29401 1579 98 0.53 4271307775 0 0 3499901456 hostname (username)
3715 28665 1560 97 0.52 2642308833 0 0 181776708 hostname (username)

所有的值都是这段时间间隔内的差额值,第一部分是系统级的统计值,第二部分是TOP会话. 你可以看到在整个系统中有四个会话引起了几乎所有的逻辑读,你可以通过HASH值找出这些会话的SQL语句, 然后再调整这些SQL,从而解决性能问题. 你会发现这是一个Oracle DBA的好工具.

4, 备注

OTop并不会在服务器端引起什么负荷,我从一个有两千多个会话的数据库生成上面的报告例子, 其中的SQL运行的时间小于1秒.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/266281/viewspace-495465/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/266281/viewspace-495465/