oracle壓縮表

⑴ orcale 壓縮表空間

有2種方法：
1.將你22G的表空間的DBF數據文件縮小，這樣表空間就自然變小了
2. 將這個22G的表空間中得文件移到別的表空間里，然後刪除表空間重新建立，最後再講移出的表移回來，這樣也能縮小表空間

⑵ oracle11g和oracle10g的區別

Oracle資料庫11g支持聯機事務處理 (OLAP)應用程序中常用的更新、插入和刪除操作的數據壓縮。

以前的Oracle資料庫版本支持數據倉庫應用程序常用的批量數據載入操作的壓縮。

Oracle資料庫11gOLTP表壓縮通過更加高效地使用內存來緩存數據以及減少表掃描的I/O提高了資料庫性能。

利用OLTP表壓縮，您可以利用最小的處理開銷達到2到3倍的壓縮比。

⑶ Oracle表壓縮真的好用么

對重復欄位多的，偏查詢的那種還可以

⑷ 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說的那麼強勁，還有待於驗證。

⑸ Oracle 11g 壓縮表無法增加刪除欄位

alter table tableName move nocompress;
ok

直接alter table tableName move nocompress後能增加列，但無法增加帶default值的列
設置為 move nocompress後即可，
原因暫未研究，備查

⑹ 怎樣壓縮Oracle數據文件

如果屬於一個單獨的表空間不是system等,可以把表空間刪除，或刪除所有對象後resize數據文件

⑺ oracle11g怎麼建立壓縮表

在數據量變的很大的情況下，可以考慮表壓縮，減少磁碟的存儲，減少buffer cache的消耗，加快查詢的速度，壓縮需要在數據載入和dml的時候消耗一些cpu.表壓縮對於應用是透明的。

你可以在表空間，表或分區級別指定壓縮，如果在表空間級別指定壓縮，那麼這個表空間中的所有表默認都是壓縮的。

壓縮會發生在數據插入，更新或批量載入到表時。有幾種類型的壓縮。基本的，oltp的，dss的，歸檔的。他們的cpu消耗見文檔。

當使用基本壓縮，數據倉庫壓縮，或歸檔壓縮的時候，壓縮僅僅是在批量載入到一個表的時候發生。當你使用了oltp壓縮，壓縮發生在數據插入，更新，批量載入。

如果你使用了alter table命令讓表啟用壓縮，那麼對於已存在的數據是不受影響的，只有在啟用壓縮後的插入，或更新會受影響。也可以使用ALTER TABLE…NOCOMPRESS將一個表設置成非壓縮，對於已經的壓縮的表是沒有影響的，壓縮的數據還是壓縮的，只是新插入的數據是不被壓縮。

創建一個oltp壓縮類型的表
CREATE TABLE orders … COMPRESS FOR OLTP;

如果你不指定壓縮的類型，那麼默認的情況下是基本壓縮類型。下面的2個語句是等價的。
CREATE TABLE sales_history … COMPRESS BASIC;

CREATE TABLE sales_history … COMPRESS;

下面的表是一個數據倉庫壓縮類型的表，對於經常查詢，並且沒有dml的表適用。
CREATE TABLE sales_history … COMPRESS FOR QUERY;

創建一個歸檔壓縮類型的表
CREATE TABLE sales_history … COMPRESS FOR ARCHIVE;

表可以包含壓縮和非壓縮的分區，並且不同的分區的壓縮的類型可以是不同的，如果在分區上指定的壓縮的類型與表上指定的壓縮的類型不同，那麼分區上的優先。

查看錶是否是壓縮的，及分區是否是壓縮的。
SQL> SELECT table_name, compression, compress_for FROM user_tables;

SELECT table_name, partition_name, compression,compress_for
FROM user_tab_partitions;

查看錶中的行是什麼壓縮類型
SELECT DECODE(DBMS_COMPRESSION.GET_COMPRESSION_TYPE(
ownname => 『HR』,
tabname => 『EMPLOYEES』,
row_id => 『AAAVEIAAGAAAABTAAD』),
1, 『No Compression』,
2, 『Basic or OLTP Compression』,
4, 『Hybrid Columnar Compression for Query High』,
8, 『Hybrid Columnar Compression for Query Low』,
16, 『Hybrid Columnar Compression for Archive High』,
32, 『Hybrid Columnar Compression for Archive Low』,
『Unknown Compression Type』) compression_type
FROM DUAL;

修改壓縮的級別

如果表是分區表，使用在線重定義可以修改表的壓縮級別。如果表是分分區表，那麼可以使用alter table ..move.. compress for語句修改表的壓縮級別，這個語句會阻塞dml操作。

對於壓縮表的限制：
1基本壓縮，你不能為添加的列指定默認的值。刪除列是不被支持的。
2oltp壓縮，如果要添加一個帶默認值的列，那麼需要指定not null，可以刪除列，但是數據只是在內部做了一個不被使用的標記而已。

3在線段收縮是不被支持的。

4上面的壓縮的方式不適合於lobs類型，他們有自己的壓縮方式。

5基本壓縮類型的表的pct_free參數自動的設置成0.

在上面的描述中可以看到對於基本類型的壓縮，沒有使用直接路徑插入的行及更新的行是不會被壓縮的。對於我們的oltp系統基本是沒有用處的，只測試下oltp的壓縮方式，這種方式對於沒有使用直接路徑插入的行及被更新的行都會壓縮。

SQL> select count(*) from xyu2;

COUNT(*)

22096384

SQL> set serveroutput on
SQL> exec show_space(『BAIXYU2』,』T』,』AUTO』);
Total Blocks……………………….334336
Total Bytes………………………..2738880512
Unused Blocks………………………1916
Unused Bytes……………………….15695872
Last Used Ext FileId………………..4
Last Used Ext BlockId……………….671872
Last Used Block…………………….6276

CREATE TABLE xyu3 COMPRESS FOR OLTP as select * from xyu2;

SQL> exec show_space(『BAIXYU3』,』T』,』AUTO』);
Total Blocks……………………….107520
Total Bytes………………………..880803840
Unused Blocks………………………112
Unused Bytes……………………….917504
Last Used Ext FileId………………..4
Last Used Ext BlockId……………….116224
Last Used Block…………………….912

看到使用的塊由33w下降到10w。壓縮效果還是不錯，但是是否使用還要結果上面的限制來根據實際情況評估。