请教10g rac性能问题

2011-01-04 03:36:27 364 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

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
------------------------------------------------------

...全文

Windows11下QGIS 3.34.4安装Geo-SAM插件全流程（附RTX3060 CUDA12.0配置技巧）本文详细介绍了在Windows 11系统中为QGIS 3.34.4安装和配置Geo-SAM插件的完整流程，特别针对RTX 3060显卡用户提供了CUDA 12.0与PyTorch环境的精准搭建方案。通过预编码与交互式分割两大核心步骤，该插件能显著提升遥感图像半自动标注的效率，降低硬件门槛，是地理信息处理领域融合AI技术的实用指南。阅读详情

yifanernei

基础和管理 17,379 成员 95,111 内容

+ 关注 + 加入社区

切换为时间正序

yifanernei 2011-01-19

打赏
举报

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

yifanernei 2011-01-07

打赏
举报

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

wffffc 2011-01-07

打赏
举报

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

wffffc 2011-01-07

打赏
举报

共享池 4096 这个为何要这么大？

yifanernei 2011-01-07

打赏
举报



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

yifanernei 2011-01-07

打赏
举报

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都不错，系统的负载也不算太大
难道真是因为内存有些吃紧造成的吗

Dave 2011-01-07

打赏
举报

做个AWR分析下吧。

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

yifanernei 2011-01-05

打赏
举报

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

yifanernei 2011-01-05

打赏
举报

数据库归档没有打开
当前一共9个重做日志文件，都在存储上，每个256M

另外exp对日志没什么影响的吧，不知道对不对
估计是晚上时应用在跑些后台操作

yifanernei 2011-01-05

打赏
举报

不好意思，看错了，调整到1600会减少物理读取9.3%

共享池 4096
缓冲区高速缓存 800
大型池 128
java池 128

PGA 1024
命中率 99.43%

yifanernei 2011-01-05

打赏
举报

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

wffffc 2011-01-05

打赏
举报

[Quote=引用 5 楼 yifanernei 的回复:]

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
[/Quote]
这段时间在干嘛？日志切换这么快？

Buffer Cache: 800M 800M Std Block Size: 8K
Shared Pool Size: 4,096M 4,096M Log Buffer: 14,340K
Buffer Cache小了，Shared Pool Size大了，你的内存怎么分配的？

AI轻创哥 2011-01-05

打赏
举报

[Quote=引用 5 楼 yifanernei 的回复:]
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 ……
[/Quote]
日志切换太频繁，估计要增加LGWn进程，以及调整日志文件大小，日志组分散放开。

ruihuahan 2011-01-05

打赏
举报

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% 《== 物理內存過低，建議擴充內存

yifanernei 2011-01-05

打赏
举报

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行

cuishengmin 2011-01-05

打赏
举报

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

yifanernei 2011-01-04

打赏
举报

buffer_cahce的用途好像和commit不commit关系不大的吧
存储的性能很不错，我觉得即使全从存储上读取也差不到哪儿去，原因是刷过buffer_cache后性能马上就好了，这时应该都是从存储上直接读取记录的，性能反而不差
而过几分钟后性能真的是差的太明显的
我晚上改改试试，有没有建议值？

操作系统上查看资源占用情况，cpu，磁盘，网络都不高
ps -e |grep oracle |wc -l大概80个
不过paging size 8192M使用了56%

gelyon 2011-01-04

打赏
举报

一是你缓冲区buffer较小，而是你不良程式照成buffer占用太大
比如：你200G的数据，大量数据DML操作就导致buffer_cache使用较大，
而你如果不commit就会照成buffer空间得不到及时释放
之所以你执行了 alter system flush buffer_cache;后性能正常，正好说明这点

因此，你最好看看哪个过程或者哪个批次会照成大量数据的DML操作，你可以分批进行commit
这样性能就比较好了
我在做客户结算的时候经常遇到，所以你试试

请教10g rac性能问题

相关推荐