轻松移植oracle.pptVIP

使用DB2 v9.7 轻松移植Oracle应用 为什么要移植到DB2? 我作为 客户 当前的数据库性能不能满足需求 在同数据库供应商谈判时，没办法得到更优的价格 DB2是性价比最高的产品 我作为 服务商 我想扩展客户群 我想得到IBM全方位的支持 我的数据库供应商同时也是我的竞争对手 DB2是性价比最高的产品 为什么还没有移植到DB2? 作为 客户 我认为 移植关键应用还是有很大的风险 投入回报周期可能很长 作为 服务商 我认为 移植并维护另一个数据库平台可能代价很大 投入回报周期可能很长 数据库移植的难点 用户的选择 选择其中一种数据库并与之绑定 支持两种或多种数据库并维护针对每种数据库的实现 只使用各种数据库都支持的功能 上面的任何一种选择都不理想 DB2如何解决移植问题？ 传统方法是 首先实现SQL标准中的功能 之后对SQL标准进行扩展加入一些业界常用功能 对于待移植数据库中的私有SQL通过移植工具进行映射 传统方法存在的问题 移植工具往往只能在DDL层次上帮助移植 例如 procedures, triggers, functions, tables 普通SQL通常散布在应用程序代码中，很难识别并转换 转换完之后很容易引入性能问题 DB2 V9.7的新思路 内置地支持Oracle的语法，语义及相关工具 客户通过开关参数选择使用DB2还是Oracle语境 统一执行引擎保证PL/SQL和SQL PL有相同的性能 这是对Oracle的有力宣战！ DB2 Server PL/SQL Compiler SQL PL Compiler SQL Unified Runtime Engine Data base Data Studio Debugger Profiler Editor DB2 9.7支持下面的Oracle功能 Oracle ? DB2 并发控制 ? 无需任何更改 Oracle SQL方言 ? 无需任何更改 PL/SQL ? 无需任何更改 PL/SQL包 ? 无需任何更改 系统函数库 ? 无需任何更改 JDBC 扩展 ? 无需任何更改 OCI ? 无需任何更改 SQL*Plus 脚本 ? 无需任何更改 只有极少情况下才需要更改 这就是为什么我们称之为转移，而不是迁移！ DB2 9.7中从Oracle向DB2转移的步骤 通过问卷了解客户环境中的Oracle应用以及使用的Oracle技术； 使用IBM MEET工具来评估移植的代价，当然代价越小越好； 用商业眼光评估移植到DB2后带来的效益，只有效益大于代价时才继续下面的步骤 ?； 使用IBM Data Movement tool 来 “直接把应用转移到DB2”: 映射DDL 导入测试数据 拷贝存储过程等应用 此时可能会人工进行一些调整来消除报错（如果需要的话）! 测试，测试再测试 没问题后导入生产数据并部署上线 DB2 9.7中从Oracle向DB2转移的步骤 Phase II 迁移阶段 Phase I 评估阶段 Phase IV 切换阶段 Phase III 测试阶段 并发控制比较 是否阻塞 读操作 写操作 读操作 No No 写操作 No Yes 是否阻塞 读操作 写操作 读操作 No No* 写操作 Yes Yes Oracle 默认情况 语句级快照 DB2 V9.7之前默认情况 游标稳定隔离级别 DB2 V9.7目前默认情况 当前提交隔离级别 是否阻塞 读操作 写操作 读操作 No No 写操作 No Yes DB2 V9.7并发控制 基于日志实现 不需要额外管理开销 没有额外的性能开销 不要求额外的存储（没有undo tablespace） User 1: update T1 set name = ‘Russo’ where country=‘Italy’ User 2: select * from T1 支持Oracle SQL方言 数据类型 类型转换 函数库 SQL语法 DB2 9.7新数据类型 类型 注释 NUMBER 利用了P6芯片加速处理能力的DECFLOAT VARCHAR2 零长度字符串等同于NULL TIMESTAMP (n) 0 (date + time) = N = 12 (date + time + picoseconds) “DATE” 从年到秒, 可以使用SYSDATE BOOLEAN 在应用开发中使用的类型 Hash tables 可以在应用中结合 “INDEX BY” 使用 VARRAY 在应用中使用的数组类型 Row Type 表示该结果行的类型 Cursor type 扩展了游标特性 DB2 曾经严格限制数据类型 但目前业界趋势是弱类型转换 (PERL, RUBY, PHP, …) 目前