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。压缩效果还是不错，但是是否使用还要结果上面的限制来根据实际情况评估。