BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation







  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.

This is an excerpt by Mike Ault’s book “Oracle9i Administration & Management”.  If you want more current Oracle tips by Mike Ault, check out his new book “Mike Ault’s Oracle Internals Monitoring & Tuning Scripts” or Ault’s Oracle Scripts Download.

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.

Remote DBA Service

Oracle Tuning Book


Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software







BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.