關於HW-contention等待的處理
The HW enqueue is used to serialize the allocation of space beyond the high water mark of a segment.
V$SESSION_WAIT.P2 / V$LOCK.ID1 is the tablespace number.
V$SESSION_WAIT.P3 / V$LOCK.ID2 is the relative data block address (dba) of segment header of the object for which space is being allocated.
If this is a point of contention for an object, then manual allocation of extents solves the problem.
思考:
但為什麼手動分配extent就可以解決問題呢?extent和high water mark有什麼關係呢?
首先是關於MSSM和ASSM下的high water mark資料
MSSM uses free lists to manage segment space. At table creation, no blocks in the segment are formatted. When a session first inserts rows into the table, the database searches the free list for usable blocks. If the database finds no usable blocks, then it preformats a group of blocks, places them on the free list, and begins inserting data into the blocks. In MSSM, a full table scan reads all blocks below the HWM.
ASSM does not use free lists and so must manage space differently. When a session first inserts data into a table, the database formats a single bitmap block instead of preformatting a group of blocks as in MSSM. The bitmap tracks the state of blocks in the segment, taking the place of the free list. The database uses the bitmap to find free blocks and then formats each block before filling it with data. ASSM spread out inserts among blocks to avoid concurrency issues.
另外:
1)首先HWM的位置是儲存在段頭塊,並且HWM的提升會增加Freelist中的free blocks,而freelist中的塊數的紀錄,也儲存在段頭(當然如果freelist group=n>1,那麼儲存在段頭後面的n個塊中~),所以這個時候要修改的是段頭塊(以及freelist 所在的塊),還有一個地方要修改,就是原來freelist中最後一個block,這個裡面記錄了freelist單項列表的最後一個地址,要把他修改,指向新加入freelist的塊的地址~還要在所有新加入freelist的塊上建立freelist單項鍊表~ 可見提高HWM是需要修改很多塊的~
但是如果新加入一個extent呢?對於字典管理表空間,需要修改資料字典等待為ST enqueue(印象中)~ 而本地管理表空間,僅僅需要修改以下資料檔案頭上的點陣圖~
這個工作量是非常小的~ 我不認為分配extent會造成多大的等待~ 當然就算有等待也不是hw enqueue
2)ASSM high-HWM extensions are not done over extent boundaries IIRC, thus with small extents you'd have lots of extensions to do, each requiring HW-enqueue get. ASSM relieves HW-enqueue contention by increasing HHWM in large sizes (depending on extent and current segment size), so less HW operations have to be done.
The LHWM extensions can be done without having HW-enqueue as they involve only changing few records in a BMB block and the BMB is pinned for that exclusively anyway. The actual batch formatting of datablocks is done while having FB enqueue, allowing finer granularity of locking block ranges in case of multiple parallel inserts.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/24104518/viewspace-730201/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 關於resmgr:cpu quantum異常等待處理
- 關於中文URL的處理
- ORACLE鎖等待的處理方法Oracle
- iOS 關於時間的處理iOS
- 關於大資料量的處理大資料
- MySQL 關於毫秒的處理薦MySql
- 關於Disruptor處理流程
- 關於aud$物件相關處理物件
- 關於Python中的日期處理Python
- 關於go的跨域處理 ginGo跨域
- 關於小數中0的處理
- 關於jdon 的事務處理疑惑?
- 關於批處理中的變數變數
- 關於GCD多工處理GC
- 關於php rsa加密處理PHP加密
- RDSforMySQLInnoDB行鎖等待和鎖等待超時的處理ORMMySql
- Java--- 關於null的處理若干方法JavaNull
- 關於特殊符號&與& 的處理符號
- 關於Android的幾種事件處理Android事件
- 關於圓角的5種處理方式
- 關於sequence問題的緊急處理
- 關於裸裝置資料的處理
- 關於JF框架中的空值處理框架
- CSS > 關於雪碧圖預處理和後處理方案的討論CSS
- 關於Oracle死鎖處理方法Oracle
- 求助:關於“JAVA事件處理模式”Java事件模式
- 關於tc型別的enqueue等待型別ENQ
- 'library cache lock'等待事件的處理方法事件
- 常見的wait等待事件及處理AI事件
- 處理等待發貨過帳的交貨
- log file sync等待事件處理思路事件
- gc current request等待時間處理GC
- 關於OT分類的一些處理
- 關於 Eloquent ORM 對資料處理的思考ORM
- 關於移動端IOS active失效的處理iOS
- Java 中關於 null 物件的容錯處理JavaNull物件
- 關於介面返回BOM頭處理的問題
- 關於jdon的HibernateTemplate類的事務處理