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

148次閱讀

共計 3477 個字符，預計需要花費 9 分鐘才能閱讀完成。

這篇文章主要介紹“Oracle Rac 利用 keep pool 解決索引高聚簇因子問題的過程”，在日常操作中，相信很多人在 Oracle Rac 利用 keep pool 解決索引高聚簇因子問題的過程問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Oracle Rac 利用 keep pool 解決索引高聚簇因子問題的過程”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

什么是聚簇因子？
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 解決索引高聚簇因子問題的過程”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！

正文完