||Oracle Tips by Burleson
Oracle Database Distribution
A distributed database, as its name implies, has its datafiles
spread across several databases in different locations. This may
require that there be Remote DBAs in these distributed locations. The major
consideration will be network reliability. This is especially true
when two-phase commit is used. Under two-phase commit, if one of
your distributed database nodes goes down, you can’t update tables
that undergo two-phase commit with that node’s data.
According to the Oracle9i Distributed Database Administrators Guide
(Oracle Corporation, 2001) the Remote DBA needs to consider the following
items in a distributed environment:
- The number of transactions posted from each location.
- The amount of data (portion of table) used by each node.
- The performance characteristics and reliability of the
- The speed of various nodes and the capacities of its disks.
- The criticality of success if a node or link is down.
- The need for referential integrity between tables.
A distributed database appears to the user to be one database,
but is in fact a collection of database tables in separate databases
spread across several locations. These databases are, of course, on
different computer systems that are connected by a network.
The computers, or nodes in a distributed database environment, will
act as both clients and servers depending upon whether they are
requesting data from another database on a different node or
providing data to a different node as it is requested.
Each site is autonomous, that is, managed independently. The
databases are distinct, separate entities that are sharing their
data. The benefits of site autonomy are:
- The various databases cooperating in the distributed
environment can mirror the local organization’s needs and
desires. This is especially useful at sites where there may be
two organizations that need to share some, but not all, data. An
example would be two aerospace companies cooperating on the
space platform. They may need to share data about design but not
want to share financial information.
- Local data is controlled by the local database
administrator. This limits the responsibility to a manageable
- Failure at one node is less likely to affect other nodes.
The global system is at least partially available as long as a
single node of the database is active. No single failure will
halt all processing or be a performance bottleneck. For example,
if the Pittsburgh node goes down, it won’t affect the Omaha
node, as long as Omaha doesn’t require any of Pittsburgh’s data.
- Failure recovery is on a per-node basis.
- A data dictionary exists for each local database.
- Nodes can upgrade software independently, within reason.
As Remote DBA you will need to understand the structures and limits of
the distributed environment if you are required to maintain a
distributed environment. The features of a two-phase commit, as well
as naming resolution and the other distributed topics, will be
covered in Chapter 14. Figure 1.3 shows a distributed database
Expert Remote DBA
BC is America's oldest and largest Remote DBA Oracle support
provider. Get real Remote DBA experts, call
BC Remote DBA today.