本地管理表空間(LMT)
?
?
??? 來(lái)學(xué)習(xí)一下LMT(Locally Managed Tablespace)的知識(shí)。雖然這個(gè)現(xiàn)在已經(jīng)很少用到了，而且基本上默認(rèn)創(chuàng)建的SYSTEM都已經(jīng)是LMT的了，這樣是無(wú)法再創(chuàng)建DMT的。所以說(shuō)這種方法其實(shí)已經(jīng)沒(méi)有什么熟練掌握的必要了，但是作為豐富知識(shí)的作用，還是可以了解一下的，因?yàn)楫吘挂策€是嘗嘗會(huì)碰到這個(gè)概念。
?
一、概述
??? 1、理解本地管理表空間的由來(lái)
??? 2、理解什么是字典管理表空間及工作原理
??? 3、理解本地管理表空間的優(yōu)勢(shì)(為什么要使用本地管理表空間)
??? 4、理解本地管理表空間的內(nèi)部結(jié)構(gòu)
??? 5、理解字典管理表空間與本地管理表空間的轉(zhuǎn)換
?
二、名詞解釋與約定
???
表空間(Tablespace)
：為數(shù)據(jù)庫(kù)提供使用空間的邏輯結(jié)構(gòu)，其對(duì)應(yīng)物理結(jié)構(gòu)是數(shù)據(jù)文件，一個(gè)表空間可以包含多個(gè)數(shù)據(jù)文件
??? 本地管理表空間(Locally Managed Tablespace簡(jiǎn)稱(chēng)LMT)：8i以后出現(xiàn)的一種新的表空間的管理模式，通過(guò)本地位圖來(lái)管理表空間的空間使用。
??? 字典管理表空間(Dictionary-Managed Tablespace簡(jiǎn)稱(chēng)DMT)：8i以前包括以后都還可以使用的一種表空間管理模式，通過(guò)數(shù)據(jù)字典管理表空間的空間使用。
??? 段(Segment)：數(shù)據(jù)庫(kù)一種邏輯結(jié)構(gòu)，如表段，索引段，回滾段等，段存在于表空間中，并對(duì)應(yīng)一定的存儲(chǔ)空間。
??? 區(qū)間<簡(jiǎn)稱(chēng)區(qū)>(Extent)：段的存儲(chǔ)可以分成一個(gè)或多個(gè)區(qū)間，每個(gè)區(qū)間占用一定數(shù)量的數(shù)據(jù)塊(block)，在本地管理的表空間中，表空間的Extent就對(duì)應(yīng)段的Extent。
??? 塊(Block)：數(shù)據(jù)庫(kù)最小的存儲(chǔ)單位，在本文中Block的大小約定為8192字節(jié)。
??? 位(Bit)：本地管理表空間的空間管理單位，一個(gè)位可能等于一個(gè)區(qū)間，也可能多個(gè)位組成一個(gè)區(qū)間。
?
三、本地管理表空間的由來(lái)
??? 在Oracle8i的版本中，Oracle推出了一種全新的表空間管理方式：本地化管理的表空間。所謂本地化管理，就是指Oracle不再利用數(shù)據(jù)字典表來(lái)記錄Oracle表空間里面的區(qū)的使用狀況，而是在每個(gè)表空間的數(shù)據(jù)文件的頭部加入了一個(gè)位圖區(qū)，在其中記錄每個(gè)區(qū)的使用狀況。每當(dāng)一個(gè)區(qū)被使用，或者被釋放以供重新使用時(shí)，Oracle都會(huì)更新數(shù)據(jù)文件頭部的這個(gè)記錄，反映這個(gè)變化。
??? 本地化管理的表空間的創(chuàng)建過(guò)程：
?
??? 語(yǔ)法：
??? CREATE TABLESPACE 表空間名字
??? DATAFILE '數(shù)據(jù)文件詳細(xì)信息'
??? [EXTENT MANAGEMENT { LOCAL
??? {AUTOALLOCATE | UNIFORM [SIZE INTETER [K|M]]}}]
?
??? 關(guān)鍵字EXTENT MANAGEMENT LOCAL 指定這是一個(gè)本地化管理的表空間。對(duì)于系統(tǒng)表空間，只能在創(chuàng)建數(shù)據(jù)庫(kù)的時(shí)候指定EXTENT MANGEMENT LOCAL，因?yàn)樗菙?shù)據(jù)庫(kù)創(chuàng)建時(shí)建立的第一個(gè)表空間。
?
??? 在8i中，字典管理還是默認(rèn)的管理方式，當(dāng)選擇了LOCAL關(guān)鍵字，即表明這是一個(gè)本地管理的表空間。當(dāng)然還可以繼續(xù)選擇更細(xì)的管理方式：是 AUTOALLOCATE 還是 UNIFORM。若為AUTOALLOCATE，則表明讓Oracle來(lái)決定區(qū)塊的使用辦法；若選擇了UNIFORM，則還可以詳細(xì)指定每個(gè)區(qū)塊的大小，若不加指定，則為每個(gè)區(qū)使用1M大小。
?
??? Oracle之所以推出了這種新的表空間管理方法，讓我們來(lái)看一下這種表空間組織方法的優(yōu)點(diǎn)：
?
??? 1. 本地化管理的表空間避免了遞歸的空間管理操作。而這種情況在數(shù)據(jù)字典管理的表空間是經(jīng)常出現(xiàn)的，當(dāng)表空間里的區(qū)的使用狀況發(fā)生改變時(shí)，數(shù)據(jù)字典的表的信息發(fā)生改變，從而同時(shí)也使用了在系統(tǒng)表空間里的回滾段。
??? 2. 本地化管理的表空間避免了在數(shù)據(jù)字典相應(yīng)表里面寫(xiě)入空閑空間、已使用空間的信息，從而減少了數(shù)據(jù)字典表的競(jìng)爭(zhēng)，提高了空間管理的并發(fā)性
??? 3. 區(qū)的本地化管理自動(dòng)跟蹤表空間里的空閑塊，減少了手工合并自由空間的需要。
??? 4. 表空間里的區(qū)的大小可以選擇由Oracle系統(tǒng)來(lái)決定，或者由數(shù)據(jù)庫(kù)管理員指定一個(gè)統(tǒng)一的大小，避免了字典表空間一直頭疼的碎片問(wèn)題。
??? 5. 從由數(shù)據(jù)字典來(lái)管理空閑塊改為由數(shù)據(jù)文件的頭部記錄來(lái)管理空閑塊，這樣避免產(chǎn)生回滾信息，不再使用系統(tǒng)表空間里的回滾段。因?yàn)橛蓴?shù)據(jù)字典來(lái)管理的話(huà)，它會(huì)把相關(guān)信息記在數(shù)據(jù)字典的表里，從而產(chǎn)生回滾信息。
?
??? 由于這種表空間的以上特性，所以它支持在一個(gè)表空間里邊進(jìn)行更多的并發(fā)操作，并減少了對(duì)數(shù)據(jù)字典的依賴(lài)。
?
?
四、本地管理表空間管理機(jī)制
??? 表空間是一種為段(表、索引等)提供空間的邏輯結(jié)構(gòu)，所以，當(dāng)在表空間中增加，刪除段的時(shí)候，數(shù)據(jù)庫(kù)就必須跟蹤這些空間的使用。
?
??? 如下例所示，假定一個(gè)新創(chuàng)建的表空間包含了5個(gè)表：
?
???
T1……T2……T3……T4……T5……Free
?
??? 當(dāng)我們刪除T4的時(shí)候，就有如下結(jié)果：
?
???
T1……T2……T3……Free……T5……Free
?
??? 很明顯，ORACLE需要有一個(gè)機(jī)制來(lái)管理表空間中各數(shù)據(jù)文件的這些分配的或未分配的空間，為了跟蹤這些可以使用的空間（包括未分配使用的和可以重復(fù)使用的），對(duì)于每一個(gè)空間，我們必須知道：
?
??? 1、這個(gè)可用空間位于什么數(shù)據(jù)文件
??? 2、這個(gè)空間的尺寸是多大
??? 3、如果它在用了，是哪一個(gè)段占用的這個(gè)空間
?
??? 直到8i之前，所有的表空間都是采用字典管理模式，為了確保能保存以上的信息，ORACLE用了兩個(gè)數(shù)據(jù)字典表:UET$(已使用的區(qū)間)或FET$(空閑空間)：
?
SQL> desc UET$
Name?? ?????????? Null??? ?? Type
----------------- ---------- -----------
SEGFILE#?? ?????? NOT NULL?? NUMBER
SEGBLOCK#?? ????? NOT NULL?? NUMBER?? | The segment that uses this space?
EXT#?? ?????????? NOT NULL?? NUMBER
TS#?? ??????????? NOT NULL?? NUMBER?? | The tablespace ID and the file?
FILE#?? ????????? NOT NULL?? NUMBER?? | ID for that tablespace?
BLOCK#?? ???????? NOT NULL?? NUMBER
LENGTH?? ???????? NOT NULL?? NUMBER?? | The location and size of the chunk?
?
SQL> desc FET$
Name?? ?????????? Null??? ?? Type
----------------- ---------- -----------
TS#?? ??????????? NOT NULL?? NUMBER?? | The tablespace ID and the file?
FILE#?? ????????? NOT NULL?? NUMBER?? | ID for that tablespace?
BLOCK#?? ???????? NOT NULL?? NUMBER
LENGTH?? ???????? NOT NULL?? NUMBER?? | The location and size of the chunk
?
??? 查詢(xún)?cè)摫砜梢钥吹剑總€(gè)使用空間或空閑空間(不一定是一個(gè)extent，可以是多個(gè)extent)都在該表中對(duì)應(yīng)了一行。它的工作方式是當(dāng)一個(gè)段被刪除的時(shí)候，ORACLE就移動(dòng)UET$中相應(yīng)的行到FET$，這個(gè)過(guò)程的發(fā)生是連續(xù)的，而且可能發(fā)生等待。當(dāng)并發(fā)性很高的時(shí)候，數(shù)據(jù)字典的爭(zhēng)用就來(lái)了。另外有一個(gè)問(wèn)題就是，當(dāng)表的空間很不連續(xù)或表空間有大量的碎片引起這兩個(gè)表的增大，那么也就會(huì)引起數(shù)據(jù)庫(kù)性能上的下降。
?
??? 本地管理表空間正是為了解決這一問(wèn)題來(lái)的，在表空間的空間管理上，ORACLE將存儲(chǔ)信息保存在表空間的頭部的位圖中，而不是保存在數(shù)據(jù)字典中。通過(guò)這樣的方式，在分配回收空間的時(shí)候，表空間就可以獨(dú)立的完成操作也不用與其它對(duì)象關(guān)系。
?
??? 下面就讓我們進(jìn)入到本地管理表空間的內(nèi)部，看看ORACLE是怎么實(shí)現(xiàn)這一工作的。
?
Uniform方式的本地管理表空間
1、先創(chuàng)建了一個(gè)本地管理的表空間，區(qū)間統(tǒng)一大小分配為64K
?
SQL> create tablespace demo?
2?? datafile '/ora01/oem/oemdemo01.dbf' size 10m?
3?? extent management local uniform size 64k;?
?
2、在該表空間中創(chuàng)建一個(gè)表
?
SQL>create table demotab ( x number ) tablespace demo?
2?? storage ( initial 1000K next 1000k );?
?
我們通過(guò)查詢(xún)?cè)摫?br />
?
SQL> select t.table_name,t.initial_extent,t.next_extent from user_tables t where t.table_name = 'DEMOTAB';
TABLE_NAME?????????????????? INITIAL_EXTENT NEXT_EXTENT
---------------------------- -------------- -----------
DEMOTAB?????????????????????? ????? 1024000 ?? ?? 65536
?
可以發(fā)現(xiàn)，該表的存儲(chǔ)參數(shù)并不是我們指定的參數(shù)INITIAL_EXTENT，而是uniform size的整數(shù)倍，NEXT_EXTENT則等于uniform size。我們從該查詢(xún)就也可以看到如下情況
?
SQL>select count(*) from user_extents where segment_name = 'DEMOTAB';?
COUNT(*)?
----------?
??????? 16?
?
也就是說(shuō)，該表在該表空間中已經(jīng)存在16個(gè)extent，而不是一個(gè)extent(這是與字典管理的差別，如果是字典管理的表空間，如果創(chuàng)建以上的表，該查詢(xún)的結(jié)果是1)
?
3、獲取該數(shù)據(jù)文件的文件ID
?
SQL> col name format a30 trunc?
SQL> select file#, name from v$datafile;?
?
File#?? NAME?
-----?? --------------------?
??? 1?? /oras1/oem/oemsystem01.dbf?
??? 2?? /oras3/oem/oemundo01.dbf?
??? 3?? /ora01/oem/oemoem_repository01?
??? 4?? /ora01/oem/oemrcat01.dbf?
??? 5?? /ora01/oem/oemdemo01.dbf?
?
我們可以檢查uet$與fet$
?
SQL> select count(*)?? from uet$?? where file# = 5;?
?
COUNT(*)?
----------?
???????? 0?
?
SQL> select count(*)?? from fet$?? where file# = 5;?
?
COUNT(*)?
----------?
???????? 0??? ?
?
4、可以看到，ORACLE沒(méi)有在這兩個(gè)表中保存任何信息，現(xiàn)在我們dump該數(shù)據(jù)文件的第三個(gè)塊
?
SQL> alter system dump datafile 5 block 3;?
System altered.?
?
查看DUMP文件，有如下信息
?
Start dump data blocks tsn: 5 file#: 5 minblk 3 maxblk 3?
buffer tsn: 5 rdba: 0x01400003 (5/3)?
scn: 0x0000.202f7a6f seq: 0x01 flg: 0x00 tail: 0x7a6f1e01?
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap?
File Space Bitmap Block:?
BitMap Control:?
RelFno: 5, BeginBlock: 9, Flag: 0, First: 16, Free: 63472?
FFFF000000000000 0000000000000000 0000000000000000 0000000000000000?
0000000000000000 0000000000000000 0000000000000000 0000000000000000?
.....?
?
注意其中的FFFF00,，這是16進(jìn)制的表現(xiàn)方法，我們轉(zhuǎn)換為二進(jìn)制，有
?
1111,1111,1111,1111,0000,0000
?
發(fā)現(xiàn)這里有16個(gè)1，每一個(gè)1就是一個(gè)位(bit)，代表64K，也就代表了該表空間有已經(jīng)分配了的16個(gè)extent，如果我們將該表擴(kuò)展，將又有什么結(jié)果呢？
?
SQL> alter table demotab allocate extent;?
Table altered.?
?
SQL> alter table demotab allocate extent;?
Table altered.?
?
SQL> alter table demotab allocate extent;?
Table altered.?
?
這樣之后，我們應(yīng)該有19個(gè)extent了，再dump第三個(gè)塊
?
Start dump data blocks tsn: 5 file#: 5 minblk 3 maxblk 3?
buffer tsn: 5 rdba: 0x01400003 (5/3)?
scn: 0x0000.202f7c64 seq: 0x01 flg: 0x00 tail: 0x7c641e01?
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap?
File Space Bitmap Block:?
BitMap Control:?
RelFno: 5, BeginBlock: 9, Flag: 0, First: 19, Free: 63469?
FFFF07 0000000000 0000000000000000 0000000000000000 0000000000000000?
?
??? 除了以前的FFFF，現(xiàn)在多了07，怎么解釋呢？
?
??? 07轉(zhuǎn)換為二進(jìn)制為0000,0111，但是還是不夠解釋以上的情況，這里我們沒(méi)有考慮到字節(jié)交換的情況，因?yàn)橐陨螰F交換后還是FF，但是如果是07， 我們就必須考慮字節(jié)交換（因?yàn)橛?jì)算機(jī)是一個(gè)字節(jié)一個(gè)字節(jié)的寫(xiě)，一個(gè)字節(jié)占兩位當(dāng)然是先寫(xiě)后面了，如從01到0F到FF為止。 如果我們明白了，那么FFFF07轉(zhuǎn)換為二進(jìn)制為 1111,1111,1111,1111,0000,0111。
?
??? 每個(gè)字節(jié)交換得
?
??? 1111,1111,1111,1111,1110,0000
?
??? 可以發(fā)現(xiàn)，這里有19個(gè)1，也就是19個(gè)位(bit)，代表了現(xiàn)在的19個(gè)extent。
?
5、同樣我們dump該數(shù)據(jù)文件第9個(gè)塊，則有
?
Start dump data blocks tsn: 5 file#: 5 minblk 9 maxblk 9
buffer tsn: 5 rdba: 0x01400003 (5/3)?
scn: 0x0000.202f7c64 seq: 0x01 flg: 0x00 tail: 0x7c641e01?
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap?
?
?? Extent Control Header
?? -----------------------------------------------------------------
?? Extent Header:: spare1: 0??? space2: 0??? #extents: 16???? #blocks: 127
?????????????? last map?? 0x00000000?? #maps: 0??? offset: 4128?
?? Highwater::?? 0x01c0000a??? ext#: 0??? blk#: 0??? ext size: 7???
?? #blocks in seg. hdr's freelists: 0???
?? #blocks below: 0???
?? mapblk?? 0x00000000?? offset: 0???
?? Disk Lock:: Locked by scn:?? 0x0006.012.00000017
??? Map Header:: next?? 0x00000000?? #extents: 16 obj#: 3090 flag: 0x40000000
?? Extent Map
?? -----------------------------------------------------------------
??? 0x01c0000a?? length: 7???
??? 0x01c00011?? length: 8???
??? 0x01c00019?? length: 8???
??? 0x01c00021?? length: 8???
??? 0x01c00029?? length: 8???
??? 0x01c00031?? length: 8???
??? 0x01c00039?? length: 8???
??? 0x01c00041?? length: 8???
??? 0x01c00049?? length: 8???
??? 0x01c00051?? length: 8???
??? 0x01c00059?? length: 8???
??? 0x01c00061?? length: 8???
??? 0x01c00069?? length: 8???
??? 0x01c00071?? length: 8???
??? 0x01c00079?? length: 8???
??? 0x01c00081?? length: 8???
?
?? nfl = 1, nfb = 1 typ = 1 nxf = 0
?? SEG LST:: flg: UNUSED lhd: 0x00000000 ltl: 0x00000000 End dump data blocks tsn: 5 file#: 5 minblk 9 maxblk 9
?
??? 這是該數(shù)據(jù)文件中表DEMOTAB的表頭(一個(gè)塊)信息， 從這里可以看到，該表從第9個(gè)塊開(kāi)始使用Highwater::?? 0x01c0000a已經(jīng)是第10個(gè)塊了，從以上列表，我們也能清楚的看到，該表耗費(fèi)了16個(gè)區(qū)間
?
??? 由于該表是數(shù)據(jù)文件的第一個(gè)表，所以位圖區(qū)占用從3到8共6個(gè)塊，加上前面兩個(gè)文件頭，也就是說(shuō)，在數(shù)據(jù)文件頭部共8個(gè)塊用于系統(tǒng)消耗。如果我們的db_block_size為8192，那么很明顯，
占用的空間為64K。
?
??? 也因?yàn)閮H僅操作數(shù)據(jù)文件頭部幾個(gè)塊，不用操作數(shù)據(jù)字典，所以O(shè)RACLE在本地管理的表空間中添加，刪除段的時(shí)候，效率要比字典管理的表空間快。特別是在并發(fā)性很強(qiáng)的空間請(qǐng)求中。
ORACLE通過(guò)強(qiáng)制性的手段使本地管理表空間中的所有Extent是同樣大小的，盡管你可能自定義了不同的存儲(chǔ)參數(shù)。
?
6、補(bǔ)充一些字典管理表空間的不同
?
??? a. 如果是字典管理，表空間中的表的區(qū)間的大小取決于表的存儲(chǔ)參數(shù)，如果沒(méi)有定義，則取表空間的通用存儲(chǔ)參數(shù)。所以每個(gè)表的區(qū)間大小可以不一樣。
??? b. 如果不指定表的最少區(qū)間數(shù)，那么默認(rèn)創(chuàng)建的時(shí)候，該表只有一個(gè)區(qū)間，而不是多個(gè)區(qū)間。
??? c. 字典管理的文件頭只占用一個(gè)塊，第一個(gè)表的HWM應(yīng)當(dāng)是Highwater:: x01c00003，關(guān)于這個(gè)可以自己dump該數(shù)據(jù)文件查看。
?
?
Autoallocate的本地管理表空間
?
在自動(dòng)分配的本地管理的表空間中，區(qū)間尺寸可能由以下尺寸組成64k, 1m, 8m, 64m 甚至是256m。但是不管多大，都有一個(gè)通用尺寸64k，所以64K就是該表空間的位大小。
?
SQL> create tablespace dummy
2?? datafile 'c:\dummy01.dbf' size 100m
3?? autoallocate;
Tablespace created.
?
SQL> create table x1 (x number)
2?? tablespace dummy
3?? storage (initial 50M);
Table created.
?
SQL> select file# from v$datafile where name like '%DUMMY%';
?
FILE#
----------
?? ???? 12
?
SQL> select extents from user_segments
where segment_name = 'X1' ;
?
EXTENTS
---------
?????? 50
?
SQL> alter system dump datafile 12 block 3;
System altered.
?
*** SESSION ID11.59) 2002-11-22 10:37:35.000
Start dump data blocks tsn: 19 file#: 12 minblk 3 maxblk 3
buffer tsn: 19 rdba: 0x03000003 (12/3)
scn: 0x0000.00f2959b seq: 0x01 flg: 0x00 tail: 0x959b1e01
frmt: 0x02 chkval: 0x0000 type: 0x1e=KTFB Bitmapped File Space Bitmap
File Space Bitmap Block:
BitMap Control:
RelFno: 12, BeginBlock: 9, Flag: 0, First: 800, Free: 62688
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF
FFFFFFFF00000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000??????
?
可以看到該表實(shí)際只有50個(gè)區(qū)間(extent)，但是有800個(gè)位(bit)
50*1024=800*64
還可以看出，位大小并不等于extent大小
?
?
五、遷移到本地管理表空間
??? 在很多情況下，如果你想在字典表空間與本地表空間之間轉(zhuǎn)換是很難的，你可能需要轉(zhuǎn)出該表空間所有的數(shù)據(jù)，從新創(chuàng)建表空間，再加載該數(shù)據(jù)。但是在816以后，有一個(gè)叫dbms_space_admin的包使兩類(lèi)表空間的互相轉(zhuǎn)換變成可能，體現(xiàn)在如下兩個(gè)過(guò)程：
?
??? DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL?
??? DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL?
?
??? 但是在你想利用這個(gè)過(guò)程進(jìn)行轉(zhuǎn)換的時(shí)候，你必須注意兩件事：
?
??? 1、 數(shù)據(jù)庫(kù)版本必須是816以上，兼容版本(compatible)必須是8.1以上
??? 2、 如果是轉(zhuǎn)換成為本地管理，必須有足夠的空閑空間做本地位圖空間（8個(gè)塊）
?
??? 當(dāng)從字典管理到本地管理的過(guò)程中，全部轉(zhuǎn)換其實(shí)基本上是不可能發(fā)生的，實(shí)際情況是，對(duì)于已經(jīng)存在的數(shù)據(jù)和空間，該過(guò)程是沒(méi)有任何辦法的，僅僅是簡(jiǎn)單把空間 取整并標(biāo)記。所以說(shuō)，這種轉(zhuǎn)換后的表空間可以減緩UET$和FET$的壓力，但并不能解決碎片問(wèn)題。從查詢(xún)DBA_TABLESPACES你還可以看到，轉(zhuǎn)換之后的表空間管理方式是LOCAL，但實(shí)際段分配是USER(不是uniform或automatic)
?
??? 很顯然，在字典管理的表空間中，存在許多大小不同的區(qū)間(extent)尺寸，所以轉(zhuǎn)換為本地管理的時(shí)候，ORACLE怎么樣把這些已經(jīng)存在的空間轉(zhuǎn)換為通用大小了？為了做到這一點(diǎn)，ORACLE必須掃描該表空間的每個(gè)數(shù)據(jù)文件，主要是檢查以下三個(gè)問(wèn)題：
?
??? 1、 所有的已經(jīng)存在的區(qū)間
??? 2、 所有的以前用過(guò)，但是現(xiàn)在空閑的空間
??? 3、 由表空間MINIMUM EXTENT語(yǔ)句標(biāo)記的大小
?
??? 在轉(zhuǎn)換的時(shí)候，ORACLE試圖發(fā)現(xiàn)一個(gè)適合于以上三個(gè)標(biāo)準(zhǔn)的最大的區(qū)間的尺寸作為本地管理的區(qū)間尺寸，也就是說(shuō)，在最壞的情況下，這個(gè)最大的區(qū)間可能就是單個(gè)塊(如果說(shuō)一個(gè)表的區(qū)間尺寸是7個(gè)塊，另外一個(gè)表的區(qū)間尺寸是8個(gè)塊)
?
??? 我們看一個(gè)從字典管理表空間到本地管理表空間的例子
?
1、首先，我們創(chuàng)建一個(gè)字典管理表空間
?
SQL> create tablespace blah?
2?? datafile 'G:\ORA9I\ORADATA\DB9\BLAH.DBF' size 10m reuse?
3?? extent management dictionary;?
Tablespace altered.?
?
SQL> col bytes format 999,999,999?
SQL> select * from dba_free_space where tablespace_name = 'BLAH';?
?
TABLESPACE_NAME FILE_ID? BLOCK_ID?? BYTES?? ??? BLOCK?? RELATIVE_FNO?
--------------- -------- ----------- ----------- ------- ----------------?
BLAH?? ??????????????? 8?? ??????? 2? 10,477,568?? 1279? ???????????? 8?
?
2、我們?cè)谏厦鎰?chuàng)建三個(gè)表，最小公用尺寸是400K
?
SQL> create table t1 ( x number ) storage ( initial 400k) tablespace blah;?
Table created.?
?
SQL> create table t2 ( x number ) storage ( initial 800k) tablespace blah;?
Table created.?
?
SQL> create table t3 ( x number ) storage ( initial 1200k) tablespace blah;?
Table created.?
?
SQL> select * from dba_free_space where tablespace_name = 'BLAH';?
?
TABLESPACE_NAME FILE_ID? BLOCK_ID?? BYTES?? ??? BLOCK?? RELATIVE_FNO?
--------------- -------- ----------- ----------- ------- ----------------?
BLAH?? ??????????????? 8?? ????? 302?? 8,019,968?? ? 979?? ???????????? 8?
?
SQL> select bytes from dba_extents where tablespace_name = 'BLAH';?
?
BYTES?
----------?
409,600?
819,200?
1,228,800?
?
3、現(xiàn)在我們開(kāi)始轉(zhuǎn)換該表空間為本地管理的表空間，假定每個(gè)位圖大小400K，也就是50個(gè)塊。
?
SQL> exec dbms_space_admin.TABLESPACE_MIGRATE_TO_LOCAL('BLAH',50);?
BEGIN dbms_space_admin.TABLESPACE_MIGRATE_TO_LOCAL('BLAH',50); END;?
?
*?
ERROR at line 1:?
ORA-03241: Invalid unit size?
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 0?
ORA-06512: at line 1?
如果我們?cè)O(shè)置表空間的minimum extent語(yǔ)句為400K：
SQL> alter tablespace blah minimum extent 400k;?
Tablespace altered.?
?
SQL> exec dbms_space_admin.TABLESPACE_MIGRATE_TO_LOCAL('BLAH',50);?
PL/SQL procedure successfully completed.?
Conversion goes through with no problems.
?
??? 從以上可以看到，轉(zhuǎn)換成功，但實(shí)際情況遠(yuǎn)遠(yuǎn)比這么復(fù)雜，或許你根本就不知道表空間里面的公用尺寸是多大。而且通過(guò)這種轉(zhuǎn)換后的表空間，并沒(méi)有消除碎片，也不一定有優(yōu)化的作用。所以建議不要用該方法進(jìn)行轉(zhuǎn)換，而是使用alter table move的辦法進(jìn)行表空間的轉(zhuǎn)換將可能是最好的辦法。
?
?
?
?
?
?
?
再轉(zhuǎn)一些其他的論述
?
*************************************************************************************
本地管理表空間與字典管理表空間的比較
?
??? 本地管理表空間與字典管理表空間相比大大提高了管理效率和數(shù)據(jù)庫(kù)性能，其優(yōu)點(diǎn)如下：
1.減少了遞歸空間管理
??? 本地管理表空間是自己管理分配，而不是象字典管理表空間需要系統(tǒng)來(lái)管理空間分配，本地表空間是通過(guò)在表空間的每個(gè)數(shù)據(jù)文件中維持一個(gè)位圖來(lái)跟蹤在此文件中 塊的剩余空間及使用情況。并及時(shí)做更新。這種更新只對(duì)表空間的額度情況做修改而不對(duì)其他數(shù)據(jù)字典表做任何update操作，所以不會(huì)產(chǎn)生任何回退信息，從 而大大減少了空間管理，提高了管理效率。同時(shí)由于本地管理表空間可以采用統(tǒng)一大小分配方式(UNIFORM),因此也大大減小了空間管理，提高了數(shù)據(jù)庫(kù)性 能。
2.系統(tǒng)自動(dòng)管理extents大小或采用統(tǒng)一extents大小
??? 本地管理表空間有自動(dòng)分配(AUTOALLOCATE)和統(tǒng)一大小分配(UNIFORM)兩種空間分配方式，自動(dòng)分配方式(AUTOALLOCATE)是 由系統(tǒng)來(lái)自動(dòng)決定extents大小，而統(tǒng)一大小分配(UNIFORM)則是由用戶(hù)指定extents大小。這兩種分配方式都提高了空間管理效率。
3.減少了數(shù)據(jù)字典之間的競(jìng)爭(zhēng)
??? 因?yàn)楸镜毓芾肀砜臻g通過(guò)維持每個(gè)數(shù)據(jù)文件的一個(gè)位圖來(lái)跟蹤在此文件中塊的空間情況并做更新，這種更新只修改表空間的額度情況，而不涉及到其他數(shù)據(jù)字典表，從而大大減少了數(shù)據(jù)字典表之間的競(jìng)爭(zhēng)，提高了數(shù)據(jù)庫(kù)性能。
4.不產(chǎn)生回退信息
??? 因?yàn)楸镜毓芾肀砜臻g的空間管理除對(duì)表空間的額度情況做更新之外不修改其它任何數(shù)據(jù)字典表，因此不產(chǎn)生回退信息，從而大大提高了數(shù)據(jù)庫(kù)的運(yùn)行速度。
?
5.不需合并相鄰的剩余空間
??? 因?yàn)楸镜毓芾肀砜臻g的extents空間管理會(huì)自動(dòng)跟蹤相鄰的剩余空間并由系統(tǒng)自動(dòng)管理，因而不需要去合并相鄰的剩余空間。同時(shí)，本地管理表空間的所有extents還可以具有相同的大小，從而也減少了空間碎片。
6.減少了空間碎片
7.對(duì)臨時(shí)表空間提供了更好的管理
?
*************************************************************************************
?
Oracle之所以推出了這種新的表空間管理方法，讓我們來(lái)看一下這種表空間組織方法的優(yōu)點(diǎn)：
??? 1. 本地化管理的表空間避免了遞歸的空間管理操作。而這種情況在數(shù)據(jù)字典管理的表空間是經(jīng)常出現(xiàn)的，當(dāng)表空間里的區(qū)的使用狀況發(fā)生改變時(shí)，數(shù)據(jù)字典的表的信息發(fā)生改變，從而同時(shí)也使用了在系統(tǒng)表空間里的回滾段。
??? 2. 本地化管理的表空間避免了在數(shù)據(jù)字典相應(yīng)表里面寫(xiě)入空閑空間、已使用空間的信息，從而減少了數(shù)據(jù)字典表的競(jìng)爭(zhēng)，提高了空間管理的并發(fā)性
??? 3. 區(qū)的本地化管理自動(dòng)跟蹤表空間里的空閑塊，減少了手工合并自由空間的需要。
??? 4. 表空間里的區(qū)的大小可以選擇由Oracle系統(tǒng)來(lái)決定，或者由數(shù)據(jù)庫(kù)管理員指定一個(gè)統(tǒng)一的大小，避免了字典表空間一直頭疼的碎片問(wèn)題。
??? 5. 從由數(shù)據(jù)字典來(lái)管理空閑塊改為由數(shù)據(jù)文件的頭部記錄來(lái)管理空閑塊，這樣避免產(chǎn)生回滾信息，不再使用系統(tǒng)表空間里的回滾段。因?yàn)橛蓴?shù)據(jù)字典來(lái)管理的話(huà)，它會(huì)把相關(guān)信息記在數(shù)據(jù)字典的表里，從而產(chǎn)生回滾信息。
??? 由于這種表空間的以上特性，所以它支持在一個(gè)表空間里邊進(jìn)行更多的并發(fā)操作，并減少了對(duì)數(shù)據(jù)字典的依賴(lài)。
?
??? 對(duì)于每一個(gè)空間，我們必須知道：
??? 1、這個(gè)可用空間位于什么數(shù)據(jù)文件
??? 2、這個(gè)空間的尺寸是多大
??? 3、如果它在用了，是哪一個(gè)段占用的這個(gè)空間
?
??? 本地化管理的表空間上，ORACLE將存儲(chǔ)信息保存在表空間的頭部的位圖中，而不是保存在數(shù)據(jù)字典中。通過(guò)這樣的方式，在分配回收空間的時(shí)候，表空間就可以獨(dú)立的完成操作也不用與其它對(duì)象關(guān)系。
?
*************************************************************************************
?
?
?