這周和同事討論技術問題時，他告訴我客戶的一套11.1.0.6的數據庫中某個本地管理表空間上存在大量的Extents Fragment區間碎片，這些連續的Extents沒有正常合并為一個大的Extent，他懷疑這是由于11.1.0.6上的bug造成了LMT上存在大量碎片。 同事判斷該表空間上有碎片的依據是從dba_free_space視圖中查詢到大量連續的Free Extents:SQL> select tablespace_name,EXTENT_MANAGEMENT,ALLOCATION_TYPE from dba_tablespaces where tablespace_name='FRAGMENT';TABLESPACE_NAME EXTENT_MAN ALLOCATIO ------------------------------ ---------- --------- FRAGMENT LOCAL SYSTEMSQL> select block_id,blocks from dba_free_space where tablespace_name='FRAGMENT' and rownum<10; BLOCK_ID BLOCKS ---------- ---------- 40009 222136 25 8 9 8 17 8 33 8 41 8 49 8 57 8 65 8 ..............SQL> select count(*),blocks from dba_free_space where tablespace_name='FRAGMENT' and blocks=8 group by blocks;COUNT(*) BLOCKS ---------- ----------5000 8 以上可以看到FRAGMENT表空間使用autoallocate的Local Extent Management，的確存在大量的連續Extents沒有合并。在DMT即字典管理表空間模式下需要SMON進程定期維護FET$基表將tablespace上的連續空閑Extents合并為更大的一個Extents。而在LMT模式下因為采用數據文件頭上(datafile header 3-8 blocks in 10g)的位圖管理區間，所以無需某個后臺進程特意去合并區間。 為什么LMT下連續空閑Extents沒有合并而造成碎片呢？因為這套庫采用11gr1較不穩定的11.1.0.6版本，所以把問題歸咎為某個bug似乎可以講得通。一開始我較為認同同事的bug論，且和同事一起查詢了Metalink上11gr1上一些已知的bug，但并沒有發現癥狀匹配的bug note。 這讓我反思這個問題，過早的將cause定位到bug過于主觀了，并不是所有我們預期外的情況(unexpected)都屬于bug。 實際上dba_free_space所顯示的信息可能并不"真實"，這種幻象往往由10g以后出現的flashback table特性引起:SQL> select text from dba_views where view_name='DBA_FREE_SPACE';TEXT -------------------------------------------------------------------------------- ======DMT REAL FREE EXTENTS=============select ts.name, fi.file#, f.block#,f.length * ts.blocksize, f.length, f.file# from sys.ts$ ts, sys.fet$ f, sys.file$ fi where ts.ts# = f.ts#and f.ts# = fi.ts#and f.file# = fi.relfile#and ts.bitmapped = 0union all======LMT REAL FREE EXTENTS=============select /*+ ordered use_nl(f) use_nl(fi) */ts.name, fi.file#, f.ktfbfebno,f.ktfbfeblks * ts.blocksize, f.ktfbfeblks, f.ktfbfefno from sys.ts$ ts, sys.x$ktfbfe f, sys.file$ fi where ts.ts# = f.ktfbfetsnand f.ktfbfetsn = fi.ts#and f.ktfbfefno = fi.relfile#and ts.bitmapped <> 0 and ts.online$ in (1,4) and ts.contents$ = 0union all======LMT RECYCLEBIN FREE EXTENTS=============select /*+ ordered use_nl(u) use_nl(fi) */ts.name, fi.file#, u.ktfbuebno,u.ktfbueblks * ts.blocksize, u.ktfbueblks, u.ktfbuefno from sys.recyclebin$ rb, sys.ts$ ts, sys.x$ktfbue u, sys.file$ fi where ts.ts# = rb.ts#and rb.ts# = fi.ts#and u.ktfbuefno = fi.relfile#and u.ktfbuesegtsn = rb.ts#and u.ktfbuesegfno = rb.file#and u.ktfbuesegbno = rb.block#and ts.bitmapped <> 0 and ts.online$ in (1,4) and ts.contents$ = 0union all======DMT RECYCLEBIN FREE EXTENTS=============select ts.name, fi.file#, u.block#,u.length * ts.blocksize, u.length, u.file# from sys.ts$ ts, sys.uet$ u, sys.file$ fi, sys.recyclebin$ rb where ts.ts# = u.ts#and u.ts# = fi.ts#and u.segfile# = fi.relfile#and u.ts# = rb.ts#and u.segfile# = rb.file#and u.segblock# = rb.block#and ts.bitmapped = 0 以上我們通過解析10g中的dba_free_space視圖可以了解到該視圖所顯示的Free Extents由以下四個部分組成:

LMT表空間上真正空閑的Extents

DMT表空間上真正空閑的Extents

LMT表空間上被RECYCLEBIN中對象占用的Extents

DMT表空間上被RECYCLEBIN中對象占用的Extents

而在10g以前的版本中因為沒有recyclebin特性的"干擾"，所以dba_free_space所顯示的Free Extents由前2個部分組成，因此我們可以在10g中創建一個兼容視圖以實現對真正空閑空間的查詢:create view dba_free_space_pre10g as select ts.name TABLESPACE_NAME,fi.file# FILE_ID,f.block# BLOCK_ID,f.length * ts.blocksize BYTES,f.length BLOCKS,f.file# RELATIVE_FNOfrom sys.ts$ ts, sys.fet$ f, sys.file$ fiwhere ts.ts# = f.ts#and f.ts# = fi.ts#and f.file# = fi.relfile#and ts.bitmapped = 0 union all select /*+ ordered use_nl(f) use_nl(fi) */ts.name TABLESPACE_NAME,fi.file# FILE_ID,f.ktfbfebno BLOCK_ID,f.ktfbfeblks * ts.blocksize BYTES,f.ktfbfeblks BLOCKS,f.ktfbfefno RELATIVE_FNOfrom sys.ts$ ts, sys.x$ktfbfe f, sys.file$ fiwhere ts.ts# = f.ktfbfetsnand f.ktfbfetsn = fi.ts#and f.ktfbfefno = fi.relfile#and ts.bitmapped <> 0and ts.online$ in (1, 4)and ts.contents$ = 0/create view dba_free_space_recyclebin as select /*+ ordered use_nl(u) use_nl(fi) */ts.name TABLESPACE_NAME,fi.file# FILE_ID,u.ktfbuebno BLOCK_ID,u.ktfbueblks * ts.blocksize BYTES,u.ktfbueblks BLOCKS,u.ktfbuefno RELATIVE_FNOfrom sys.recyclebin$ rb, sys.ts$ ts, sys.x$ktfbue u, sys.file$ fiwhere ts.ts# = rb.ts#and rb.ts# = fi.ts#and u.ktfbuefno = fi.relfile#and u.ktfbuesegtsn = rb.ts#and u.ktfbuesegfno = rb.file#and u.ktfbuesegbno = rb.block#and ts.bitmapped <> 0and ts.online$ in (1, 4)and ts.contents$ = 0 union all select ts.name TABLESPACE_NAME,fi.file# FILE_ID,u.block# BLOCK_ID,u.length * ts.blocksize BYTES,u.length BLOCKS,u.file# RELATIVE_FNOfrom sys.ts$ ts, sys.uet$ u, sys.file$ fi, sys.recyclebin$ rbwhere ts.ts# = u.ts#and u.ts# = fi.ts#and u.segfile# = fi.relfile#and u.ts# = rb.ts#and u.segfile# = rb.file#and u.segblock# = rb.block#and ts.bitmapped = 0 / 通過以上創建的dba_free_space_pre10g和dba_free_space_recyclebin視圖，我們可以很明確地區分表空間上空閑Extents。 針對本例中的LMT上存在大量連續的空閑Extent碎片，可以直接從上述視圖中得到答案:SQL> select * from dba_free_space_pre10g where tablespace_name='FRAGMENT';TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO ------------------------------ ---------- ---------- ---------- ---------- ------------ FRAGMENT 13 40009 1819738112 222136 13SQL> select count(*),blocks from dba_free_space_recyclebin where tablespace_name='FRAGMENT' group by blocks;COUNT(*) BLOCKS ---------- ----------5000 8顯然是RECYCLEBIN中存在大量的小"對象"從而造成了LMT上出現大量碎片的假象SQL> select space,count(*) from dba_recyclebin where ts_name='FRAGMENT' group by space;SPACE COUNT(*) ---------- ----------8 5000我們可以通過purge recyclebin來"合并"這些Extents碎片SQL> purge dba_recyclebin;DBA Recyclebin purged.SQL> select count(*),blocks from dba_free_space where tablespace_name='FRAGMENT' group by blocks;COUNT(*) BLOCKS ---------- ----------1 262136

如果應用程序創建大量的小型堆(heap)表來存放臨時數據，在不再需要這些數據時將這些堆表drop掉，那么就可能造成上述LMT"碎片"問題。我們在實際處理10g以后的這類空間問題時一定搞清楚，哪些是真正的Free Extents,而哪些是來自RECYCLEBIN的Extents。 另一方面這個case還告訴我們不要一遇到預料外的行為方式(unexpected behavior)就將問題定位到bug，這樣會過早僵化我們的診斷預期。為了盡可能地發散思維，我們有必要如圍棋中所提倡的"保留變化"那樣來安排診斷步驟。

本文轉自maclean_007 51CTO博客，原文鏈接:http://blog.51cto.com/maclean/1277821

總結

以上是生活随笔為你收集整理的Too many fragmentation in LMT?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。