11g推出的數據壓縮技術已經打破了這個束縛，Oracle通過只存儲在保存壓縮元數據的特定表（符號表，symbol table）中有重複的列值的單個副本，消除了block中所有重複的值。Select 壓縮數據時的I/O也大大減少，進而，壓縮技術延展到了OLTP領域。
1. 10G與11G的效能比較
1.1 10G的測試
使用版本
SQL> select * from v$version;BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
1.1.1 創造一個 300M的一般Table
Table created.
SQL> insert into test select * from test;
SQL> insert into test select * from test;
197424 rows created.
SQL> /
394848 rows created.
SQL> /
789696 rows created.
SQL> /
1579392 rows created.
SQL> commit;
SQL> select segment_name,bytes/1024/1024 MB from DBA_segments where segment_name='T';
SEGMENT_NAME MB
------------------------------ ----------
T 343
1.1.2 使用CTAS 來創造Table
Table created.
SQL> select segment_name,bytes/1024/1024 MB from DBA_segments where segment_name = 'TEST_COMPRESS';
SEGMENT_NAME MB
------------------------------ ----------
TEST_COMPRESS 104
1.1.3 比較一般table 與 壓縮過後table 的佔用空間
SEGMENT_NAME MB
------------------------------ ----------
T 343
TEST_COMPRESS 104
幾乎節省了 1/3的空間 ，Oracle號稱可以達到 3.5 : 1 的壓縮比
1.1.4 比較一下select 效率 (因排版關係則使用截圖
未壓縮
有壓縮
cost 從9556 降到 2875 > 少了69%
consistent gets 從 43320 降到 12909 > 少了70%
壓縮過後 select 的 I/O 讀取數與Cpu使用率大幅度減少
1.1.5 比較一下 update 效率
Update 壓縮過後的 Table 增加了非常多的時間 , 這是因為 Oracle進行 Update時會進行解壓縮所以才導致處理時間太長
1.1.6 update 後 compress table 是否會被解壓縮 ?!
很明顯的 Update 後資料被解壓縮了, 而且並不會再自動壓縮 , 除非有啟動一些條件 Oracle 才會再進行壓縮 ( 資料量接近 PCTFREE )
以上測試証明了10G使用壓縮技術對倉儲的 Table 效果最好, 很常在Update 的 Table 就不建議了
1.2. 11G的測試
使用版本
SQL> select * from v$version;BANNER
------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
1.2.1 創造一個 300M的一般Table
Table created.
SQL> insert into test select * from test;
92640 rows created.
SQL> /
185280 rows created.
SQL> /
370560 rows created.
SQL> /
741120 rows created.
SQL> /
1482240 rows created.
SQL> commit;
Commit complete.
SQL> select segment_name,bytes/1024/1024 MB from DBA_segments where segment_name='TEST' ;
SEGMENT_NAME MB
----------------- ----------
TEST 336
1.2.2 建立 COMPRESS FOR OLTP 壓縮技術的Table
Table created.
SQL> select segment_name,bytes/1024/1024 MB from DBA_segments where segment_name='TEST_COMPRESS' ;
SEGMENT_NAME MB
---------------------- ----------
TEST_COMPRESS 120
1.2.3 比較一般table 與 壓縮過後table 的佔用空間
SEGMENT_NAME MB
----------------- ----------
TEST 336
TEST_COMPRESS 120
----------------- ----------
TEST 336
TEST_COMPRESS 120
1.2.4 比較一下select 效率 (因排版關係則使用截圖
未壓縮
cost 從12457 降到 4156 > 少了66%
consistent gets 從 42244 降到 15615 > 少了63%
1.2.5 比較一下 update 效率
結論：因為 11G 在壓縮技術的提升進行 Update 異動時不用在對 Table解壓縮就可以直接對block 做異動，所以整體處理時間大幅下降，因此對於重覆值相當多的 Big Table 使用壓縮技術比建立一般的table還來得有效率的。
2 壓縮的種類
Basic compression：只能用直接路徑加載插入的數據，並支持有限的數據類型和SQL操作。
OLTP compression：用於OLTP應用程序和壓縮任何SQL操作操縱 。
Warehouse compression和Archive compression：達到最高的壓縮級別，因為它們使用混合列壓縮技術 。(僅限於建立在 Exadata存儲上
2.1 11g壓縮技術 BASIC 與 OLTP 的效能比較
2.1.1 先建立TABLE
SQL>create table Compression_BASIC COMPRESS as select * from t;
Table created.
SQL>create table Compression_OLTP COMPRESS FOR OLTP as select * from t;
Table created.
看一下兩個Table 壓縮的種類
SQL> SELECT owner,table_name, compression, compress_for FROM dba_tables where compression = 'ENABLED';
TABLE_NAME COMPRESS COMPRESS_FOR
------------------------------ -------- ------------
COMPRESSION_BASIC ENABLED BASIC
COMPRESSION_OLTP ENABLED OLTP
SQL> SELECT segment_name, bytes / 1024 / 1024 MB
2 FROM DBA_segments
3 WHERE segment_name IN ('T', 'COMPRESSION_OLTP', 'COMPRESSION_BASIC') order by 2 desc;
SEGMENT_NAME MB
------------------------------ ----------
T 198
COMPRESSION_OLTP 72
COMPRESSION_BASIC 58
*BASIC 的壓縮比則是較 OLTP 優
2.1.2 Select 效能比較 (因排版關係則使用截圖
BASIC
OLTP
2.1.3 Update效能比較 (因排版關係則使用截圖
蝦米!!!! 還是 BASIC 較優
2.1.4 模擬實際的狀況
現在模擬一下符合實際 OLTP DB 的 table 被分條式 insert 的狀況
SQL> truncate table Compression_BASIC;
Table truncated.
SQL> declare
2 type t_list is table of t%rowtype index by binary_integer;
3 i integer;
4
5 t_infos t_list;
6 begin
7 select *
8 bulk collect into t_infos
9 from t;
10
11 for i in 1..t_infos.count loop
12 insert into Compression_BASIC values t_infos(i);
13
14 if (mod(i,1000)=0) then
15 commit;
16 end if;
17 end loop;
18
19 commit;
20 end;
21 /
PL/SQL procedure successfully completed.
SQL> truncate table Compression_OLTP;
Table truncated.
SQL> declare
2 type t_list is table of t%rowtype index by binary_integer;
3 i integer;
4
5 t_infos t_list;
6 begin
7 select *
8 bulk collect into t_infos
9 from t;
10
11 for i in 1..t_infos.count loop
12 insert into Compression_OLTP values t_infos(i);
13
14 if (mod(i,1000)=0) then
15 commit;
16 end if;
17 end loop;
18
19 commit;
20 end;
21 /
PL/SQL procedure successfully completed.
SQL> SELECT segment_name, bytes / 1024 / 1024 MB
2 FROM DBA_segments
3 WHERE segment_name IN ('T', 'COMPRESSION_OLTP', 'COMPRESSION_BASIC') order by 2 desc;
SEGMENT_NAME MB
------------------------------ ----------
T 198
COMPRESSION_BASIC 176
COMPRESSION_OLTP 80
2.1.5 比較 Select 的效能
BASIC
OLTP
cost 從6070 降到 2752 > 少了54%
consistent gets 從 22606 降到 9458 > 少了58%
最後再補一張未壓縮 table 的情形 ( 使用 OLTP 壓縮過的效能都優於未壓縮的2~3倍 )
2.1.6 結論
Oracle 11g推出的Advanced Compression 突出表現在兩個方面的優勢：其一是對OLTP系统操作的高效壓縮上，另一方面是現在對RMAN、DataPump和Dataguard等多範圍壓縮支持。查詢有壓縮的table
SELECT owner,table_name, compression, compress_for FROM dba_tables where compression = 'ENABLED';
查詢有壓縮的 partition table
SELECT table_owner,table_name, partition_name, compression, compress_for FROM dba_tab_partitions where compression='ENABLED';
沒有留言:
張貼留言