散发思维:数据迁移 李广才 ludatou

关于我 OLM浙江DBA团队负责人 ZJOUG发起人 Oracle 9i/10g OCP，10g OCM Oracle特殊恢复工具MDATA作者，交流群：313558251 新浪微博：http://weibo.com/ludal QQ：feigigi@qq.com MAIL：feigigi@qq.com http://weibo.com/ludal

数据迁移开始之前要考虑的事情 迁移方案 迁移流程 测试方案 业务怎么办? 迁移失败怎么办?

数据迁移方案的选型 同构平台 异构平台 物理迁移 逻辑迁移 Rman Dataguard 第三方的同步工具 磁盘阵列级别的复制 Dataguard 基于异构平台的物理主备库(Note: 413484.1) Export/import(包含了Datapump) RMAN Convert Database(仅适用都属于相同 ENDIAN 格式) 基于DBLINK的CTAS Oracle Golden Gate

数据迁移方案的选型 迁移的数据范围 业务时间窗口 妥协于业务多数时候大于技术选择 部分表数据(部分系统) 部分用户 全库 业务系统连续性问题(允许的停机时间) 多个系统数据交换的问题(复杂的系统交互) 数据库内部任务处理的问题(crontab?job?schedul?)

数据迁移方案的选型 迁移的技术选择 业务or数据 迁移时间效率成本 迁移技术是否熟练掌握 迁移技术是否成熟 选择自己熟练的技术比从新学新技术更有保证! 业务or数据 从业务迁移的角度来看待数据迁移,站在应用的角度考虑下迁移!

数据迁移流程 迁移前的处理 迁移过程的细化 细节脚本化 流程化 job,crontab定时任务,schedul的处理(源库和目标库都需要) 数据库设置为受限模式或者锁住相关用户 收集迁移对象(主要是表数据,函数,同义词(特别是公有同义词),视图/物化试图等)的相关信息 如果ip会变需要收集dblink信息,涉及迁移的DB以及外部系统连进来的dblink 对dblink有依赖的对象(函数,plsql,同义词),容易编译失效 迁移选择技术的一些缺陷应对策略(比如dg或者rman需要的force logging处理) 源库和目标库的db基础信息一致检测 等 迁移过程的细化 细节脚本化 流程化

数据迁移流程 验证迁移是否成功 目标库与源库对象数量的对比 rows count(*)的结果比对 工具比对(veridata,ultra等) 核心数据内容对比(dbms_utility.get_hash_value,dbms_comparison,minus 等方式

一次典型的数据迁移案例 迁移的所面临基本情况 到此为止思考下初步的迁移方案? 数据量400g 停机窗口6个小时 用户表空间大小超过1T 原平台 系统版本: AIX 5.3 数据库版本: Oracle 10.2.0.3.0 目标平台 系统版本: AIX 6.1 数据库版本: Oracle Rac 11.2.0.3.8 迁移的所面临基本情况 数据量400g 停机窗口6个小时 用户表空间大小超过1T 被迁移数据库对应系统与20多套其他业务系统之间7*24有数据交互 用户想趁机对索引和表的存储上基于表空间层面做分离 内网带宽千M 到此为止思考下初步的迁移方案?

(续)一次典型的数据迁移案例 双击添加标题文字 双击添加标题文字 双击添加标题文字 迁移方式 可行与否 原因 CATS 阵列复制 Rman × 升级数据字典需要较长时间, 表空间过大恢复时间长 Rman convert 无法满足时间窗口 Dataguard 版本不一致,初始实施有困难 第三方的同步工具 客户未有该类工具 Goldenagte 受限字段类型多,潜在影响因素多 DATAPUMP(exp/imp) √ CATS 效率过低,业务元数据 阵列复制 版本不一致,字典升级耗时. 所在环境未有该功能的存储 双击添加标题文字 双击添加标题文字 双击添加标题文字

Datapump全库迁移关注点 EXPDP执行前的信息收集处理 EXPDP导出的优化 根据cpu信息活动并行 优先使用io性能好的vg 关闭对应监听 数据库置为受限模式 检查源库和目标库的配置 内部job_queque_process置为0 对比迁移开始时间的job以及批处理任务情况,收集对应job,schedul,crontab的信息对于系统级别的调用脚本处理需要禁止 收集dblink信息,与迁移系统交互的系统都需要收集(重点是外部业务系统) 收集依赖dblink的存储过程,同义词,函数,物化视图,视图的信息 Tnsnames文件的同步配置 收集有效对象的基础信息(count(*)等),失效对象的信息 SYS用户拥有的应用系统对象信息(同义词,建错的索引,表等) EXPDP导出的优化 根据cpu信息活动并行 优先使用io性能好的vg 针对内存以及expdp本身内存的设置,更大的buffer池与pga 最大成都避免不必要的数据的导出 对tmp做对应的变更

Datapump全库迁移关注点(续) IMPDP执行前的信息收集处理 IMPDP导入的优化 根据cpu信息活动并行(需要参考原先的导出设置) 关闭对应监听 确认目标库处于干净状态(导入前已经清理干净) 确认目标库的服务配置正确(在导出工作之前检测对应的服务,表空间等是否已配置好) Role以及Profile的补建检测 内部job_queque_process置为0, 如果导入元数据后的时间点对应job的信息,归属用户等可能发生变化 Tnsnames文件的同步配置(目标库依赖情况处理是否马上生效) 某些场景下需要考虑应用约束(constraints)以及触发器(triggers)的的禁用 IMPDP的较严重的缺陷,基于用户单元导入时候,会丢失对应基于其他用户的对象权限 IMPDP导入不包括带有dblink的公有同义词 不建议对统计信息进行迁移,特别是在跨版本的情况下 IMPDP导入的优化 根据cpu信息活动并行(需要参考原先的导出设置) 优先使用io性能好的vg 针对内存以及impdp本身内存的设置,更大的buffer池与pga 最大程度避免不必要的数据的导入 对tmp做对应的扩大处理 最小化的日志产生(避免redo log上的io耗用) Index的创建与数据导入的分离

Datapump全库迁移关注点(续) IMPDP导入后的处理 数据效验完成之前对相关的job不恢复 DBLINK的重建(梳理)以及其他系统的connect ip信息的更新(TNSNAMES或者字符串的连接) 失效对象的修复等 受限模式的处理 最佳配置的恢复 等

回归案例 Step 1: 关闭数据库监听(原核心数据库端执行) $ SEC-OLD/expdp_sec.ksh //该过程持续35分钟左右 Step 4: 将dump文件传输至新的核心数据库服务器(原核心数据库端执行) $ scp LIS.*.dump 192.168.1.100:/data01/dump //该过程持续60分钟左右 Step 5: 创建tnsnames.ora(新核心数据库端执行) $ 将SEC-NEW/tnsnames.ora文件拷贝至$ORACLE_HOME/network/admin Step 6: 创建导入的参数文件(导入原数据)(新核心数据库端执行) $ 将SEC-NEW/impdp.meta.par中的dumpfile修改为正确的dumpfile。 $ 创建directory(如果不存在的话) Step 7: 导入原数据到新的数据库(新核心数据库端执行) $ impdp system/<password> parfile=impdp.meta.par logfile=impdp.meta.<DATETIME>.log //该过程持续30分钟左右

案例(续) Step 8: 清理多余的用户(新核心数据库端执行) SQL> @SEC-NEW/cleanup_users.sql SQL> @SEC-NEW/rebuild_indexes.sql Step 10: 重建大表，将大表进行单独存储(新核心数据库端执行) SQL> @SEC-NEW/rebuild_large_tables.sql Step 11: 禁用应用级别的触发器(新核心数据库端执行) SQL> @SEC-NEW/disable_triggers.sql //执行完成后，请检查触发器是否已禁用 Step 12: 禁用应用级别的JOB(新核心数据库端执行) SQL> @SEC-NEW/disable_jobs.sql //执行完成后，请检查JOB是否已禁用 --设置job process=0 Step 13: 禁用应用级别的约束(新核心数据库端执行) SQL> @SEC-NEW/disable_constraints.sql //执行完成后，请检查约束是否已禁用 Step 14: 创建导入的参数文件(导入数据)(新核心数据库端执行) $ 将SEC-NEW/impdp.data.par中的dumpfile修改为正确的dumpfile。 Step 15: 导入数据到新的数据库(新核心数据库端执行) $ impdp system/<password> parfile=impdp.data.par logfile=impdp.data.<DATETIME>.log //该过程持续90分钟左右 Step 16: 启用触发器(新核心数据库端执行) SQL> @SEC-NEW/enable_triggers.sql //执行完成后，请检查触发器是否已启用

案例(续) Step 17: 启用约束(新核心数据库端执行) SQL> @SEC-NEW/enable_constraints.sql //执行完成后，请检查约束是否已启用 Step 18: 编译失效对象(新核心数据库端执行) SQL> conn / as sysdba SQL> @?/rdbms/admin/utlrp Step 19: 检查DBLINKs的有效性(新核心数据库端执行,同时通知业务变更其他系统的连接信息) SQL> @SEC-NEW/check_dblinks.sql Step 20: 与原数据库进行对比(原核心数据库端和新核心数据库端分别执行) (并对缺失部分的对象权限进行补救) Step 21: 重新收集统计信息(新核心数据库端执行) SQL> @SEC-NEW/gather_stats.sql //该过程持续30分钟左右 Step 22: 启用JOB(新核心数据库端执行) SQL> @SEC-NEW/enable_jobs.sql //执行完成后，请检查JOB是否已启用,同事恢复对应的系统和数据库的调度任务 --将job process 设置恢复 Step 23: 开启数据库归档，开启数据库的附加日志，并启用数据库级别的闪回(新核心数据库端执行)

本次分享结束，谢谢欣赏