物化视图进行逻辑数据迁移

sjqy5753

首先，描述一下整个迁移操作的环境。迁移操作的源数据，部署在9204环境中，而目标环境部署在10203的RAC环境中，迁移是跨版本的；
源数据库中用户名、表空间名称与目标数据库中目标用户名和表空间名称不同，也就是说要进行用户和表空间的转换；源数据库中的同名用户和同名表空间在目标数据库中是存在的，不过目标数据库中目标用户是新建的，不包含表和数据；
要迁移的对象中包括分区表和LOB表；
源数据库部署了物化视图复制环境，迁移中的部分表是物化视图复制环境中的物化视图，而目标数据库中也部署了物化视图复制环境，源数据库中部分物化视图在目标数据库中同名用户下也是存在的；
最重要的一点，迁移只是针对部分数据。对于一部分表，需要将全表数据迁移过去，而对于一部分表，只迁移表中部分的数据，这些数据可以根据表中的某个业务字段进行过滤，迁移之后，源数据库中剩余数据将继续作为产品数据库使用；
最后，在晚上上面所有目标的基础上，要求迁移的停机时间尽可能短。
针对上面的条件限制，采用了物化视图迁移方式配合EXP方式，并对部分无法迁移的表单独进行手工处理。下面列出了一些处理的步骤，以及每个步骤所需的关注点：
确定迁移数据范围，建立配置表记录上面的信息：这一步实际上是准备工作，记录下来那些表的数据需要迁移，那些表需要迁移部分数据，迁移部分数据的表的过滤字段的值如何确定等等，这个主要和迁移业务有关，就不相信描述了，这张表在迁移之前用作配置表，用来生成迁移所需的脚本，迁移之后用作迁移记录，记录了迁移过程中各个表的数据变化，也为迁移成功后，源数据库删除迁移数据做准备；
验证现有物化视图日志添加新列对快速刷新的影响：由于环境比较复杂，源数据库本身是物化视图复制环境中的物化视图库，又是另外一个物化视图复制环境的主库，因此部分要迁移的表本身已经创建了物化视图日志，而这些表又是需要在迁移过程中对某个列进行过滤的，这就要求物化视图日志中必须包含这个过滤的列，这里必须验证对物化视图日志进行添加列的操作是否对现有复制环境的快速刷新有影响，这个结果将会直接影响整个迁移所需的时间。Oracle在这里还是比较智能的，物化视图日志新增列对已经存在的物化视图刷新没有影响，不过物化视图日志没有提供删除列的方式，如果要在物化视图日志中删除列，则必须重建物化视图日志。好在添加新列对于现有结构只是增加了部分空间开销，因此在迁移后没有必要删除重建物化视图日志；
迁移之前导出源数据库中待迁移用户的全部结构，使用参数compress=n和rows=n：由于物化视图迁移只针对数据部分，因此使用EXP方式将所有的对象导入到目标库，利用EXP和物化视图配合的方式来达到迁移所有对象的目的。使用rows=n的目的就是不导出数据，数据部分通过物化视图方式来处理，而compress=n就更明显了，既然导入的是空表，就没有必要占有那么大的空间了，而且导入的部分表只是部分数据，因此按原有的参数导入会造成空间的浪费；
寻找一个中间数据库，版本最好和目标数据库一致，否则和源数据库相同亦可，建立目标用户，为目标用户建立所需表空间，提前建立分区表和
LOB表：由于导出用户、表空间信息和目标用户、表空间都是不相同的，必须进行一次转换，而分区表和LOB是没有办法转换表空间的，因此必须提交建立，在中间库进行转换工作可以避免大量的导入错误对目标库的影响，不过这些并不是中间库存在的必要条件，下面提到的才是为什么一定要先在中间数据库中进行导入操作；
导入到中间库：在中间数据库执行导入操作，使用参数ignore=y。中间库对于这个迁移环境是必须的，这是因为源数据库和目标数据库都部署了高级复制的环境，在目标数据库中存在一些和源数据库中同用户同名物化视图，而这些物化视图正是迁移数据中的一部分。如果这里直接在目标数据库进行导入，虽然物化视图由于缺少权限而无法导入，但是这个导入操作会影响到目标库这些同名的物化视图，使它们无法在进行快速刷新。关于这个bug的详细描述，可以参考：物化视图导出导入可能导致物化视图日志的失效：
http://yangtingkun.itpub.net/post/468/25331
在中间数据库进行结构调整：比如检查中间库JOB是否和目标数据库冲突，如冲突进行调整。删除目标数据库中所不需要的对象，如高级复制残留环境等等；
导出中间库结构，并最终导入到目标数据库中，完成EXP部分的迁移工作：至此，所有的对象都已经迁移完成，下面就需要通过物化视图来处理数据部分了；
在进行物化视图迁移方式之前，首先编译失效对象，并将所有JOB置于BROKEN状态，避免运行的JOB对迁移工作造成影响；
源数据库添加物化视图日志：这个操作需要根据配置表中的信息进行，有些表仅添加物化视图日志就可以了，有些表必须添加物化视图日志的时候指定过滤列，而有些是在已经存在的物化视图日志上添加过滤列；
在目标数据库中，对于需要迁移数据的表建立ON PREBUILT TABLE物化视图：需要迁移的表建立ON PREBUILT TABLE类型的物化视图，并设置为快速刷新，并根据配置表对一些表的数据进行过滤，物化视图创建的SQL需要注意，尽量满足快速刷新的条件，否则将会延长物化视图迁移过程的停机时间。比如迁移过程中过滤条件是通过树型查询获取，这里就尽量改成硬编码的IN方式，这是由于物化视图的快速刷新不支持树型查询；
禁用所有的外键约束：由于物化视图刷新过程很难保证主外键的顺序，因此这里选择了先DISABLE所有的外键，然后同一执行物化视图的刷新，最后统一ENABLE外键的方式；
物化视图初始化：由于ON PREBUILT TABLE物化视图在创建的时候并不会同步数据，因此在快速刷新之前必须执行一次完全刷新，这个步骤和以上的所有步骤都可以放到停机之前进行，这样就可以极大的缩短停机时间。而且在停机之前，还可以进行多次物化视图的同步，来减少停机后物化视图同步的数据量，进一步减少停机操作所需要的时间；
停止数据库对外的应用：这个时间是真正停机的开始时间，这里可以采用多种方法，比如停止前台应用、将中间件服务停机、断开数据库连接后，停止监听，并建立一个新的监听端口内部使用、或者断开当前所有的数据库连接后，修改源数据库用户帐号，避免新的连接登陆到数据库；
物化视图同步：通过物化视图的快速刷新来进行最后一次同步数据。由于源数据库已经避免了新的连接，因此不会再有新的数据修改，执行这次同步后，就可以保证源数据库和目标数据库的数据是一致的。根据业务是否需要，也可以在物化视图同步之前，考虑停止源数据库中用户下的
JOB；
删除物化视图：数据已经同步完成，下面就可以将物化视图删除，这样保证目标数据库中仍然是表，而不是物化视图；
源数据库删除基表的物化视图日志：同样，物化视图日志也不再需要，可以删除掉，不过这里需要根据配置表进行删除，避免将原有的物化视图日志删除掉；
检查并所有序列，对目标数据库中的序列NEXTVAL进行调整：由于源数据库自从EXP之后一直处于修改状态，因此用户的序列一直在不断的增加，而目标数据库一直没有被使用，序列的值还处于导出时的状态，如果不加处理，直接使用的话，目标数据库在使用序列来生成ID，很可能会和表中现有的记录出现冲突，所有在数据库对外服务之前必要先处理序列的值；
启用所有外键约束：外键约束是数据库中业务逻辑的限制，也是数据库中数据合理性的保障，因此数据库正式使用之前必须先启用约束，对于无法启用的约束，需要根据业务情况手工处理其中的数据；
对部分无法用物化视图迁移的表进行手工处理：主要包括一些没有主键的日志表、配置表或者一些过滤条件过于复杂，没有办法进行快速刷新的表；
启用JOB，重新收集统计信息，建立辅助用户：这些都是数据库可以正常、高效工作的必要条件；
删除源数据库上所有迁移走的数据：这个步骤就和具体的业务、以及迁移目的有关了，至于什么时候执行这一步或者是否需要这一步，就需要具体问题具体分析了。如果要执行这个操作的话，仍然是根据配置表的信息来批量生成脚本执行；
数据库对外提供服务：根据前面停止服务的反向操作，使数据库开始提供服务。这个时候迁移停机时间结束。
测试人员应该对整个业务流程和业务数据进行测试，来验证迁移是否成功完成。
该文章转载自德仔工作室：
http://www.dezai.cn/article_show.asp?ArticleID=22899


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/74483/showart_1095030.html