計算LMT表空間的大小該怎么建是最優的
2024-07-21 02:39:39
供稿：網友
1。使用LMT時，不更新數據字典，不產生回滾活動。
2。自動跟蹤相鄰的自由空間，不需要合并盤區。
3。通過更新自由塊和已用塊的位映射來治理空間，避免了遞歸的空間治理操作。
4。有UNIFORM和AUTOALLOCATE兩種指定盤區大小方法，缺省為AUTOALLOCATE
5。臨時表空間用LMT治理則僅僅只能用UNIFORM分配方式
6。針對LMT，NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS, and DEFAULT STORAGE 將不再起作用
7。用UNIFORM指定一個值，表示盤區大小，缺省是1M，而對AUTOALLOCATE，你只要指定一個初始盤區的大小，Oracle會自動用一個最佳值為其他盤區指定大小，最小是64KB，這也是固定表空間中系統治理的缺省盤區大小。
這里我還不明白，這是說ORACLE為其他的盤區分配的盤區大小是不定的但最小是64Kb，不知這個理解對不對。那么初始盤區該設多大呢？最小也是64KB吧。如此說AUTOALLOCATE方式比UNIFORM方式更好嗎？
盤區的分配：
ORACLE首先在第一個屬于這個表空間的數據文件中分配一個新的盤區，先為需要的相鄰自由塊數目在這個數據文件中查找位映射（BITMAP），假如這個數據文件沒有足夠的自由塊數目，ORACLE則查找下一個數據文件。當這個盤區釋放了，ORACLE修改數據文件的位映射。
位映射治理：
假設指定的一個盤區大小是256KB，一個數據塊的大小是4KB，則
256/4=64，表示位映射中的每一位都表示64塊。
我的環境是WIN2000+ORACLE817， db_block_size=4096
問題一：理解BITMAP治理
1。首先建立表空間
SYS@ORAEXP:ADMIN> create tablespace abc datafile 'd:/oracle817/oradata/oraexp/abc.dbf' size
2 1000k extent management local uniform size 40k;
2.立即查看DBA_FREE_SPACE
SYS@ORAEXP:ADMIN> select * from dba_free_space where tablespace_name='ABC';
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
ABC 15 17 942080 230
15
這里看到block_id=17,說明已經使用了16塊，這16塊就是給這個數據文件分配的BITMAP使用的，16*4=64KB，
另外，我們建立這個表空間是1000KB，也就是250塊，但現在只有230塊，加上已用的16塊，也只有246塊，還有8塊到哪里去了？因為一個盤區是40/4=10個塊，8個塊還不能構成一個盤區，所以被浪費了。這就是為什么上面說的在建立表空間數據文件是要在數據文件大小上再加上64K的原因了。
再看看效果：
SYS@ORAEXP:ADMIN> create tablespace abc_1 datafile 'd:/oracle817/oradata/oraexp/abc_1.dbf'
2 size 1064k extent management local uniform size 40k;
SYS@ORAEXP:ADMIN> select * from dba_free_space where tablespace_name='ABC_1';
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
ABC_1 16 17 1024000 250
16
只要加上64K，就能救回很多空間來！！！
問題2：盤區的分配：
建立一張表：
SYS@ORAEXP:ADMIN> CREATE TABLE ABC(A VARCHAR2(10)) TABLESPACE ABC STORAGE
2 (INITIAL 20K NEXT 20K );
SYS@ORAEXP:ADMIN> SELECT* FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME='ABC';
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
ABC 15 27 901120 220
15
可見并沒有按照建表定義里的參數INITIAL來分配表空間，而是按照定義的UNIFORM SIZE來分配盤區的。
假如定義INITIAL參數大于UNIFORM SIZE 定義呢？
先DROP 表 ABC 恢復到表空間ABC初始定義的狀態。
再重建表ABC
SYS@ORAEXP:ADMIN> CREATE TABLE ABC(A VARCHAR2(10)) TABLESPACE ABC STORAGE
2 (INITIAL 100K NEXT 100K);
SYS@ORAEXP:ADMIN> SELECT * FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME='ABC';
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
ABC 15 47 819200 200
15
分配30塊，也就是120KB，因為建表是定義INITIAL是100KB，按照UNIFORM SIZE 40K 只能分配120KB才能滿足。
再讓表擴展一個盤區
SYS@ORAEXP:ADMIN> ALTER TABLE ABC ALLOCATE EXTENT;
表已更改。
SYS@ORAEXP:ADMIN> SELECT * FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME='ABC';
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS
------------------------------ ---------- ---------- ---------- ----------
RELATIVE_FNO
------------
ABC 15 57 778240 190
15
看出只用了10塊，也就是40KB，還是按照UNIFORM SIZE 40K分配的，并沒有使用建表里NEXT 100KB參數。
SYS@ORAEXP:ADMIN> L
1 SELECT INITIAL_extent,next_extent,min_extentS,max_extentS from dba_segmentS
2* where segment_name='ABC'
SYS@ORAEXP:ADMIN> /
INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS
-------------- ----------- ----------- -----------
102400 40960 1 2147483645
這里就可以看到ABC表的初始盤區是100KB，具體盤區分配：
SYS@ORAEXP:ADMIN> select extent_id,file_id,block_id,bytes,blocks from
2 dba_extents where segment_name='ABC';
EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS
---------- ---------- ---------- ---------- ----------
0 15 17 40960 10
1 15 27 40960 10
2 15 37 40960 10
3 15 47 40960 10
得到結論：
1。建LMT表空間時，考慮在建立的數據文件大小上再加64KB
2。對于LMT表空間，建表STORAGE里的參數基本沒什么用處了，僅僅是在第一次分配時參考INITIAL和NEXT參數分配空間，實際還是按照UNIFORM SIZE來分配盤區。EXP/IMP時應該避免使用COMPRESS=Y參數，否則初始盤區會很大的。
要做到準確的性能測試，其實是很復雜的。
一般而言，雖然LMT的表空間不會比DICT的表空間性能上強很多，但是不會更差 的。
你要做性能的對比測試，應該給他們完全相等的條件。
比如，你第一次已經做了測試，做了大量的數據插入，但是在第二次做測試的時候，可能就會出現ckpt 不能完成的情況。這樣一來，第二次的性能數據肯定會大大打折扣的。
至于空間治理，我現在的，基本上都采用了LMT ＋ Uniform 的大小，按照表的增長和大
小來劃分不同的表空間。
基本上不再區分索引和表了。
