記一次索引分裂造成rac業務短暫業務不可用的情況

根據客戶描述， 9:47 分到 9:50 分業務出現短暫不可用的現象

節點一

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	242040	07-Dec-21 09:40:36	1462	8.8
End Snap:	242041	07-Dec-21 09:50:09	1802	10.1
Elapsed:		9.56 (mins)
DB Time:		1,278.11 (mins)

 

 

節點二

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	242040	07-Dec-21 09:40:35	4326	8.5
End Snap:	242041	07-Dec-21 09:50:09	4655	8.9
Elapsed:		9.55 (mins)
DB Time:		1,130.81 (mins)

 

 

節點一

Top 5 Timed Foreground Events

 

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
gc current block 2-way	742,186	15,588	21	20.33	Cluster
gc buffer busy acquire	57,670	12,568	218	16.39	Cluster
gc buffer busy release	41,139	11,069	269	14.43	Cluster
gc cr grant 2-way	343,681	8,629	25	11.25	Cluster
enq: TX - index contention	14,672	6,489	442	8.46	Concurrency

 

節點二

Top 5 Timed Foreground Events

 

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
enq: TX - index contention	19,547	17,643	903	26.00	Concurrency
gc buffer busy acquire	76,148	13,004	171	19.17	Cluster
DFS lock handle	228,842	3,593	16	5.30	Other
DB CPU		3,556		5.24
gc cr grant 2-way	623,429	3,316	5	4.89	Cluster

 

可以看到gc消耗嚴重

 

 11g開始gc buffer  busy分為gc buffer busy acquire和gc buffer  busy release:

   gc buffer busy acquire是當session#1嘗試請求訪問遠端例項(remote  instance) buffer，但是在session#1之前已經有相同例項上另外一個session#2請求訪問了相同的buffer，並且沒有完成，那麼session#1等待gc buffer busy acquire。

 

gc buffer busy release是在session#1之前已經有遠端例項的session#2請求訪問了相同的buffer，並且沒有完成，那麼session#1等待gc buffer busy release。

 

Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
gc current block 2-way	742,186	15,588	21	20.33	Cluster
gc buffer busy acquire	57,670	12,568	218	16.39	Cluster
gc buffer busy release	41,139	11,069	269	14.43	Cluster
gc cr grant 2-way	343,681	8,629	25	11.25	Cluster
enq: TX - index contention	14,672	6,489	442	8.46	Concurrency

我認為可能是兩個原因造成的：

1. 低效SQL，邏輯讀過大，且訪問頻繁，造成爭用嚴重。

2. 資料庫IO資源緊張，導致一些頻繁訪問的SQL語句響應慢，造成gc buffer busy acquire,gc buffer busy release等待事件。

定位是否是原因1的問題，就找Segments by Global Cache Buffer Busy。然後根據物件的名稱去找對應的SQL，然後檢視SQL的執行計劃定位問題。

 

節點一

Segments by Global Cache Buffer Busy

• % of Capture shows % of GC Buffer Busy for each top segment compared 
• with GC Buffer Busy for all segments captured by the Snapshot

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	GC Buffer Busy	% of Capture
HZSI	USERS	IDX_BUSSINESSLOG_AAE036		INDEX	34,132	63.10
HZSI	USERS	IDX_KC22_TEMP21_BAZ001		INDEX	3,384	6.26
HZSI	SJZH	IDX_KC61_BAZ001		INDEX	3,328	6.15
HZSI	INDX_K	IDX_KC21_AKC002		INDEX	2,289	4.23
HZSI	USERS_K	PK_KC61_AKC001		INDEX	1,427	2.64

 

節點二

Segments by Global Cache Buffer Busy

• % of Capture shows % of GC Buffer Busy for each top segment compared 
• with GC Buffer Busy for all segments captured by the Snapshot

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	GC Buffer Busy	% of Capture
HZSI	USERS	IDX_BUSSINESSLOG_AAE036		INDEX	46,991	58.48
HZSI	SJZH	IDX_KC61_BAZ001		INDEX	7,218	8.98
HZSI	USERS	IDX_KC22_TEMP21_BAZ001		INDEX	5,558	6.92
HZSI	INDX_K	IDX_KC21_BAZ001		INDEX	2,792	3.47
HZSI	USERS_K	PK_KC61_AKC001		INDEX	2,714	3.38

 

可見這個索引

IDX_BUSSINESSLOG_AAE036

對於高爭用和熱塊：

Solution is to reorganize the index in a way to avoid the contention or hot spots using the below options

I. Global Hash partition the index

CREATE INDEX hgidx ON tab (c1,c2,c3) GLOBAL

PARTITION BY HASH (c1,c2)

(PARTITION p1  TABLESPACE tbs_1,

PARTITION p2  TABLESPACE tbs_2,

PARTITION p3  TABLESPACE tbs_3,

PARTITION p4  TABLESPACE tbs_4);

II. Recreate the index as reverse key index (not suitable for large table, could require buffer cache increased accordingly)

III. If index key is generated from a sequence, increase cache size of the sequence and make the sequence 'no order' if application supports it.

 

引申：

btree ，點陣圖，反向，全域性 hash 分割槽，複合壓縮， oracle 就這幾個索引

  全域性 hash 分割槽索引可以用範圍查詢的

 

反向索引不支援範圍，是因為索引葉子節點儲存的是反向後的鍵值和 rowid ，是無序的。

hash 分割槽索引，可以範圍查詢的原因，我覺得是分割槽實際上是物理上的分割槽，並不是索引樹上的分割槽。物理上，使用 hash 演算法將索引樹的節點存放在不同表空間的塊裡，在邏輯上，索引葉子節點儲存的鍵值是順序的，由於之間會有指標連線，所以就算不是連續的塊，也可以根據指標來遍歷下一個葉子節點。