散发思维之oracle数据迁移-李广才ludatou.ppt

散发思维:数据迁移 李广才 ludatou 数据迁移开始之前要考虑的事情 数据迁移方案的选型 数据迁移方案的选型 数据迁移方案的选型 数据迁移流程 数据迁移流程 一次典型的数据迁移案例 (续)一次典型的数据迁移案例 Datapump全库迁移关注点 Datapump全库迁移关注点(续) Datapump全库迁移关注点(续) 回归案例 案例(续) 案例(续) 本次分享结束，谢谢欣赏 * 关于我 OLM浙江DBA团队负责人 ZJOUG发起人 Oracle 9i/10g OCP，10g OCM Oracle特殊恢复工具MDATA作者，交流群：313558251 新浪微博：/ludal QQ：feigigi@ MAIL：feigigi@ /ludal 物理迁移 逻辑迁移 Rman Dataguard 第三方的同步工具 磁盘阵列级别的复制 Dataguard 基于异构平台的物理主备库(Note: 413484.1) Export/import(包含了Datapump) RMAN Convert Database(仅适用都属于相同 ENDIAN 格式) 基于DBLINK的CTAS Oracle Golden Gate 妥协于业务多数时候大于技术选择 部分表数据(部分系统) 部分用户 全库 业务系统连续性问题(允许的停机时间) 多个系统数据交换的问题(复杂的系统交互) 数据库内部任务处理的问题(crontab?job?schedul?) 迁移时间效率成本 迁移技术是否熟练掌握 迁移技术是否成熟 选择自己熟练的技术比从新学新技术更有保证! 从业务迁移的角度来看待数据迁移,站在应用的角度考虑下迁移! 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 等方式 原平台 系统版本: AIX 5.3 数据库版本: Oracle .0 目标平台 系统版本: AIX 6.1 数据库版本: Oracle Rac .8 迁移的所面临基本情况 数据量400g 停机窗口6个小时 用户表空间大小超过1T 被迁移数据库对应系统与20多套其他业务系统之间7*24有数据交互 用户想趁机对索引和表的存储上基于表空间层面做分离 内网带宽千M 到此为止思考下初步的迁移方案? 迁移方式 可行与否 原因 Rman × 升级数据字典需要较长时间, 表空间过大恢复时间长 Rman convert × 无法满足时间窗口 Dataguard × 版本不一致,初始实施有困难 第三方的同步工具 × 客户未有该类工具 Goldenagte × 受限字段类型多,潜在影响因素多 DATAPUMP(exp/imp) √ CATS × 效率过低,业务元数据 阵列复制 × 版本不一致,字典升级耗时. 所在环境未有该功能的存储 EXPDP执行前的信息收集处理 关闭对应监听 数据库置为受限模式 检查源库和目标库的配置 内部job_queque_process置为0 对比迁移开始时间的job以及批处理任务情况,收集对应job,schedul,crontab的信息对于系统级别的调用脚本处理需要禁止 收集dblink信息,与迁移系统交互的系统都需要收集(重点是外部业务系统) 收集依赖dblink的存储过程,同义词,函数,物化视图,视图的信息 Tnsnames文件的同步配置 收集有效对象的基础信息(count(*)等),失效对象的信息 SYS用户拥有的应用系统对象信息(同义词,建错的索引,表等) EXPDP导出的优化 根据cpu信息活动并行 优先使用io性能好的vg 针对内存以及expdp本身内存的设置,更大的buffer池与pga 最大成都避免不必要的数据的导出 对tmp做对应的变更 IMPDP执行前的信息收集处理 关闭对应监听 确认目标库处于干净状态(导入前已经清理干净) 确认目标库的服务配置正确(在导出工作之前检测对应的服务,表空间等是否已配置好) Role以及Profile的补建检测 内部