关于修改分区表的问题总结

在之前的章节中讨论了关于修改表分区的一些准备工作和操作细则，这个问题的来由有必要说一下。

通过分区键值发现性能问题   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语句的执行速度下降了。

分区修改之前。

Elapsed:

120.14 (mins)

DB Time:

220.20 (mins)

分区修改之后。

119.16 (mins)

125.26 (mins)

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