帮忙看一下这个statspack报告

显示全部楼层 · 2005-10-30 17:05:33

如题

千问 · 2005-10-30 17:05:33

1. 采集时间短了点，30分钟到60分钟比较好
2. 从TOP5 wait event你就能看出系统的瓶颈是什么了.

% Total
Event
WaitsTime (s) Ela Time
db file scattered read
14,939 5
4.27
可能的原因:全表扫描比较多，SQL语句没有使用索引
再看这些SQL语句:
第一组:
select gou.group_uuid, sg.sgroup_name, sg.sgroup_uuid, od.organi
ze_uuid, od.organize_name from upc_group_own_users gou, upc_user
uu, upc_group ug, upc_single_group sg, upc_organize_domain od w
here uu.user_login_name='2304119' and gou.user_uuid = uu.user_uu
id and ug.group_uuid = gou.group_uuid and sg.sgroup_uuid = ug.sg
select gou.group_uuid, sg.sgroup_name, sg.sgroup_uuid, od.organi
ze_uuid, od.organize_name from upc_group_own_users gou, upc_user
uu, upc_group ug, upc_single_group sg, upc_organize_domain od w
here uu.user_login_name='2304918' and gou.user_uuid = uu.user_uu
id and ug.group_uuid = gou.group_uuid and sg.sgroup_uuid = ug.sg
第二组:
select gou.group_uuid, sg.sgroup_name, sg.sgroup_uuid, od.organi
ze_uuid, od.organize_name from upc_group_own_users gou, upc_user
uu, upc_group ug, upc_single_group sg, upc_organize_domain od w
here uu.user_login_name='2204004' and gou.user_uuid = uu.user_uu
id and ug.group_uuid = gou.group_uuid and sg.sgroup_uuid = ug.sg
select gou.group_uuid, sg.sgroup_name, sg.sgroup_uuid, od.organi
ze_uuid, od.organize_name from upc_group_own_users gou, upc_user
uu, upc_group ug, upc_single_group sg, upc_organize_domain od w
here uu.user_login_name='2104029' and gou.user_uuid = uu.user_uu
id and ug.group_uuid = gou.group_uuid and sg.sgroup_uuid = ug.sg
...
很明显，语句没有使用绑定变量 ...
先看看上面这个语句的查询计划再说 ?

另外，有些初始化参数也设置的不是很合理:
JAVA_POOL_SIZE, LARGE_POOL_SIZE 都太大

最初由 phigon 发布
[B]如题 [/B]

千问 · 2005-10-30 17:05:33

谢谢！
这个库确实还有很多地方需要建立索引。
另cpu time 等待事件表示什么意思？

千问 · 2005-10-30 17:05:33

物理读次数比较多：
Physical reads:
66.28
应加大db_cache_size的大小
以下语句的物理读次数最高，建议调整该语句：
SELECT vo.DeclareDataId as DeclareDataId, vo.TaxpayerId as Taxpa
yerId, vo.TaxpayerVer as TaxpayerVer, vo.DeclareDate as DeclareD
ate, vo.TaxTotal as TaxTotal, vo.IsRuralEnt as IsRuralEnt, vo.Ac
countFlag as AccountFlag, vo.FatherPointer as FatherPointer, vo.
NegativeFlag as NegativeFlag, vo.TaxFileId as TaxFileId, vo.Oper

从报告中可以看出系统等待最严重的五个事件分别如下：
CPU time
10489.85
db file scattered read
14,939 5 4.27
db file parallel write
324 3 2.37
SQL*Net more data to client
16,245 1 1.04
control file parallel write

对于db file sequential read等待事件，一般问题出现在读索引上，建议将数据表空间和索引表空间分开存储在不同的卷下，或者将表空间数据文件条带化分布在不同的磁盘下，以提高磁盘的I/O性能。
对于db file scattered read等待事件，建议程序中尽量避免使用全表扫描的语句，或者可以增大db_file_multiblock_read_count的值，提高全表扫描一次读取数据块的速度，减少磁盘I/O。
对于db file parallel write等待事件，说明DBWR进程正等待把缓冲区的内容并行写入数据文件中去,等待将一直持续到所有的I/O全部完成。建议增大初始化参数中的db_writer_processes的值，可以增大到4。

千问 · 2005-10-30 17:05:33

1、Rollback per transaction %:6.45 这个值偏高，回滚的代价非常昂贵的
2、 Memory Usage %: 93.84 94.90正在使用的共享池的百分率太高

千问 · 2005-10-30 17:05:33

最初由 chenfeng 发布
[B]
对于db file parallel write等待事件，说明DBWR进程正等待把缓冲区的内容并行写入数据文件中去,等待将一直持续到所有的I/O全部完成。建议增大初始化参数中的db_writer_processes的值，可以增大到4。 [/B]
这个一条有疑问。

千问 · 2005-10-30 17:05:33

最初由 xxscfh 发布
[B]1、Rollback per transaction %:6.45 这个值偏高，回滚的代价非常昂贵的
2、 Memory Usage %: 93.84 94.90正在使用的共享池的百分率太高 [/B]
1、我控制不了应用程序的。
2、不是越高越好吗？可以给个理由吗？

千问 · 2005-10-30 17:05:33

控制不了应用程序，那至少可以修改初始化参数文件吧，另外，
你说的越高越好，指的是哪个参数？

千问 · 2005-10-30 17:05:33

最初由 chenfeng 发布
[B]控制不了应用程序，那至少可以修改初始化参数文件吧，另外，
你说的越高越好，指的是哪个参数？ [/B]
Memory Usage %:

千问 · 2005-10-30 17:05:33

Memory Usage %: 的使用率一般在75-90％，如果值太低，说明浪费了Memory；太高，说明留给系统的可用memory很少，系统的调节性就差了，可以说，共享池小了