Databases Reference
In-Depth Information
ing of the application connection to the standby if needed. Thus, if the database
server fails, the application is automatically reconnected to the standby server.
•
Again, unlike the replication-based scenario, setup and configuration of the
standby system are partially automated usually through the help of software
wizards.
The memory-to-memory log shipping strategy is used in Oracle Data Guard,
Informix HDR, and DB2 HADR. These products can offer a range of control for the
degree to which data is kept synchronous on the standby servers. For example, DB2
offers synchronous, near-synchronous, and asynchronous modes. This allows a com-
mon infrastructure to be used for both local failover and geographic failover, where a
local standby server is kept synchronized through synchronous replication, while a
remote server (which incurs latency due to its distance) can be updated asynchronously.
Depending on the product, the replicated database may or may not be available for
query processing or write operations (insert, update, delete). When the standby server is
available to share in the data processing, the overall solution is called “active-active”
since both servers contribute processing power to transaction query processing. Con-
versely, when the standby database server is unavailable for processing unless the pri-
mary database has failed, the system is called “active-passive” processing.
All of the three strategies we have discussed so far are useful both for keeping data
available when a local server has failed and for geographically remote failover in the
case of site disaster. The site disaster is handled by keeping the standby server in a geo-
graphically remote location (perhaps another city). The geographic separation of the
servers can incur time delay as well as some administrative burden since the DBA and
system administrator can't be in the same location as both servers. For most adminis-
tration functions, being in the same room or same city as the database server is not
important, though there are obvious exceptions (e.g., inserting a CD or replacing a
hardware component).
The fourth availability technology is “shared disk.” The most popular of these are
Oracle RAC and DB2 for zOS's Parallel Sysplex solution. With these strategies several
computers share the same set of data on disk, but considerable handshaking is required
to ensure consistency of the data that may be updated by any one of the servers. The
major focus in shared-disk solutions is to ensure that the failure of any node in the sys-
tem results in very little downtime and data loss for the entire system (as perceived by
the connected applications). However, what shared-disk solutions do not focus on is the
disk availability, which is assumed to be highly available through the use of RAID
arrays, and their implied redundancy.
Oracle RAC (Figure 13.16) has become quite popular in recent years because of its
ease of use and it is the only shared-disk solution in the open platform space (UNIX/
Windows). Database storage pages can be accessed by more than one server at a time
using a technique known as “cache cohesion,” which maintains integrity of data on
