Oracle Rac利用keep pool解决索引高聚簇因子问题

什么是聚簇因子？ Oracle中的表用的最多的是堆表，堆表是无序的；而索引是有序的。体现两者之间无序程度就是聚簇因子。一般来说，理想的聚簇因子应该近乎接近表上的块数，而差的聚簇因子十分接近表的行数。索引聚簇因子高了以后，会使得索引使用成本偏高，造成本来应该走索引的执行计划变成了全表扫描，对sql效率危害极大。 如何解决索引聚簇因子高？ 1.按照索引顺序重建表。但是这种方法弊端要考虑清楚，如果表上有其他索引的话，那么这种重建表行为会可能会使得其他索引的聚簇因子上升。相当于拆了东墙补西墙，所以要对sql进行详细的分析，并与开发讨论取数逻辑，对索引重要性高低做到心中有数，可能会对其他索引造成不良影响，但是其他索引使用相对较少，效率下降可以接受，那么这种方法是可行的。 2.采用keep pool优化聚簇因子高的索引。这种方法将聚簇因子高的索引放到keep pool中，避开了索引的聚簇因子问题。因为在内存中自然不存在这种有序无序的问题了。下面就是在rac中采用keep pool解决该问题的过程。 注意下面的行为是不会解决聚簇因子问题的： 1.重建索引 2.move或者shrink表 3.数据泵导入导出 有时候有人会说有点作用，如果发生了积极作用，那只能是因为表或者索引的碎片率太高了。聚簇因子问题仍然存在。 实战过程：rac中设置keep pool 聚簇因子高的两个索引大小 15:45:11 SQL> select sum(bytes / 1024 / 1024) M_size 15:45:31   2    from dba_segments 15:45:31   3   where segment_name in 15:45:31   4         ('PK_LG_FSPE_YEJIBIAOXIAN', 'IDX_FSPE_YEJIBIAOXIAN_CHGDATE');     M_SIZE ----------        208 1 row selected. Elapsed: 00:00:00.19 设置keep pool大小： 15:16:31 SQL> alter system set db_keep_cache_size=250m scope=both sid='*'; alter system set db_keep_cache_size=250m scope=both sid='*' * ERROR at line 1: ORA-32018: parameter cannot be modified in memory on another instance Elapsed: 00:00:00.00 15:17:15 SQL> !oerr ora 32018 32018, 00000, "parameter cannot be modified in memory on another instance" // *Cause:  Parameter adjustment can take a very long time // *Action: Modify the parameter individually on each instance using //          the SID clause of the alter system command 不能用sid='*'的方式； alter system set db_keep_cache_size=250m scope=both sid='ECAC2'; alter system set db_keep_cache_size=250m scope=both sid='ECAC1'; 查询keep pool大小 show parameter db_keep_cache_size 15:20:11 SQL> show parameter db_keep_cache_size NAME                                 TYPE                              VALUE ------------------------------------ --------------------------------- ------------------------------ db_keep_cache_size                   big integer                       512M select component,current_size from v$sga_dynamic_components where component='KEEP buffer cache'; 虽然设置了250M，但是实际分配了512M。这样也好，因为随着表的增删改，索引的碎片率不可避免的越来越高，如果是250M，到时候可能会存在无法完全容乃索引的情况。 将index缓存到keep pool中 alter  /*source only*/ index EMDB.PK_LG_FSPE_YEJIBIAOXIAN storage(buffer_pool keep); alter  /*source only*/ index EMDB.IDX_FSPE_YEJIBIAOXIAN_CHGDATE storage(buffer_pool keep); 将索引块读取到keep pool中,两个节点都执行 select /*+index(IDX_FSPE_YEJIBIAOXIAN_CHGDATE,t1)*/ count(CHGDATE) from EMDB.FSPE_YEJIBIAOXIAN t1; select /*+index(PK_LG_FSPE_YEJIBIAOXIAN,t1)*/ count(CLFCODE) from EMDB.FSPE_YEJIBIAOXIAN t1; 查看此时的执行计划： 15:26:37 SQL> set line 200 15:26:39 SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Plan hash value: 3009983618 ------------------------------------------------------------------------------------------------- | Id  | Operation                   | Name              | Rows  | Bytes | Cost (%CPU)| Time     | ------------------------------------------------------------------------------------------------- |   0 | SELECT STATEMENT            |                   |     1 |     8 |  2082   (3)| 00:00:01 | |   1 |  SORT AGGREGATE             |                   |     1 |     8 |            |          | |   2 |   TABLE ACCESS INMEMORY FULL| FSPE_YEJIBIAOXIAN |  3986K|    30M|  2082   (3)| 00:00:01 | ------------------------------------------------------------------------------------------------- 9 rows selected. Elapsed: 00:00:00.02 查询keep pool剩余大小 select p.name,a.cnum_repl "total buffers",a.anum_repl "free buffers" from x$kcbwds a, v$buffer_pool p  where a.set_id=p.LO_SETID and     p.name='KEEP';