Network Topology   «Prev  Next»

Lesson 6 Distributed databases
ObjectiveWhat are the features of a distributed database?

Distributed Database Features

There is an ongoing debate regarding a standard definition for distributed Oracle databases. To Oracle, a distributed database is a geographically distributed system composed entirely of Oracle products. To the GUI/tools vendors, a distributed database is a system that is distributed architecturally, having systems with different architectures and access methods. To the hardware vendors, a distributed database is a system composed of different databases, all running on the same hardware platforms. In fact, each of these descriptions fits the overall distributed model, but there are some distinguishing characteristics that differentiate a real distributed database from a loosely coupled system. The standard definition of distributed database has been developed by C. J. Date; he lists 12 specifications for an ideal distributed database:

Homogenous Distributed Database Systems

A homogenous distributed database system is a network of two or more Oracle databases that reside on one or more machines. Figure 3-6 illustrates a distributed system that connects three databases: hq, mfg, and sales. An application can simultaneously access or modify the data in several databases in a single distributed environment. For example, a single query from a Manufacturing client on local database mfg can retrieve joined data from the products table on the local database and the dept table on the remote hq database. For a client application, the location and platform of the databases are transparent. You can also create synonyms for remote objects in the distributed system so that users can access them with the same syntax as local objects. For example, if you are connected to database mfg but want to access data on database hq, creating a synonym on mfg for the remote dept table enables you to issue this query:

SELECT * FROM dept;
In this way, a distributed system gives the appearance of native data access. Users on mfg do not have to know that the data they access resides on remote databases.
Homogenous Distributed Database Systems
Figure 3-6 Homogenous Distributed Database Systems

An Oracle distributed database system can incorporate Oracle databases of different versions. All supported releases of Oracle can participate in a distributed database system. Nevertheless, the applications that work with the distributed database must understand the functionality that is available at each node in the system. A distributed database application cannot expect an Oracle7 database to understand the SQL extensions that are only available with Oracle9i.

Continuous Operation

Each site is capable of processing independently from the other remote sites, and the addition of a new site will not affect the overall system. While each site maintains its own unique identity and control, it functions as a part of a unified federation such that other remote sites can access information from it in a seamless fashion.
Continuous operation also refers to the ability of each node to be available to the overall system 24 hours per day, seven days per week. To accomplish this goal, remote sites may have a "hot backup" tool such as the Oracle Enterprise Backup Utility (EBU) or the Oracle8 Recovery Manager (RMAN) to back up the database while it remains available for update. Other Oracle continuous-operation tools include Oracle Parallel Server and Oracle snapshots.

One of the most common reasons for developing a distributed database system is to provide redundancy and fault tolerance. By the same token, a distributed system should not require scheduled outages to perform maintenance such as adding and removing a site or upgrading software. Of course, in the ideal world we would have zero downtime, scheduled or not, however unplanned outages are difficult to avoid entirely.

Definition of Continuous Operation Distributed System

Continuous operation of a distributed system means that no maintenance tasks should require an outage of the entire system. Maintenance tasks may include upgrades to the operating system or RDBMS or the addition and deletion of participating sites.
If the Oracle distributed system is built on database links and simple replication (i.e., read-only snapshots), then there are no maintenance activities that would require an outage of the entire distributed environment. Sites can be added or removed at any time, and upgrades can be executed without impacting participating sites. However, if you are using the advanced replication facilities, Oracle imposes certain limitations. Most significantly, if you wish to add a new master or snapshot site to a replicated environment, you must coordinate the addition so that the data at the new site includes data changes that may have occurred while the new site is being instantiated.

Distributed Databases eliminates Central Database Reliance

Ideally, all sites are equally remote, and no one site has governing authority over another.
Each site retains its own Oracle data dictionary and table security.
A data dictionary is a set of metadata that contains definitions and representations of data elements. Within the context of a DBMS, a data dictionary is a read-only set of tables and views. Amongst other things, a data dictionary holds the following information:

  1. Precise definition of data elements
  2. Usernames, roles and privileges
  3. Schema objects
  4. Integrity constraints
  5. Stored procedures and triggers
  6. General database structure
  7. Space allocations

Distributed database systems provide information on the networking, configuration, security, and design of systems. Any organization that uses the Oracle relational database management system (RDBMS) probably has multiple databases. There are a variety of reasons why you might use more than a single database in a distributed database system:
  1. Different databases may be associated with particular business functions, such as manufacturing or human resources.
  2. Databases may be aligned with geographic boundaries, such as a very large database at a headquarters site and smaller databases at regional offices.
  3. Two different databases may be required to access the same data in different ways, such as an order entry database whose transactions are aggregated and analyzed in a data warehouse.
  4. A busy internet commerce site may create multiple copies of the same database to attain horizontal scalability.
  5. A copy of a production database may be created to serve as a development test bed.

Ad Distributed Databases