1. 首页
  2. IT资讯

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

当前生产环境下,已有很多表成长成了记录数上亿,体积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://www.cxybcw.com/194620.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code