在之前的博文中,讨论过一个根据分区键值发现性能问题的案例。90%以上的数据都分布在了一个分区上,其它的分区要么没有数据要么数据很少,这是很明显的分区问题。当然这个过程中也发现了分区的划分从开发角度和数据角度还是存在很大的差别,导致了分区的问题。
通过分区键值发现性能问题http://blog.itpub.net/23718752/viewspace-1263068/
发现了问题,以点带面,发现一些相关的分区表也有类似的问题,最后确认和分析后,发现收到影响的表有20多个,而且数据量都不小。
看来又得是一个忙碌的夜晚来修复这个问题了。
如果要准备相应的脚本,也要考虑很多的问题,我大体列了几个步骤。相应的脚本也会按照这个步骤处理。
大体的思路和数据迁移有些类似,相比来说增加了分区的操作。
step1_dump_bak 关于备份,最好存有两份备份,物理备份和逻辑备份
step2_truncate 分区之前,需要清空表中的数据。这个过程中需要考虑disable foreign key和trigger.
step3_drop_par 重新分区的时候,只保留一个默认分区maxvalue,然后使用drop partition命令完成。
step4_pre_par 在正式分区之前,可以先把表设为nologging,index设置为nologging,lob字段也设置为nologging.作为后面数据导入的时候的优化准备。
step5_par_one 开始正式的分区修改,这个操作依赖于默认的maxvalue分区,不断的split,因为没有了数据所以速度还是很快的。这个部分处理分区键值为一个的表
step6_par_two 开始正式的分区修改