EnterpriseDB: Verify EDB Schema
Oracle Tips by
few steps in this example are to demonstrate how to verify a
replication set up. The first step in verification is to ensure
that the new HR schema exists in EnterpriseDB (our snapshot should
have created that).
check this by opening Developer Studio and check that a new HR schema
exists (Figure 7.21)
7.21: Verify Schema Created in EnterpriseDB
see in the figure above that the tables I selected for replication:
countries, departments, employees, jobs, locations and regions, do
exist in the edb database.
Verify Oracle Configuration
step is to verify that the expected triggers were created for the HR
objects (Figure 7.22).
7.22: Verify Triggers in Oracle
also verify that the shadow tables were created in the rrepadmin
schema (Figure 7.23) in Oracle.
7.23: Verify Replication Administrator Tables
Insert Source Data
I am sure that all of the expected objects exist in both Oracle and
EnterpriseDB, I will insert a record in Oracle and then monitor
EnterpriseDB to see it arrive.
7.24 shows an Oracle SQL*Plus session connecting to the HR account and
inserting a record into the HR.locations table. Before inserting
the row, I did a describe to see which columns were not null (so I
could successfully insert a row) and then selected any rows with a
location ID of 9999 to make sure I was inserting a unique row.
7.24: Create a Test Record
Select Target Data
successfully inserting a row in Oracle, I check the EnterpriseDB
instance to see if the new row arrives. The schedule was
configured as continuous (execute every 10 seconds).
take at least 10 seconds before I see the transactions. In
Figure 7.25, I run the command several times before the transaction
7.25: Verify Data Synchronization
error in the above screenshot was a typo on my part. Not an
error in replication.
that this chapter is one of the most important in this book. To
me, the success of EnterpriseDB Advanced Server is not in how it
replaces Oracle, but in how it works with Oracle. The
EnterpriseDB Replication Sever allows Oracle and EnterpriseDB to work
together in your data center.
EnterpriseDB Replication Server is integrated with the DBA Management
Server instance and is optionally available to premium subscribers.
The replication console is the GUI configuration and monitoring tool.
replication works via a repository based, publish/subscribe model.
Publications and subscriptions are maintained in a central repository
and the replication server maintains the appropriate connections and
7.26 displays a simple diagram outlining the architecture of the
replication server and its relationship to the Oracle source databases
and the EnterpriseDB target databases.
7.26: Simplified Replication Architecture
Implementation of Oracle to EnterpriseDB replication via the
replication console can be reduced to a checklist:
Configure Oracle Replication Administrator
on replicated tables
Configure Replication Management Server
Replication Services (Publish and Subscribe)
Configure the Publisher (Oracle)
Configure the Subscriber (EnterpriseDB)
the Publication (List of replicated objects)
the Subscriptions (Who gets what)
* Take a
snapshot (Create replicated objects in target)
Synchronize (Play catch-up)
follow the checklist in order, any errors will prevent you from
continuing through the process until they are fixed. That will
save you from having to redo steps later.
thing to watch out for is performance impacts due to the triggers
being added to the source database. Testing replication does not
just mean testing data propagation; you must test all of the pieces to
ensure a quality implementation.
chapter ends the discussion of EnterpriseDB tools. The next and
last chapters discuss compatibility with Oracle and migrating a sample
is an excerpt from the book "EnterpriseDB:
The Definitive Reference" by Rampant TechPress.