请教10g rac性能问题

Question

AIX6 8G内存 10.2.0.4 三个节点
跑了多套应用软件，一共200G数据量
当前性能非常差，但是执行alter system flush buffer_cache;
之后，性能正常，几分钟之后又变得非常差
扩过内存，调整过cache大小，效果都不明显
救解------------------------------------------------------------
               Begin         End   
Buffer Cache:     800M        800M      Std Block Size: 8K 
Shared Pool Size: 4,096M    4,096M      Log Buffer: 14,340K 
-------------------------------------------
Buffer access - local cache %: 94.09 
Buffer access - remote cache %: 2.93 
Buffer access - disk %: 2.97 
-------------------------------------------
Avg message sent queue time (ms): 0.1 
Avg message sent queue time on ksxp (ms): 0.2 
Avg message received queue time (ms): 0.0 
Avg GCS message process time (ms): 0.0 
Avg GES message process time (ms): 0.0 
% of direct sent messages: 14.91 
% of indirect sent messages: 84.27 
% of flow controlled messages: 0.83 
------------------------------------------------------

Answer 1

一是你缓冲区buffer较小， 而是你不良程式照成buffer占用太大
比如：你200G的数据，大量数据DML操作就导致buffer_cache使用较大，
而你如果不commit就会照成buffer空间得不到及时释放
之所以你执行了 alter system flush buffer_cache;后性能正常，正好说明这点因此，你最好看看哪个过程或者哪个批次会照成大量数据的DML操作，你可以分批进行commit
这样性能就比较好了
我在做客户结算的时候经常遇到，所以你试试

Answer 2

buffer_cahce的用途好像和commit不commit关系不大的吧
存储的性能很不错，我觉得即使全从存储上读取也差不到哪儿去，原因是刷过buffer_cache后性能马上就好了，这时应该都是从存储上直接读取记录的，性能反而不差
而过几分钟后性能真的是差的太明显的
我晚上改改试试，有没有建议值？操作系统上查看资源占用情况，cpu，磁盘，网络都不高
ps -e |grep oracle |wc -l大概80个
不过paging size 8192M使用了56%

Answer 3

自己顶一下
记得在书上看到过
Buffer access - remote cache %: 2.93 
% of indirect sent messages: 84.27 
这些值可能是有问题的
remote cache是由于热块造成的，但现在的应用不具有可改性
indirect sent messages是消息传递出现问题了，当时看书时就没明白这点是什么意思

Answer 4

变慢的时候alert log 里面没有什么异常吗？

Answer 5

ALTER SYSTEM: Flushing buffer cache
Tue Jan 04 21:00:59 BEIST 2011
Thread 1 advanced to log sequence 678 (LGWR switch)
  Current log# 3 seq# 678 mem# 0: /dev/rdb_Redo1_3
Wed Jan 05 02:23:41 BEIST 2011
Thread 1 advanced to log sequence 679 (LGWR switch)
  Current log# 1 seq# 679 mem# 0: /dev/rdb_Redo1_1
Wed Jan 05 02:24:46 BEIST 2011
Thread 1 advanced to log sequence 680 (LGWR switch)
  Current log# 2 seq# 680 mem# 0: /dev/rdb_Redo1_2
Wed Jan 05 02:26:25 BEIST 2011
Thread 1 advanced to log sequence 681 (LGWR switch)
  Current log# 3 seq# 681 mem# 0: /dev/rdb_Redo1_3
Wed Jan 05 08:00:46 BEIST 2011
Thread 1 advanced to log sequence 682 (LGWR switch)
  Current log# 1 seq# 682 mem# 0: /dev/rdb_Redo1_1
Wed Jan 05 10:10:46 BEIST 2011
ALTER SYSTEM: Flushing buffer cache就只有类似的信息，文件也不大，不到4K行

Answer 6

Buffer Cache: 800M 800M Std Block Size: 8K 《== buffer cache 太小  
Shared Pool Size: 4,096M 4,096M Log Buffer: 14,340K  
不过paging size 8192M使用了56% 《== 物理內存過低，建議擴充內存

Answer 7

日志切换太频繁，估计要增加LGWn进程，以及调整日志文件大小，日志组分散放开。

Answer 8

这段时间在干嘛？日志切换这么快？Buffer Cache: 800M 800M Std Block Size: 8K 
Shared Pool Size: 4,096M 4,096M Log Buffer: 14,340K 
Buffer Cache小了，Shared Pool Size大了，你的内存怎么分配的？

Answer 9

日志切换快可能是因为晚上在exp数据的原因
已经准备加内存了，只是觉得内存原因不能使性能差成这样啊
内存是手动分配的，800M，4096M
通过企业管理器中的内存建议得到的这两个值
如果把buffer_cache增加到1600M可减少物理读取1.5%，800－1600之间变化都不大
可是内存有点吃紧才没有增加

Answer 10

不好意思，看错了，调整到1600会减少物理读取9.3%共享池 4096
缓冲区高速缓存 800
大型池   128
java池 128PGA   1024
命中率  99.43%

Answer 11

数据库归档没有打开
当前一共9个重做日志文件，都在存储上，每个256M另外exp对日志没什么影响的吧，不知道对不对
估计是晚上时应用在跑些后台操作

Answer 12

共享池 4096
缓冲区高速缓存 800
觉得这两个对掉一下会好点，或者让oracle自动分配内存吧。

Answer 13

这两个值都是根据oracle的推荐值设置的
总觉得自动分配内存有点不可控的感觉

Answer 14

做个AWR分析下吧。 1. 生产库还是建议设成归档模式。
2. SGA和 PGA 自动分配就好了。 在AWR报告里会有这2个参数的建议值，可以用建议值，在看看影响怎么样。
3. 分析下相关SQL语句。 看下占用资源较多的几个SQL还有优化的余地没有。 
4. 看下DB的等待事件. 

Answer 15

1. 是否打开归档对性能没有很大影响吧，这个属于历史问题，不好处理啊
2. 当前基本就是按建议值设置的
3. 资源占用高的sql几乎都是在查询系统表，像是user_tab_cols表了，还有exp.exe的一些调用（exp也的确非常的慢，flush buffer_cache后很快，几分钟后就又变慢了）
4. Top 5 Timed Events
--------------------------------------------------------------
Event        Waits   Time(s)   Avg Wait(ms) % Total Call Time Wait Class
gc buffer busy           4,629,634 10,516 2 40.1 Cluster
CPU time                          4,601 17.5
gc cr multi block request   2,476,064 2,865 1 10.9 Cluster
db file sequential read   494,246 1,761 4 6.7 User I/O
latch: library cache   14,828         1,253 84 4.8 Concurrency－－－－－－－－－－－－－－－－－－－－－－－－－－我在想，和没使用ASM而直接使用裸设备文件有关系没有
其它资源应该都没有问题啊，cpu、网络、存储IO都不错，系统的负载也不算太大
难道真是因为内存有些吃紧造成的吗

Answer 16

Top 5 Timed Events 
-------------------------------------------------------------- 
Event    ｜Waits ｜ Time(s)   ｜Avg Wait(ms) ｜% Total Call Time｜Wait Class
gc buffer busy            4,629,634  10,516    2    40.1  Cluster
CPU time                              4,601         17.5 
gc cr multi block request 2,476,064   2,865     1   10.9  Cluster
db file sequential read     494,246   1,761     4    6.7  User I/O
latch: library cache         14,828   1,253    84    4.8  Concurrency

Answer 17

扩了内存，把buffer_cache增加到2G时，情况好转了，只是不知道会不会是把问题出现的时机推迟了
谢谢各位了