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

Presentation on theme: "散发思维:数据迁移 李广才 ludatou."— Presentation transcript:

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

2 关于我 OLM浙江DBA团队负责人 ZJOUG发起人 Oracle 9i/10g OCP，10g OCM
Oracle特殊恢复工具MDATA作者，交流群： 新浪微博：

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

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

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

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

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

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

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

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

11 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做对应的变更

12 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的创建与数据导入的分离

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

14 回归案例 Step 1: 关闭数据库监听(原核心数据库端执行)
$ SEC-OLD/expdp_sec.ksh //该过程持续35分钟左右 Step 4: 将dump文件传输至新的核心数据库服务器(原核心数据库端执行) $ scp LIS.*.dump :/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分钟左右

15 案例(续) Step 8: 清理多余的用户(新核心数据库端执行) SQL> @SEC-NEW/cleanup_users.sql
Step 10: 重建大表，将大表进行单独存储(新核心数据库端执行) Step 11: 禁用应用级别的触发器(新核心数据库端执行) //执行完成后，请检查触发器是否已禁用 Step 12: 禁用应用级别的JOB(新核心数据库端执行) //执行完成后，请检查JOB是否已禁用 --设置job process=0 Step 13: 禁用应用级别的约束(新核心数据库端执行) //执行完成后，请检查约束是否已禁用 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: 启用触发器(新核心数据库端执行) //执行完成后，请检查触发器是否已启用

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

17 本次分享结束，谢谢欣赏