部署statspack工具（二）之解决方案3
9解决方案三：使用绑定变量并生成报告进行分析
9．1重新修改查询业务语句加入绑定变量
脚本如下
sqlplus scott/tiger <<EOF
declare
v_empno emp2.empno%type;
v_emp2 emp2%rowtype;
begin
v_empno := 0;
whilev_empno<=2000000 loop
v_empno :=v_empno + 1;
select * into v_emp2
from emp2 whereempno=v_empno;
if v_empno=2000000 then
v_empno:=0;
end if;
end loop;
end;
/
sh script/bin/share_pool_sql_2.sh
9.2执行新的查询业务脚本并启动statspack自动快照
[email protected]:/home/oracle/script/bin>sh share_pool_sql_2.sh
9.3生成statspack新的分析报告
perfstat@TESTDB12>selectsnap_id,snap_time,snap_level from stats$snapshot order by snap_time;
idle>selectsnap_id,snap_time,snap_level from stats$snapshot order by snap_time;
SNAP_ID SNAP_TIME SNAP_LEVEL
---------- -------------------
1 28-JUL-14 7
11 28-JUL-14 7
21 28-JUL-14 7
31 28-JUL-14 7
41 29-JUL-14 7
51 29-JUL-14 7
61 29-JUL-14 7
71 29-JUL-14 7
81 29-JUL-14 7
91 29-JUL-14 7
101 29-JUL-14 7
111 29-JUL-14 7
121 29-JUL-14 7
131 29-JUL-14 7
141 29-JUL-14 7
151 29-JUL-14 7
161 29-JUL-14 7
171 29-JUL-14 7
181 29-JUL-14 7
191 29-JUL-14 7
201 29-JUL-14 7
211 29-JUL-14 7
221 29-JUL-14 7
231 29-JUL-14 7
241 29-JUL-14 7
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 191
Enter value for end_snap: 201
Enter value for report_name:
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 201
Enter value for end_snap: 211
Enter value for report_name:
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 211
Enter value for end_snap: 221
Enter value for report_name:
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 221
Enter value for end_snap: 231
Enter value for report_name:
9.4通过新生成的4个statspack报告对比各个时间段的数据缓冲区的命中率和库缓冲区的命中率：
时间 |
Buffer Hit（%） |
Library Hit（%） |
06:28:02~ 07:18:02 |
99.84 |
98.42 |
07:18:02 ~07:33:03 |
99.75 |
99.89 |
07:33:03~ 07:48:04 |
99.76 |
99.95 |
07:48:04~ 08:03:03 |
99.75 |
99.87 |
通过对比以上4个报告，使用绑定变量后，Library Hit得到了很大的改善达到oracle所要求的99%，自此，Buffer Hit和Library Hit都达到了理想状态。
9.5查看Top 5 Timed Events找出4 个报告中各个时间段跟磁盘I/O相关的等待事件
时间 |
name |
Wait(s) |
Time(s) |
06:28:02~ 07:18:02 |
db file sequential read |
165,762 |
43 |
log file parallel write |
112,381 |
39 |
|
os thread startup |
117 |
18 |
|
07:18:02 ~07:33:03 |
os thread startup |
37 |
10 |
db file sequential read |
143,036 |
2 |
|
db file async I/O submit |
84 |
0 |
|
control file parallel write |
320 |
0 |
|
07:33:03~ 07:48:04 |
os thread startup |
31 |
5 |
db file sequential read |
140,882 |
2 |
|
db file async I/O submit |
94 |
0 |
|
control file parallel write |
320 |
0 |
|
07:48:04~ 08:03:03 |
os thread startup |
38 |
8 |
db file sequential read |
143,889 |
2 |
|
db file async I/O submit |
92 |
1 |
|
log file parallel write |
406 |
0 |
对比前面的Top 5 Timed Events，加索引和绑定变量后，索引次数又上来了，每秒中处理的事物也提升了。
9.6造成物理读最大的前几个sql语句在报告中未找到，用sql语句查询得出这些语句:select sql_text from v$sqlwhere disk_reads=(select max(disk_reads) from v$sql);
时间 |
Executions |
Elapsed |
Sql语句 |
06:28:02~ 07:18:02 |
15,912,511 |
399.21 |
SELECT * FROM EMP2 WHERE EMPNO=:B1 |
07:18:02 ~07:33:03 |
14,299,147 |
345.59 |
SELECT * FROM EMP2 WHERE EMPNO=:B1 |
07:33:03~ 07:48:04 |
14,452,859 |
343.56 |
SELECT * FROM EMP2 WHERE EMPNO=:B1 |
07:48:04~ 08:03:03 |
14,237,466 |
341.70 |
SELECT * FROM EMP2 WHERE EMPNO=:B1 |
通过对比发现还是有重用执行计划，但重用的执行计划已经使用了绑定变量，并且这些语句执行次数都很大，说明绑定变量生效。
生成语句的执行计划: set autotrace traceonly select * from scott.emp2
idle>select *from scott.emp2 where empno=1484;
Execution Plan
----------------------------------------------------------
Plan hash value:2918945472
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 48 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| EMP2 | 1 | 48 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN |IND_EMPNO | 1 | | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------
PredicateInformation (identified by operation id):
---------------------------------------------------
2 - access("EMPNO"=1484)
Statistics
----------------------------------------------------------
55 recursive calls
0 db block gets
78 consistent gets
4 physical reads
0 redo size
1033 bytes sent via SQL*Net to client
523 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
1 rows processed
9.7查看Buffer Pool Advisory并把Buffer cache的大小设置为推荐的大小
06:28:02~ 07:18:02时间段的Buffer PoolAdvisory
Est
Phys Estimated Est
Size for Size Buffers Read Phys Reads Est Phys % dbtime
P Est (M) Factr (thousands) Factr (thousands) Read Time for Rds
--- -------- ----------------- ------ -------------- ------------ --------
D 4 .1 0 7.4 1,646 797 5.5
D 8 .2 1 1.0 232 115 .8
D 12 .3 1 1.0 229 114 .8
D 16 .4 2 1.0 226 113 .8
D 20 .5 2 1.0 225 112 .8
D 24 .5 3 1.0 225 112 .8
D 28 .6 3 1.0 224 112 .8
D 32 .7 4 1.0 224 111 .8
D 36 .8 4 1.0 224 111 .8
D 40 .9 5 1.0 224 111 .8
D 44 1.0 5 1.0 224 111 .8
D 48 1.1 6 1.0 223 111 .8
D 52 1.2 6 1.0 223 111 .8
D 56 1.3 7 1.0 223 111 .8
D 60 1.4 7 1.0 223 111 .8
D 64 1.5 8 1.0 223 111 .8
D 68 1.5 8 1.0 223 111 .8
D 72 1.6 9 1.0 223 111 .8
D 76 1.7 9 1.0 223 111 .8
D 80 1.8 10 1.0 223 111 .8
07:18:02 ~07:33:03时间段的Buffer PoolAdvisory
Est
Phys Estimated Est
Size for Size Buffers Read Phys Reads Est Phys % dbtime
P Est (M) Factr (thousands) Factr (thousands) Read Time for Rds
--- -------- ----------------- ------ -------------- ------------ --------
D 4 .1 0 7.3 2,693 786 4.6
D 8 .2 1 1.0 382 117 .7
D 12 .3 1 1.0 377 116 .7
D 16 .4 2 1.0 373 115 .7
D 20 .5 2 1.0 370 114 .7
D 24 .5 3 1.0 369 114 .7
D 28 .6 3 1.0 369 114 .7
D 32 .7 4 1.0 368 114 .7
D 36 .8 4 1.0 368 114 .7
D 40 .9 5 1.0 368 114 .7
D 44 1.0 5 1.0 368 114 .7
D 48 1.1 6 1.0 368 113 .7
D 52 1.2 6 1.0 367 113 .7
D 56 1.3 7 1.0 367 113 .7
D 60 1.4 7 1.0 367 113 .7
D 64 1.5 8 1.0 367 113 .7
D 68 1.5 8 1.0 367 113 .7
D 72 1.6 9 1.0 367 113 .7
D 76 1.7 9 1.0 367 113 .7
D 80 1.8 10 1.0 367 113 .7
07:33:03~ 07:48:04时间段的Buffer PoolAdvisory
Est
Phys Estimated Est
Size for Size Buffers Read Phys Reads Est Phys % dbtime
P Est (M) Factr (thousands) Factr (thousands) Read Time for Rds
--- -------- ----------------- ------ -------------- ------------ --------
D 4 .1 0 7.3 3,708 783 3.9
D 8 .2 1 1.0 529 119 .6
D 12 .3 1 1.0 522 118 .6
D 16 .4 2 1.0 516 117 .6
D 20 .5 2 1.0 513 116 .6
D 24 .5 3 1.0 512 116 .6
D 28 .6 3 1.0 511 115 .6
D 32 .7 4 1.0 510 115 .6
D 36 .8 4 1.0 510 115 .6
D 40 .9 5 1.0 510 115 .6
D 44 1.0 5 1.0 510 115 .6
D 48 1.1 6 1.0 509 115 .6
D 52 1.2 6 1.0 509 115 .6
D 56 1.3 7 1.0 509 115 .6
D 60 1.4 7 1.0 509 115 .6
D 64 1.5 8 1.0 509 115 .6
D 68 1.5 8 1.0 509 115 .6
D 72 1.6 9 1.0 509 115 .6
D 76 1.7 9 1.0 508 115 .6
D 80 1.8 10 1.0 508 115 .6
07:48:04~ 08:03:03时间段的Buffer PoolAdvisory
Est
Phys Estimated Est
Size for Size Buffers Read Phys Reads Est Phys % dbtime
P Est (M) Factr (thousands) Factr (thousands) Read Time for Rds
--- -------- ----------------- ------ -------------- ------------ --------
D 4 .1 0 7.2 4,736 786 3.5
D 8 .2 1 1.0 679 121 .5
D 12 .3 1 1.0 671 120 .5
D 16 .4 2 1.0 663 118 .5
D 20 .5 2 1.0 659 118 .5
D 24 .5 3 1.0 657 117 .5
D 28 .6 3 1.0 656 117 .5
D 32 .7 4 1.0 656 117 .5
D 36 .8 4 1.0 655 117 .5
D 40 .9 5 1.0 655 117 .5
D 44 1.0 5 1.0 655 117 .5
D 48 1.1 6 1.0 654 117 .5
D 52 1.2 6 1.0 654 117 .5
D 56 1.3 7 1.0 654 117 .5
D 60 1.4 7 1.0 654 117 .5
D 64 1.5 8 1.0 654 117 .5
D 68 1.5 8 1.0 653 117 .5
D 72 1.6 9 1.0 653 117 .5
D 76 1.7 9 1.0 653 117 .5
D 80 1.8 10 1.0 653 117 .5
通过以上4个时间段中Buffer Pool Advisory建议可以看的出来，对于增加Buffer cache的大小对性能的影响并不明显，不用再对buffer cache进行调整。
9.8查看Time Model System Stats
06:28:02~ 07:18:02时间段Time Model System Stats |
Statistic Time (s) % DB time ----------------------------------- -------------------- --------- sql execute elapsed time 6,078.7 92.9 DB CPU 2,000.3 30.6 parse time elapsed 342.9 5.2 hard parse elapsed time 285.0 4.4 connection management call elapsed 213.7 3.3 PL/SQL execution elapsed time 147.7 2.3 hard parse (sharing criteria) elaps 4.7 .1 hard parse (bind mismatch) elapsed 4.5 .1 repeated bind elapsed time 0.9 .0 PL/SQL compilation elapsed time 0.9 .0 sequence load elapsed time 0.6 .0 DB time 6,542.4 background elapsed time 147.9 background cpu time 69.4
|
07:18:02 ~07:33:03时间段Time Model System Stats |
Statistic Time (s) % DB time ----------------------------------- -------------------- --------- sql execute elapsed time 2,717.7 100.0 DB CPU 897.8 33.0 PL/SQL execution elapsed time 119.1 4.4 parse time elapsed 10.6 .4 hard parse elapsed time 10.3 .4 hard parse (sharing criteria) elaps 1.7 .1 hard parse (bind mismatch) elapsed 1.6 .1 repeated bind elapsed time 0.2 .0 PL/SQL compilation elapsed time 0.2 .0 sequence load elapsed time 0.0 .0 DB time 2,718.2 background elapsed time 16.0 background cpu time 0.7 |
07:33:03~ 07:48:04时间段Time Model System Stats |
Statistic Time (s) % DB time ----------------------------------- -------------------- --------- sql execute elapsed time 2,708.5 100.0 DB CPU 898.7 33.2 PL/SQL execution elapsed time 120.7 4.5 parse time elapsed 4.0 .1 hard parse elapsed time 3.7 .1 hard parse (sharing criteria) elaps 0.7 .0 hard parse (bind mismatch) elapsed 0.7 .0 connection management call elapsed 0.1 .0 repeated bind elapsed time 0.1 .0 PL/SQL compilation elapsed time 0.0 .0 sequence load elapsed time 0.0 .0 DB time 2,708.9 background elapsed time 10.7 background cpu time 0.6 |
07:48:04~ 08:03:03时间段Time Model System Stats |
Statistic Time (s) % DB time ----------------------------------- -------------------- --------- sql execute elapsed time 2,706.4 100.0 DB CPU 894.2 33.0 PL/SQL execution elapsed time 120.5 4.5 parse time elapsed 8.2 .3 hard parse elapsed time 7.9 .3 hard parse (sharing criteria) elaps 1.0 .0 hard parse (bind mismatch) elapsed 1.0 .0 repeated bind elapsed time 0.2 .0 PL/SQL compilation elapsed time 0.2 .0 sequence load elapsed time 0.0 .0 DB time 2,706.8 background elapsed time 17.6 background cpu time 2.9 |
通过对比4个报告各个时间段中的hard parse elapsed time，发现产生的硬解析比前几次都少，几个没有，说明使用绑定变量后的重复的执行计划，得到了有效的利用。
9.9查看Latch Sleep breakdown
06:28:02~ 07:18:02时间段的Latch Sleep breakdown |
Get Spin Latch Name Requests Misses Sleeps Gets -------------------------- --------------- ------------ ----------- ----------- shared pool 25,440,163 5 5 0 space background task latc 3,866 3 3 0 call allocation 242,581 2 2 0 row cache objects 9,378,891 2 2 0 simulator lru latch 5,547 1 1 0 |
07:18:02 ~07:33:03时间段的Latch Sleep breakdown |
Get Spin Latch Name Requests Misses Sleeps Gets -------------------------- --------------- ------------ ----------- ----------- space background task latc 1,260 4 4 0
|
07:33:03~ 07:48:04时间段的Latch Sleep breakdown |
Get Spin Latch Name Requests Misses Sleeps Gets -------------------------- --------------- ------------ ----------- ----------- shared pool 14,593,478 1 1 0 space background task latc 1,177 1 1 0 |
07:48:04~ 08:03:03时间段的Latch Sleep breakdown |
Get Spin Latch Name Requests Misses Sleeps Gets -------------------------- --------------- ------------ ----------- ----------- space background task latc 1,153 4 4 0 shared pool 14,584,529 1 1 0 |
通过以上4个sp报告各个时间段的Latch Sleep breakdown的内容，发现cache bufferslru chain已经没有了，cache bufferschains的miss和sleep的次数都很少。
总结
通过在频繁查询的列上加索引和对重用次数的执行计划上添加绑定变量，数据库的性能得到了很大的提高。