Oracle Rac利用keep pool解決索引高聚簇因子問題的過程

這篇文章主要介紹“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  /*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';

到此，關于“Oracle Rac利用keep pool解決索引高聚簇因子問題的過程”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！