再次问：为什么加大databuffer后hit ratio下降？

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

系统什么都没有修改，就是加大了data buffer，hit ratio 从95%下降到75％，老板一定让我给我说法，我实在想不出，大家帮我想想，要不我就惨了！
我也知道，不应该看hit ratio等等，要看等待事件
我也知道，我现在这个系统存在大量的table scan （还没来得及调整），可是就算有fts，也不应该hit ratio 下降啊？
到底为什么下降呢？

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

大家帮忙看看吧，出个主意

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

你的计算公式是什么？可能因为你的cache大了，默认小表的threshold没变，这样更多的fts可能把需要的索引块从cache里排出，你可以试试改_small_table_threshold小一点，不过根本的解决方法还是避免过多的fts

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

计算的公式很简单，也就是最传统的那种
SELECT 1 - phy.value/(con.value+block.value) "CACHE HIT RATIO"
FROM v$sysstat con, v$sysstat block, v$sysstat phy
WHERE con.name = 'consistent gets'
ANDblock.name= 'db block gets'
AND phy.name = 'physical reads';
这个虽然不是最准确的，但大致也差不太多。
现在的问题不是如何解决这个问题，是想如何解释这个问题。
请问一下：_small_table_threshold 这个参数的具体含义是什么？能不能说详细些？

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

你这样的公式可能会区别不小，因为physical read direct也是一部分，v$sysstat里table scans (short tables)值是多少？table scans (long tables)值是多少？

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

查了一些资料，基本上应该能够解释这个问题。
关键点还是在于_small_table_threshold这个参数，当db_cache_size小的时候，发生一个table scan的时候，这个表可能将作为大表处理，而放在lru的末端，这样这个表的数据会很快老化，从而表现的hit ratio较高；但是当db_cache_size变大的时候，在发生这个table scan的时候，这个表可能会作为一个小表处理，那么这个的表的数据放在lru的首端，从而可能导致了hit ratio的降低！
关于这个hit ratio的降低到底是促进了性能的提升还是降低了呢？估计要看fts的频率和具体的数据内容了。但是有一点可以肯定，如果系统没有必要fts的话，还是想办法解决它！
另外，hit ratio已经不能作为一个重要的指标来表示性能的好坏。一个性能比较差的sql，执行可能会触发很多consistent read，但是这个会导致databuffer hit ratio很高，而整个系统的性能很差。
我感觉我可以跟我的老板交差了！

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

table scans (short tables)
23590776
table scans (long tables)
805087
这个系统才启动12天，就有这么多的fts，平均每天有67090个大表scan，也就是每小时有2795个大表扫描，也就是几乎每秒一个！呵呵，真厉害！
可惜现在还不优化它，需要手续！有的玩了

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

羡慕ing.

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

.>table scans (short tables) 23590776
.>table scans (long tables) 805087
说明你的系统存在大的全表扫描,,你必须找到..

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

the formula should be
1 - ((physical reads - physical reads direct - physical reads direct (lob))

/ (db block gets + consistent gets))
or
1 - ((physical reads - physical reads direct - physical reads direct (lob))

/ session logical reads)