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

2024-04-02 19:55

短信预约 -IT技能 免费直播动态提醒

这篇文章主要介绍“Oracle Rac利用keep pool解决索引高聚簇因子问题的过程”，在日常操作中，相信很多人在Oracle Rac利用keep pool解决索引高聚簇因子问题的过程问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”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 index EMDB.PK_LG_FSPE_YEJIBIAOXIAN storage(buffer_pool keep);
alter index EMDB.IDX_FSPE_YEJIBIAOXIAN_CHGDATE storage(buffer_pool keep);

将索引块读取到keep pool中,两个节点都执行
select count(CHGDATE) from EMDB.FSPE_YEJIBIAOXIAN t1;
select 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';