前段时间跟了一个很有意思的优化项目
解决严重的性能问题只需要干一件事情：重启数据库，而且不会复发

Load Profile

	Per Second	Per Transaction	Per Exec	Per Call
DB Time(s):	31.1	4.9	0.24	0.09
DB CPU(s):	3.3	0.5	0.03	0.01
Redo size:	19,867.7	3,120.1
Logical reads:	8,721.6	1,369.7
Block changes:	108.2	17.0
Physical reads:	451.1	70.8
Physical writes:	5.8	0.9
User calls:	345.5	54.3
Parses:	79.3	12.5
Hard parses:	0.5	0.1
W/A MB processed:	77,431.2	12,159.9
Logons:	3.1	0.5
Executes:	128.1	20.1
Rollbacks:	2.7	0.4
Transactions:	6.4

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:	100.00	Redo NoWait %:	100.00
Buffer Hit %:	99.87	In-memory Sort %:	100.00
Library Hit %:	99.57	Soft Parse %:	99.34
Execute to Parse %:	38.10	Latch Hit %:	99.71
Parse CPU to Parse Elapsd %:	0.00	% Non-Parse CPU:	32.80

Shared Pool Statistics

	Begin	End
Memory Usage %:	86.58	85.75
% SQL with executions>1:	94.44	94.08
% Memory for SQL w/exec>1:	91.11	90.69

Top 5 Timed Foreground Events

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
library cache: mutex X	225,287,761	44,877	0	40.14	Concurrency
latch: shared pool	9,940	37,235	3746	33.30	Concurrency
latch free	3,031	11,828	3902	10.58	Other
DB CPU		11,772		10.53
enq: TX - row lock contention	260	2,190	8425	1.96	Application

系统负载极轻，但是CPU 100%,系统遭遇到了严重的latch & mutex 争用
硬解析也极少，对于一个12C的系统，完全在承受的范围内
cursor_sharing在系统出现性能问题后，已经在Oracle的建议下修改为force，但是基本没有好转

做了个ASH的切片，确认持有library cache: mutex X 的会话，在等待latch: shared pool，而持有SP latch的会话，只是在on cpu,说明SP latch是主因。

先开始怀疑是BUG，毕竟硬解析很少，后来没找到相关的BUG
检查了下SP latch的数目，竟然才1个，对于一个12C的系统，应该有3个SP latch才对，和客户交流，原来他们系统本来只有4C，后来出现了严重的性能问题后，动态调了8C过来。

虽然CPU_COUNT从10g开始，可以随动态调整而增加，但是SP latch的数目，是无法动态增加的，随着本来系统就有的硬解析问题的积累，导致共享池严重碎片化，最终积累成了严重的性能问题。

重启了数据库后，困扰客户几个月的性能问题就这样解决了

ITPub博客

通过重启数据库，完成了一次优化

最新文章