北京一家规模不大的医院,使用了IBM的P550小型机,在业务高峰期性能急剧下降.
1.在业务高峰期，系统无法登录 。
2.性能下降很明显，部分业务无法正常开展。
2.性能下降很明显，部分业务无法正常开展。
3.在alertSID.log文件中,出现了连接超时的错误,医院已经加大procesess参数,未见明显好转.
4.在下午等非高峰时段,性能也不理想.
下面时采集的awr报告台头:
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst num Release RAC Host
ORCL 1247897117 orcl 1 10.2.0.4.0 NO HISDB01
Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 13055 22-Nov-11 08:00:03 212 99.1
End Snap: 13056 22-Nov-11 09:00:03 245 101.5
Elapsed: 59.99 (mins)
DB Time: 2,377.04 (mins)
从awr来看db time是间隔时间的近40倍，性能确实无法接受了。
3.cpu占用率不高。
分析：
1.load profile部分:
Instance Efficiency Percentages (Target 100%)
1.load profile部分:
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00 Redo NoWait %: 99.99
Buffer Hit %: 97.75 In-memory Sort %: 100.00
Library Hit %: 98.62 Soft Parse %: 97.15
Execute to Parse %: 69.23 Latch Hit %: 99.73
Parse CPU to Parse Elapsd %: 0.68 % Non-Parse CPU: 95.96
主要的问题在于Parse CPU to Parse Elapsd只有0.68%，说明大多数的时间花费在了sql的解析上了。
2.Top 5 Events部分：
Top 5 Timed Events
Buffer Hit %: 97.75 In-memory Sort %: 100.00
Library Hit %: 98.62 Soft Parse %: 97.15
Execute to Parse %: 69.23 Latch Hit %: 99.73
Parse CPU to Parse Elapsd %: 0.68 % Non-Parse CPU: 95.96
主要的问题在于Parse CPU to Parse Elapsd只有0.68%，说明大多数的时间花费在了sql的解析上了。
2.Top 5 Events部分：
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
latch: library cache 499,350 139,280 279 97.7 Concurrency
latch free 282,082 82,252 292 57.7 Other
latch: shared pool 136,826 33,818 247 23.7 Concurrency
latch: session allocation 37,423 10,858 290 7.6 Other
db file sequential read 289,996 4,273 15 3.0 User I/O
再次映证了load profile部分，相关的latch非常严重；问题就出在共享池上。
3.看相关的参数,发现了几个参数经过了一些调整，经询问客户，原来是他们先前已经请过Oracle维保的工程师做了一些调整：
session_cached_cursors 1000
open_cursors 3000
session_cached_cursors控制pga/uga中缓存的cursor数量，sql可以不用到共享池进行parse，可减轻共享池的压力;但1000这个值相对ZLHIS太高了；
Open_cursors控制session同时打开的cursors数;这位工程师也认为问题是出在sql parse上。但不幸的是，调整基本没有效果。
4.os相关的分析，通过vmstat发现有一定的swap in /out的发生，服务器只有16g的内存，而sga的设置达到13g；这样os的占用与pga部分很有可能使用到swap,
sga特别是共享池被swap到交换分区，对性能是非常大的损失。同时，查看到了一下aix中vmo的设置，发现相关的设置也有问题，将大量的内存作为文件系统
缓存;需要做一些调整。 一般的数据库服务器，文件型内存可以使用较少的空间，因为文件型内存并不主动释放，可能造成内存资源的短缺及Paging Space使用率过高，所以数据库服务器上maxclient、maxperm、minperm的值不宜过大，典型值如下：
maxclient% = 8
maxperm% = 12
minperm% = 5
如何更改这三个参数呢， 在AIX5.3上，可以使用 vmo 命令，此命令设置或显示所有虚拟内存管理器调整参数的当前值或下一个引导值。还可以用此命令进行永久性更改，或将更改推迟到下一次重新引导之后生效。此命令是设置参数还是显示参数，要由所带标志来决定。带 -o 标志的话，两个操作都执行。同时需要注意AIX5.3与AIX6.1的差异.在AIX6下,部分VMO参数变成了固定参数,需要加F开关才能修改.
latch: library cache 499,350 139,280 279 97.7 Concurrency
latch free 282,082 82,252 292 57.7 Other
latch: shared pool 136,826 33,818 247 23.7 Concurrency
latch: session allocation 37,423 10,858 290 7.6 Other
db file sequential read 289,996 4,273 15 3.0 User I/O
再次映证了load profile部分，相关的latch非常严重；问题就出在共享池上。
3.看相关的参数,发现了几个参数经过了一些调整，经询问客户，原来是他们先前已经请过Oracle维保的工程师做了一些调整：
session_cached_cursors 1000
open_cursors 3000
session_cached_cursors控制pga/uga中缓存的cursor数量，sql可以不用到共享池进行parse，可减轻共享池的压力;但1000这个值相对ZLHIS太高了；
Open_cursors控制session同时打开的cursors数;这位工程师也认为问题是出在sql parse上。但不幸的是，调整基本没有效果。
4.os相关的分析，通过vmstat发现有一定的swap in /out的发生，服务器只有16g的内存，而sga的设置达到13g；这样os的占用与pga部分很有可能使用到swap,
sga特别是共享池被swap到交换分区，对性能是非常大的损失。同时，查看到了一下aix中vmo的设置，发现相关的设置也有问题，将大量的内存作为文件系统
缓存;需要做一些调整。 一般的数据库服务器，文件型内存可以使用较少的空间，因为文件型内存并不主动释放，可能造成内存资源的短缺及Paging Space使用率过高，所以数据库服务器上maxclient、maxperm、minperm的值不宜过大，典型值如下：
maxclient% = 8
maxperm% = 12
minperm% = 5
如何更改这三个参数呢， 在AIX5.3上，可以使用 vmo 命令，此命令设置或显示所有虚拟内存管理器调整参数的当前值或下一个引导值。还可以用此命令进行永久性更改，或将更改推迟到下一次重新引导之后生效。此命令是设置参数还是显示参数，要由所带标志来决定。带 -o 标志的话，两个操作都执行。同时需要注意AIX5.3与AIX6.1的差异.在AIX6下,部分VMO参数变成了固定参数,需要加F开关才能修改.
5.通过查询v$sga_resize_ops视图在高峰期间，也有resize的情况；这就需要关闭sga自动管理。
调整的过程：
--调整vmo参数
vmo -p -o minperm%=3
vmo -p -o maxperm%=90
vmo -p -o maxclient%=90
vmo -p -o strict_maxperm=0
vmo -p -o strict_maxclient=1
vmo -p -o lru_file_repage=0
vmo -p -o page_steal_method=1
vmo -p -o minperm%=3
vmo -p -o maxperm%=90
vmo -p -o maxclient%=90
vmo -p -o strict_maxperm=0
vmo -p -o strict_maxclient=1
vmo -p -o lru_file_repage=0
vmo -p -o page_steal_method=1
--参数
alter system set processes=1000 scope=spfile;
alter system set sessions=1200 scope=spfile;
alter system set open_cursors=300 scope=spfile;
alter system set session_cached_cursors=100 scope=spfile;
alter system set pga_aggregate_target=4g scope=spfile;
alter system set shared_pool_size=4g scope=spfile;
alter system set db_cache_size=3g scope=spfile;
alter system set sga_max_size=8g scope=spfile;
alter system set sga_target=0 scope=spfile;
alter system set large_pool_size=300m scope=spfile;
alter system set java_pool_size=100m scope=spfile;
alter system set log_buffer=16777216 scope=spfile;
alter system set "_library_cache_advice"=false scope=spfile;
alter system set cursor_sharing=exact scope=spfile;
alter system set processes=1000 scope=spfile;
alter system set sessions=1200 scope=spfile;
alter system set open_cursors=300 scope=spfile;
alter system set session_cached_cursors=100 scope=spfile;
alter system set pga_aggregate_target=4g scope=spfile;
alter system set shared_pool_size=4g scope=spfile;
alter system set db_cache_size=3g scope=spfile;
alter system set sga_max_size=8g scope=spfile;
alter system set sga_target=0 scope=spfile;
alter system set large_pool_size=300m scope=spfile;
alter system set java_pool_size=100m scope=spfile;
alter system set log_buffer=16777216 scope=spfile;
alter system set "_library_cache_advice"=false scope=spfile;
alter system set cursor_sharing=exact scope=spfile;
--重启db生效。
通过上述调整，性能恢复正常,下面调整后awr报告的load profile:
| Begin Snap: | 13424 | 07-12月-11 10:00:13 | 297 | 98.2 |
| End Snap: | 13425 | 07-12月-11 11:00:59 | 297 | 99.9 |
| Elapsed: | 60.77 (mins) | |||
| DB Time: | 175.39 (mins |
可以看到,dbtime有大幅的下降.这个案例说明在Oracle中,共享池是最重要的内存区域,重要性超过了SGA中的其他区域,一量共享池出现问题,对性质的影响将是致命的,在给Oracle配置内存时,首先应该考虑满足共享池的需要,同时要注意共享池"抖动"对性能的影响,也说明部分Oracle自动管理特性不是包打天下的良方.
