Page Comparison

Dbvisit Replicate works with Oracle Cloud.

Dbvisit Replicate can be used with the Oracle Database Cloud - Database as a Service - with either the pre-installed or the Virtual Image options. 
This can be on-premise to cloud, cloud to cloud, or cloud back to on-premise configurations.

In this article we focus on configuring an Oracle to Oracle replication – powered by Dbvisit Replicate.
This software ensures that the changes made in our local “on-premise” Oracle database, for the schema/table Dbvisit Replicate works with Oracle Cloud.

Dbvisit Replicate can be used with the Oracle Database Cloud - Database as a Service - with either the pre-installed or the Virtual Image options. 
This can be on-premise to cloud, cloud to cloud, or cloud back to on-premise configurations.

In this article we focus on configuring an Oracle to Oracle replication – powered by Dbvisit Replicate.
This software ensures that the changes made in our local “on-premise” Oracle database, for the schema/table subsets we are interested in, are synchronized in real time with an Oracle database running in the Oracle Cloud.

...

1. Download it from the Dbvisit website
2. Load it onto your source server
3. From there copy it to the Oracle Cloud VM. Alternatively you could establish another SSH connection to the Oracle Cloud VM (i.e. from your local machine/laptop) and upload from that machine. I chose this latter method and use the FileZilla FTP application for the transfer. Having this connection from my laptop is also beneficial if I want to download log files/support packages, etc, from that machine, later on for review.

Then RUN the install command. In my example which follows, I make use of the RPM method (there are also zip file and Windows installer options) which requires root access – so you need to connect as OPC to the Oracle Cloud VM (sudo -s) to do the same. 
The RPM install command takes this format:

...

9. Replication configuration. The good news is that, at this point, all the hard work has been done and from here there is nothing specific or unusual about connecting Dbvisit Replicate up to an Oracle Database running in the Oracle Cloud. From the perspective of our application this is basically a standard Oracle to Oracle configuration and so the standard step by step details should be worked through.

For the purposes of this replication test, I have created a user called HR in both the source and target databases, and the following empty tables (HR.TEST1 and HR.TEST2) on both sides:

create table HR.TEST1 ( 
  test_number NUMBER, 
  test_float FLOAT, 
  test_varchar2 VARCHAR2(100), 
  test_varchar VARCHAR(100), 
  test_char CHAR, 
  test_nvarchar2 NVARCHAR2(100), 
  test_nchar NCHAR, 
  test_date DATE, 
  test_raw RAW(1000), 
  test_long LONG, 
  CONSTRAINT TEST1_PK PRIMARY KEY (test_number) 
);


create table HR.TEST2 ( 
  test_number NUMBER, 
  test_long_raw LONG RAW, 
  CONSTRAINT TEST2_PK PRIMARY KEY (test_number) 
);

Step 1: Specify Databases – add the local on-premise database as 1 and the remote Oracle Cloud Database Service as 2 (make sure you remember the passwords for SYS and SYSTEM which you specified for this back when creating the service!). Note that archive log mode does not need to be enabled on the target database – UNLESS you intend to configure bi-directional replication, or use this as a source for another replication configuration.

Step 2: Specify Replication Pairs – select 1 (on-premise) as source and 2 (Oracle Cloud database) as target. Accept the defaults, including the DDL replication option. For the purposes of this example, we are going to start with empty tables on both sides so the instantiation options will not come into play here – but you should review these to learn more about the types available. 

Step 3: Specify Schemas and Tables – again, select all the defaults to keep things simple, and enter HR as the schema to replicate.

Step 4: Configure Processes – accept all the defaults for 1, the MINE side configuration. For 2 APPLY side, pay attention to the “Directory with DDC file and default where to create log files etc” question. This is the location created on the Oracle Cloud VM as the home directory for the replication configuration, and this may be different to what you have for the MINE/source side (see 8.iii above). It is also highly likely that the TNS_ADMIN location on your Oracle Cloud will be different to that of your on-premise server, so choose the option to review all the parameters, and edit TNS_ADMIN accordingly. This location is $ORACLE_HOME/network/admin by default and should look something like this:

/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/

Step 5: Final Wrap Up – once completed, then exit out of the Dbvisit Replicate setup wizard, and run the .all script as directed, and follow the other detailed instructions. worked through.

For the purposes of this replication test, I have created a user called HR in both the source and target databases, and the following empty tables (HR.TEST1 and HR.TEST2) on both sides:

create table HR.TEST1 ( 
  test_number NUMBER, 
  test_float FLOAT, 
  test_varchar2 VARCHAR2(100), 
  test_varchar VARCHAR(100), 
  test_char CHAR, 
  test_nvarchar2 NVARCHAR2(100), 
  test_nchar NCHAR, 
  test_date DATE, 
  test_raw RAW(1000), 
  test_long LONG, 
  CONSTRAINT TEST1_PK PRIMARY KEY (test_number) 
);


create table HR.TEST2 ( 
  test_number NUMBER, 
  test_long_raw LONG RAW, 
  CONSTRAINT TEST2_PK PRIMARY KEY (test_number) 
);

Step 1: Specify Databases – add the local on-premise database as 1 and the remote Oracle Cloud Database Service as 2 (make sure you remember the passwords for SYS and SYSTEM which you specified for this back when creating the service!). Note that archive log mode does not need to be enabled on the target database – UNLESS you intend to configure bi-directional replication, or use this as a source for another replication configuration.

Step 2: Specify Replication Pairs – select 1 (on-premise) as source and 2 (Oracle Cloud database) as target. Accept the defaults, including the DDL replication option. For the purposes of this example, we are going to start with empty tables on both sides so the instantiation options will not come into play here – but you should review these to learn more about the types available. 

Step 3: Specify Schemas and Tables – again, select all the defaults to keep things simple, and enter HR as the schema to replicate.

Step 4: Configure Processes – accept all the defaults for 1, the MINE side configuration. For 2 APPLY side, pay attention to the “Directory with DDC file and default where to create log files etc” question. This is the location created on the Oracle Cloud VM as the home directory for the replication configuration, and this may be different to what you have for the MINE/source side (see 8.iii above). It is also highly likely that the TNS_ADMIN location on your Oracle Cloud will be different to that of your on-premise server, so choose the option to review all the parameters, and edit TNS_ADMIN accordingly. This location is $ORACLE_HOME/network/admin by default and should look something like this:

/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/

Step 5: Final Wrap Up – once completed, then exit out of the Dbvisit Replicate setup wizard, and run the .all script as directed, and follow the other detailed instructions. 

Demo Videos building on the configuration example above

Demo 1: in this short clip, we walk through Steps 1-5 outlined above to configure an “on-premise Oracle to Oracle Cloud database” replication pair, working with Dbvisit Replicate. 

Demo 2: in this second short clip, we turn our attention to seeing the replication we have just configured put to work in real time, and try it out with some basic test loads. The assumption is, at this stage, that all the configuration steps listed above (and walked through in Demo 1) have been completed AND that the instruction set produced by the ALL script (*all.sh) has been actioned. Amongst other things, this requires that the APPLY.ddc file and the script to run the APPLY process on the target side have been transferred across.

As explained earlier, to keep things simple in this test, we are working with empty tables, TEST1 and TEST2, under the HR schema – which has also been cleaned out of any other tables that may have existed prior. We are going to startup the Dbvisit Replicate processes, and then create a test load by inserting data into these tables on the source (on-premise) database (and you can get the script for this here). Once this has been replicated across to the target side, the Oracle Cloud database, we create a new table on the source side under the HR schema, TEST3, using a CTAS statement (logged in as SYS):

create table HR.TEST3 as select * from dba_tables;