如何做好Oracle逻辑数据迁移

如何做好逻辑数据迁移
    如何使用exp/expdp进行数据迁移，如果是一个简单的业务系统迁移，你可能不需要考虑任何外部因素，只要新库建好，执行导入导出即可，你也完成了一个数据迁移项目，如果面对一个复杂的业务系统，与其他系统关联度较高的业务系统，简单的导入导出是无法安全的按时完成整个数据迁移项目，或许一个疏忽都会导致整个项目失败而全部回退，本章节介绍了一套业务系统进行迁移的诸多注意事项，希望能给数据迁移实施工程师多一点参考少走一些弯路，若有不正确的地方还望指正。
 
一、信息调研
 
㈠ 最初的基本信息核定
作为数据库迁移项目的工程师，在进行数据库迁移前需要进行充分的前期调研，调研得到的信息越详细，迁移就会越顺利，制定的方案会更匹配当前的系统迁移，碰到的问题自然就会越少，在确定迁移方案之前你需要核实以下数据库相关信息
 
1.	源库的建设架构
       确定源库的架构，其中包括Single instance单实例,linux unix，windows平台下的HA, Single instance+DataGuard,多节点RAC,多节点RAC+DG，对于有DG环境的系统，当存在备库作为业务查询系统的情况时，如果数据迁移失败回退，确保原主库和DG备库数据同步正常，确保回退时不遗留问题
 
2.	源库的业务架构
       确定源库的业务架构，主要核证业务属于CS架构或者BS架构还是CS+BS混合架构，迁移后需要修改多少个业务客户端和连接池，这部分信息涉及到后面的业务验证与业务回退
 
3.	源库的交互架构
核查与源库有交互的所有数据库的版本和dblink及当前的SCN headroom阀值，SCN阀值可以通过MOS [ID 1393363.1]文章中的scnhealthcheck.sql” 脚本来检查当前SCN情况，如果客户业务的办理方式是通过数据库间的dblink交互来实现，则在使用跨数据库版本迁移方案中需要特别谨慎对待，由于不同版本数据库的SCN增长速率与阀值不同，如果在不同版本的数据库之间发生SCN拒绝同步，在迁移后的数据库使用dblink进行交互查询时会频繁出现ORA-19706: Invalid SCN的错误，此项错误对于使用dblink办理业务的系统来说无疑使致命的，终将会导致通过使用dblink来办理的业务均无法正常办理，因此对于是否确定使用跨数据库版本迁移方案事前一定要评估跨版本迁移的风险和影响范围。
 
4.	源库与新库的版本
    确定源库与新库的数据库版本，包括同版本间的数据迁移、跨版本的数据迁移，数据库版本决定这使用exp还是expdp工具还是exp/imp结合expdp/impdp，例如oracle 9i就只能使用exp/imp
 
5.	源库新库操作系统的平台
     确定源库与新库的操作系统平台Windows,Linux,Unix
 
6.	源库与新库主机硬件资源
    确定源库与新库的主机硬件，主要包括CPU，内存，这两项参数决定使用exp/expdp/imp/impdp进行逻辑迁移时最大可以加到多少并发量以达到最快的速度完成迁移
 
7.	源库与新库的可用的存储
 7.1 存储类型确定
  源库与新库存储类型的核查包括确认本次迁移所有使用的存储是独立的存储还是服务器的本地存储，因为两者读写的性能差异巨大，直接影响迁移速度和项目完成时间
 7.2 存储性能确定
  确定源库与新库的所使用的存储，主要验证存储的最大可使用空间，存储的读、写性能，RAID冗余级别，读写性能测试使用dd只能作为参考值，可以通过orion专业IO测试工具或数据库创建表空间的方式粗略估算存储的读写性能
 
8.	源库与新库的网络情况
 确定源库的网络使用情况，千兆网络还是百兆网络，网络稳定性，如果涉及到网络传输dmp文件还需要估算最大传输的时间，这项参数决定着迁移的进度快慢
 
9.	源库的数据 
 9.1数据量
首先确定的是数据量，包括segment与datafile，LOB字段（LOB字段作为一个Oracle特殊字段需要特殊对待，通常lob字段在（exp/expdp/imp/impdp）导入导出的时候速度非常缓慢，导入导出速度通常慢于传统数据的几倍或者十几倍，大量的LOB字段也是迁移的瓶颈，因此在迁移过程中存在大量的LOB字段则需要单独进行处理）
 9.2有效数据
用户的有效数据是指哪些数据是可以提前进行迁移，哪些用户的表数据是不需要迁移，这种情况包括很多业务端通过CTS备份的表和过期的不使用业务表等这些都属于无效数据，忽略无效数据会大大加快迁移速度
 
10.	源库的停机时间
用户允许最大停机时间，与客户商定最大的停机时间，保证迁移时间充裕确定了基本信息后基本可以确定使用哪种方案进行对数据库迁移，你有多少可控的数据迁移时间
 
二、方案选择
 
Exp/Expdp为例
 在对数据库进行逻辑迁移的时一般使用最多的是Oracle自带的exp/expdp/imp/impdp逻辑迁移工具，在对数据库进行迁移的时一般包括两种，全库迁移和部分用户迁移，全库进行迁移到时候主要还是对除数据库系统用户(SYS,SYSTEM等)外的所有业务用户进行迁移，由于用户之间存在依赖关系，迁移顺序无法掌控，这种多用户的数据迁移往往再迁移后容易丢失一些权限和同义词等信息，对于丢失部分信息的情况需要在迁移完成后进行单独比对处理 
 ㈠ 数据库信息处理
 
1.	数据库的job
在使用sysdba权限的用户对数据库业务用户进行迁移的时，会发生部分用户业务的job会发生导入失败的情况或者属主导入不匹配的情况，这种情况的job是无效的，对于这种情况迁移工程师需要与业务系统的运维人员确认业务所有的可用的job，然后以业务用户自身的角色进行单独对job导出导入，使用expdp/impdp  include=job，content=meatdata_only选项即可
 
2.	数据库的dblink
在数据交互多的系统中，dblink也是用的最多的，需要确认哪些dblink需要重建，包括创建dblink的用户和密码和Netservice name
 
3.	数据库的ACL列表
11g的数据库，某些应用程序需要ORACLE  ACL的访问列表进行访问，此种情况存在,通过Select * From  dba_network_acls命令来查看
 
4.	数据库的字符集
确定好源库与新库的字符集，新库与源库的字符集必须要一致
 
5.	数据库的无效对象
确定好业务用户无效的对象，以在迁移后进行比对
 
6.	数据库的加密对象
检查源库是否存在加密的package，procedure数据库如果存在加密的package，procedure，则使用impdp还是容易触发数据泵bug，impdp导入会损坏加密的包以及存储过程，导致业务无法使用，如果存在加密的package需要使用原始的exp/imp方式对其进行单独导出导入
 
7.	源库的SQL执行计划
对于业务压力大的待迁移数据库系统，迁移前后务必保持迁移后SQL执行计划最优，需要提前两周做好核心业务的SQL执行计划的抓取，执行计划的抓取可以使用awr+sqlrpt及sqlplus autotrace工具进行抓取，在跨数据库版本进行数据库迁移后，由于优化器算法，表的统计信息，聚簇因子等变化导致SQL的执行计划改变，在进行迁移后，新库很容易出现由于SQL走了错误的执行计划导致数据库性能问题
 
8.	操作系统的NLS环境变量
使用Select * from v$nls_parameters  where parameter='NLS_CHARACTERSET';语句来查询源库与新库的NLS环境变量，在使用exp/imp导入前通过export NLS_LANG=XXXX 保证源库与新库的NLS_LANG一致,以避免IMP-00091导入错误和其他异常
 
㈡ 数据库用户处理
1.	用户的数据量
统计迁移用户的数据量，这是数据迁移的常识，统计好单个用户的数据量，定制合理的迁移顺序和并发导入
 
2.	用户的密码
     对于个别不知道密码的数据库业务用户可以在导入时临时在新库修改用户密码，再通过查询源库dba_user或user$中的password字段得到加密过的原密码，在新库中通过（alter user identified by values‘源库查询出来的加密的密码’;）命令来恢复新库迁移后用户的原密码
 
3.	用户的默认表空间，临时表空间
       在新库中创建迁移用户的对应的默认表空间与临时表空间，保证新库与源库表空间一致，新库表空间空间充足
 
4.	用户的权限，同义词、主键
    在迁移多个用户的过程中由于不同用户之间存在权限的依赖关系，往往在用户导入的顺序不同的时候会发生权限缺失，而迁移工程师经常会面临迁移后用户权限缺失的问题，在迁移后用户的赋权的语句需要重新执行，可以使用impdp 中sqlfile的参数通过加载dmp文件生成相关的所有ddl dml的sql脚本，或者使用plsql、toad等工具抽取用户的相关赋权sql脚本
 
㈢ 统计业务
      确定有多少个业务需要连接源库，使用什么方式连接，CS客户端还是使用连接池connect pool，估算业务IP的修改时间，以保证在发生迁移失败后以最短的时间回退
 
 
㈣ 系统测试
        如果情况允许，最好能在新数据库搭建成功后测试一些imp/impdp的导入速度以评估数据迁移时间
 
三、实施数据迁移
 
㈠ 业务端操作
 
1.停止业务系统
     确定开始迁移后，备份所有中间件的连接配置，修改与源库相关的所有配置有软件业务系统的连接配置，关闭业务软件系统
㈡ 源库端操作
 
1.	停止源库监听
关闭数据库监听，以保证没有其他业务通过连接池和dblink连接源对数据库进行业务操作
 
2.	重启数据库
以shutdown immediate的方式关闭数据库，再重新打开，此项保证在迁移后sequence序列和源数据与新库迁移后保持一致
 
3.	停止源数据库JOB
      对于复杂的业务系统，通常数据库在不同时段有很多job在运行，因此在迁移时避免性能问题应该停止源库的所有job通过alter system set job_queue_processes=0设置停止所有执行或将要执行的job，在dba_jobs_running 数据字典来查询是否所有job都已经关闭
 
4.	导出数据
源库检查无误后开始对数据库进行导出，根据当前的硬件与存储资源来设置并行，对于较大用户数据，建议生成多个dmp文件
 
5.	数据传输
数据传输注意oracle权限与文件使用二进制方式传输
 
㈢ 新库端操作
 
1.	检查字符集
在导入前，检查数据库的字符集与操作系统的环境变量
 
2.	关闭归档
关闭新库的归档，以提升数据导入的性能
 
3.	检查表空间
对比源库与新库的数据表空间与临时表空间的个数、名称及其所属关系是否一致
 
4.	检查dmp文件权限
    检查文件权限是否正确
 
5.	开启并行导入
加大新库的数据库PGA内存，根据服务器的CPU个数来开启数据泵的并行导入
 
㈣ 验证
 
 
1.	数据验证
导入全部结束后，检查imp/impdp的导入日志，检查数据库的job,dblink，主键，外键、序列、物化视图是否完整或有效，可以使用plsqldeveloper，veridata进行比对，重新执行赋权的sql,检查、重新编译无效对象，在sqlplus里执行@？/rdbms/admin/utlrp.sql编译所有无效对象
 
2.	开启数据库归档
开启数据库归档使数据库运行在归档模式下
 
3.	重启业务验证业务
需要业务运维工程师配合验证业务，核心业务逐一验证
 
四、回退
 
回退，这是最不愿意看到的一幕，如果数据库迁移在规定时间内无法完成，需要立刻回退至原系统
 
㈠ 业务软件系统
还原软件系统的连接配置
 
㈡ 数据库回退
对源库的操作根据修改记录逐一回退
 
㈢ 验证业务
验证回退的业务
 

--------------------- 
作者：灰帽DBA 
来源：CSDN 
原文：https://blog.csdn.net/Evils798/article/details/50219257 
版权声明：本文为博主原创文章，转载请附上博文链接！
如何做好Oracle逻辑数据迁移

猜你喜欢
