关于数据库调优node1 (欢迎各位看看~~~~~)

biti_rainy · 发表于 2003-5-9 17:17

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

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

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

默认应该是 2000

Fenng · 发表于 2003-5-9 18:21

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

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

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

phonee · 发表于 2003-5-9 18:52

hi fenng

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

parrotao · 发表于 2003-5-9 21:28

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;
的存储过程好象也很消耗系统资源

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

chao_ping · 发表于 2003-5-9 22:45

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率非常高.这一点一定要弄清楚,修正.数据库都是在白干活.

phonee · 发表于 2003-5-9 23:00

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

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

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

biti_rainy · 发表于 2003-5-10 12:39

这个是太夸张了！

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

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

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

biti_rainy · 发表于 2003-5-10 13:03

关于 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 优化认识不足，
系统开发之前的设计人员也没有这个意识
没有评估系统的瓶颈，准确的说是没有经验或者没有吃过这个亏
所以任由开发人员自行处理代码