Oracle索引合并coalesce操作(二)

2015-04-07 14:09:51 · 作者: · 浏览: 84
536? ? ? ? ? 8


? ? ? ? 14? ? ? ? ? 1? ? ? 92584? ? ? 65536? ? ? ? ? 8


? ? ? ? 15? ? ? ? ? 1? ? ? 92592? ? ? 65536? ? ? ? ? 8


? ? ? ? 16? ? ? ? ? 1? ? ? 91776? ? 1048576? ? ? ? 128


17 rows selected


多extent结构,表示结构没有回收。下面使用analyze语句分析一下索引的情况:


SQL> analyze index idx_t_id validate structure;


Index analyzed


SQL> select height, blocks, lf_rows, lf_blks, lf_rows_len, lf_blk_len, br_rows, br_blks, del_lf_rows from index_stats;


? ? HEIGHT? ? BLOCKS? ? LF_ROWS? ? LF_BLKS LF_ROWS_LEN LF_BLK_LEN? ? BR_ROWS? ? BR_BLKS DEL_LF_ROWS


---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- -----------


? ? ? ? 2? ? ? ? 256? ? ? 77406? ? ? ? 172? ? 1227792? ? ? 7996? ? ? ? 171? ? ? ? ? 1? ? ? 77405


索引树两层结构,包括了256个数据库,叶子节点包括77406个,被删除节点77405个。


开启10046事件跟踪coalesce过程操作。


SQL> select value from v$diag_info where name='Default Trace File';?


VALUE


--------------------------------------------------------------------------------


/home/oracle/app/diag/rdbms/awpdb/awpdb/trace/awpdb_ora_14931.trc?


SQL> alter session set events '10046 trace name context forever, level 12';


Session altered.?


SQL> alter index idx_t_id coalesce;


Index altered.?


SQL> alter session set events '10046 trace name context off';


Session altered.


操作之后检查一下结构效果。


SQL> select EXTENT_ID, FILE_ID, BLOCK_ID, BYTES, BLOCKS from dba_extents where owner='SYS' and segment_name='IDX_T_ID';


?EXTENT_ID? ? FILE_ID? BLOCK_ID? ? ? BYTES? ? BLOCKS


---------- ---------- ---------- ---------- ----------


? ? ? ? 0? ? ? ? ? 1? ? ? 91704? ? ? 65536? ? ? ? ? 8


? ? ? ? 1? ? ? ? ? 1? ? ? 91712? ? ? 65536? ? ? ? ? 8


? ? ? ? 2? ? ? ? ? 1? ? ? 91720? ? ? 65536? ? ? ? ? 8


? ? ? ? 3? ? ? ? ? 1? ? ? 91728? ? ? 65536? ? ? ? ? 8


? ? ? ? 4? ? ? ? ? 1? ? ? 91736? ? ? 65536? ? ? ? ? 8


? ? ? ? 5? ? ? ? ? 1? ? ? 91744? ? ? 65536? ? ? ? ? 8


? ? ? ? 6? ? ? ? ? 1? ? ? 91752? ? ? 65536? ? ? ? ? 8


? ? ? ? 7? ? ? ? ? 1? ? ? 91760? ? ? 65536? ? ? ? ? 8


? ? ? ? 8? ? ? ? ? 1? ? ? 91768? ? ? 65536? ? ? ? ? 8


? ? ? ? 9? ? ? ? ? 1? ? ? 92544? ? ? 65536? ? ? ? ? 8


? ? ? ? 10? ? ? ? ? 1? ? ? 92552? ? ? 65536? ? ? ? ? 8


? ? ? ? 11? ? ? ? ? 1? ? ? 92560? ? ? 65536? ? ? ? ? 8


? ? ? ? 12? ? ? ? ? 1? ? ? 92568? ? ? 65536? ? ? ? ? 8


? ? ? ? 13? ? ? ? ? 1? ? ? 92576? ? ? 65536? ? ? ? ? 8


? ? ? ? 14? ? ? ? ? 1? ? ? 92584? ? ? 65536? ? ? ? ? 8


? ? ? ? 15? ? ? ? ? 1? ? ? 92592? ? ? 65536? ? ? ? ? 8


? ? ? ? 16? ? ? ? ? 1? ? ? 91776? ? 1048576? ? ? ? 128


17 rows selected


索引段存储分配没有发生变化,还是17个extent。但是索引逻辑结构已经变化:


SQL> analyze index idx_t_id validate structure;


Index analyzed


SQL> select height, blocks, lf_rows, lf_blks, lf_rows_len, lf_blk_len, br_rows, br_blks, del_lf_rows from index_stats;


? ? HEIGHT? ? BLOCKS? ? LF_ROWS? ? LF_BLKS LF_ROWS_LEN LF_BLK_LEN? ? BR_ROWS? ? BR_BLKS DEL_LF_ROWS


---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- -----------


? ? ? ? 2? ? ? ? 256? ? ? ? ? 1? ? ? ? ? 1? ? ? ? ? 16? ? ? 7996? ? ? ? ? 0? ? ? ? ? 1? ? ? ? ? 0


索引高度和分配块数量没有变化,但是叶子节点进行了重组。被删除数据节点被整理合并。


3、10046文件分析


从10046事件文件分析的情况看,如下:


=====================


PARSING IN CURSOR #139851695602760 len=29 dep=0 uid=0 oct=11 lid=0 tim=1427182487640740 hv=4054144165 ad='aa2f2710' sqlid='a88sghvsuap55'


alter index idx_t_id coalesce


END OF STMT


PARSE #139851695602760:c=17997,e=56662,p=9,cr=117,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1427182487640739


根据游标编号,可以定位到检索读取数据过程。


WAIT #139851695602760: nam='db file sequential read' ela= 8 file#=1 block#=91705 blocks=1 obj#=164093 tim=1427182487878712


WAIT #139851695602760: nam='db file sequential read' ela= 6 file#=1 block#=91706 blocks=1 obj#=164093 tim=1427182487878751


WAIT #139851695602760: nam='db file sequential read' ela= 8 file#=1 block#=91707 blocks=1 obj#=164093 tim=1427182487878989


WAIT #139851695602760: nam=