這周和同事討論技術(shù)問(wèn)題時(shí)，他告訴我客戶的一套11.1.0.6的數(shù)據(jù)庫(kù)中某個(gè)本地管理表空間上存在大量的Extents Fragment區(qū)間碎片，這些連續(xù)的Extents沒(méi)有正常合并為一個(gè)大的Extent，他懷疑這是由于11.1.0.6上的bug造成了LMT上存在大量碎片。 同事判斷該表空間上有碎片的依據(jù)是從dba_free_space視圖中查詢到大量連續(xù)的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，的確存在大量的連續(xù)Extents沒(méi)有合并。在DMT即字典管理表空間模式下需要SMON進(jìn)程定期維護(hù)FET$基表將tablespace上的連續(xù)空閑Extents合并為更大的一個(gè)Extents。而在LMT模式下因?yàn)椴捎脭?shù)據(jù)文件頭上(datafile header 3-8 blocks in 10g)的位圖管理區(qū)間，所以無(wú)需某個(gè)后臺(tái)進(jìn)程特意去合并區(qū)間。 為什么LMT下連續(xù)空閑Extents沒(méi)有合并而造成碎片呢？因?yàn)檫@套庫(kù)采用11gr1較不穩(wěn)定的11.1.0.6版本，所以把問(wèn)題歸咎為某個(gè)bug似乎可以講得通。一開(kāi)始我較為認(rèn)同同事的bug論，且和同事一起查詢了Metalink上11gr1上一些已知的bug，但并沒(méi)有發(fā)現(xiàn)癥狀匹配的bug note。 這讓我反思這個(gè)問(wèn)題，過(guò)早的將cause定位到bug過(guò)于主觀了，并不是所有我們預(yù)期外的情況(unexpected)都屬于bug。 實(shí)際上dba_free_space所顯示的信息可能并不"真實(shí)"，這種幻象往往由10g以后出現(xiàn)的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 以上我們通過(guò)解析10g中的dba_free_space視圖可以了解到該視圖所顯示的Free Extents由以下四個(gè)部分組成:

LMT表空間上真正空閑的Extents

DMT表空間上真正空閑的Extents

LMT表空間上被RECYCLEBIN中對(duì)象占用的Extents

DMT表空間上被RECYCLEBIN中對(duì)象占用的Extents

而在10g以前的版本中因?yàn)闆](méi)有recyclebin特性的"干擾"，所以dba_free_space所顯示的Free Extents由前2個(gè)部分組成，因此我們可以在10g中創(chuàng)建一個(gè)兼容視圖以實(shí)現(xiàn)對(duì)真正空閑空間的查詢: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 / 通過(guò)以上創(chuàng)建的dba_free_space_pre10g和dba_free_space_recyclebin視圖，我們可以很明確地區(qū)分表空間上空閑Extents。 針對(duì)本例中的LMT上存在大量連續(xù)的空閑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中存在大量的小"對(duì)象"從而造成了LMT上出現(xiàn)大量碎片的假象SQL> select space,count(*) from dba_recyclebin where ts_name='FRAGMENT' group by space;SPACE COUNT(*) ---------- ----------8 5000我們可以通過(guò)purge recyclebin來(lái)"合并"這些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

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

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

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。