又到创建分区的时候，支撑一个数据仓库，一个重要的工作就是添加分区。一般的大型企业，都会每年做一次这样的分区维护，添加下一财务年度的分区。
我支撑的Campbell DW，大约有20T的数据量，现有分区，子分区约50万，分布在4个数据库，6个架构里面。每年每个架构需要添加大约4万个分区/子分区。每做一次这样的工作就意味着一场战役，在较短的维护窗口内要确保100%成功的完成这个工作，唯一的方式就是做非常详细的准备工作。
1.子分区模板
客户随着业务的发展往往会改变分区的设计，比如我们90%的FACT表都是以时间（年，月，季度，周，天）进行分区，然后按分公司划分子分区。客户的业务在扩展到新的地区后（有了新的分公司数据），就会要求添加，修改子分区设计。这个时候，就得对子分区模板进行修改。分区模板可以在Dba_Subpartition_Templates中找到，分区定义信息是存储在一个LONG的字段里面。对它进行修改,确定新的模板。当然，我们不可能靠手工去做这样的时候，我们写了脚本对分区模板进行分析和产生新的分区模板脚本，从而避免人工错误。
2.添加新分区的方式。
在处理海量的分区的时候添加分区，是最愚蠢的方式。最好的方式是从默认分区进行分割。分割分区的脚本量比添加分区小很多，而且不容易出错。不过必须注意的是，为了使得新分区模板生效，你必须放弃，重新创建默认分区。这样分割分区的时候，才会产生和新模板对应的分区。
3.你的默认分区有数据吗？
如果要放弃，重新创建默认分区，你的默认分区有数据吗？如果有，请考虑你的备份方式。
如果默认分区的数据特别大，然后又不能够较早的被分裂进新分区，那么很可能就会影响你分割分区的性能。这个时候，建议备份数据，截短分区。在添加分区完成后，再导入。
4.你空间足够吗？
每个分区都有一个初始化大小，我们环境里面是80K。可以通过分区数*size精确估算出需要的空间大小。确保在整个过程中，不会发生空间错误。
5.时间估算
分裂一个分区在当前服务器大概需要多少时间？然后估算出整个过程需要的时间。我们一个架构大概需要10小时。
6.索引的时间和空间
不得不说的一个问题就是全局索引，虽然我们尽量避免创建全局索引。但根据业务需求，还是创建了近800GB的全局索引。
添加分区会使得这个800GB索引失效，重建索引其实是整个工作中一个非常重要的部分。时间的估算，需结合索引的并行度。ORACLE有一个非常恼人的bug，就是BITMAP索引高并行度重建后，有可能发生内部崩溃。我目前只能采用3~5的程度，因为连续两年的经验证明parallel 10 会触发bug。另外还得重建的新的索引分区。
当然重建索引的临时表空间你足够吗？
7.创建batch脚本
超过10万个分区命令肯定不能手工写。不过也不难，通过SQLPLUS和SPOOL命令批量创建脚本。
对脚本进行验证。
8.运行脚本 验证结果
这一步，很简单。nohup sh DW_2011.sh &
验证结果是非重要，确保你没有任何错误。分区的错误，带给业务的影响是很大，所以一定要确保100%成功。可以通过查询你的log和数据库视图来确认。
手工处理错误或异常。这个过程可能触发多种ORACLE bug（10g，11.2目前我没遇到bug）。
9.重建索引
10.总结
所有的日志、脚本、步骤，总结成一个文档，存档以备后查。
通过这些步骤，能够确保顺利完成年度分区这个大活，从而确保你的客户在商业上取得成功。
