深圳创业补贴政策2023,价格优化网站建设,百度搜索收录提交入口,简述网站内容管理流程这周和同事讨论技术问题时#xff0c;他告诉我客户的一套11.1.0.6的数据库中某个本地管理表空间上存在大量的Extents Fragment区间碎片#xff0c;这些连续的Extents没有正常合并为一个大的Extent#xff0c;他怀疑这是由于11.1.0.6上的bug造成了LMT上存在大量碎片。 同事判…这周和同事讨论技术问题时他告诉我客户的一套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_nameFRAGMENT;TABLESPACE_NAME EXTENT_MAN ALLOCATIO
------------------------------ ---------- ---------
FRAGMENT LOCAL SYSTEMSQL select block_id,blocks from dba_free_space where tablespace_nameFRAGMENT and rownum10;
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_nameFRAGMENT and blocks8 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_nameDBA_FREE_SPACE;TEXT
--------------------------------------------------------------------------------
DMT REAL FREE EXTENTSselect 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 allLMT REAL FREE EXTENTSselect /* 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 allLMT RECYCLEBIN FREE EXTENTSselect /* 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 allDMT RECYCLEBIN FREE EXTENTSselect 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表空间上真正空闲的ExtentsDMT表空间上真正空闲的ExtentsLMT表空间上被RECYCLEBIN中对象占用的ExtentsDMT表空间上被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_nameFRAGMENT;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_nameFRAGMENT group by blocks;COUNT(*) BLOCKS
---------- ----------5000 8显然是RECYCLEBIN中存在大量的小对象从而造成了LMT上出现大量碎片的假象SQL select space,count(*) from dba_recyclebin where ts_nameFRAGMENT 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_nameFRAGMENT group by blocks;COUNT(*) BLOCKS
---------- ----------1 262136 如果应用程序创建大量的小型堆(heap)表来存放临时数据在不再需要这些数据时将这些堆表drop掉那么就可能造成上述LMT碎片问题。我们在实际处理10g以后的这类空间问题时一定搞清楚哪些是真正的Free Extents,而哪些是来自RECYCLEBIN的Extents。 另一方面这个case还告诉我们不要一遇到预料外的行为方式(unexpected behavior)就将问题定位到bug这样会过早僵化我们的诊断预期。为了尽可能地发散思维我们有必要如围棋中所提倡的保留变化那样来安排诊断步骤。转载于:https://www.cnblogs.com/macleanoracle/archive/2013/03/19/2967801.html
