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 network.
• 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 level.
   
• 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 structure.

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.