Oracle Replication Resource Page

Oracle Database 9.2 and above are supported by HVR.

HVR supports all editions of the Oracle Database, i.e. Express Edition, Standard Edition, Standard Edition One, and Enterprise Edition.

Yes, HVR supports all combinations of versions and editions, clustered and non-clustered, with the many options to store database files.

Yes, from HVR’s perspective Oracle Exadata is an Oracle RAC on Linux environment.

Linux, Windows, Solaris, AIX and HP-UX, both on physical and virtual environments.

HVR relies on Oracle Client libraries to connect to the Oracle Database, and to ASM if it is used. To establish the connection HVR requires access to Oracle Client libraries. With that HVR supports connections to a local database and remote connections using Oracle’s TNS. For a RAC environment a connection can be made through the SCAN listener.

Yes, HVR services can be enrolled in Oracle Clusterware in order to be highly available in a RAC environment.

Yes, HVR can be used for log-based change data capture from and delivery into pluggable databases, as well as of course traditional non-pluggable database.

HVR directly accesses the Oracle Database transaction logs on the file system, including when the data resides in ASM. In rare cases HVR may (transparently) retrieve data from the database using an SQL statement.

Yes, HVR integrates with the Oracle Wallet and supports all flavors of Transparent Data Encryption in Oracle.

For optimum performance, HVR recommends a local installation on the Oracle Database server. However, depending on the setup, there are options for remote capture on a different server running the same operating system using remote TNS connects, or file sharing e.g. using NFS. HVR also supports a so-called archive log only mode to run capture on a different server that does not run any database processing.

At the database level the DBA must enable minimal supplemental logging using an alter database statement. In addition, HVR will create supplemental log groups on all tables that will be replicated in order to capture at least the primary key columns for updates. The HVR solution connects to the database using a database user account with elevated privileges.

Yes, HVR can run directly on a data guard physical standby database. The physical standby can be an active standby database but doesn’t have to be. Note that for the initial load (so-called refresh in HVR) HVR will have to run against the primary database if the standby is not open for read-only. Also, supplemental logging has to be enabled on the primary database.

Yes, HVR can be run on a separate server (or virtual machine) in an archive log only mode with archives copied to the server or made accessible through a file share. Note the operating system on the capture machine must match the database operating system, and supplemental logging has to be enabled through a connection to the actual source database. Also, the initial load has to be performed directly from the source database.

On the capture side HVR will position a capture process, per thread, to a position in the transaction log based on the initialization time. From the starting point forward HVR will capture any changes against the tables that are part of the setup. Following the initial positioning the capture process keeps track of the log sequence number of the oldest open transaction it was tracking, and the relative byte address within that. If the capture is restarted for whatever reason then HVR simply goes back to the point in the logs where it left off when it last checkpointed. This type of recovery is fundamental to HVR. On the integration side, HVR uses a state table to ensure recoverability. As part of every transaction HVR applies to the target database it will process an update to the state table. In case of any interruptions, HVR will rely on the state table in the destination database, and the fact that Oracle performs transactional processing, to ensure not change are lost and changes are not applied more than once.

Yes, by default HVR will not capture changes applied by HVR, and with that setting up active/active replication is straightforward. A quick video on how to setup active/active replication on Oracle is here: https://www.hvr-software.com/resource/setup-multi-active-active-environment/

HVR supports almost all scalar data types through log-based change data capture, including large objects (CLOB, NCLOB and BLOB). Data types that are not natively supported (including XML data types, Spatial and user-defined data types) can typically be included in the replication using a capture expression to retrieve the data through a SQL expression.

Yes, HVR supports DDL replication but only DDL against tables, and changes to the primary key. Other DDL like secondary indexes, triggers, and DDL related to the creation of other database objects like PL/SQL stored objects, data types, users, tablespaces etc. is ignored. With the changes captured HVR supports delivery of the DDL changes in a heterogeneous environment i.e. against any of the supported targets, even if there are transformations in the setup.

At present HVR only supports tables and their primary keys, and database sequences. Any other database objects are ignored during replication.

No, changes to the view are recorded against the underlying tables that make up the view definition. In order to capture changes against a view you should replicate the underlying tables, and re-create the view on the target database. HVR does support replication of changes against a materialized view given the materialized view is implemented using its own table.

Oracle Data Guard is included with the Enterprise Edition Database, providing a disaster recovery solution for the Oracle Database. With that an Oracle Data Guard standby database – in physical standby mode which is the most commonly used mode – has to be the same version of the source database. Also, the entire database is replicated and there is no flexibility for any transformations, or to replicate only one schema or a subset of the tables from the database. However all database objects are duplicated. The Data Guard destination database is however closed for DML and unless the extra-paid option for Active Data Guard is in place there is not even read-only access on the destination database. HVR on the other hand provides logical database replication with the ability to filter tables, columns and even rows, as well as the ability to deliver changes in a heterogeneous environment. The target database for data replication is always open for DML and DDL, so for example any requirement to implement a custom indexing strategy can be implemented on the HVR target database. Also, HVR is not restricted to the Enterprise Edition database but also supports all other Oracle Database editions.

Oracle GoldenGate is Oracle’s data replication technology. It is a very powerful data replication solution similar to HVR’s that comes at a significant cost. Recent versions of Oracle GoldenGate use integrated components in the database which means that bug fixes or enhancements often require a database patch. With similar Change Data Capture capabilities and richer support for heterogeneous environments, HVR is generally more cost-effective than Oracle GoldenGate. In addition, the HVR solution provides powerful capabilities to perform table creation (in a heterogeneous environment), initial data load (again heterogeneously), compare/repair, as well as a graphical user interface an automatic monitoring, all in a single user-interface. Oracle provides products for data integration and management, but they are all different, not necessarily integrated but separately priced, tools and options (Data Integrator for heterogeneous initial loads, Veridata for compare/repair, Enterprise Manager plugin for graphical monitoring, and GoldenGate Studio for a GUI on top of Oracle GoldenGate).

Yes, HVR can be set up to replicate a subset of the tables from the Oracle Database. Even better, per table a subset of the columns can be replicated, and even a subset of the rows can be replicated. In addition, extra columns can be defined with values populated during the replication.