Oracle distributed Features

There has been a debate about 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 architecture's and access methods. 

To the hardware vendors, a distributed database is a system composed of different database all running on the same hardware platforms.  In fact, each of these descriptions fits the overall model for distributed, but there are some distinguishing characteristics between a real distributed database and a loosely-coupled system.  The standard definition of distributed database has been developed by C. J. Date, where he stated twelve specifications for an ideal distributed database:

1.  Local Autonomy

2.  No reliance on a central site

3.  Continuous operation

4.  Location independence

5.  Fragmentation independence

6.  Replication independence

7.  Distributed query processing

8.  Distributed transaction management (update processing)

9.  Hardware independence

10.  Operating system independence

11.  Network independence

12.  Database independence

1.  Local Autonomy

Local autonomy means that all of the data in the distributed network is owned and managed locally.  For example, a site in New York would have a remote database that participates in a national distributed system.  While functioning as a part of the distributed network, the New York database continues to process local operations independently from the overall distributed system, and the New York database does not rely on the distributed system to function.  Oracle allows this feature in Net8 by allowing each database to function independently from other "linked" databases.

2.  No reliance on a central site.

Ideally, all sites are equally "remote", and no one site has governing authority over another node.  Each site retains it's own Oracle data dictionary and table security.

3.  Continuous operation

Each site is capable of processing independently from the other remote sites, and the addition of a new site will not effect 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 site may access information from the site in a seamless fashion.  Continuous operations 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 operations tools include Oracle Parallel Server and Oracle snapshots.

4.  Location independence

End-user do not necessarily know, or care, about the physical location of the databases that comprise the system.  Data is retrieved without any specific reference to the physical sites.  Oracle Net8 accomplishes this by the use of transparent service names that hide the IP address, protocol and remote database name.

5.  Fragmentation independence

Fragmentation independence refers to the ability of the end-users to store logically related information at different physical locations.  There are two types of fragmentation independence, vertical partitioning and horizontal partitioning.  Horizontal partitioning allows for different rows of the same table to be stored at different remote sites.  This is commonly used by organizations that maintain several branch offices, each with an identical set of table structures.  Vertical partitioning refers to the ability of a distributed system to fragment information such that the data columns from the same logical tables are maintained across the network.  Oracle accomplishes this with Oracle "views" that hide specific columns and rows in a table.

6.  Replication independence

Replication is the ability of a database to create copies of a master database at remote sites.  These copies are sometimes called snapshots and may contain the whole database or any sub-component of the database.  In relational databases, a CUSTOMER table may be snapped to many remote sites for read-only query.  Subsets of the customer table may be specified, requesting only specific row and columns, and these replication are refreshed on a periodic basis.  Oracle accomplishes this feature with Oracle snapshots and replication.

7.  Distributed query processing

Distributed query processing is more than the ability to execute a query against more than one database.  In Oracle, the query is executed at the node that the user is signed-on to, while other database's partition a distributed query into sub-queries, executing each subquery on it's host processor.  In Oracle, a distributed query might query data items from widely distributed databases in a single query.  Oracle implements distributed queries with database links.

8.  Distributed transaction management (update processing)

Distributed transaction management refers to an Oracle database that can manage an update, insert, or delete to multiple databases from a single query.  Most database vendors use the two-phase commit to implement this process, and Oracle implements this feature with the RECO process.  The two-phase commit insures that all of the remote database have successfully completed their sub-updates before the entire transaction is COMMITTED to the database. 

9.  Hardware independence

This refers to the ability of a query to query and update information regardless of the hardware platform on which the data resides.  A single query from a PC might retrieve information from an IBM 3090, a local database on the PC, and an HP-9000 in a single transaction.  Of course a Net8 implementation does not care what type of processor is included in the network.

10.  Operating system independence

Again, a query should not be dependent upon an operating system and Oracle  multi-protocol facility manages this aspect if distribution.

11.  Network independence

Network protocols should not be an issue for distributed databases.  Protocol conversion routines such as Net8 allow synchronous channels (such as those on IBM mainframes) to communicate with the asynchronous Unix world.  They also accommodate differences in topology so that LU6.2 can communicate with TCP/IP, and so on.

12.  Database independence

Database independence refers to the ability to retrieve and update information from many different database and database architectures.  Oracle has not fully implemented this feature, although there are gateway products that allow Oracle to communicate with other databases such as IBM's DB2 database product.