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

在之前的章节中讨论了关于修改表分区的一些准备工作和操作细则，这个问题的来由有必要说一下。
通过分区键值发现性能问题   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分钟左右。
需要提前准备好并行进程。


最后一个问题是关于性能调整的。
可能分区工作完成，大部分工作都完成了。但是最重要的工作还是分区之后的性能。


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