访问量增加1倍，出现大量CACHE BUFFER CHAINS LATCHES

d.c.b.a

你的LATCH是CACHE BUFFER CHAINS LATCHES,所以现在和SQL解释没有多大关系.

还是LOGICAL READ太多了，先搞定这个吧。

oracledba

减少结果集是最根本解决问题的办法 这样可以大大减少CPU的压力 其实只要找到几条关键语句就可以起很明显的效果的
把session_cached_cursors设置成0对于繁忙的系统是一件恐怖的事情 呵呵

husthxd

CPU      Elapsd
  Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
     30,974,145          438       70,717.2   28.2   316.44    680.44  132190350
Module: JDBC Thin Client
select /*+rule*/ c.id, c.EDISPLAYNAME, c.CDISPLAYNAME, c.WEBURL,
c.LASTUPDATE, c.PROVINCE FROM COMPANY c where c.id in (  select
v.companyid  from vacancy v,vaccity vcity  where v.id=vcity.vac
ancyid and v.issuestatus=3   and SUBSTR(vcity.citycode,1,2)=SUBS
TR(:1,1,2)) order by c.lastupdate desc

使用了rule模式?
v.issuestatus上是否有索引,索引的选择性高不高?
能否把select /*+rule*/ c.id, c.EDISPLAYNAME, c.CDISPLAYNAME, c.WEBURL,
c.LASTUPDATE, c.PROVINCE FROM COMPANY c where c.id in (  select
v.companyid  from vacancy v,vaccity vcity  where v.id=vcity.vac
ancyid and v.issuestatus=3   and SUBSTR(vcity.citycode,1,2)=SUBS
TR(:1,1,2)) order by c.lastupdate desc
的执行计划贴出来看看?
如biti所说的:
关键在于找出热点的块到底是什么
才能针对性的解决问题
联合 v$latch / v$latch_children /x$bh / dba_objects 找出是哪些对象的热点块
再看是索引还是表
针对性的解决问题

rxh

最初由 eygle 发布
[B]

如wing hong所说，高逻辑读是你的主要问题之一。
部分SQL需要调整。

Latch free是另外一个需要关注的问题，高logical read也是导致Latch free的部分原因。

如果你的内存足够，可以考虑设置session_cached_cursors为非0值，对于SQL反复执行的应用，可以减少对于shared pool的Latch争用。 [/B]

我现在已经跟开发说了让他们改应用，但要一段时间，这期间有什么方法，暂时解决一下，可以是不治本的方法。
session_cached_cursors本来就设了50。

[PHP]
                                                CPU per    Elap per
Executions   Rows Processed   Rows per Exec    Exec (s)   Exec (s)  Hash Value
------------ --------------- ---------------- ----------- ---------- ----------
     316,179         316,153              1.0       0.00        0.00 3876449241
Module: JDBC Thin Client
SELECT 1 FROM DUAL


                           % Total
Parse Calls  Executions   Parses  Hash Value
------------ ------------ -------- ----------
     316,179      316,179    73.74 3876449241
Module: JDBC Thin Client
SELECT 1 FROM DUAL

  .                                   
[/PHP]

这个会有影响吗？占了解析总量的73%

rxh

最初由 husthxd 发布
[B]CPU      Elapsd
  Buffer Gets    Executions  Gets per Exec  %Total Time (s)  Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
     30,974,145          438       70,717.2   28.2   316.44    680.44  132190350
Module: JDBC Thin Client
select /*+rule*/ c.id, c.EDISPLAYNAME, c.CDISPLAYNAME, c.WEBURL,
c.LASTUPDATE, c.PROVINCE FROM COMPANY c where c.id in (  select
v.companyid  from vacancy v,vaccity vcity  where v.id=vcity.vac
ancyid and v.issuestatus=3   and SUBSTR(vcity.citycode,1,2)=SUBS
TR(:1,1,2)) order by c.lastupdate desc

使用了rule模式?
v.issuestatus上是否有索引,索引的选择性高不高?
能否把select /*+rule*/ c.id, c.EDISPLAYNAME, c.CDISPLAYNAME, c.WEBURL,
c.LASTUPDATE, c.PROVINCE FROM COMPANY c where c.id in (  select
v.companyid  from vacancy v,vaccity vcity  where v.id=vcity.vac
ancyid and v.issuestatus=3   and SUBSTR(vcity.citycode,1,2)=SUBS
TR(:1,1,2)) order by c.lastupdate desc
的执行计划贴出来看看?
如biti所说的:
关键在于找出热点的块到底是什么
才能针对性的解决问题
联合 v$latch / v$latch_children /x$bh / dba_objects 找出是哪些对象的热点块
再看是索引还是表
针对性的解决问题 [/B]

这就是表结构的问题，其实只要在vaccity增加一个冗余字段issuestatus就完全解决了，但现在动不了结构。现在我打算整合一个中间表，将检索用的字段整合到这张表中，所有记录一共就几百万条，有效的其实就几万条，将这部分单摘出来就算全表查询放到keep buffer cache中性能也会比现在好太多了。但有时会一次读出几千条数据，这个是不可避免的，这个问题怎么，有点类似BBS分页的情况。

xzh2000

最初由 rxh 发布
[B]

这就是表结构的问题，其实只要在vaccity增加一个冗余字段issuestatus就完全解决了，但现在动不了结构。现在我打算整合一个中间表，将检索用的字段整合到这张表中，所有记录一共就几百万条，有效的其实就几万条，将这部分单摘出来就算全表查询放到keep buffer cache中性能也会比现在好太多了。但有时会一次读出几千条数据，这个是不可避免的，这个问题怎么，有点类似BBS分页的情况。 [/B]

这个SQL还有优化的余地，你把它的执行计划贴出来让大家看看，
而且你的硬件配置不错，而且事务也很少，所以不要老想着去改
表结构什么的，先试试优化SQL先。

rollingpig

几个建议：
第一步：如biti所说，找出hot buffer.看看是哪些BLOCK

第二步：看看TOPSQL的sqlplan吧
script

[php]
select  distinct
id,parent_id,OPERATION,OPTIONS,OBJECT_NAME,object_owner
from v$sql_plan
where HASH_VALUE = &hash
order by id

....
[/php]

第3步：据metalink减，HIGH buffer cache chain很多时候是由不合理的NL loop引起大量index扫描造成的，如果第1/2步的结果印证了这一点，考虑加大 db_file_multiblock_read_count,使本来走index改走FTS，说不定有帮助

rxh

最初由 xzh2000 发布
[B]

这个SQL还有优化的余地，你把它的执行计划贴出来让大家看看，
而且你的硬件配置不错，而且事务也很少，所以不要老想着去改
表结构什么的，先试试优化SQL先。

[/B]

[PHP]

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   SORT (ORDER BY)
   2    1     NESTED LOOPS
   3    2       VIEW OF 'VW_NSO_1'
   4    3         SORT (UNIQUE)
   5    4           TABLE ACCESS (BY INDEX ROWID) OF 'VACCITY'
   6    5             NESTED LOOPS
   7    6               TABLE ACCESS (BY INDEX ROWID) OF 'VACANCY'
   8    7                 INDEX (RANGE SCAN) OF 'INDX_VACANCY_ISSUESTA
          TUS' (NON-UNIQUE)

   9    6               INDEX (RANGE SCAN) OF 'INDEX_VACCITY_VACID' (N
          ON-UNIQUE)

  10    2       TABLE ACCESS (BY INDEX ROWID) OF 'COMPANY'
  11   10         INDEX (UNIQUE SCAN) OF 'PK_COMPANY' (UNIQUE)




Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      81581  consistent gets
          0  physical reads
          0  redo size
     111804  bytes sent via SQL*Net to client
        943  bytes received via SQL*Net from client
        196  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
       1441  rows processed

.
[/PHP]

husthxd

v.issuestatus上是否有索引
->看执行计划,答案是有
索引的选择性高不高?
->条件是=3,感觉这个字段的选择性不高把?

分析表,用cost模式看看?

rxh

最初由 husthxd 发布
[B]v.issuestatus上是否有索引
->看执行计划,答案是有
索引的选择性高不高?
->条件是=3,感觉这个字段的选择性不高把?

分析表,用cost模式看看? [/B]

总数据有几百万条，等于3的就不超过4万条。其实这个字段再加在vaccity上性能就会快很多！

用CBO的话会全表扫描。