关于修改分区表的问题总结 (r3笔记35天)

在之前的章节中讨论了关于修改表分区的一些准备工作和操作细则，这个问题的来由有必要说一下。 通过分区键值发现性能问题 http://blog.itpub.net/23718752/viewspace-1263068/ 当时是在做数据迁移的时候发现了一些表，导入数据比较慢，尽管做了分区的并行切分，速度还是很慢，最后查看数据的分布时，发现90%左右的数据都分布到了一个表分区上。 最后和开发部门协调，重新调整了分区键值，从DBA这边来说，就需要重新来创建分区了。 尽管已经考虑了很多的准备工作和可能碰到的问题，还是遇到了一些问题，自己总结一下。 第一个判断是否是关于备份，当时考虑使用exp来作为一个物理备份，结果在数据导出的时候，尽管开了多个并行进程同时导出，但是速度还是很慢。 结果exp还没有运行到20%，外部表的导出就完成了。从时间的角度考虑这个物理备份还是考虑有些欠缺，最后的解决方案就是导出了一个dump,里面只包含关于表结构，不包含数据， 如果出现问题，也能够及时的参考和调整。 第二个没有考虑到的因素就是表空间,当时想数据没有增加，重新分区以后，应该也不会有多大的空间变化，就没有申请额外的存储空间，结果在删除分区后，使用split来修改分区的时候 开始报一个劲的报错。提示无法扩展空间。 ORA-01658: unable to create INITIAL extent for segment in tablespace xxxxx 碰到这种问题，只得重新来过,如果再根据日志来逐个分析，也是得不偿失， 最后重新估算了需要的表空间，折腾了几轮才算把问题搞定。 第三个问题是在准备的时候也要考虑到各种可能遇到的情况，如果失败，还能够及时的调整。我是专门把分区的步骤分为了 以下的几个步骤。 1)数据清理，-->在有完整备份的前提下 2）删除分区 3）检查删除分区是否成功 4）先删除分区表中分区键值是一个的。 5）删除分区表中分区键值是两个的。 6）检查分区的修改情况是否满足要求。 这样的话，任何一个步骤失败，都可以及时的调整，重新部署。我在碰到了一些问题之后，就及时调整或者重新来做，这样不会浪费太多时间。 第4个问题就是数据的加载 对于大量的分区表数据的加载量还是很大的， 也需要合理的估算时间。这次做的分区表数据量都在亿级，在数据导入前也考虑了不少的细节，并行就是一个关键的因素。 合理的控制并行资源能够极大的提高系统的响应速度。 我专门预留了两个进程，等待其他的进程有提前完成的，然后作为补充，使得系统的处理速度一直处于高效状态，不至于一开始压力就太大，速度太慢，后期的时候空闲并行太多，导致系统的资源使用不是很合理。 以下是我在做数据导入时的一些指标信息。redo是1G大小，在不到一个小时的时间内切换300多次，加载的速度还是相当的快的。 GROUP# THREAD# SEQUENCE# MEMBERS SIZE_MB ARC STATUS ---------- ---------- ---------- ---------- ---------- --- ---------------- 1 1 11157 2 1024 YES INACTIVE 2 1 11158 2 1024 NO CURRENT 3 1 11155 2 1024 YES INACTIVE 4 1 11156 2 1024 YES INACTIVE Redo Switch times per hour NFTCUS1 2014-Oct-23 13:17:47 MON DA 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 --- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 10 22 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 7 0 0 0 0 0 0 0 0 10 23 0 0 0 0 0 0 0 0 0 0 335 311 155 0 0 0 0 0 0 0 0 0 0 0 第5个问题是关于统计信息的考虑，这个部分最后使用nohup在后台收集，可以提前把环境先提供给开发，让大家都有一个缓冲的时间，根据我的经验，平均亿级的数据收集大概在15-20分钟左右。 需要提前准备好并行进程。 最后一个问题是关于性能调整的。 可能分区工作完成，大部分工作都完成了。但是最重要的工作还是分区之后的性能。

我碰到的情况是数据库的负载下降了，但是部分sql语句的执行速度下降了。 分区修改之前。

分区修改之后。

这个时候需要借助awr来仔细的分析一下，到底是哪些地方存在较大的误差。有些sql语句可能有毫秒级的差别，但是执行的频率太高，可能导致的执行时间还是有很大的差别，这些可以和开发来做协调，看有些延迟是否能够接受，当然了我们希望看到的是整体性能得到提高。毕竟付出这么大的代价，性能下降的厉害，就有些得不偿失了。