PARTIOTION表对于处理巨量数据来讲几乎是个killer function!
我对于系统中的大表和超大型表，主要的处理方式是根据公司前台应用的操作特性，对于一定周期后，只进行查询的数据，进行分区压缩，只是保留近期内可能还涉及DML操作的表在“最近”(我的分区名称：recent)中，用普通的存储方式进行保存。
而对于PARTITION的表来讲，之后的管理工作还是比较多的。
其中涉及到的工作中比较多的就是SPLIT(分裂)和DROP PARTITION（11g中应该就不会这样痛苦了）。
通过我对SPLIT过程的分析，发现SPLIT内部操作的基本过程：
1.发出命令后，ORACLE在我制定的新分区所在表空间中建立一个TEMPERORARY类型的表，其实这个表就是未来的新分区。将符合条件的数据导入。
2.在完成第一步后，ORACLE在原被分区的分区所在表空间上，又建立了一个TEMPRORARY类型的临时表，这时ORACLE开始将不属于新分区的数据在导入到这张临时表中。如果使用了UPDATE INDEXES的话，ORACLE最后还要维护索引。
3.完成后，改变表名（更新数据字典）
知道了这样的过程，我们在做SPLIT操作时，需要注意：
在被分区的分区所在的表空间上，需要有足够的剩余表空间。当然，如果使用UPDATE INDEXES的话，索引所在的表空间也需要必要的剩余表空间。
如果说有LOCAL INDEX，在系统资源允许的情况下，带上 update indexes子句是不错的选择。
另外，这个分裂过程也解除了我的一个忧虑，被分裂的分类数据是否要重组？现在看是没有必要的，因为ORACLE已经为你重组了这个分区中的数据了。
-------
ORACLE版本：10.2.0.1
我对于系统中的大表和超大型表，主要的处理方式是根据公司前台应用的操作特性，对于一定周期后，只进行查询的数据，进行分区压缩，只是保留近期内可能还涉及DML操作的表在“最近”(我的分区名称：recent)中，用普通的存储方式进行保存。
而对于PARTITION的表来讲，之后的管理工作还是比较多的。
其中涉及到的工作中比较多的就是SPLIT(分裂)和DROP PARTITION（11g中应该就不会这样痛苦了）。
通过我对SPLIT过程的分析，发现SPLIT内部操作的基本过程：
1.发出命令后，ORACLE在我制定的新分区所在表空间中建立一个TEMPERORARY类型的表，其实这个表就是未来的新分区。将符合条件的数据导入。
2.在完成第一步后，ORACLE在原被分区的分区所在表空间上，又建立了一个TEMPRORARY类型的临时表，这时ORACLE开始将不属于新分区的数据在导入到这张临时表中。如果使用了UPDATE INDEXES的话，ORACLE最后还要维护索引。
3.完成后，改变表名（更新数据字典）
知道了这样的过程，我们在做SPLIT操作时，需要注意：
在被分区的分区所在的表空间上，需要有足够的剩余表空间。当然，如果使用UPDATE INDEXES的话，索引所在的表空间也需要必要的剩余表空间。
如果说有LOCAL INDEX，在系统资源允许的情况下，带上 update indexes子句是不错的选择。
另外，这个分裂过程也解除了我的一个忧虑，被分裂的分类数据是否要重组？现在看是没有必要的，因为ORACLE已经为你重组了这个分区中的数据了。
-------
ORACLE版本：10.2.0.1
OS ：HP-UX B.11.23 U ia64
本文转自Be the miracle!博客51CTO博客，原文链接http://blog.51cto.com/miracle/51516如需转载请自行联系原作者
Larry.Yue
