這周客戶的問題非常多，總是說我的資料不對。於是我對資料梳理了以後發現以前認為是重複資料的，其實並不是，而是我忽略了乙個維度。那麼這樣一來，我們的周詳單錶就會有500多萬的資料。乙個月按照4周計算，就要有2000萬條資料。而我大概計算了一下，每乙個周的分割槽要占用2g多的儲存空間，要知道電信給我們的空間不過是500g左右，我們大家都在用，我乙個人每週消耗2g，顯然不合適。
這個時候有如下幾個解決方案，第乙個，將乙個月或者幾個月以前的資料乾掉，以後客戶需要的時候從資料倉儲抽取資料，然後重新展現就好了。但是這個辦法並不是很靠譜，因為資料倉儲每一段時間會清理一些表，萬一那個時候資料沒有了，那群客戶一定會把我五馬分屍。第二種就是對資料本身進行處理，我想到的辦法就是壓縮表——compress。
--建立普通表create
table
table1
( ......
) compress;
--建立分割槽表
create
table
table1
( ...
) compress
partition
byrange(...)
( partition part_1
values
less than(...) compress,
partition part_2
values
less than(...) compress,
...)
如果是乙個已經存在的表要進行壓縮也很簡單：
altertable table1 move compress;
如果是乙個分割槽表的話會更加靈活，只需要壓縮你想要壓縮的表空間就可以了：
altertable tables1 move partition part_1 compress;
在我遇到的這個情況中，我傾向於在另外乙個表空間新建一張分割槽壓縮表，然後在儲存過程每週重新整理資料的時候，把指定的歷史資料轉移到這個新的表中，然後清空該分割槽，這種處理方法不管過多久，表的大小基本上是不變的，不用擔心時間長了資料會把表空間佔滿。
根據我在網上查閱的資料，我發現壓縮表其實和平時用rar壓縮一大堆word檔案是差不多的道理，壓縮的時候需要耗費不少時間，壓縮以後效果非常明顯，占用空間只是以前的一半甚至不到一半，但是想查閱這些資料的時候，卻要消耗比平時多的時間。據網上的資料顯示，甚至會三倍於非壓縮表。所以，壓縮表並不適合儲存當月的新鮮資料，而比較適合歷史資料的儲存，因為客戶想看一年前的資料的情況基本不大，尤其是這種周詳單。
一周以來的工作總結
這周客戶的問題非常多，總是說我的資料不對。於是我對資料梳理了以後發現以前認為是重複資料的，其實並不是，而是我忽略了乙個維度。那麼這樣一來，我們的周詳單錶就會有500多萬的資料。乙個月按照4周計算，就要有2000萬條資料。而我大概計算了一下，每乙個周的分割槽要占用2g多的儲存空間，要知道電信給我們的空...
一周以來工作總結 關於高水位線
我們都知道，表中的資料其實是存在在資料塊中的，資料塊中有一部分是used，有一部分是freespace，在你插入若干條資料之後，資料塊就被占用了，因此會出現以下情況 我發現把自己已經掌握的知識像寫書一樣寫出來，會讓你的知識得到昇華，讓你系統的知道自己會什麼，不會什麼，什麼精通，什麼略懂。我最近就在整...
一周工作總結
一周又過去了，感覺時間過得快，又覺得慢。這不上次寫部落格離現在已經一周了，但上次寫部落格的情景還很清晰，故為快。這過去的幾天比較充實，也許因為這樣覺得時間也慢吧。下面簡要回顧下上週工作吧，做個小總結。上次還認為工作是嵌入式開發，會跟硬體打交道多，對硬體開發平台和軟體開發環境還只是初步了解。根據現在的...