EnterpriseDB Replication,复制Oracle数据测试(1)

EntepriseDB 复制软件目前支持多种数据库到postgre的复制,其基本结构由发布者(Publication)与订阅者(Subscriptions)组成,Replication软件可针对来自不同类型数据库的多个发布者,将其数据复制到多个订阅者(Subscriptions)数据库中。
其可能的几种拓扑结构,如以下图:



同Oracle中普通的物化视图一样,不支持对订阅者(Subscriptions)数据的修改–Changes must not be made to the data or the definitions of the subscription tables.

EnterpriseDB Replication软件的具体工作模式分成2种:即快照模式(snapshot)与同步模式(synchronization);在第一次启用同步前,需要进行一次快照操作,之后便可以进行较为轻量级同步操作了。若要使用同步模式(synchronization)则要求发布者所包含的表必须具有主键,而在仅使用快照模式的情景中则不需要。(Each table used in a publication must have a primary key with the exception of tables in snapshot-only publications, which do not require a primary key.) 以上模式均支持过滤器(fliter),即可以指定需要复制的具体数据子集。

EnterpriseDB Replication软件其同步(synchronization)模式复制的基本原理是基于trigger的,而非如Quest公司的shareplex或golden gate般抽取重做日志生成SQL的方式。trigger方式会在数据库源端产生一定的性能影响,若在mission critical的生产数据库中实施EDB replication 复制则需要考虑到这一点(这种情况下推荐使用Snapshot模式)。这可能是EDB复制软件比较不成熟的一点,就目前仅对Oracle日志文件的研究认识,挖掘重做日志进而实现数据复制的途径已经没有技术上的难点了。

以下发布者所包含的数据对象或表属性,将在订阅者成功建立时被复制到订阅者所在的数据库:

  • Tables
  • Views (for snapshot-only publications) – created as a table in the subscription database
  • Primary keys
  • Not null constraints
  • Unique constraints
  • Check constraints
  • Indexes

注意:外键约束将不被复制

同时目前复制软件存在一定的限制,Oracle中的hash分区将不被复制,同时Oracle中包含以下数据类型列的表将无法复制:

  • BFILE
  • BINARY_DOUBLE
  • BINARY_FLOAT
  • MLSLABEL
  • XMLTYPE

Oracle中包含以下数据类型列的表,将不能使用同步模式(synchronization replications):

  • BLOB
  • CLOB
  • LONG
  • LONG RAW
  • NCLOB
  • RAW

快照模式情况下,订阅者中复制目标表将首先被truncate截断,之后若订阅者数据库类型是Oracle则将使用JDBC驱动批量的将源端的数据INSERT进来,若数据库类型是EnterpriseDB advanced Sever则将使用Postgre中的Copy命令。

同步模式下复制软件通过在源端配置的触发器记录表,获知源端该时段内所经历的DML操作,进而在目标端生成对应修改的SQL语句(显然同源端的原始SQL不同)。

EnterpriseDB公司推荐在以下情景中使用快照模式以获得更好的性能:

  1. 表相对而言较小
  2. 在复制间隔中绝大多数数据行会被修改

而同步模式则更适宜于以下情景:

  1. 数据表非常巨大
  2. 在复制间隔中仅少数数据会被修改

EnterpriseDB Migration 迁移工具使用测试(2)

下面我们来测试EnterpriseDB Migration 工具对于Oracle 大对象(LOB)的迁移情况;
首先在在Oracle实例Scott模式下创建具有LOB对象的表,如:

SQL> create table tlob (t1 int primary key,t2 clob,t3 blob);
Table created.
-- 并填充数据
SQL> begin
  2  for i in 1..100 loop
  3  insert into tlob values(i,rpad('A',9999,'Z'),hextoraw(i) );
  4  end loop;
  5  commit;
  6  end;
  7  /

PL/SQL procedure successfully completed.

打开EnterpriseDB Migration 工具界面,从树形图中找到需要迁移的表TLOB,选择进行在线迁移:

导出日志:

[Starting Migration]
源数据库连接信息…
连接 =jdbc:oracle:thin:@rh2.home:1521:G10R21
用户 =system
密码=******
目标数据库连接信息…
连接 =jdbc:edb://rh2.home:5444/subuser
用户 =maclean
密码=******
正在导入 Redwood 架构 SCOTT…
表列表: ‘TLOB’
正在创建表…
正在创建表: TLOB
已创建 1 个表。
正在以 8 MB 批次大小加载表数据…
正在将大型对象加载到表: TLOB…
表数据加载摘要: 时间总计 (秒): 1.122 行数总计: 100 大小总计 (MB): 0.380859375
数据加载摘要: 时间总计 (秒): 1.122 行数总计: 100 大小总计 (MB): 0.39
正在创建约束: SYS_C005182

已成功导入架构 SCOTT。

迁移过程已成功完成。

迁移日志已保存到 C:\Users\windesk\.enterprisedb\migrationstudio\build60

******************** 迁移摘要 ********************
Tables: 1 来自 1
Constraints: 1 来自 1

全部对象: 2
成功计数: 2
失败计数: 0

*************************************************************
—————-FINISHED———

下面我们到EnterpriseDB中去验证导入数据:

[enterprisedb@rh2 ~]$ psql
Password:
Welcome to psql 8.3.0.112, the EnterpriseDB interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with edb-psql commands
       \g or terminate with semicolon to execute query
       \q to quit

edb=# \c subuser
You are now connected to database "subuser".
subuser=# desc scott.tlob;
      Table "scott.tlob"
 Column |  Type   | Modifiers
--------+---------+-----------
 t1     | numeric | not null
 t2     | text    |
 t3     | bytea   |
Indexes:
    "sys_c005182" PRIMARY KEY, btree (t1)

subuser=# select count(*) from scott.tlob;
 count
-------
   100

(1 row)

可以看到装换过程中将clob类型转制为text,而blob类型则转制为bytea。postgre中text类型为可变无限长文本类型(variable unlimited length)。

正想去EnterpriseDB网站去查一下官方定义,却发现了以下留言:

We are in the process of updating our website. The site will not be available for the next few minutes. Sorry for the inconvenience.
The EnterpriseDB Web team.

另外bytea类型为一种变长的二进制字串,postgre组织的文档对这2种类型的存储数据上限没有非常明确的叙述,就目前找到的文献可以肯定的是postgre V7中这两种类型大小限制为1G

那么如果Oracle 中Blob/Clob类型大小超过了1G,就可能导致迁移无法正常进行。

EnterpriseDB Migration 迁移工具使用测试(1)

EntperpriseDB 目前作为Postgre开源数据库的企业发行版,在原开源社区的基础上对postgre进行了扩展(contribute),值得关注的技术有infiniteCache,以及其强大的迁移工具Migration tools;下面我们来简单测试该迁移工具.

通过安装postgreplus-advanced-server软件包,其中将默认包括DBA management Server,DBA monitor Console,Migrate Studio,Replication Tools等一系列管理工具。我们需要用到的是Migrate Studio.

打开Migrate Studio首先定义迁移目标端的Enterprisedb实例,事先已经在主机rh2.home上安装了EnterpriseDB 8.3R2版本,同时创建了名为maclean的数据库(database),使用默认端口5444,新建EDB服务器:

该工具同大多数Oracle管理工具一样使用java驱动,但速度较快显得十分轻量级。

接着我们需要创建源端的Oracle服务器,同样在远程主机rh2.home上建立了Version 10.2.0.1的Oracle EE版数据库实例名为g10r21,Listener监听在端口1521上,尝试创建该服务器时将被要求Oracle JDBC包,该包可以到oracle官方网站下载,之后将该包放置到$EDBHOME/jre/lib/ext目录下;新建Oracle服务器:

之后我们可以尝试将Oracle实例中Scott模式下的对象迁移到enterprisedb中,在此之前我们在该模式下建立简单的存储过程,协同测试。

SQL> create or replace procedure scott.count_emp as
2  c int;
3  begin
4  select count(*) into c from scott.emp;
5  dbms_output.put_line('emp count is '||c);
6  end;
7  /

Procedure created.

SQL> set serveroutput on ;
SQL> exec scott.count_emp;
emp count is 14

PL/SQL procedure successfully completed.

接下来开始进行正式迁移,打开源库Oracle实例的树形图,并找到Scott模式,右键进入在线迁移模式, 目标端服务器为target(rh2.home:5444),指定Maclean数据库,架构(模式)仍为Scott,其他均使用默认设置,点击运行开始迁移:

迁移日志如下:

[Starting Migration]

源数据库连接信息...

连接 =jdbc:oracle:thin:@rh2.home:1521:g10r21

用户 =system

密码=******

目标数据库连接信息...

连接 =jdbc:edb://rh2.home:5444/maclean

用户 =maclean

密码=******

正在导入 Redwood 架构 SCOTT...

正在创建架构...scott

正在创建表...

正在创建表: BONUS

正在创建表: DEPT

正在创建表: EMP

正在创建表: SALGRADE

已创建 4 个表。

正在以 8 MB 批次大小加载表数据...

正在加载表: BONUS ...

表数据加载摘要: 时间总计 (秒): 0.128 行数总计: 0

正在加载表: DEPT ...

已迁移 4 行。

表数据加载摘要: 时间总计 (秒): 0.118 行数总计: 4

正在加载表: EMP ...

已迁移 14 行。

表数据加载摘要: 时间总计 (秒): 0.121 行数总计: 14

正在加载表: SALGRADE ...

已迁移 5 行。

表数据加载摘要: 时间总计 (秒): 0.145 行数总计: 5

数据加载摘要: 时间总计 (秒): 0.512 行数总计: 23 大小总计 (MB): 0.0

正在创建约束: PK_DEPT

正在创建约束: PK_EMP

正在创建约束: FK_DEPTNO

正在创建过程: COUNT_EMP

已成功导入架构 SCOTT。

正在创建用户: SCOTT

迁移过程已成功完成。

迁移日志已保存到 C:\Users\windesk\.enterprisedb\migrationstudio\build60

******************** 迁移摘要 ********************

Tables: 4 来自 4

Constraints: 3 来自 3

Procedures: 1 来自 1

Users: 1 来自 1

全部对象: 9

成功计数: 9

失败计数: 0

*************************************************************

----------------FINISHED---------

迁移过程中没有出现错误,下面我们来测试下之前建立的存储过程:

maclean=# exec count_emp;
emp count is 14

EDB-SPL Procedure successfully complete

沪ICP备14014813号-2

沪公网安备 31010802001379号