這周客戶的問題非常多，總是說我的數據不對。於是我對數據梳理了以後發現以前認爲是重複數據的，其實並不是，而是我忽略了一個維度。那麼這樣一來，我們的周詳單表就會有500多萬的數據。一個月按照4周計算，就要有2000萬條數據。而我大概計算了一下，每一個周的分區要佔用2G多的存儲空間，要知道電信給我們的空間不過是500G左右，我們大家都在用，我一個人每週消耗2G，顯然不合適。
這個時候有如下幾個解決方案，第一個，將一個月或者幾個月以前的數據幹掉，以後客戶需要的時候從數據倉庫抽取數據，然後重新展現就好了。但是這個辦法並不是很靠譜，因爲數據倉庫每一段時間會清理一些表，萬一那個時候數據沒有了，那羣客戶一定會把我五馬分屍。第二種就是對數據本身進行處理，我想到的辦法就是壓縮表——compress。
壓縮表本身的語句相當簡單，總的來講分爲兩種類型，一種普通表的壓縮，一種是分區表的壓縮。相關的語法如下：
--建立普通表 create table table1 ( ...... ) compress;
--建立分區表 create table table1 ( ... ) compress partition by range(...) ( partition part_1 values less than(...) compress, partition part_2 values less than(...) compress, ... )
如果是一個已經存在的表要進行壓縮也很簡單：
alter table table1 move compress;
如果是一個分區表的話會更加靈活，只需要壓縮你想要壓縮的表空間就可以了：
alter table tables1 move partition part_1 compress;
在我遇到的這個情況中，我傾向於在另外一個表空間新建一張分區壓縮表，然後在存儲過程每週刷新數據的時候，把指定的歷史數據轉移到這個新的表中，然後清空該分區，這種處理方法不管過多久，表的大小基本上是不變的，不用擔心時間長了數據會把表空間佔滿。
根據我在網上查閱的資料，我發現壓縮表其實和平時用rar壓縮一大堆word文件是差不多的道理，壓縮的時候需要耗費不少時間，壓縮以後效果非常明顯，佔用空間只是以前的一半甚至不到一半，但是想查閱這些數據的時候，卻要消耗比平時多的時間。據網上的資料顯示，甚至會三倍於非壓縮表。所以，壓縮表並不適合存儲當月的新鮮數據，而比較適合歷史數據的存儲，因爲客戶想看一年前的數據的情況基本不大，尤其是這種周詳單。
還有一點需要講的是，插入語句必須有hint：/*+append*/，如果不加這個是沒有辦法壓縮的。存進去還是原來那麼大。
