国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

深度分析數據庫的熱點塊問題（latch: cache buffers chains）

IT那活兒 / 2843人閱讀
深度分析數據庫的熱點塊問題（latch: cache buffers chains）

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！

熱點塊的定義

數據庫的熱點塊，從簡單了講，就是極短的時間內對少量數據塊進行了過于頻繁的訪問。定義看起來總是很簡單的，但實際在數據庫中，我們要去觀察或者確定熱點塊的問題，卻不是那么簡單了。要深刻地理解數據庫是怎么通過一些數據特征來表示熱點塊的，我們需要了解一些數據庫在這方面處理機制的特性。

數據緩沖區的結構

我們都知道，當查詢開始的時候，進程首先去數據緩沖區中查找是否存在查詢所需要的數據塊，如果沒有，就去磁盤上把數據塊讀到內存中來。在這個過程中，涉及到數據緩沖區中LRU鏈的管理。現在我們的重點是，到底進程是如何地去快速定位到自己所想要的block的，或者如何快速確定想要的block不在內存中而去進行物理讀的。
我們仔細想一想，隨著硬件的發展，內存越來越大，cache buffer也越來越大，我們如何才能在大量的內存中迅速定位到自己想要的block？總不能去所有buffer中遍歷吧！
在此數據庫引出了hash的概念（oracle中快速定位信息總是通過hash算法的，比如快速定位sql是否在shared pool size中存在就是通過hash value來定位的，也就是說shared pool size中對象也是通過hash table來管理的），了解一點數據結構的基本知識就知道，hash 的一大重要功能就是快速地查找。
舉個最簡單的例子，假設我們有一個hash table 就是一個二維數組a[200][100],現在有1000個無序數字，我們要從這1000個數字里面查找某個值是否存在，或者說當我們接收到某個數字的時候必須判斷是否已經存在，當然，我們可以遍歷這1000個數字，但這樣的效率就很低。
但現在我們考慮這樣一種方法，那就是把1000個數字除以200，根據其余數，放在a[200][100]里面(假設相同余數的最大數量不超過100)，余數就是數組的下標。這樣，平均來說一個數組a[i]里面可能有5個左右的數字。當我們要去判別一個數字是否存在的時候，對這個數字除以200(這就是一個最簡單的hash算法)，根據余數i作為下標去數組a[i]中查找，大約進行5次查找就能判別是否已經存在，這樣通過開辟內存空間a[200][100]來換取了時間(當然hash 算法的選取和hash table的大小是一個很關鍵的問題)。
明白了基本的hash原理之后，我們再來看oracle的block的管理。
數據庫為這些block也開辟了hash table，假設是a,則在一維上的數量是由參數_db_block_hash_buckets 來決定的，也就是存在hash table a[_db_block_hash_buckets ],從oracle8i開始，_db_block_hash_buckets =db_block_buffers*2。而一個block被放到哪個buckets里面，則是由block的文件編號、塊號(x$bh.dbarfl、x$bh.dbablk對應了block的文件屬于表空間中的相關編號和block在文件中的編號，x$bh是所有cache buffer的header信息，通過表格的形式可以查詢)做hash 算法決定放到哪個bucket的，而bucket里面就存放了這些buffers的地址。這樣當我們要訪問數據的時候，可以獲得segment的extent(可以通過dba_extents查到看，詳細的信息來源這里不做探討)，自然知道要訪問的文件編號和block編號，根據文件和block編號可以通過hash算法計算出hash bucket,然后就可以去hash bucket里面去找block對應的buffer。
除此之外，為了維護對這些block的訪問和更改，oracle還提供了一種latch來保護這些block。
因為要避免不同的進程隨意地徑直并發修改和訪問這些block，這樣很可能會破壞block的結構的。latch是數據庫內部提供的一種維護內部結構的一種低級鎖，latch的生存周期極短(微秒以下級別)，進程加latch后快速的進行某個訪問或者修改動作然后釋放latch(關于latch不再過多的闡述，那可能又是需要另一篇文章才能闡述清楚)。
這種latch數量是通過參數_db_block_hash_latches 來定義的，一個latch對應的保護了多個buckets。從8i開始，這個參數的default規則為:
  • 當cache buffers 少于2052 buffers
    _db_block_hash_latches = power(2,trunc(log(2, db_block_buffers - 4) - 1))
  • 當cache buffers多于131075 buffers

    _db_block_hash_latches = power(2,trunc(log(2, db_block_buffers - 4) - 6))

  • 當cache buffers位于2052與131075 buffers之間
    _db_block_hash_latches = 1024

通過這個規則我們可以看出，一個latch大約可以維護128個左右的buffers。由于latch使得對block的操作的串行化(9i中有改進，讀與讀可以并行，但讀與寫、寫與寫依然要串行)，很顯然我們可以想到一個道理，如果大量進程對相同的block進程進行操作，必然在這些latch上造成競爭，也就是說必然形成latch的等待。這在宏觀上就表現為系統級的等待。明白了這些原理，為我們下面的在數據庫中的診斷奠定了基礎。

如何確定熱點對象

如果我們經常關注awr報告，會發現有時候出現cache buffer chains的等待。這個cache buffer chains就是_db_block_hash_latches所定義的latch的總稱，通過查詢v$latch也可得到：
select">sys@OCN>select latch#,name,gets,misses,sleeps from v$latch where name like cache buffer%;
LATCH# NAME GETS MISSES SLEEPS
---------- ------------------------------ ---------- ---------- ----------
93 cache buffers lru chain 54360446 21025 238
98 cache buffers chains 6760354603 1680007 27085
99 cache buffer handles 554532 6 0
在這個查詢結果里我們可以看到記錄了數據庫啟動以來的所有cahce buffer chains的latch的狀況，gets表示總共有這么多次請求，misses表示請求失敗的次數(加鎖不成功)，而sleeps 表示請求失敗休眠的次數，通過sleeps我們可以大體知道數據庫中latch的競爭是否嚴重，這也間接的表征了熱點塊的問題是否嚴重。
由于v$latch是一個聚合信息，我們并不能獲得哪些塊可能存在頻繁訪問。那我們要來看另一個view信息，那就是v$latch_children,v$latch_children.addr記錄的就是這個latch的地址。
select">sys@OCN>select addr,LATCH#,CHILD#,gets,misses,sleeps from v$latch_children
2 where name = cache buffers chains and rownum < 21;
ADDR LATCH# CHILD# GETS MISSES SLEEPS
-------- ---------- ---------- ---------- ---------- ----------
91B23B74 98 1024 10365583 3957 33
91B23374 98 1023 5458174 964 25
91B22B74 98 1022 4855668 868 15
91B22374 98 1021 5767706 923 22
91B21B74 98 1020 5607116 934 31
91B21374 98 1019 9389325 1111 25
91B20B74 98 1018 5060207 994 31
91B20374 98 1017 18204581 1145 18
91B1FB74 98 1016 7157081 920 23
到此我們可以根據v$latch_child.addr關聯到對應的x$bh.hladdr(這是buffer header中記錄的當前buffer所處的latch地址)，通過x$bh可以獲得塊的文件編號和block編號。
select">sys@OCN>select dbarfil,dbablk
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11);
DBARFIL DBABLK
---------- ----------
4 6498
40 14915
15 65564
28 34909
由此我們就打通了cache buffers chains和具體block之間的關系，那再繼續下來，知道了block，我們需要知道究竟是哪些segment。這個可以通過dba_extents來獲得。
select distinct a.owner,a.segment_name from
dba_extents a,
(select dbarfil,dbablk
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11)) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;

OWNER SEGMENT_NAME SEGMENT_TYPE
------------------------------ ------------------------------ ------------------
ALIBABA BIZ_SEARCHER TABLE
ALIBABA CMNTY_USER_MESSAGE TABLE
ALIBABA CMNTY_VISITOR_INFO_PK INDEX
我們還有另外一種方式：
select object_name
from dba_objects
where data_object_id in
(select obj
from x$bh
where hladdr in
(select addr
from (select addr
from v$latch_children
order by sleeps desc)
where rownum < 11)) ;

OBJECT_NAME
------------------------------------
I_CCOL2
RESOURCE_PLAN$
DUAL
FGA_LOG$
AV_TRANSACTION
到這里我們基本能找到熱點塊對對應的對象。但實際上還有另外一個途徑來獲取這些信息，那就是和x$bh.tch 相關的一種方法。對于8i開始oracle提供了接觸點(touch count)來作為block是冷熱的標志，在一定條件滿足的情況下block被進程訪問一次touch count 增加一，到某個標準之后被移動到LRU熱端(關于touch count 在這里不做詳細介紹，那又將是一大篇文章)。那在短時間內從某種意義上講，touch count 大的block可能暗示著在當前某個周期內被訪問次數比較多。
select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk;
OWNER SEGMENT_NAME SEGMENT_TYPE
------------------------------ ------------------------------ ------------------
ALIBABA CMNTY_USER_MESSAGE TABLE
ALIBABA MEMBER_PK INDEX
ALIBABA OFFER_DRAFT_GMDFY_IND INDEX
同上面一樣還有這個方法：
select object_name
from dba_objects
where data_object_id in
(select obj
from (select obj
from x$bh order by tch desc) where rownum < 11) ;
OBJECT_NAME
---------------------------------------------------
DUAL
MEMBER_PK
SAMPLE_GROUP_PK
CMNTY_USER_MESSAGE_TD_BSM_IND
OFFER_DRAFT_MID_GMDFY_IND
OFFER_MID_GPOST_IND

到這里，我們尋找熱點塊和熱點對象的工作算是完成了，但我們還并沒有解決問題。

熱點問題的解決

熱點塊和熱點對象我們都找到了，但是我們該怎么來解決這個問題呢？
一般來說，熱點塊會導致cache buffers chains競爭等待，但并不是說cache buffer chains一定是因為熱點塊而起，在特別情況下有可能是因為latch數量的問題導致的，也就是一個latch管理的buffers數量太多而導致競爭激烈。但是latch數量我們一般是不會輕易去設置的，這是oracle的隱藏參數。
實際上最有效的辦法，是從優化sql入手，不良的sql往往帶來大量的不必要的訪問，這是造成熱點塊的根源。
比如本該通過全表掃描的查詢卻走了索引的range scan，這樣將帶來大量的對塊的重復訪問。從而形成熱點問題。再或者比如不當地走了nested loops的表連接，也可能對非驅動表造成大量的重復訪問。
那么在這個時候，我們的目標就是找出這些sql來并嘗試優化。在awr報告中，根據報告中sql列表，我們如果是通過dba_extents確定的熱點對象而不是通過dba_objects確定的，則可以通過查找出的熱點segment轉換為對應的表，對于非分區的索引，index_name就是segment_name,通過dba_indexes很容易的找到對應的table_name,對于分區表和分區索引也能通過和dba_tab_partition和dba_ind_partitions找到segment和table的對應關系。通過這些table到awr報告中去找相關的sql。
select sql_text
from stats$sqltext a,
(select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk) b
where a.sql_text like %||b.segment_name||% and b.segment_type = TABLE
order by a.hash_value,a.address,a.piece;
SQL_TEXT
----------------------------------------------------------------
SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
SELECT SEQ_SAMPLE.nextval FROM DUAL
SELECT bizgroup.seq_grp_user.NextVal FROM DUAL當然這里是從awr搜集的stats$sqltext中去找的(你可以在awr的文本報告中去找)，實際上，我們可以直接在當前數據庫中的v$sqlarea或者v$sqltext里面去找到這些sql，然后來嘗試優化。
select sql_text
from v$sqltext a,
(select distinct a.owner,a.segment_name,a.segment_type from
dba_extents a,
(select dbarfil,dbablk
from (select dbarfil,dbablk
from x$bh order by tch desc) where rownum < 11) b
where a.RELATIVE_FNO = b.dbarfil
and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk) b
where a.sql_text like %||b.segment_name||% and b.segment_type = TABLE
order by a.hash_value,a.address,a.piece;
SQL_TEXT
----------------------------------------------------------------
SELECT NULL FROM DUAL FOR UPDATE NOWAIT
SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
SELECT SEQ_IM_GROUP.nextval FROM DUAL
SELECT SEQ_SAMPLE.nextval FROM DUAL
=DD-MON-RR HH.MI.SSXFF AM TZR NLS_DUAL_CURRENCY=$ NLS_COMP=
SELECT SEQ_BIZ_SEARCHER.nextval FROM DUAL除了優化sql外，當然對于熱點的表或者索引來說，如果小的話，我們可以考慮cache在內存中，這樣可能降低物理讀提高sql運行速度(這并不會減少cache buffer chains的訪問次數)，對于序列，我們可以對序列多設置一些cache。如果是并行服務器環境中的索引對象，并且這個索引是系列遞增類型，我們可以考慮反向索引(關于反向索引這里就不過多地做介紹了)。

熱點塊的其他相關癥狀

在數據庫中還可能存在一些其他方面的熱點塊癥狀，通過v$waitstat的等待可以看出一些端倪,v$waitstat是根據數據緩沖區中各種block的類型(x$bh.class)而分類統計的等待狀況。
select">sys@OCN>select * from v$waitstat;
CLASS COUNT TIME
------------------ ---------- ----------
data block 1726977 452542
sort block 0 0
save undo block 0 0比如在ASSM表空間出現之前，由于freelist的存在，如果表經常被并發的進程DML，則可能存在大量的data block的等待，或者有free list的等待。那么這個時候我們發現這樣的segment之后需要考慮增加freelist數量。再比如經常發生長時間的DML的表被頻繁地訪問，這樣將會造成過多的對回滾段中塊的訪問，這時可能undo block 的等待會比較多。那么我們可能需要控制DML的時間長度或者想辦法從應用程序入手來解決問題。如果是undo header的等待比較多，沒使用undo tablespace 之前，可能需要考慮增加回滾段的數量。
總 結：
本文從熱點塊的原理入手，詳細地由oracle的內部結構特征開始介紹了熱點塊的產生和表現特征。進而闡述了診斷熱點對象和找出造成熱點對象的sql的方法。并從解決熱點問題方面提供了解決方向。

知識點：

  • 在cache buffer中搜索block的機制，使用hash技術來搜索，數據庫為buffer中的block也開辟了hash table，hash table a[_db_block_hash_buckets ]，_db_block_hash_buckets =db_block_buffers*2。而一個block被放到哪個buckets里面，則是由block的文件編號、塊號(x$bh.dbarfl、x$bh.dbablk對應了block的文件屬于表空間中的相關編號和block在文件中的編號，x$bh是所有cache buffer的header信息，通過表格的形式可以查詢)做hash 算法決定放到哪個bucket的，而bucket里面就存放了這些buffers的地址。
  • Latch競爭的原因：如果大量進程對相同的block進程進行操作，必然在這些latch上造成競爭，也就是說必然形成latch的等待。
  • 如何確定熱點對象：v$latch_children.addr記錄的就是latch的地址。根據v$latch_child.addr關聯到對應的x$bh.hladdr(這是buffer header中記錄的當前buffer所處的latch地址)，通過x$bh可以獲得塊的文件編號和block編號。
  • 熱點問題的解決：一般來說，熱點塊會導致cache buffers chains競爭等待，但并不是說cache buffer chains一定是因為熱點塊而起，在特別情況下有可能是因為latch數量的問題導致的，也就是一個latch管理的buffers數量太多而導致競爭激烈。但是latch數量我們一般是不會輕易去設置的，這是oracle的隱藏參數。實際上最有效的辦法，是從優化sql入手，不良的sql往往帶來大量的不必要的訪問，這是造成熱點塊的根源。比如本該通過全表掃描的查詢卻走了索引的range scan，這樣將帶來大量的對塊的重復訪問。從而形成熱點問題。再或者比如不當地走了nested loops的表連接，也可能對非驅動表造成大量的重復訪問。那么在這個時候，我們的目標就是找出這些sql來并嘗試優化。對于的小表可以CACHE到內存里。


本文作者：湯 杰(上海新炬王翦團隊）

本文來源：“IT那活兒”公眾號

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129171.html

相關文章

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<