刚才我给建议的时候没有看你的  statspack 报告呢  

至于 db_block_lru_latches    ,我并不确信 16  /  48  到底哪个好


如果存在你所说的这样的大量session等待的问题
那你可以尝试 调整 _spin_count  减小

默认应该是 2000

性能没有问题为什么还要调整?

如果是我，我是不会去作调整的

此外，如果要调整的话，硬件有变化，一般的你的应用怕是也要做不小的改动

hi fenng

确实是这样，目前数据库的一些命中率都还好
性能也能接受
我们一致也考虑尽量不做调整，问题在于这种状态持续4个月了！
只不过通信行业每月出帐后缴费高峰期业务量还是比较大的
所以相对来说CPU占用很高、而5G--6G的内存在FREE
而且业务始终是在不断增长，系统负荷也在逐步增大
所以还是要调整的 ，应用没有什么要改动的

Db buffer size 可以增加到4G-5G

还可以适当的调整一下SQL
确认
SELECT ACCOUNT_ID,CUSTOMER_ID,INHERIT_ID   FROM BB_SERVICE_RELAT
ION_T  WHERE USER_ID = :b1  AND IF_VALID = 1
是否用了index


SELECT NVL(SUM(FEE1 + FEE2  + FEE3  + FEE4  + FEE11  + FEE12  +
FEE13  + FEE14 ),0)   FROM BF_GATHER_FEE_T A,BF_FEE_KIND_T B  WH
ERE A.USER_ID = :b1  AND (A.FEE_DATE = :b2  OR A.FEE_DATE = :b3
) AND A.CITY_CODE = :b4  AND A.SERVICE_KIND = :b5  AND A.SPECIAL
_BILL != 1  AND B.SERVICE_KIND = :b5  AND A.FEE_KIND = B.FEE_ID
是否有问题

begin customer_service_main_proc(:trans_buffer,:buffer_len,:last
_flag,:exclusive_id,:ret_code);end;
的存储过程好象也很消耗系统资源

先看看这些吧可能是由某个程序引起的.

1.log_buffer不必增加了.增加了没有什么好处.

你们基本上没有log_buffer_space wait event.

2.share pool 也不用增加了.

你们当前poor 的使用率还没有60%

再增加你们的大小,也是没有用处的. 只要有literal sql进来,再大的share pool也不会提高命中率.

3.16G的物理内存,还是用的raw device, data buffer可以大大增加.

初步估计可以增加到8GB左右.

4.
你们的很多SQL的资源消耗很高. 调整SQL得到的性能提升是最大的. 调整Index,或者SQL的实现方法.让每个Session干活的时间短, 每个CPU在固定的CPU时间里面, 可以服务更多的session, 这样, run queue里面的等待队列就会降低.


5. 非常关键的一点,

你们的rollback率非常高.这一点一定要弄清楚,修正.数据库都是在白干活.

chao_ping 你说的3，今晚可能来不及修正了，
因为操作系统参数没有调，所以当前的内存分配已经出现no enough space
只好下次调整了

4、其实index \sql 调整优化过几次，但涉及集成商、软件开发商，同时，许多表确实很大，
结构本身就比较负责，所以这个确实是关键，但却是最不利索的。

5、ROLLBACK 率非常高 ，并非表示数据库在白干活啊？
本身批量insert update  的操作比较多、数据量比较大，联机事务也很多
rollback 率高也正常啊，具体说说如何？

这个是太夸张了！

检查你们的应用，肯定存在什么问题
要知道 rollback 是代价昂贵的操作！

回退率达到这么高，检查是哪里的问题，业务逻辑的出错还是应用程序的问题……

rollback 次数可以比较多，但是比率却通常应该不会高过10%的，越小越好
420936 个事务里面有  230841 个事务失败，必定有问题！！！！！！！

关于 shared_pool_size
实际上来讲

假如不存在 literal sql 的问题
你觉得你的所有的sql 放在一起有多大？解析后所有的占用的空间有多大？
你的所有的sql的文本有没有 20M ？

假如存在 literal sql ,并且动态生成大量的sql,没有使用 bind var
那增大内存能缓解问题么？ 这个值得斟酌

可能命中率一样不高但带来 很大的CPU 的代价

在一些系统的 案例中，shared_pool_size 在接近 1G 或者超过 1G 的时候带来CPU 的严重的负担并且系统出现严重问题，实际上，一个32G RAM ,SGA > 25G  的系统中， shared_pool_size 也没有达到1G ,并且系统仍然存在 literal  sql 的问题

所以 shared_pool_size 并不能跟 RAM 成比例的增长
当然具体 问题具体分析
有些系统本身确实需要很大的 内存，那时另外一回事

造成这种问题的根源在于 程序员 对 bind var 和 sql 优化认识不足，
系统开发之前 的设计人员也没有这个意识
没有评估系统的瓶颈，准确的说是 没有经验或者没有吃过这个亏
所以任由开发人员自行处理代码

从TOP EVENTS来看，全表扫描过多了，索引扫描争用也过多，应该增加DB_BLOCK_BUFFER。
其实重要还是应该调整你的应用。

QUOTE:

---

最初由 idler 发布
从TOP EVENTS来看，全表扫描过多了，索引扫描争用也过多，应该增加DB_BLOCK_BUFFER。
其实重要还是应该调整你的应用。

---

要电信去调整一个应用谈何容易啊，涉及面太广，有些应用还是不断的扩充功能形成的，早期的软件开发商也找不到了，去调整恐怕还不如重新搞一个来得简单。