请教一个数据库性能问题！

lizhong627ad

环境oracle 10.2.0.4.0 4节点rac
现象
入库程序显示入库速度奇慢。做了awr请大家帮忙定位一下问题所在 非常感谢

感觉这2个指标异常的大

Avg global cache current block pin time (ms):

1,353.6

Avg global cache current block flush time (ms):

95,830.2

但是苦于找不到解决办法！

awr   20120427-1带索引插入.html (461.86 KB, 下载次数: 710)

2012-5-4 23:44 上传

点击文件名下载附件

[ 本帖最后由 lizhong627ad 于 2012-5-4 23:44 编辑 ]

xteitxu

最终的问题是用单点做入库，效率得以提高了是吧？

ora-hansey

学习了，service_name入库的中途有过断开么？

lizhong627ad

这个问题最终解决了，现场的工程师发现，入库程序配置的tns是用的rac的service name进行连接的，这样入库程序同时连接在rac的多个节点上，将tns中的servicename改成sid  入库性能提高了数十倍

不了峰

在RAC 中默认会将 并行操作 传播到其他节点上 运行， 所以并不能保证 这个索引的重建工作是纯本地的.

如何只让其并行只在本地实例上创建 ？

是不是只要把remote_listener 参数设为空就OK了

Maclean Liu(刘相兵

ALTER INDEX L xxxxxx04_lakesii REBUILD PARTITION P06_12 parallel(degree 6)

这是从AWR 中找到的 快照时间内 重建INDEX 的操作， 它使用 parallel degree 6 ， 在RAC 中默认会将 并行操作 传播到其他节点上 运行， 所以并不能保证 这个索引的重建工作是纯本地的。

lizhong627ad

补充 redo的问题我再去跟现场的工程师了解一下!

lizhong627ad

这些都是业务需要的事情。每秒的大表扫描是一个业务系统在生成数据库中某天的报告,我刚看了一下没有online 重建索引呀？，另外您看internal connection是不是流量有些异常的大?另外数据加载和维护索引都在一个节点上做的！非常感谢！

[ 本帖最后由 lizhong627ad 于 2012-5-7 21:35 编辑 ]

Maclean Liu(刘相兵

抱歉 周末比较忙 没有回复 ，  就这个AWR 报告看：


10.2.0.4 on

Elapsed:                 60.10 (mins)                  
DB Time:                 209.87 (mins)                  

AAS=3  有一定的负载

Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
CPU time                 6,079                 48.3         
db file sequential read        2,816,902        1,812        1        14.4        User I/O
gc cr disk read        2,206,028        999        0        7.9        Cluster
gc cr block 3-way        1,070,956        780        1        6.2        Cluster
gc cr block 2-way        1,307,860        689        1        5.5        Cluster

Top 5中 cluster + User I/O 占了大头

db file sequential read avg wait =  1ms 处于正常水平

Avg global cache cr block flush time (ms):        0.8
Avg global cache current block pin time (ms):        1,353.6
Avg global cache current block send time (ms):        0.1
Global cache log flushes for current blocks served %:        1.9
Avg global cache current block flush time (ms):        95,830.2


current block的 平均redo flush time 很高 =95,830.2 ms

wait class 中 cluster wait占了大头：

Wait Class        Waits        %Time -outs        Total Wait Time (s)        Avg wait (ms)        Waits /txn
Cluster         6,312,252         0.07         3,768         1         361.75
User I/O         3,241,096         0.00         3,019         1         185.75
Other         14,225,006         85.09         304         0         815.23


log file sync         16,046         0.00         29         2         0.92
log file parallel write         33,034         0.00         27         1         1.89


log file parallel write 的avg wait =27ms 说明 日志文件写的性能存在瓶颈

gcs log flush sync         38,652         18.71         26         1         2.22

gcs log flush sync 的avg wait=26ms

SQL ordered by Cluster Wait Time

Cluster Wait Time (s)        CWT % of Elapsd Time        Elapsed Time(s)        CPU Time(s)        Executions        SQL Id        SQL Module        SQL Text
239.99         92.98         258.11         16.27         21,728         9qgtwh66xg6nz                   update seg$ set type#=:4, bloc...
8.97         58.84         15.25         1.58         496         64wq3fa5a77sm                   insert into seg$ (file#, block...
2.07         75.56         2.74         1.74         1,570         2ym6hhaq30r73                   select type#, blocks, extents,...



update seg$ set type#=:4, blocks=:5, extents=:6, minexts=:7, maxexts=:8, extsize=:9, extpct=:10, user#=:11, iniexts=:12, lists=decode(:13, 65535, NULL, :13), groups=decode(:14, 65535, NULL, :14), cachehint=:15, hwmincr=:16, spare1=DECODE(:17, 0, NULL, :17), scanhint=:18 where ts#=:1 and file#=:2 and block#=:3

update seg$ 语句 耗费大量时间在 cluster wait上


引起update seg$的 可能是 大的索引重建        ALTER INDEX L xxxxxx04_lakesii REBUILD PARTITION P06_12 parallel(degree 6)


配合statistics信息看 table scans (long tables)         9,005         2.50         0.52
存在 每秒 2.5次的 大表扫描

为什么要 非online的重建 index partition ? 是否因为index 失效 导致了 table scan?

尝试不要cross instance的 parallel rebuild index partition 减少 update seg$造成的cluster wait。

同时 建议你确认为什么 log file 日志文件写的性能变得很差。

Maclean Liu(刘相兵

SQL> select systimestamp from dual;

SYSTIMESTAMP
---------------------------------------------------------------------------
04-MAY-12 11.54.53.797000 PM +08:00

夜深了 ， 该问题 延迟到 明天回复

Maclean Liu(刘相兵

请 直接上传 AWR 附件