繼續(xù)昨天的內(nèi)容?http://blog.itpub.net/23718752/viewspace-1624762/
我們已經(jīng)根據(jù)dba_segments和sys.seg$的不同發(fā)現(xiàn)最后的差距有2T左右，已經(jīng)定位到了dba_segments的一些細(xì)節(jié)信息，可以發(fā)現(xiàn)其實(shí)還是一個(gè)層級(jí)的調(diào)用關(guān)系。

我們把SYS_DBA_SEGS是一個(gè)處于中間層的角色，它的定義是3個(gè)union all，可以從定義中看到，差別主要還是segment_type的不同，我們采用逐個(gè)擊破的方法，一個(gè)一個(gè)來(lái)看。
-->第一個(gè)子查詢
?select NVL(u.name, 'SYS'), sum(s.blocks)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?from sys.user$ u, sys.obj$ o, sys.ts$ ts, sys.sys_objects so, sys.seg$ s,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sys.file$ f
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?where s.file# = so.header_file
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.block# = so.header_block
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = so.ts_number
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = ts.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and o.obj# = so.object_id
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and o.owner# = u.user# (+)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.type# = so.segment_type_id
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and o.type# = so.object_type_id
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = f.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.file# = f.relfile#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and u.name='PRDAPPO'
group by u.name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
NVL(U.NAME,'SYS') ? ? ? ? ? ? ?SUM(S.BLOCKS)
------------------------------ -------------
PRDAPPO ? ? ? ? ? ? ? ? ? ? ? ? ? ?323983920
SQL> select 32398390*8192/1024/1024 size_MB from dual;
? ?SIZE_MB
----------
253112.422
-->第二個(gè)子查詢。
select NVL(u.name, 'SYS')，sum( s.blocks)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?from sys.user$ u, sys.ts$ ts, sys.undo$ un, sys.seg$ s, sys.file$ f
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?where s.file# = un.file#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.block# = un.block#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = un.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = ts.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.user# = u.user# (+)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.type# in (1, 10)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and un.status$ != 1
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and un.ts# = f.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and un.file# = f.relfile#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and u.name='PRDAPPO'
group by u.name ?

no rows selected
-->第三個(gè)子查詢
select NVL(u.name, 'SYS'), sum( s.blocks)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?from sys.user$ u, sys.ts$ ts, sys.seg$ s, sys.file$ f
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?where s.ts# = ts.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.user# = u.user# (+)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.type# not in (1, 5, 6, 8, 10)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = f.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.file# = f.relfile#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and u.name='PRDAPPO'
group by u.name ? ? ? ??
no rows selected

所以看來(lái)主要的數(shù)據(jù)還是在第一個(gè)子查詢，但是如果細(xì)想，有點(diǎn)奇怪啊，基表中查到的數(shù)據(jù)是2.6T左右。那剩下的2T還沒(méi)有找到原因，到底差在哪了。
我們這個(gè)時(shí)候可以往回看，sys.seg$里的信息得到的是2.6T，dba_segments里面得到的信息是5T左右。那么唯一的差別就在于sys_dba_segs了，是不是這個(gè)中間表做了什么操作呢。
我們截取相關(guān)的字段查看一下。
select sum(decode(bitand(segment_flags, 131072), 131072, blocks,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (decode(bitand(segment_flags,1),1,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?dbms_space_admin.segment_number_blocks(tablespace_id, relative_fno,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?header_block, segment_type_id, buffer_pool_id, segment_flags,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?segment_objd, blocks), blocks))))
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?from sys_dba_segs where owner='PRDAPPO' ?;
SUM(DECODE(BITAND(SEGMENT_FLAGS,131072),131072,BLOCKS,(DECODE(BITAND(SEGMENT_FLA
--------------------------------------------------------------------------------
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?607401104

這下數(shù)字就對(duì)上了，可以看到在統(tǒng)計(jì)過(guò)程中，做了大量的判斷，可以從下面改動(dòng)的語(yǔ)句中做一些基本的分析。
SQL> select?
? ? sum(decode(bitand(segment_flags, 131072), 131072,blocks)) col1,
? ? sum(decode(bitand(segment_flags,1),1,dbms_space_admin.segment_number_blocks(tablespace_id, relative_fno,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?header_block, segment_type_id, buffer_pool_id, segment_flags,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?segment_objd, blocks))) ?col2
from sys_dba_segs where owner='PRDAPPO' group by segment_flags ;?
? 12860336 ? 12860336
? ? ? ? ? ? ? 4145504
?209686704 ?210292912
? ? ? ? ? ? 385152992
可以從上面的語(yǔ)句看出，主要的差別數(shù)據(jù)都在dbms_space_admin.segment_number_blocks調(diào)用中產(chǎn)生差異。
對(duì)此，我們需要查看一下這個(gè)包中對(duì)應(yīng)的代碼，但是不幸的是這部分代碼做了屏蔽，我們看看是怎么描述的。
?function segment_number_blocks(
? ? ? ? header_tablespace_id ? ?in ? ?natural ,
? ? ? ? header_relative_file ? ?in ? ?positive ,
? ? ? ? header_block ? ? ? ? ? ?in ? ?positive ,
? ? ? ? segment_type ? ? ? ? ? ?in ? ?positive ,
? ? ? ? buffer_pool_id ? ? ? ? ?in ? ?natural ,
? ? ? ? dictionary_flags ? ? ? ?in ? ?natural ,
? ? ? ? data_object_id ? ? ? ? ?in ? ?number,
? ? ? ? dictionary_blocks ? ? ? in ? ?number
? ? ? ? ? ? ? ? ? ? ? ? ) return pls_integer;
? pragma RESTRICT_REFERENCES(segment_number_blocks,WNDS,WNPS,RNPS);
? --
? -- Returns the number of blocks which belong to the segment. Will return
? -- NULL if segment has disappeared. IS NOT to be used for any other
? -- purposes but by the views which need it and are sure that there info
? -- is correct. Else internal errors will abound
我們繼續(xù)來(lái)看一下，盡管沒(méi)有代碼可供參考，但是我們還是能夠做些什么，至少我們可以定位到底是哪些segment在統(tǒng)計(jì)時(shí)出現(xiàn)了大的數(shù)據(jù)出入。
我們用下面的語(yǔ)句來(lái)看一下。
col segment_name format a30
col partition_name format a20
select t1.segment_name,t1.partition_name,t1.sum_blocks,t2.sum_blocks,(t1.sum_blocks-t2.sum_blocks)*8192/1024/1024 diff_size_MB
from
(select owner,segment_name,partition_name,sum(blocks) sum_blocks from dba_segments where owner='PRDAPPO' group by owner,segment_name,partition_name )t1,
(select NVL(u.name, 'SYS')owner,o.name oname,o.subname,sum(s.blocks) sum_blocks
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?from sys.user$ u, sys.obj$ o, sys.ts$ ts, sys.sys_objects so, sys.seg$ s,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sys.file$ f
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?where s.file# = so.header_file
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.block# = so.header_block
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = so.ts_number
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = ts.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and o.obj# = so.object_id
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and o.owner# = u.user# (+)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.type# = so.segment_type_id
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and o.type# = so.object_type_id
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.ts# = f.ts#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and s.file# = f.relfile#
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?and u.name='PRDAPPO' ?
group by ? ?u.name,o.name,o.subname)t2
where t1.owner=t2.owner
and t1.segment_name=t2.oname
and t1.partition_name=t2.subname
and t1.sum_blocks-t2.sum_blocks>0
order by t1.sum_blocks-t2.sum_blocks desc?
可以看到，對(duì)于不同的segment_type產(chǎn)生的數(shù)據(jù)差異?？梢钥吹皆诜謪^(qū)表中還是存在著較大的出入，數(shù)據(jù)差別 779705M+697946M+445368 大約是1.9T左右，可見(jiàn)問(wèn)題的定位找到了一些突破口。 SEGMENT_TYPE ? ? ? SUM_BLOCKS SUM_BLOCKS DIFF_SIZE_MB
------------------ ---------- ---------- ------------
TABLE PARTITION ? ? 292044544 ?192242304 ? ? ? 779705
INDEX PARTITION ? ? 131229056 ? 41891872 ? ?697946.75
LOB PARTITION ? ? ? 110592896 ? 53585792 ? ? ? 445368
INDEX ? ? ? ? ? ? ? ?27807392 ? ?4629536 ? ? ? 181077
TABLE ? ? ? ? ? ? ? ?44770432 ? 31578752 ? ? ? 103060
LOBSEGMENT ? ? ? ? ? ?5386880 ? ? 220928 ? ? ? ?40359
LOBINDEX ? ? ? ? ? ? ? ?14336 ? ? ?14336 ? ? ? ? ? ?0

通過(guò)上面的語(yǔ)句我們可以繼續(xù)分析。為什么有些分區(qū)相關(guān)的段有較大的數(shù)據(jù)差異。
同時(shí)也在Metalink上查了一下，有一篇文章：Bug 12940620??Cached block/extent counts in SEG$ not updated after ADD extent
這個(gè)里面描述的是一個(gè)bug，是關(guān)于查詢比較慢的問(wèn)題,和目前的使用的場(chǎng)景有些類似，可以做進(jìn)一步的關(guān)注。

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的深度解析dba_segments和sys.seg$中的细节差异(下)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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