重新定义分区 - 大表分区的彻底解决方案与配套工具

                           当前生产环境下，已有很多表成长成了记录数上亿，体积2、30G的大表，站在运维的角度：这种大表再不分区，存在性能与管理隐患；分区，需要停机，影响同步，过程痛苦；为什么不一开始设计时就分区呢？ 站在开发的角度：开发任务紧，只会选择熟悉与最快的方式建表，分区我不熟，没有时间去折腾，先让我上线，以后量大了再说；真到量大的时候呢，转换分区太麻烦，能拖则拖； 都是套路，怎么破？
     运维的痛点是大表转分区麻烦，因为一直采用传统的转换方式：先创建一个新分区表，再把数据插过去，再重命名，重建索引与权限等；已经有了更好的解决方案就是ORACLE自己提供的 “ 在线重定义 ” ，可以在不停机（不影响交易）情况下的轻松实现分区表转换，应该大力推广，上线就不会那么头疼了；

开发的痛点是不会写合适的分区脚本，以及在线重定义脚本，公司80%以上的开发是不太熟悉分区的，并且他们不愿意投入时间去更深入地学习数据库（搞JAVA的），因此，我特地设计与打造了一个分区脚本自动生成工具，让建分区的成本降低到与普通表完全一样：

主要实现的功能有 :

1、   普通表转分区表的在线重定义脚本；

只需要简单选择分区方式，就能生成完整的分区转换脚本，按照顺序执行脚本，就能实现已有的表转分区了；oracle推出的在线重定义是个好方案，但问题是，开发人员 不会写脚本， 甚至很多DBA也不熟悉，从而不敢用，生成的脚本我是测试过多次的，而且随着测试次数越多，会越来越可靠，从而现有大表转分区也不再太担心了；

所以，有了这个工具，基本上分区无难事了，从而，表设计规范也要相应的调整：

1、 对于新表，除去基础信息表、配置表，只要是随着时间会不断增长的表（包括日志表），都要求分区，并且审核时将不会再因为上线急而让步；

2、 优先采用自动分区，除非自动分区不适用，才考虑手工分区；

3、 尽量按业务时间 分区，业务时间不适用时，方考虑create_time分区；

4、 如果是预计增长较慢或不确定的（每天不足 1000条的），按“年”分区，不要说量小分区不合算，按年归档，买不了吃亏也买不了上当^_^；

5、 如果是预计增长较快的（每天不超过 10000的），按月分区；

6、 如果是预计增长很快的（每天 1万以上），按天分区，并根据数据量可灵活按（3天、7天）分；

7、 对于生产环境 已经 超过 5G的大表，开发人员可利用工具生成转换脚本，测试后，提交上线；

8、 对于个别不适用于在线重定义的表，仍采用传统的转换方式，后续可考虑支持此种脚本生成；


最后附上工具的下载，就是mydbtools插件，增加了分区生成的新功能，也有了更新，其中get full sql text做了一个彻底的改进，现在已能相当好的实现参数的替换，对于长的绑定变量SQL简直是神器，另外还附加了一个自动安装工具，支持懒人^_^：

20180901更新：

这个功能又进来了彻底的重构，界面更清晰，使用更方便，功能更强大，新建分区、传统分区转换、在线分区转换、以及增加分区都可一键生成，大大提升效率。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13365316/viewspace-2141452/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13365316/viewspace-2141452/