混合列壓縮

『壹』 資料庫插入數據時報ora-08103錯誤 再次執行該插入語句通過

【Oracle數據恢復】ORA-08103錯誤解析

如果自己搞不定可以找詩檀軟體專業資料庫修復團隊成員幫您恢復!
ORA-8103是我們Database Consultant 經常要遇到的一個問題，了解ORA-8103的成因非常重要。
【數據恢復】利用構造ROWID實現無備份情況下繞過ORA-1578、ORA-8103、ORA-1410等邏輯/物理壞塊問題
簡單來說ORA-8103 的主要成因有2類:
數據塊的 block type 類型 是 無效的 或者讀出來的塊類型與Oracle期望的不一致。 例如 Oracle 認為該數據塊的類型為data(type=6)，但實際卻不是。
數據塊中的data_object_id 和 數據字典中的data_object_id不匹配

針對ORA-8103問題 我們優先推薦一些措施：
ORA-08103問題的診斷最好是能生成8103錯誤的ERROR STACK TRACE， 在TRACE中會記錄具體引發8103的對象的OBJ和OBJD，這便於我們定位可能存在corruption的對象。
問題在於往往前台進程遇到ORA-08103錯誤不會在後台生成TRACE文件，這需要我們手動設置8103 觸發ERRORSTACK的EVENTS:
ALTER SYSTEM SET EVENTS 』8103 TRACE NAME ERRORSTACK LEVEL 3′;
解決思路包括：
1. 通過OBJD和DBA定位到具體的表名和塊號
2. 有條件的情況下對該表做一個analyze .. validate structure
3. 有條件的情況下對該表所在tablespace做一個 dbms_space_admin.ASSM_TABLESPACE_VERIFY
4. 有條件的情況下move這張表或者相關的分區，嘗試繞過該問題
5. 有條件的情況下降該表或分區移動到MSSM表空間上，繞過該問題
execute dbms_space_admin.tablespace_verify(『&tablespace_name』)
oradebug setmypid
oradebug tracefile_name
execute dbms_space_admin.assm_tablespace_verify(『&tablespace_name』,dbms_space_admin.TS_VERIFY_BITMAPS)
oradebug setmypid
oradebug tracefile_name

針對不同的 analyze validate structure 後得到的結果 ， 我們可以得到一些初步的結論：

如果執行 flush buffer cache之後再次analyze validate structure不再報ORA-8103錯誤則說明：
可能是完全正常的現象，之前的ORA-8103正是也因為對象正在被DROP/TRUNCATE而導致SELECT報ORA-8103。一般來說Call Stack會顯示進程正嘗試訪問該段的segment header。 更多信息可以參考BUG 7441661
也可能該問題僅僅發生在buffer cache層，而沒有發生在DISK上。通過flush buffer_cache若能解決，則一般是這種情況，往往是Buffer Cache管理的BUG 。

如果執行 flush buffer cache之後再次analyze validate structure再次報ORA-8103錯誤則說明：
如果mp對應的數據塊發現 該塊在邏輯上是完整一致的(也可以用bbed/dbv工具驗證)， 則有可能是Lost Write，則不是被其他對象重格式化使用了。
這里判斷Lost Write的一個重要手段是 對塊做recover/blockrecover，如果recover能修復該塊，則說明是因為Lost Write引起了本ORA-8103問題，如果不是則說明99%的可能性是BUG引起的。
常見的一種現象是 使用第三方工具在資料庫打開的情況下 資料庫，這些工具的BUG可能導致 老的版本的block到目標新庫中。

另一種可能是 extent盤區級別的不一致。 同一個數據塊/extent 可能 同時屬於 2個數據段segment，這導致其中的一個被後者覆蓋。 通過recover的方式是無法修復這種場景的， 因為這種邏輯的訛誤發生在表空間級別的extent信息上。 可以檢查dba_extents/dba_segments/dba_free_space這些視圖來確定問題數據塊到底是否同時屬於多個對象， 或者 一個數據塊 同時出現在dba_extents/dba_segments/dba_free_space 三個視圖中， 因為 used extent 不該出現在dba_free_space中，而free extent不該在dba_extents，當然要排除recyclebin中對象的影響。 絕大多數情況下這種extent邏輯不一致的現象， 被稱作extent overlap ， 通常是Oracle Space Management空間管理層面的BUG。

在對ORA-8103問題的診斷過程中 定位問題的OBJD異常重要。應當說准確地將ORA-8103錯誤與BUG定位起來是有難度的，因為這往往需要涉及到redo mp以發現到底是哪些opcode造成了後續的objd 或 block type 不一致。在一些BUG中我們發現，由於可能的變數陳舊，造成objd的結構未合理清除， 之後就發現block上的objd是錯的了，可能遇到ORA-8103也可能是ORA-1410， 這引起了後續其他的邏輯訛誤，以至於很難通過TRACE/REDO LOG DUMP來定位原始問題所在。 這也是為什麼雖然在例如版本10.2.0.4上有幾個ORA-8103的bug Note， 但這些BUG最終未被close為real software bug即真的軟體BUG ， 大多都是不了了之，因為在用戶現場的TRACE和REDO DUMP都未必能真實定位到問題所在，這也是為什麼我們要說邏輯訛誤的分析和處理原要比物理訛誤來的復雜。

Maclean的經驗是 在有大量Oracle DB的環境下 一年出個幾次的邏輯/物理壞塊是很正常的事情， 對於物理訛誤 我們只要切實備份即可99%得解決。 而對於邏輯壞塊可做的 事情不多， 打最新的補丁 開 db_block_checking、db_block_checksum幾件事情而已。

值得一說的是 如果去讀一下ORA-8103的一些Bug Note，可以發現使用 LOB、APPEND INSERT、PARALLEL INSERT、exchange partition 、Split partition、advanced compression、HCC 混合列壓縮往往是引起ORA-8103的高危操作 ， 但實際我們又不可能放棄上述操作。

如果自己搞不定可以找ASKMACLEAN專業資料庫修復團隊成員幫您恢復!

『貳』 oracle 混合列壓縮 可以提高多少性能

"Exadata Storage Server 提供了一種非常先進的壓縮功能，稱作混合列壓縮 (HCC)，可顯著減少大型資料庫的存儲佔用。
混合列壓縮可實現最高水平的數據壓縮，由於 I/O 減少，可大幅降低成本並顯著提高性能，這對於分析負載尤為有效。存儲壓縮率取決於具體的數據類型，通常在 5 至 20 倍之間。"

『叄』 1.1 什麼是Oracle資料庫

在這里我必須插幾句，說說我對拉里•埃里森的崇拜之情。我曾經崇拜過喬布斯，不過那是我對80年代發明蘋果電腦的喬布斯的崇拜，也許iPhone是喬布斯人生輝煌的頂點，但是我只崇拜發明了那台綠色字元的小電腦的喬布斯；我也曾崇拜比爾•蓋茨，不過那是我對DOS 3.0的崇拜。但自從聽說了拉里用錘子為辦公室開辟網線通道的故事（不管這個故事是不是真實的），我就開始崇拜他了。用聖跡來命名一家公司和一個產品，這不是我們這種凡夫俗子能夠做到的。Oracle也確實像聖跡一樣，深深地影響著全世界。 Oracle RDBMS是一款十分優秀的關系型資料庫產品，Oracle從頭到尾都是一個RDBMS，是針對OLTP系統進行設計的，這一點從它底層的塊結構就可以看出。Oracle在大並發量和海量數據關系型檢索方面具有十分優越的性能，但是它並不擅長OLAP，因為它不支持列壓縮存儲（當然，從exadata開始，Oracle也能夠支持混合列壓縮，這是一種行存儲和列壓縮的混合模式，目前只在exadata資料庫一體機上實現）。與其他關系型資料庫相比，Oracle在某些方面更為優秀，但也有其不足的地方，因此它絕對不是萬能的。優勢和劣勢都是與生俱來的，這是由Oracle資料庫的基本架構和數據存儲的基礎結構所決定的，優化只能解決局部性的問題，有限度地提升其性能，但是絕對無法完全掩蓋結構性問題帶來的負面影響。Oracle的優勢在於大並發量下的高吞吐能力，因此很適合大型企業級應用。但是如果我們在一個並發量和數據量都不是很大的系統中，對Oracle和MS SQL Server進行比較，就不難發現Oracle並沒有多大的優勢，甚至在某些方面還不如後者。 再往更為本質的方面去探討，Oracle是一個RDBMS系統，也是一款應用軟體。Oracle資料庫除了將數據存儲於文件中外，還通過一個被稱為實例的後台機制向外提供服務，這兩部分我們將在隨後的兩節中詳細介紹，這里不做過多的描述。我們在這里僅僅討論作為應用程序的Oracle RDBMS系統，它必須依賴於某個操作系統或硬體體系。和我們自己編寫的程序一樣，Oracle必須適應於某個操作系統，並充分利用操作系統提供的資源，反過來，操作系統也必須能夠將資源提供給Oracle資料庫使用。在一個僅僅運行Oracle RDBMS的系統上，操作系統應該被調整為能夠將絕大多數的資源都提供給Oracle資料庫。這樣，Oracle的進程就能夠最大可能地得到足夠的系統資源。 討論這個似乎又有點跑題了，其實不然，只有充分了解Oracle的本質，我們才不會神化Oracle。Oracle的本質就是一款軟體、一個程序，那麼它就具備程序的一切特徵，包括可能出現的bug。 但是Oracle不是一個簡單的程序，而是十分復雜的體系。首先，Oracle需要將數據存儲在數據文件中，為了能夠支持大量的並發用戶訪問資料庫，並且提高資料庫的訪問性能，Oracle需要引入共享內存，從而實現資源的共享。比如，針對SQL引擎，每個SQL最終將會被解析為一系列的執行步驟，這就是我們常說的執行計劃。如果同一個SQL執行多次，每次都要重新生成執行計劃，那麼效率就比較低下了，Oracle引入了共享池來實現這方面的共享。同樣，如果一個數據塊每次讀取都要訪問文件，那麼效率就不高了，於是Oracle引入了DB Cache來緩存這些數據。同一個數據塊可能被多個用戶修改，如果每次修改就要直接存檔，那麼效率也會降低，於是Oracle設計了DBWR進程，來專門負責將數據塊寫入文件。這似乎很復雜，不過這一切對於架構師來說很好理解。架構設計的目的就是有效地將功能劃分成不同的組成部分，然後讓這些部分能夠很好地協同工作，從而達到最好的效果，因此架構師很容易做出類似的設計。 實際上，作為一個應用程序的Oracle，它的實現原理是十分朴實的，並不像我們想像的那麼神秘。前幾天我碰到一個案例，有個客戶的Oracle 9.2.0.6資料庫突然出現了故障，sqlplus通過sysdba能夠登錄，並且能夠訪問一些系統視圖，比如v$session，但如果使用普通用戶登錄就會被掛起。通過HANGANALYZE工具分析，沒有發現任何異常。然而，在檢查Oracle後台進程的時候，我們發現所有的Oracle後台進程和絕大多數前台進程都消失了。客戶很是不解，為什麼會這樣呢？檢查日誌，沒有發現任何異常。於是我們使用shutdown abort關閉了實例，並且進行了重啟。我們都覺得沒有日誌，很難分析，也就沒有深入研究。 第二天，客戶又找到了我，說資料庫又出現了昨天的情況，這回所有的Oracle進程，包括前台進程、後台進程，統統沒有了，而且沒有任何的日誌產生。我考慮了半天，突然有所感悟，Oracle的實例實際上也是一款應用軟體，由多個進程組成，任何一個進程發現系統存在異常，都會第一時間記錄日誌，如果問題十分嚴重，就會關閉實例。我們可以使用sysdba賬號登錄系統，並且能夠在HANGANALYZE工具中看到會話的信息，說明Oracle的共享內存還存在，只是所有的進程都沒有了。這種情況只有一種可能，就是所有的Oracle後台進程都是在同一個時間點被終止的，而且不是程序自己退出的（因為程序自己退出，應該有機會完成自己的退出業務邏輯，比如寫日誌記錄故障），而是被外力強行終止的。 從上面的分析，很自然就能聯想到Oracle的後台進程很可能是被人為殺掉了。於是我做了一個實驗，發現如果殺掉所有的後台進程，Oracle的共享內存還是存在的，並且能夠通過sysdba賬號訪問，普通用戶登錄由於缺乏後台進程的支持，會被掛起。這個現象和客戶目前碰到的問題十分相似。 發現這個問題的真相只有一個渠道，就是從應用程序本質上去考慮，這樣才能得出所有的後台進程都是在同一時間被終止的結論，並找出其原因。只有外部力量的介入，才有可能出現所有後台進程全部終止，而共享內存還保持正常的現象，這絕對不是某個bug能產生的結果。排除了bug的影響，我們才能把主要精力集中在正確的方向上。 到這里，對於這個案例的分析就接近尾聲了，本節並沒有很深入地介紹什麼是Oracle，而是更加直接地介紹了Oracle的本質。Oracle在本質上就是一組應用軟體，它也具備所有應用軟體所具備的特徵。了解這一點，是我們今後解決任何問題的基礎。任何看似妖異的現象，都離不開Oracle作為應用軟體的本質，都無法違背應用軟體所遵循的規律。 作為應用程序的Oracle，必須依賴於其運行的系統環境，Oracle資料庫的處理能力和性能也依賴於主機硬體、存儲、網路和操作系統等因素，因此作為DBA不能僅僅就Oracle而論Oracle，還必須熟悉Oracle運行所依賴的環境。作為應用程序的Oracle，會和操作系統中的其他進程競爭有限的系統資源，因此，在資料庫伺服器上做一些比較大的操作時，一定要謹慎，因為這些操作可能會使Oracle資料庫出現問題。 Oracle不僅是特殊的應用程序，更是龐大的資料庫管理系統，它包含了一個RDBMS管理系統和其他一系列應用程序。Oracle的核心RDBMS管理系統包含在$ORACLE_HOME/bin/oracle映像、$ORACLE_HOME/lib/libclntsh.so等中，而sqlplus、exp等則是一些Oracle資料庫的工具。tnslsnr是Oracle的網路連接部件，用於連接客戶端到RDBMS。這些應用程序都被安裝在ORACLE HOME目錄下。 通過上述應用程序，RDBMS管理系統及其工具，用戶就可以創建、管理資料庫。另外，用戶還可以通過sqlplus工具，使用create database命令去創建一個資料庫，也可以使用startup和shutdown命令去啟動和關閉資料庫。 資料庫是獨立的，從物理結構上看，它是由一系列文件組成的，包括參數文件、口令文件、控制文件、數據文件、日誌文件等。一套完整的資料庫，只要其所有的文件都是完整的，那麼即使資料庫的RDBMS管理系統遭到破壞，只要重新安裝和資料庫版本一致的RDBMS管理系統，該資料庫就可以重新啟用。其實所謂重新啟用，本質上就是可以在某個實例中打開這個資料庫，供客戶使用。 另外需要注意的是，Oracle資料庫是一個RDBMS管理系統，其本質是關系型資料庫。關系型資料庫是十分適合OLTP應用的，因為它存儲的是一系列的關系，各種關系以表的形式被存儲起來。比如，春節前鐵路網上售票系統崩潰，有人分析這是由於鐵路系統固步自封，沒有使用國外某大廠商的產品，而選用了通用RDBMS資料庫產品所導致的性能問題，如果選用了某國際知名廠商的網狀資料庫，就不會有問題了。這個說法看似有理，實際上，如果足夠了解RDBMS，就知道其不值一駁了，因為鐵路售票系統是十分典型的OLTP應用。 另外，由於Oracle是行存儲的RDBMS資料庫，這一特點也使其十分適合OLTP應用。從Oracle資料庫的內部數據結構可以看出，Oracle在行存儲數據方面下足了功夫，甚至連行鎖都是設置在行頭中的。在行鎖的性能方面，Oracle的表現極為優秀，這一點毋庸置疑。不過這種設計，可能不適合一些經常以列為訪問對象的OLAP系統，列壓縮技術才是實現這類應用的最佳解決方案。

『肆』 oracle 什麼是compressed 表

Hybrid Columnar Compressed
首先我們要搞清楚，什麼是行壓縮，什麼叫列壓縮。我們熟悉的資料庫，如Oracle，MySQL等都是基於行的資料庫，就是行的不同欄位物理上存放在一起，還有一種是基於列的資料庫，就是每個欄位的不同行物理上存放在一起。他們的優缺點同樣突出：
基於行的資料庫，訪問一行非常方便，但是由於同一列的數據是分開存放的，如果要針對某一列進行查詢時，幾乎要掃描整個表才能得到結果。基於行資料庫的壓縮，稱為行壓縮。
基於列的資料庫，因為同一列的數據物理上放在一起，所以訪問一列非常方便，也就是說如果針對某一列進行查詢時，不需要掃描整個表，只需要掃描這一列的數據就可以了，但是訪問一行的全部欄位非常不方便（又是廢話）。基於列資料庫的壓縮，稱為列壓縮。
Oracle通常說的compress功能（包括11g R2的Advanced compress），都是行壓縮，因為Oracle是個基於行的資料庫。大概的方法就是在block頭部存放一個symbol table，然後將相同的值放在那裡，每行上相同的數據指向symbol table，以此來達到壓縮的目的。行壓縮的效果通常不好，因為我們知道行與行之間，其實相同的數據並不多。但是列壓縮則不同，因為相同列的數據類型相同，很容易達到很好的壓縮效果。
行壓縮和列壓縮都有其優缺點，而Oracle的混合列壓縮技術，實際上是融合了列壓縮的高壓縮比和行資料庫的訪問特性，將兩者的優點結合起來。Oracle提出了CU的概念（compress unit），在一個CU內，是一個基於列的存儲方式，採用列壓縮，但是一個CU內保存了行的所有欄位信息，所以在CU與CU之間，Oracle還是一個基於行的資料庫，訪問某一行，總是只在一個CU內。每個CU由一些連續的block組成，CU header中記錄了每一行的各個列在CU中的分布情況，在混合列壓縮模式下，一行通常是跨多個block的。
所以說混合列壓縮，結合了列壓縮和行訪問的特點，即可以提供非常高的壓縮率，又很好的保證了基於行類型的訪問。
Exadata的另一個重要功能是IO resource management，如果我們在一個Exadata上部署了很多個資料庫，可以用它來管理IO資源，這里就不作闡述了。
目前，我還沒有了解到在國內有Exadata的應用，而且資料也是比較少的。希望有機會可以真實的測試一下它的性能，我不懷疑他在DSS環境下的表現，但是對於OLTP類型的應用，是否真的象Oracle說的那麼強勁，還有待於驗證。

『伍』 如何把圖片壓縮成指定大小

你可以用這種在線的圖片壓縮工具，就可以把圖片文件壓縮到你期望的體積大小，比如你將壓縮數值設置到100kb，稍等幾秒鍾之後，在線圖片壓縮工具就已經把圖片的文件大小壓縮到最高100kb了。換句話說，你設定壓縮到多少kb的期望值，他壓縮完的輸出圖片就是多少kb大小了，非常方便。在線智能圖片壓縮,壓縮圖片體積大小

在線圖片智能壓縮使用步驟：

一、首先點擊加號添加需要壓縮的圖片。目前已知支持對jpg、png、webp、bmp等多種常見的圖片格式進行壓縮，如果選擇圖片後正常顯示並能夠壓縮成功，則代表支持該圖片格式。
二、可以自行修改圖片需要被壓縮到的最大寬高尺寸，默認為圖片原始的寬高尺寸，並且寬高比例是自動鎖定的，確保圖片不會變形。
三、必須設置圖片被壓縮後，期望輸出的壓縮之後圖片文件的最大佔用空間，該選項是必填的。
四、選擇圖片壓縮的演算法。默認為智能混合壓縮演算法，絕大多數情況下使用默認演算法進行圖片壓縮即可。
五、當你設置壓縮後的大小單位為」Kb「時，壓縮大小的設定值不能小於1Kb，但圖片壓縮後的最終文件大小是可以小於1Kb的。

『陸』 豐田系統狀態過濃

短期燃油修正值和長期燃油修正值的總和已超出故障設定范圍值以外，說明實際的空燃比處於過濃的狀態，解決方法如下：

1、可能是空氣流量感測器臟污或損壞以及發動機電路，油路故障，從車上拆下空氣流量感測器，使用壓縮空氣清理，再裝車觀察數據流。

2、拆檢火花塞時，發現所有氣缸的火花塞都沒有安裝到規定扭力，十分松動，並且所有氣缸的火花塞點火極點偏黑。至此，由於火花塞擰緊力矩不夠，導致火花塞點火能量不足，導致可燃混合氣燃燒不充分，超出燃油修正范圍，發動機故障燈報警。

(6)混合列壓縮擴展閱讀

汽車發動機系統過濃的故障分析：

1、混合氣過稀的主要原因是噴油量不足，各種進氣感測器不能准確檢測出進氣量。

2、積碳過多、噴油被積碳吸附，氧感測器閉環控制失效，混合氣（噴油量）過多。

3、怠速、發動機滿足扭矩，導致混合氣過濃，氧感測失效，進氣量檢測不準確。

4、過濃會出現車沒勁，排氣管子冒煙，過稀會出現放炮聲，車沒勁不穩定。

『柒』 EPA《燃油經濟性指南》十年大數據對比，這些結果你絕對想不到

十年，這個行業到底發生了多大的變化？

沒有什麼比數據更有說服力了。

青主最近簡單對比了一下EPA（美國環保署）發布的2020版和2010版的《燃油經濟性指南》，從"能效"——汽車行業最重要的技術維度——來看看這個行業的巨大變化。

這16款車型中，十年間能效提升幅度最大的是本田雅閣，2020款雅閣市區能效比2010款提升了42.9%！第二名是本田CR-V，市區能效提升了33.3%，第三名是凱美瑞2.5L，市區能效提升了31.8%。

不過，本田的能效提升主要得益於用1.5T發動機替代以前的2.4L自吸發動機，如果是同類型、同排量發動機對比，那麼10年間能效提升幅度最大的是凱美瑞2.5L，同樣搭載2.5L自吸發動機，2020款凱美瑞市區和高速工況比2010款的能效分別提升了31.8%和28.1%；

第二名是同樣搭載2.5L發動機的豐田RAV4，10年間市區和高速工況能效提升幅度是27.3%和25.0%；

第三名是寶馬5系，同樣搭載3.0T發動機的寶馬540i，市區和高速能效比10年前的寶馬535i，分別提升了29.4%和15.4%。

從上表也可以明顯看出，採用小排量增壓發動機替代大排量自吸發動機之後，市區工況能效提升幅度更加明顯，但高速工況則提升幅度有限。

和同期優秀的自吸發動機相比，小排量渦輪增壓發動機在能效上也並沒有什麼優勢。比如高爾夫1.4T，兩種工況下的能效都不如卡羅拉1.8L；翼虎1.5T的能效也同樣遜色於RAV42.5L；賓士E350雖然改用了2.0T發動機，但是市區和高速工況能效，也只是和雷克薩斯ES3.5L基本持平。

所以，如果從實際能效的角度出發，我們對小排量渦輪增壓可能真的是誤解了。

文|青主

本文來源於汽車之家車家號作者，不代表汽車之家的觀點立場。

『捌』 汽車壓縮比是指什麼

汽車壓縮比是指汽車發動機的性能，壓縮比作為發動機非常重要的參數，是活塞在下止點壓縮開始時的氣體體積與活塞在上止點壓縮終了時的氣體體積之比。從動力性和經濟性方面來說，壓縮比越大越好。壓縮比高，動力性好、熱效率高。

較高壓縮比的發動機可以使用更高標號的燃油。燃油標號越高，燃燒速度就越慢，爆震產生的可能性就越低；反之，低標號燃油的燃燒速度較快，爆震爆震產生的可能性大。

高壓縮比車輛的油品選擇。

高壓縮比的發動機如果選用低標號汽油，會使汽缸溫度劇升，汽油燃燒不完全，機器強烈震動，從而使輸出功率下降，機件受損。低壓縮比的發動機硬要用高標號油，就會出現「滯燃」現象，即壓到了頭它還不到自燃點，一樣會出現燃燒不完全現象，對發動機也沒什麼好處。

車輛越高檔對燃油質量的要求也越高，例如30萬元以上的中高檔車，就只能加95號或97號汽油，而這里說的95號和97號代表的只是汽油中的辛烷值能量的大與小，並不能說明97號汽油就比93號汽油清潔。

以上內容參考鳳凰網——解讀渦輪增壓發動機壓縮比為何這么低

『玖』 如何啟用basic compression

Oracle提供了一下幾種類型的表壓縮方法：
1、Basic Compression：壓縮等級High，CPU開銷較小
2、OLTP Compression：壓縮等級High，CPU開銷較小
3、Warehouse Compression：壓縮等級Higher，CPU開
銷較大（取決於壓縮參數是Low還是High，默認是HIGH）
4、Archive Compression：壓縮等級Highest，CPU開銷很大
（取決於壓縮參數是Low還是High，默認是LOW）
當使用Basic Compression，warehouse
Compression，Archive Compression類型的壓縮時，
盡在發生批量數據導入時才會執行壓縮。
OLTP Compression被用於聯機事務處理系統，
可以對任意的SQL操作執行數據壓縮。
Warehouse Compression和Archive Compression可
以獲得很高的壓縮等級，因為它們採用了Hybrid Columnar
（混合列）壓縮技術，Hybrid Columnar採用一種改良的列
的存儲形式替代一行為主的存儲形式。
Hybird Columnar技術允許將相同的數據存儲在一起，
提高了壓縮演算法的效率。當使用混合列壓縮演算法時，
將導致更多的CPU開銷，因此這種壓縮技術適用於更
新不頻繁的數據。
之前未壓縮的表可以通過alter table ... compression ...
語句進行壓縮。
在這種情況下，壓縮啟用前的記錄不會被壓縮，
只有新插入或更新的數據才會進行壓縮。
同樣，通過alter table ... nocompression ...語句解除對一個表的壓縮，
表內已壓縮的數據還會繼續保持壓縮的狀態，新插入的數據就不再被壓縮。
表壓縮語法：
CREATE TABLE table_name (column_defination...)
COMPRESS FOR [OLTP]|[QUERY|ARCHIVE
[LOW|HIGH]];
ALTER TABLE table_name COMPRESS FOR [OLTP]|
[QUERY|ARCHIVE [LOW|HIGH]];