Oracle has sophisticated
mechanisms to manage data concurrency and replication is
normally used when we have geographically distributed systems
with unreliable network connectivity between systems. In a
perfect world, database would not be replicated, but the nature
of worldwide networking mandates that global eCommerce system
have replicated database to provide fast response time
worldwide.
Because the Oracle Streams
product is new, Oracle professionals are only now recognizing
how Streams can be used to in a master-master replication
architecture. Let’s take a closer look.
On the other had, Oracle
Streams is perfect for geographically distributed applications
where real-time synchronization is not required. Let’s
explore master-master replication with a hypothetical example.
Assume that we have a online database serving the US Federal
government which is deployed using APEX making it accessible
anywhere in the world with an internet-enabled web browser.
Federal agencies will connect with either the California or the
Texas server, based on their APEX shortcut URL. The two
systems are cross-fed updates via Oracle Streams and the Texas
server will use Data Guard to replicate to standby database in Kittrell North Carolina (Figure 1).
Figure 1 – Combining Oracle
Streams and Oracle data Guard
Oracle Streams will provide
near real-time replication of important information and in case
of a server outage, updates are automatically stored in update
queues and applied automatically when service is restored to the
crashed Oracle server.
Providing reliable
connectivity during network outages is very challenging and
sophisticated, and Oracle has several tools that will aid TCI in
their goals. In case of any type of outage we see alternative
connection options:
-
Interconnect is down – All end-users
will continue to operate independently and when the
interconnect is restored the updates queues will synchronize
each database.
-
California or Texas Server down – The
end-user will have three icons on their desktop, and a
California end-user simply clicks on the URL for the Texas
database and continues working.
-
Major Disaster
– In this case the
Kittrell NC server will be synchronized using Data Guard
(with a possible loss of the most recent redo log updates)
and end-users with access to the internet can continue to
work on the standby server. Upon restoration of service,
the Kittrell server will flush all updates back to the main
California and Texas databases.
Establishing the replication
mechanisms is only part of the task. We also need detailed
checks to alert the DBA staff when an outage has occurred. The
end-user will have it easier, and know to simply log in to the
surviving Oracle database. Let’s look at the replication alert
mechanisms.
Streams replication failure alerts
This is a critical component
of the replication so that Oracle staff can be aware when there
has been a server or network failure. The alerts will include
checks from the Kittrell, checks between Texas and California,
and checks of the replication queues. Because the connectivity
checks must be done outside from Oracle, the checks can be done
using Linux cron entries.
-
Ping from standby server - The
Kittrell standby server will check every 15 minutes for
connectivity to all servers with a “ping” command. If the
servers fail to respond a pager alert will be sent to
support staff.
-
California and Texas connectivity checks
– Each server will cross-check each other, first checking
with tnsping, then ping, and sending appropriate alerts in
cases of network failure.
Creating a self-synchronizing replication
architecture
Once the Oracle Streams, Data
Guard and alerts are in-place, the only challenge for the Oracle
DBA is ensuring that the Streams replication queues have enough
room to hold updates on the surviving Oracle instance.
For more information on using
Oracle Streams and Multimaster Replication, we recommend these
books and links:
Streams Replication Links:
Replication Course Training:
