Multiple Database Instances

21
C H A P T E R

In This Chapter
Introduction to Oracle8 instances Oracle8 database applications Oracle8 Parallel Server applications Distributed database server applications

istributing an Oracle8 database seamlessly throughout your enterprise is a challenge. This process involves knowledge of the Users and the applications that use the database, the Oracle8 instance, and the enterprises network, as well as the Oracle8 applications that support multi-instance communication between the Oracle8 database servers. This chapter focuses on the concepts, strategies, and principles involved in implementing multiple instance Oracle8 database systems in your enterprise.

The Oracle8 Instance

To understand how an Oracle8 database can be distributed in an enterprise, lets first discuss Oracle8 instances. The following three steps start and make an Oracle8 database available to your enterprise: 1. Starting an Oracle8 instance. 2. Mounting a database to the instance. 3. Opening the mounted database to the enterprise. Every running Oracle8 database is associated with an Oracle8 instance. The process of starting on an Oracle8 database instance involves reading a parameter file. This file initializes the instance and instructs Oracle8 to allocate a memory area called the System Global Area (SGA). It simultaneously starts one or more Oracle8 processes. An Oracle8 instance can include the following Oracle8 processes:

520

Chapter 21 3 Multiple Database Instances

3 Database Write 3 Log Writer 3 Checkpoint 3 System Monitor 3 Process Monitor 3 Archiver 3 Recoverer 3 Lock 3 Snapshot Refresh 3 Dispatcher 3 Shared Servers The background processes depend on the configuration and application of the Oracle8 server.
Note

Oracle8 options and modules installed on a database server also create extra background processes. You can start an Oracle8 instance in either an exclusive or shared (parallel) mode. Once an instance has mounted a database in an exclusive mode, that database cannot be mounted by any other instance. Exclusive mode instances enable you to design Oracle8 applications with interdatabase communication across the nodes in a loosely coupled multiple database system Oracle8 distributed database systems. A database mounted on an instance started in shared or parallel mode, on the other hand, allows other instances residing on other nodes to mount the same database as well. Shared or parallel multi-instance database systems are known as Oracle8 Parallel Server applications. Oracle8 requires interinstance communication across all nodes of the system to manage the parallel DML transactions directed to a single Oracle8 database. The SGA and the Oracle8 processes of an instance work together to manage the databases data. The combination of the SGA and the Oracle8 processes is known as an Oracle database instance.

Oracle8 Instance Applications

Application design and the available hardware resources dictate the types of Oracle8 instance applications you can implement. The most common Oracle8 strategies follow: 3 Single instance database in exclusive mode.

Chapter 21 3 Oracle8 Instance Applications

521

3 Multi-instance database system in parallel mode. 3 Distributed database systems in exclusive mode.

Single instance database systems

A single instance Oracle8 application started in exclusive mode accesses a single database. Thus, it does not require coordination between other instances running on other nodes in an enterprise. The effort and expense required to migrate this type of Oracle8 application to a multi-instance, multi-node database application can be quite extensive. Both the application using the database and the database itself would require a complete overhaul, redesign, and tune. Figure 21-1 illustrates a single Oracle8 instance application.
Figure 21-1: A single Oracle8 instance database application

Oracle8 instance

Multiple processor machine

Oracle8 database

Multi-instance database system

A multi-instance Oracle8 database system requires an Oracle8 server to run with the Parallel Server option. In this type of database application, the Oracle8 instances are decoupled from their respective databases. Starting an instance in exclusive mode produces a one-to-one relationship of an instance to a database. An instance started in shared or parallel mode enables you to relate many instances directly to a single Oracle8 database. Thus, the Parallel Server application enables

522

Chapter 21 3 Multiple Database Instances

continued access to all data when one instance fails, including the data accessed by an instance on the failed node. Figure 21-2 illustrates multiple instance database application.

Oracle8 instance

Oracle8 instance

Oracle8 instance

Multiple processor machine

Multiple processor machine

Multiple processor machine

Node 1

Node 2

Node 3

Oracle8 database

Figure 21-2: Oracle8s multiple instance database application

An applications performance usually improves with exclusive access to a database on a larger system in comparison with its performance on smaller nodes of a multinode database system. In the latter situation, the high cost of synchronizing and maintaining the database tasks could affect system performance. A Parallel Server accessing a single consolidated database avoids distributed updates, inserts, and deletions. This arrangement also avoids the more expensive two phase commit operations by allowing a transaction on any node to write to multiple Tables simultaneously, regardless of which nodes usually write to these Tables. Overall, the difference in performance depends on the characteristics of all applications sharing access to one single database through the multiple database instances residing on the different nodes of the system.

Chapter 21 3 Oracle8 Instance Applications

523

Note

This Oracle8 application requires the Integrated Distributed Lock Manager (IDLM) process to run on each instance. This process communicates with other IDLMs on other instances to coordinate global locking. The following types of applications are best suited for the Oracle8 Parallel Server application: 3 Applications that primarily query data. 3 Applications that either change disjointed groups of data blocks or change the same data blocks at different times. (These characteristics reduce synchronization costs and IDLM work.)

Caution

Do not assume you can seamlessly switch to a Parallel Server application from a single instance application. This change requires a great deal of database design and tuning. Also, the scalability of a system is not only determined by the number of nodes or CPUs involved, but also by interconnect (bandwidth/latency) and by the amount and cost synchronization.

Oracle8 distributed database system

An Oracle8 distributed database system involves multiple databases directly accessed by a single server and indirectly accessed by other instances through server-to-server cooperation. Each database server node can perform database processing because the data permanently resides among the nodes. You can treat the multiple databases of a distributed system as one logical database each Oracle8 server can access remote databases transparently using Oracles networking product, Net8. If an instance fails in a distributed database system, only the database owned by the failed instance is inaccessible.
Note

An Oracle8 Parallel Server application, in contrast, involves multiple instances that automatically share direct access to a single Oracle8 database. Figure 21-3 illustrates an Oracle8 distributed database application. With distributed database applications, you can keep the data at several widely separated sites as long as network connections exist between the separate nodes. Parallel Server applications, on the other hand, require all data reside at a single site due to the requirement for low latency and high bandwidth communication between the database nodes. If data can be partitioned into multiple databases with minimal overlap, you should use distributed database applications instead of Parallel Server applications.

524

Chapter 21 3 Multiple Database Instances

Oracle8 instance

Oracle8 instance

Multiple processor machine

Net8

Multiple processor machine

Node 1

Node 2

Oracle8 database

Oracle8 database

Figure 21-3: An Oracle8 distributed database application

Administrating a distributed database system requires the coordination of separate database administration between the databases and the network protocols, however. A Parallel Server system, with its consolidated database, greatly simplifies the administrative tasks.

Oracle8 Parallel Server Application

An overview of the Parallel Server application
The Oracle8 Parallel Server application divides large transactions into smaller transactions to execute concurrently on the Oracle8 Parallel Server nodes. This application is designed to run on multiple instances that share a single physical database. Each independent transaction executes immediately on its respective nodes processor without wait time. Each processor of a node in a system performs tasks concurrently. Thus, you can complete Parallel Server transactions in less time than in normal Oracle8 applications. In addition to balancing the workload among CPUs, the Parallel database provides for concurrent access to data and protects data integrity.

Chapter 21 3 Oracle8 Parallel Server Application

525

In Parallel Server applications, data blocks can be present in several SGAs at the same time. Data sharing between SGAs in an Oracle8 Parallel Server is controlled by the Parallel Cache Management (PCM) process, which uses PCM Locks. PCM Locks ensures database buffer cache consistency for all instances. Each Oracle8 instance in a Parallel Server system has a shared memory pool. Any applications connected to the particular instance use this pool. If the same SQL statement is also submitted by another application on a different instance, then the same SQL statement is parsed and stored on the other instance as well. Each instance in an Oracle8 Parallel Server system has its own set of background processes, which are identical to the background process of a single Oracle8 server in exclusive mode. Each instance of an Oracle8 Parallel Server system has its own dictionary cache containing Data Dictionary information in its SGA. Oracle instances in parallel and exclusive modes have the same Data Dictionary structure. In addition to the standard background processes, each instance of a Parallel Server has at least one lock process (LCK0) additional lock processes can be enabled if required. The Oracle8 Parallel Server also has an Integrated Distributed Lock Manager (IDLM) that uses the LMON and LMD0 processes. The LMON process manages instances and processes the data. The LMD process handles remote lock requests. The lock process (LCKn) manages the locks used by an instance and coordinates requests for those locks by other instances. All instances in an Oracle8 Parallel Server must have the same number of lock processes. When an instance fails in shared mode, another instances System Monitor process detects failure and recovers for the failed instance. The lock process of the recovery instance cleans up any outstanding PCM locks for the failed instance. The following list summarizes the characteristics of an Oracle8 Parallel Server system: 3 It is possible to start an Oracle8 instance on one or more nodes in the network. 3 Each instance has its own SGA and set of background processes. 3 All instances share the same datafiles and Control Files. 3 The redo logs must be accessible to all instances in case of instance failure. 3 Archived Logs are private but must be accessible to all instances for media recovery. 3 All instances can execute transactions concurrently against the same database and each instance can have multiple Users executing transactions. 3 Row level locking is preserved. 3 You must connect to an instance to administer the Oracle8 Parallel Server.

526

Chapter 21 3 Multiple Database Instances

In addition to the normal Oracle8 instance background processes, the Oracle8 Parallel Server option also contains the following: 3 A parallel cache management lock area in its SGA to coordinate the use of shared resources. 3 An integrated distributed lock manager. 3 Lock processes to coordinate the locking of shared resources among the multiple processes in a Parallel Server. 3 A lock monitor process to manage global locks and resources.

Attributes of a Parallel Server application

Consider an Oracle8 database topology in which a single physical database is accessed by multiple instances located on different nodes of a database system. This topology prompts additional considerations and concerns for database and network applications when designing the system. The foremost concerns are: 3 Task synchronization 3 Locking 3 Interinstance communication 3 Server hardware 3 Shared instance access to common database resources 3 Redo log files

Task synchronization
In an Oracle8 system, synchronization applies to the coordination of concurrent tasks. The amount of synchronization depends on the amount of resources and the number of Users and tasks working on the resources. Parallel Server database design should have little or no synchronization. A server spending a large amount of time synchronizing tasks indicates a high contention for resources. This contention diminishes the benefits of the parallel processing of tasks. If the cost of synchronization is too high when a Table takes inserts from different nodes, for example, there will be high contention from the different nodes to insert into the same data block. This situation arises because the data block must be passed between the different instance nodes.

Locking
Locks are fundamental to Oracle8 Parallel Server application synchronization. The IDLM is the internal locking facility used by the Oracle8 Parallel Server. The IDLM coordinates resource sharing between nodes running the Oracle8 Parallel Server. The multiple instances also use the IDLM to communicate and coordinate modifications of database resources.

Chapter 21 3 Oracle8 Parallel Server Application

527

Note

Each Parallel Server node operates independently from the other nodes except when contending for the same resources. The IDLM process performs the following database services: 3 Keeps track of the current ownership of a resource. 3 Accepts lock requests for resources from application processes. 3 Notifies the requesting process when a lock on a resource is available. 3 Obtains access to resources for a process. 3 Performs database messaging.

Interinstance communication
The Oracle8 Parallel Server system requires the IDLM to perform interinstance communication over a high network bandwidth with low latency. A networks bandwidth can be described as the total size of messages one can send per second. Latency applies to the time (in seconds) to place a message on the network for processing.

Hardware
Oracle8 Parallel Server systems are more memory- and CPU-intensive than single instance database systems. Migrating or designing a Parallel Server application enables you to complete database tasks in less time. This savings comes with an overhead cost, however. Extra background processes are required for locking and synchronizing tasks from the multiple instances in the Parallel Server system. I recommend the following hardware to support each node in an Oracle8 Parallel Server system: 3 Clustered and Massively Parallel Processing (MPP) hardware in which each node has its own memory. 3 SMP hardware in which multiple processors use one memory resource.

Shared instance access to common database resources

The multiple instances of an Oracle8 Parallel Server system need concurrent access to the same database. Thus, all nodes in an Oracle8 Parallel Server system must have simultaneous access to the same database resources. The first started instance must verify access to all online datafiles to determine if media recovery is required. Additional instances can operate without access to all online datafiles, but you generate an error if you attempt to use a nonexistent datafile.

528

Chapter 21 3 Multiple Database Instances

See Reference Section

ALTER SYSTEM

When an instance adds a datafile or brings an offline datafile online, all instances verify access to that datafile. If the verification fails for any instance, you need to diagnose and repair the datafiles using the ALTER SYSTEM CHECK DATAFILES. This statement ensures online datafiles are available for instances that require access. Oracle8 cannot recover from media instance failure unless the instance that performs recovery can verify access to all online datafiles.

Note

Redo log files

In an Oracle8 Parallel Server system, each instance writes to its own set of online redo log files. As redo files are written by a single instance, it is also known as a thread of a redo. Each online redo log file is associated with a particular thread number. When an online redo log is archived, its thread number is recorded for identification during recovery.

Designing an Oracle8 parallel server system

Oracle8 usually bases the Parallel Server systems around applications that focus on optimizing the CPU usage of each instances node. Each Oracle8 Parallel Server residing on each node must minimize the computing resources used for interinstance lock operations. This minimization is also termed Parallel Cache Management (PCM) and synchronization by the IDLM. The PCM ensures all master copies of the data blocks in any instances SGA are identical if the instance SGA requires a master copy. Thus, the most recent copy of the data block in all SGAs contains all changes made to that data block by all instances in the system, regardless of whether any of the transactions on those instances have been committed. If a data block is modified in one buffer cache, all existing copies in other buffer caches are no longer current and you obtain new copies after modification completes.
Note

You cannot minimize the number of PCM lock operations during the final tune of the system. You must plan this stage early in the physical database design process. By partitioning the application and data, you obtain greater cache affinities between the database data and the specific nodes. A partitioned application ensures Oracle8 performs a minimum number of lock conversions. In this way, you reduce data block pinging and IDML activities. A lock conversion occurs when a shared lock moves up to an exclusive lock and vice versa.

Database application profiling

When partitioning an application and its data, the database designer must understand and anticipate the type of transactions or business functions that may cause excessive interinstance lock conversions on the respective data blocks. You

Chapter 21 3 Oracle8 Parallel Server Application

529

must undertake an access cross-reference profile of the application Tables and their respective access patterns. This profiling exercise can include: 3 Identifying read only Tables 3 Experiencing random SELECT and UPDATE SQL operations 3 Experiencing SELECT, INSERT, UPDATE, and DELETE SQL operations

Read only Tables

Read only Tables and their associated Index structures require a small allocation of PCM locks. All Parallel Server nodes initialize the PCM locks to shared mode and little locking activity takes place.
See Reference Section Tip

ALTER TABLESPACE

Consider putting read only Tables on read only Tablespaces using the ALTER TABLESPACE READ ONLY statement. This placement speeds recovery and does not require PCM locks.

Random SELECT and UPDATE Tables

This kind of SQL access requires many PCM lock conversions. If transactions on different Parallel Server nodes modify the same data blocks, the PCM locks the same data blocks concurrently, which leads to performance penalties.
INSERT, UPDATE, and DELETE Tables

These types of SQL operations require reading a number of data blocks and modifying some or all of the data blocks read. This process requires converting the PCM locks to shared mode and then converting them to exclusive mode after block modification. Again, if these types of transactions are executed from different nodes, a performance penalty could result from the number of PCM locks converted and held. Using the Table access profiles, you can differentiate between transactions that run well over multiple Oracle8 Parallel Server nodes and transactions which should be executed within a single node. Load balancing between the nodes should not be the main objective. Partitioning is the key to good performance and CPU utilization in an Oracle8 Parallel Server system.

Partitioning a database system

The following elements of a database system can be partitioned: 3 Users 3 Applications 3 Data

530

Chapter 21 3 Multiple Database Instances

Partitioning Users
Users can be partitioned based on the following criteria: 3 The groups of Users who access the database 3 Application User groups that access the same data 3 Users based on their respective locations

Partitioning applications
Partitioning applications involves running different applications on different instance nodes in an Oracle8 Parallel Server system. Application partitioning yields good performance as long as you assign different PCM locks to their respective datafiles. With this approach, you must ensure each applications Tables and Indexes are stored so that a PCM lock does not cover any data blocks used by more than one application. Applications that share a set of SQL statements perform optimally when run on the same instance because SQL areas are not shared across instances. Similar sets of SQL statements should run on one instance to improve memory usage and reduce parsing.
Note

This partitioning model is very similar to a distributed database model in which the accessed database Objects are stored together. Data partitioning. In data partitioning, you partition the data vertically and horizontally. This type of partitioning ensures each SQL transaction is executed upon the correct Oracle8 Parallel Server instance. The correct node for execution of the SQL transaction depends on the actual data values used in the transaction. Another name for this process is data-dependent routing. Vertical partitioning. Vertical partitioning divides tables among the instances. Applications run against tables in a single partition and a large number of tasks can run on a large number of resources without substantial synchronization. Figure 21-4 illustrates vertical partitioning of an Oracle8 Parallel Server system. In this example, tables used only for engineering students reside in one partition, exclusive tables for computer science students are stored in a second partition, and tables only for accounting students are placed in a third partition of the database. The three parallel nodes each serve a single set of students so there is no resource contention between the nodes.

Chapter 21 3 Oracle8 Parallel Server Application

531

Oracle8 instance

Oracle8 instance

Oracle8 instance

Multiple processor machine

Multiple processor machine

Multiple processor machine

Engineering student

Computer science student

Accounting student

Node 1

Node 2

Node 3

Oracle8 Database
Engineering Accounting

Computer science

Figure 21-4: Vertically partitioning an Oracle8 Parallel Server system

Horizontal partitioning
Horizontal partitioning divides portions of tables among the instances based on a data value. Suppose an Oracle8 Parallel Server system is made up of four instances. The data can be partitioned so that each instance accesses only a subset of the whole data. Little synchronization is necessary because the instances access different sets of rows. Figure 21-5 illustrates horizontal partitioning of an Oracle8 Parallel Server system. In this type of partitioning, a single tables rows are divided into partitions. The three partitions base their division of rows on the type of student (engineering, computer science, or accounting). Furthermore, the three nodes have applications dedicated to a single type of student. Few transactions affect more than one partition, thus minimizing synchronization.

532

Chapter 21 3 Multiple Database Instances

Oracle8 instance

Oracle8 instance

Oracle8 instance

Multiple processor machine

Multiple processor machine

Multiple processor machine

Engineering student

Computer science student

Accounting student

Node 1

Node 2

Node 3

Oracle8 database

Node 1 data

Node 2 data

Node 3 data

Figure 21-5: Horizontally partitioning an Oracle8 Parallel Server system

Implementing and administrating an Oracle8 Parallel Server

Parallel Server is an Oracle8 option you must install after installation of the Oracle8 server. Once installed, the Parallel Server can be disabled or enabled. If the Parallel Server option is disabled, only one Oracle8 instance can mount or open a database. The Parallel Server disabled mode is necessary to create and completely recover a database. When enabled, one or more instances of an Oracle8 Parallel Server system can mount the same database. In this case, it reads from and writes to the same datafiles. When an instance starts, the Oracle8 Parallel Server uses the values found in an initialization parameter file to create the SGA for that instance. All instances of the Parallel Server access the same Control Files. These Control Files hold the values of

Chapter 21 3 Oracle8 Parallel Server Application

533

global constant initialization parameters some of which must be identical for all instances. When the instances of the Parallel Server start, each instance compares the global constant initialization values with other instances in the Parallel Server system. If certain core values are different, Oracle8 generates a message and the Parallel Server system startup fails.

Distributing the Oracle8 control files

You can use the following topologies to distribute Control Files for multiple instances in an Oracle8 Parallel Server system: 3 Using a common parameter file for all instances. This allows a one-to-many mapping between the Control File and the Parallel Server instances. Administration of the Control Files is simple because you only need to make changes to one Control File for all instances. 3 Using an individual parameter file for all instances. If the initialization parameters are different for various Parallel Server instances, you can use individual files with a one-to-one mapping to the instances. 3 Using Control Files with an IFILE parameter. If you set the IFILE parameter in the Control Files, each individual parameter file can embed an additional parameter file containing common values. In a Parallel Server system, some initialization parameters must have the same values for every instance, whether you use individual or common parameter files. By using the IFILE parameter, you place common parameters in a single source Parameter File used by all instances. Then you can safely use a separate parameter file for each instance to define the remaining individualized parameters. Instances must use individual parameter files in the following cases: 3 Every instance that uses a private rollback segment must have its own parameter file, but instances that only use public rollback segments can all use the same parameter file. 3 Every instance that specifies the INSTANCE_NUMBER or THREAD parameter must have its own parameter file.
Note

The PFILE option of the STARTUP command enables you to specify a parameter file other than the default file when you start an instance. The parameter must be accessible to the local node, even for an instance on a Remote node.

Starting multiple instances

Before starting multiple instances, you should conduct the following administrative tasks: 3 Create an extra rollback segment for each additional instance 3 Add and enable a thread for each additional instance 3 Provide additional locks for any added datafiles

534

Chapter 21 3 Multiple Database Instances

Enabling Parallel Server and starting multiple instances

In a Parallel Server system, each instance must mount the database in shared mode. Each initialization file for each instance must have the SINGLE_PROCESS parameter set to FALSE and the PARALLEL_SERVER Parameter set to TRUE. If one instance mounts a database in shared mode, other instances can also mount the database in shared mode, but not in exclusive mode.
See Reference Section

ALTER DATABASE

Use the following steps as a guide to starting the instances on each node of the Parallel Server system: 1. Set the PARALLEL_SERVER parameter to TRUE in the initialization file. (Default is FALSE.) 2. Start any required OS-specific processes. 3. Start Group Membership Services. 4. Connect with SYSDBA or SYSOPER privileges or connect as INTERNAL. 5. Start an instance by using the following command:
STARTUP NOMOUNT;

6. Mount a database using the following command:

ALTER DATABASE <database_name> MOUNT;

7. Open the database using the following command:

ALTER DATABASE <database_name> OPEN;
Note

If an instance mounts a database with the PARALLEL_SERVER parameter set to FALSE, no other instance can mount that database. Before you can start an instance in exclusive mode, you must shut down all instances running in shared mode. Suppose you attempt to start an instance and mount a database in shared mode while another instance is currently recovering the same database. Your new instance cannot mount the database until the recovery is complete. In this case, specify the STARTUP RETRY statement, which causes the new instance to attempt to remount the database every five seconds until it succeeds. For example:
STARTUP OPEN <database_Name> RETRY;

Multiple instance startup sequence

An instance can specify its own instance number on startup by explicitly using the initialization parameter INSTANCE_NUMBER specified in its Control File. The INSTANCE_NUMBER parameter ensures consistent allocation of extents to instances

Chapter 21 3 Oracle8 Parallel Server Application

535

for INSERTs and UPDATEs and enables efficient maintenance of partitioned data among the instances. If an instance does not use a specified instance number, it automatically acquires the lowest available instance number. The startup order of the instances determines the instance numbers for those instances that do not specify their own INSTANCE_NUMBER parameter. These nonspecified instance numbers are difficult to control when instances start in parallel because a particular instance receives a new number when you shut down and restart that instance.
Note

Instance numbers must be unique for each instance in the Oracle8 Parallel Server system. The SHOW PARAMETERS INSTANCE_NUMBER command displays the instance numbers assigned for each instance in an Oracle8 Parallel Server system. A null value for an instance number implies the value is server-assigned.

Multiple instance groups

To ease administration, you can logically group different instances together and perform parallel operations upon all associated instances at once, thus enabling effective partitioning of resources. To specify instance groups, the INSTANCE_GROUPS initialization parameter within the parameter file for each instance is associated with an instance group. For example:
INSTANCE_GROUPS = ObjectMind, Library
Note

You cannot change instance groups dynamically. To use a particular instance group for a given parallel operation, specify the following parameter in the initialization file:
PARALLEL_INSTANCE_GROUP = <groupname>

All operations initiated from that instance spawn processes only within that group. You can change this dynamic parameter using ALTER SESSION or ALTER SYSTEM commands.

Shutting down instances

To shut down a Parallel Server system, you must shut down every instance in the system. The following steps must take place on each Oracle8 Parallel Server instance: 1. Connect with SYSDBA privileges or connect as INTERNAL:
CONNECT Username/Password AS SYSDBA;

536

Chapter 21 3 Multiple Database Instances

2. Close the database:

ALTER DATABASE <database_Name> CLOSE;

3. Dismount the database:

ALTER DATABASE <database_Name> DISMOUNT;

Parallel server concepts

You need to understand concepts not usually addressed in a single instance system before designing an Oracle8 Parallel Server system. The Parallel Server concepts mainly focus on how the Oracle8 caches are synchronized across instances. This synchronization assists in understanding the ongoing overhead that affects the performance in an Oracle8 Parallel Server system. The following major concepts are prerequisite knowledge for the database application: 3 Internode synchronization issues 3 Parallel cache management 3 Instance lock modes

Internode synchronization issues

Internode synchronization involves the following concepts: 3 Block level locking 3 Row level locking 3 Space management 3 System change numbers In exclusive mode, you perform all synchronization within the instance. In shared mode, you achieve synchronization with the assistance of the IDLM process.

Block level locking

Every time Oracle attempts to read a block from the database, it needs to obtain an instance lock. Thus, you assign ownership of the lock to the instance. When certain blocks are locked by an instance, Oracle8 does not permit other instances to access them. Since the Oracle8 Parallel Server system runs in an environment with multiple instance memories, multiple copies of the same data block can reside in the different multiple instance memories. In this case, you apply internode synchronization using the IDLM to ensure all copies of the block are valid.

Chapter 21 3 Oracle8 Parallel Server Application

537

Row level locking

Row level locking operates in an Oracle8 system whether the Parallel Server is enabled or disabled in addition to block level locking in the buffer cache.
Note

Row level locks are stored within the data blocks.

Space management
Allocating space for inserts creates space management issues in an Oracle8 Parallel Server system.
Example

For example, when a Table uses more space for an INSERT operation, how do you make sure no other INSERT transaction uses the same space? How can you make sure two nodes are not inserting into the same space on the same disk in the same Datafile? The Oracle8 Parallel Server system uses free lists and free list groups to optimize space management.

Free lists
A free list is a set of data blocks located in extents that contain free space. You use these data blocks when you make INSERTs or UPDATEs to a database Object (such as a Table or a cluster). No contention among instances occurs when different instance transactions insert data into the same database Object. Oracle8 locates the free space for the new rows using free space lists it associates with one or more instances. The free lists may be from a common pool of blocks or multiple free lists can be partitioned so specific extents in files are allocated to objects.

Free list groups

The Oracle8 Parallel Server can use free list groups to eliminate contention between instances accessing a single block containing free lists. Even if multiple free lists reside in a single block, the block containing the free list forces constantly reads and writes between all instances. To avoid this contention problem, group free lists to assign one group to each instance. Each instance then has its own block containing free lists. Now you know each instance uses its own free lists, which eradicates contention between instances accessing the same block that contains the free lists.

System Change Number

The System Change Number (SCN) is a logical timestamp Oracle8 uses to order events within a single instance and across all instances. In standard Oracle8, the SCN is maintained and incremented in the SGA by an exclusive mode instance. In an Oracle8 Parallel Server system, the IDLM or the Lamport SCN scheme can manage the SCN generation process. The Lamport SCN is the fastest and most scaleable way to produce SCNs in parallel on all instances. In this scheme, all messages

538

Chapter 21 3 Multiple Database Instances

across instances including lock messages piggyback the SCNs. Thus, you generate the SCNs without extra communication among the multiple instances.

Parallel Cache Management

The Parallel Cache Manager (PCM) uses the IDLM Locks to coordinate access to the following database resources. The instances of an Oracle8 Parallel Server system require the following: 3 Rollback segments 3 Data Dictionary 3 Data blocks The PCM enforces cache coherency while minimizing I/O and use of the IDLM. I/O and lock operations are only required when the current version of a data block is in one instances buffer cache and another instance requests that block for an UPDATE operation. Instances use instance locks simply to indicate the master copy ownership of a database resource. When an instance becomes the owner of a master copy of a database resource, it also inherently becomes the owner of the instance lock covering the resource with fixed locking. A master copy indicates it is an updateable copy of the resource. The instance only disowns the instance lock when another instance requests the resource for an UPDATE operation. After another instance owns the master copy of the resource, that instance becomes the owner of the instance lock. PCM locks and row level locks operate independently. The row level lock concurrency control mechanisms are independent of the PCM because the Oracle8 concurrency controls do not require PCM locks and the PCM lock operations do not depend on individual transactions committing or rolling back. The major differences between PCM locks and row level locks follow: 3 An instance can disown a PCM lock without affecting row locks held in the same set of blocks covered by the PCM lock. 3 A row level lock is acquired during a transaction in which it does not release the row level lock until changes to the row are either committed or rolled back. 3 A data block acquires a PCM lock when an instance reads it for an UPDATE Operation. During UPDATE transactions, a PCM lock can be disowned and owned many times if other instances need the blocks.

Instance lock modes

An instance can acquire an instance lock in the following Modes: Exclusive lock mode. The exclusive lock mode allows the instance to update a set of blocks. For example, an instance needs to update a data block with an exclusive

Chapter 21 3 Oracle8 Parallel Server Application

539

instance lock from another instance. The instance requiring the data block uses the IDLM to request the locking instance to disown the instance lock, writing the blocks to disk if necessary. Read lock mode. The read lock mode only allows the instance to read the data blocks. Multiple instances can own an instance read lock as long as they do not modify the data blocks covered. Null lock mode. The null lock mode allows instances to keep a lock without any permission on the actual data block. This mode is useful when you do not continually need to obtain and release instance locks, thus saving the cost of lock conversions.

The benefits of an Oracle8 Parallel Server

Implementing an Oracle8 Parallel Server can reap the following advantages over single instance Oracle8 systems as well as Oracle8 distributed database systems:

Higher performance
A Parallel Server takes advantage of each instances processor by sharing resources without sacrificing any transaction processing features of the Oracle8 DBMS. Utilizing this database topology, more CPUs are available to an application. The improvement in performance is dependent on the degree of internode locking and synchronization activities, however. Each lock operation is processor- and message-intensive, thereby allowing for high levels of latency.

Better transaction handling

Oracle8 only reads data blocks from disk if they are not already in the buffer cache of the instance that needs the data. Because data blocks are deferred, they often contain modifications from multiple instances. The Oracle8 Parallel Server provides a feature known as multiversion read consistency to handle this issue. For example, when a transaction on one node locks and updates a row, the multiversion read consistency feature allows other transactions (on other nodes) to lock and update other rows in the same data block without waiting for the first transaction to commit or roll back its row. If a row has been modified but not yet committed, the original row values are available to all instances for read access only. The Oracle8 Parallel Server only writes modified data blocks to disk under the following conditions: 3 When the blocks have not been used recently and new data requires buffer cache space 3 During checkpoints 3 When another instance needs the data block 3 Row locking and multiversion read consistency

540

Chapter 21 3 Multiple Database Instances

Higher availability
An Oracle8 Parallel Server system isolates the nodes. In this way, a failure at one node does not crash the whole system. The remaining nodes can recover the failed node transactions and continue to provide data access to Users. This strategy enables applications to automatically reconnect to the database after a break in the connection. On instance failure, any active transactions are rolled back the new database is identical to the original database. An Oracle8 Parallel Server system never allows a client to experience loss of connection as long as one instance is left serving the application.
Tip

The DBA should dictate which applications run on the different Oracle8 instances, thus creating a failover order for each application.

Greater flexibility
Instances can be allocated or deallocated from an Oracle8 Parallel Server system as necessary. If there is a high demand for database resources, instances can be temporarily allocated. Once the traffic for the database reduces, the instances can be deallocated from the system. Thus, the DBA can set up instance allocation strategies based on peak and nonpeak times of a database applications usage.

More Users
An Oracle8 Parallel Server system can overcome memory limits by enabling a single system to serve thousands of Users.

Online backup and recovery

In an Oracle8 Parallel Server system, each instance can automatically and manually archive its redo log files. In ARCHIVELOG mode, both online and offline backups can take place, but in NOARCHIOVELOG mode, only offline backups can take place.
Tip

Parallel Servers should always be in ARCHIVELOG mode.

Sequence number generators

An Oracle8 Parallel Server system enables Users on multiple instances to generate unique sequence numbers. The Parallel Servers sequence number generator allows multiple instances to access and increment a sequence without creating contention among instances for sequence numbers or waiting for any transactions to commit. Each instance has its own dedicated sequence cache for faster access to sequence numbers.
Note

The IDLM locks coordinate sequences across the multiple instances in an Oracle8 Parallel Server.

Distributed processing of a parallel query

An Oracle8 Parallel Server enables the parallel query feature of Oracle8 to distribute queries between nodes so multiple nodes can execute processing on

Chapter 21 3 Distributed Database Application

541

behalf of a single query. The Parallel Server splits individual queries into units of work Oracle8 can process simultaneously.
Tip

In general, queries consume more CPU and disk I/O than INSERT, UPDATE, and
DELETE transactions.

The traps of an Oracle8 Parallel Server system

The benefits of implementing an Oracle8 Parallel Server system are inviting. Without understanding the concepts behind the Parallel Server system, however, the benefits can easily be negated. The following guidelines summarize when an Oracle8 Parallel Server system is not as advantageous as a multi-instance database application: 3 When the cost of synchronization becomes too high 3 When there is contention between instances for a single data block or row

Distributed Database Application

An Oracle8 distributed database system is a set of Oracle8 databases stored on multiple computers that appears to applications and Users as a single Oracle8 database. Each Oracle8 database in a distributed database system efficiently cooperates with the other remote Oracle8 databases to maintain consistency of the globally distributed data. Each computer involved in an Oracle8 distributed database system is a node.
Note

Database replication should not be confused with a distributed database system. Replication is the process of copying and maintaining database objects in multiple databases that compose a distributed database system. You need a networking infrastructure to link and allow the Oracle8 database servers to communicate with each other. You can accomplish this interdatabase communication by using Net8, Oracles networking software for distributed database systems. Net8 supports remote and distributed transactions in an Oracle8 distributed database system. Net8 makes the connectivity necessary to transmit SQL requests transparent and receives data for applications using the distributed database system. Net8 transmits SQL and Packages to an Oracle server over industry-standard communication protocols (such as TCP/IP). Net8 also receives replies from a server and packages them for transmission back to the appropriate client.

Note

Net8 supports all interdatabase communication independent of an underlying network operating system.

542

Chapter 21 3 Multiple Database Instances

An Oracle8 network can also use Oracle Names to provide the system with a global directory service. This service acts as a central repository for information about each database in the distributed system. Thus, introducing Oracle Names to a distributed database system eases the configuration of all distributed database access requirements.

Heterogeneous Oracle8 distributed database systems

In a heterogeneous distributed database system, at least one of the databases is a non-Oracle system. To allow interdatabase communication between a heterogeneous database and an Oracle8 database, you need an Oracle8 Open Gateway. There are different Oracle8 Open Gateways. Each is suited to interface to a particular database vendor such as Sybase, Microsoft, or Informix. Together with an Oracle8 Open Gateway, an Oracle8 server provides full transparency to an application between the Oracle8 and heterogeneous distributed database environments. The various features of the Oracle8 Open Gateways follow: 3 Distributed transactions 3 Transparent SQL access 3 Procedural access 3 Data Dictionary translations 3 Non-Oracle pass-through SQL 3 Accessing stored Procedures 3 National language support 3 Global query optimization
Note

Each Oracle8 Open Gateway product contains some or all of the preceding features.

Developing distributed database systems

Before designing or migrating to an Oracle8 distributed database system, you should assess the proposed system for the following requirements: 3 The number of transactions posted from each location 3 The amount of data used by each node 3 The performance characteristics and reliability of the network 3 The speed and capacities of disks to be used

Chapter 21 3 Distributed Database Application

543

3 The importance of access of a node if the link goes down 3 The need for referential integrity among remote and local Tables using Constraints and Triggers Each preceding point is critical in any Oracle8 distributed database environment.

Schema Object name resolution

A single instance Oracle8 server guarantees each Schema has a unique name and each database Object has a unique name within a Schema. In a distributed database system, Schemas, as well as Schema Objects, can share the same Name. At the same time, they can be accessible to all applications in the system. To resolve references between the various Schemas and Schema Objects in a distributed database system, Oracle8 simply extends the hierarchical naming model with global database names to create global Object names effectively. For example, the following two queries each reference a different STUDENTS Table:
SELECT * FROM maria.students@UK.ObjectMind.COM SELECT * FROM rao.students@UK.ObjectMind.COM

Using different Oracle server versions

You can incorporate different versions of the Oracle server into an Oracle8 distributed database system. The most important aspect of integrating different Oracle server versions is adherence to their respective functionality capabilities at each node of the distributed system. For example, you cannot expect an Oracle7 server to understand the extended PL/SQL in Oracle8.

Transparency in an Oracle8 distributed database system

The goal of transparency is to make an Oracle8 distributed database system appear like a single Oracle8 database, thereby shielding the developers and Users from the interdatabase complexities of the distributed environment. The following methods achieve distributed database transparency:

Location transparency
Location transparency enables a User or application to refer universally to a database Object, regardless of the location of the node to which the database connection takes place. The advantages for location transparency follow: 3 Access to remote data is simple because the Users are not concerned with the physical location of the database Objects. 3 Administrators can move database Objects with no impact on end Users or existing applications. You can achieve location transparency for database Objects by creating Synonyms.

544

Chapter 21 3 Multiple Database Instances

A Synonym can be created for any Table, type, view, snapshot, sequence, Procedure, function, or Package. All Synonyms are stored in the Data Dictionary of the database in which they are created.
See Reference Section

CREATE SYNONYM

The following syntax creates a Synonym:

CREATE [Public] SYNONYM Synonym_Name For [Schema.]Object_Name[@database_Link_Name]

For example, the following statement creates a Synonym for the STUDENTS Table residing in the ObjectMind domain:
CREATE PUBLIC SYNONYM students for tony.students@UK.ObjectMind.COM

To access the STUDENTS Table without using Synonyms, use the following SQL statements:
SELECT student_Name FROM tony.students@UK.ObjectMind.COM

With the Synonym in place, you can issue the following SQL statement to retrieve the same results:
SELECT student_Name FROM students

A Synonym is a reference to an actual database Object. A User with access to a Synonym for a particular Schema Object must also have privileges on the Schema Object itself. The owner of the local Synonym cannot grant any Object privileges on the Synonym to any other local User.
Tip

Local views can also provide location transparency for database Tables residing on remote databases.

SQL statement transparency

You do not need complex programming to provide distributed transaction control. Oracle8 allows the following DML statement to reference remote Tables in a distributed database environment:
SELECT INSERT UPDATE DELETE SELECT..FOR UPDATE LOCK TABLE

The preceding DML statements must reference LONG and LONG RAW data on the same node.

Chapter 21 3 Distributed Database Application

545

Note

Oracle8 does not allow remote DDL operations.

Administrating an Oracle8 distributed database system

Administrating an Oracle8 distributed database system is identical to administrating a single instance Oracle8 system, with the addition of the following areas: 3 Managing global database and database Object names 3 Managing database links

Global database names and global Object names

In an Oracle8 distributed database system, each database must have a global name for unique identification. A global database name consists of two parts: 3 A database name 3 A database Domain name The database and domain names are determined by the initialization parameters DB_NAME and DB_DOMAIN.
Note

You should name a database link the global database name of the remote database it references. Oracle uses the global database name to globally name the Schema Objects using the following naming convention:
<Schema>.<schema_Object><@Global_Database_Name>

For example, the following global Object name identifies the STUDENTS Table in Marias Schema in the UK.ObjectMind.COM domain:
maria.students@UK.ObjectMind.COM
Tip

If you set the GLOBAL_NAMES initialization parameter to TRUE, Oracle8 ensures the database link name matches the global database name of the remote database. Once global naming has been enabled, database links are essentially transparent to the Users and applications of a distributed database system.

Database links
Database links facilitate application database requests within an Oracle8 distributed database system. These links define a one-way communication path from one Oracle8 database to another Oracle8 database. A database link should

546

Chapter 21 3 Multiple Database Instances

be transparent to Users and applications if it shares the same name as the global name of the database to which the link points.
See Reference Section

CREATE DATABASE LINK

For example, the following statement creates a database link in a local server to the UK.ObjectMind.COM database:
CREATE DATABASES LINK UK.ObjectMind.COM;

After creating this database link, Users and applications connected to the local database can immediately access data in the remote UK.ObjectMind.COM database. If the Oracle8 Names server is used to resolve distributed database network addresses for the SQL queries, the Net8 Assistant tool can also create database links, as illustrated in Figure 21-6.

Figure 21-6: Create database links using Oracles Net8 Assistant

Types of database links

To support User and application access to data and Schema Objects in an Oracle8 distributed database system, administrators must create all necessary database links to allow full remote communication between the Oracle8 distributed databases.

Chapter 21 3 Distributed Database Application

547

Database links can be created with three levels of security: Private. With a private database link, only the owner of a database link or PL/SQL subprograms in the schema can use the link to access data and Objects in a corresponding remote database.
See Reference Section

CREATE DATABASE LINK

To create a private database link, begin the command using the following syntax:
CREATE PRIVATE DATABASE LINK...

Private links can only be used by the user that created the link. Public. With a public database link, all Users and PL/SQL subprograms in a database can use a public database link to access data and database Objects in the corresponding remote database.
See Reference Section

CREATE DATABASE LINK...

To create a public database link, begin the command using the following syntax:
CREATE PUBLIC DATABASE LINK...

Global database links. Global database links only apply to networks that use Oracle Names. In such a system, the Oracle8 Name servers automatically create and manage global database links for every Oracle8 database in the network. With a private or public database link, you can dictate to which Schema on the remote database the database link establishes connections. To enable these connections, create fixed User, current User, and connected User database links. Fixed User database link. With a fixed User database link, the local server always establishes a connection to a fixed remote Schema in the remote database. Use the following syntax to create a fixed User database link:
CREATE [PUBLIC] DATABASE LINK <db_Link_Name> [CONNECT TO Username IDENTIFIED BY Password] | [CONNECT TO CURRENT_USER] AUTHENTICATED BY Schema_Name IDENTIFIED BY Password [USING 'service_name'];

Connected User and current User database links. In an Oracle8 distributed database system, the credentials used to connect to a remote database can change depending on the User referencing the database Link and the operations performed by the application. For example, if you want to establish a database link based on the type of credentials of the connected User or applications, you create connected User and current User database links.

548

Chapter 21 3 Multiple Database Instances

A connected User connects to a database using a database application. A current User connects to the database in the security context in which a database operation executes. Use the following syntax to create a connected User database link:
CREATE [PUBLIC] DATABASE LINK <db_Link_Name> AUTHENTICATED BY Schema_Name IDENTIFIED BY Password [USING 'service_name'];

Use the following syntax to create a current User database link:

CREATE [PUBLIC] DATABASE LINK <db_Link_Name> [CONNECT TO Username IDENTIFIED BY Password] | [CONNECT TO CURRENT_USER] [USING 'service_name'];

Shared database links. By default, every application that references a remote server using a standard database link establishes a connection between the local database and the remote database. Therefore, many Users or applications accessing the databases simultaneously can cause the number of connections between the local and remote databases to increase suddenly. You can use shared database links to resolve the escalating connection problem. Shared database links limit the number of network connections required between the local and remote server. Use shared database links when you expect the number of Users accessing a database link to be much larger than the number of shared servers in the local database. Use the following syntax to create a shared database link:
CREATE SHARED DATBASE LINK <db_Link_Name> [CONNECT TO Username IDENTIFIED BY Password] | [CONNECT TO CURRENT_USER] AUTHENTICATED BY Schema_Name IDENTIFIED BY Password [USING 'service_name'];
Note

To use shared database links, the local server must run in Multi-Threaded Server (MTS) mode. The remote server can either run in MTS mode or dedicated server Mode.

See Reference Section

Dropping a database link

DROP DATABASE LINK

To drop an existing database link regardless of its type, use the following syntax:
DROP DATABASE LINK <db_Link_Name>
Tip

Use one of the following Data Dictionary views first to confirm the database link exists.

Chapter 21 3 Distributed Database Application

549

3 USER _DB_LINKS 3 ALL _DB_LINKS 3 DBA_DB_LINKS

Understanding distributed transaction management

Any relational database management system must guarantee all statements in a transaction, distributed or nondistributed, either commit or roll back as one unit. This form of transaction management ensures the data in the database is always consistent. Oracle8 coordinates distributed transaction control in its distributed systems with the same characteristics as local Oracle8 systems. Oracle automatically controls and monitors the commit or roll back of a distributed transaction and maintains the integrity of the global database using a transparent transaction management mechanism known as the Two Phase Commit.
Note

Do not confuse a remote transaction with a distributed transaction. A remote transaction contains remote statements that all reference the same remote node. A distributed transaction includes statements that individually or as a group update data on two or more distinct nodes of a distributed database system.

Oracle8s Two Phase Commit mechanism

Oracle8s Two Phase Commit mechanism guarantees all database servers participating in a distributed transaction either commit or roll back the statements in a transaction. It also protects against implicit DML operations performed by integrity Constraints, remote procedure calls, and Triggers. The committing of a distributed transaction has two distinct phases: 3 The Prepare phase 3 The Commit phase

The Prepare phase

The Prepare phase is the first phase in committing a distributed transaction. In this phase, no commits or rollbacks are carried out. Instead, all nodes referenced in a distributed transaction prepare to commit. Each node establishes the necessary locks and resource allocations needed to commit or abort the transaction. When a node responds to the requester, the prepared node promises it will either commit or roll back the transaction at a later time.
Note

Queries starting after a node has prepared the transaction cannot access the associated locked data until all phases are complete.

550

Chapter 21 3 Multiple Database Instances

When a requester instructs a node to prepare, it can respond using the following return values: 3 Prepared. Implies the node has successfully prepared. 3 Read Only. Implies data on the node can only be queried, not modified. 3 Abort. Implies the node could not successfully prepare, causing the transaction to be rolled back immediately.

The Commit phase

Before this phase occurs, all nodes referenced in the distributed transaction must first guarantee they have successfully prepared and thus have the necessary resources to commit the transaction. The Commit phase consists of the following operations: 3 The global coordinator sends a message to all nodes requesting them to commit the transaction. 3 At each node, Oracle8 commits the local portion of the distributed transaction, thereby releasing any locks held. 3 The local Oracle8 server records an additional redo entry in the local redo log indicating the transaction was committed. When the Commit phase is complete, the data on all nodes of the distributed system is consistent.

The Oracle8 session trees

As Oracle8 issues the statements in a distributed transaction, it defines a session tree of all nodes participating in the transaction. A session tree is a hierarchical model that describes the relationship between sessions and their respective Roles. All nodes participating in the session tree of a distributed transaction assume one or more of the following Roles:

Client
The client node references information from another nodes database.

Database server
The database server node is directly referenced in a distributed transaction or is requested to participate in a transaction because another node requires data from its database.

Chapter 21 3 Distributed Database Application

551

Global coordinator
The global coordinator node identifies the node from which the distributed Transaction originated. This node becomes the parent node or root of the session tree. The global coordinator node performs the following steps: 1. It sends all distributed transactions directly to the referenced nodes, thus forming the session tree. 2. If all nodes prepare successfully, the global coordinator instructs the commit point site to initiate the global commit of the transaction. 3. If one or more abort messages are received, the global coordinator instructs all nodes to initiate a global rollback of the transaction.

Local coordinator
The local coordinator node references data on other nodes to complete its part in a distributed transaction. The following criteria determine the roles played by nodes in a distributed transaction: 3 Whether a transaction is local or remote to the node 3 The commit point strength of that node 3 Whether all requested data is available at a node or whether other nodes need to be referenced 3 Whether the node is read only

The commit point site

The commit point site initiates a commit or rollback as instructed by the global coordinator node. The system administrator must designate a node as the commit point site in the session tree by assigning all nodes a commit point strength. The node selected as commit point site stores the most critical data. The commit point site differs from all other nodes in that it never enters the prepared state. The outcome of a distributed transaction at the commit point site determines whether the transaction at all nodes is committed or rolled back.
Note

You can set a nodes commit point strength by using the initialization parameter COMMIT_POINT_STRENGTH. The range of valid values for the commit point strength are 0 200.

552

Chapter 21 3 Multiple Database Instances

Summary
This chapter introduces the concept of having multiple instances to an Oracle8 database. Multiple instance Oracle8 databases can be created using two different architectures the Oracle8 Parallel Server option and the Oracle8 distributed database architecture. Both architectures require a great deal of architecture planning and implementation effort. The end result, embraced by the hardware resources, provides fault tolerant node architectures for an Oracle8 database. The advantages of distributing the processing and data across multiple modes (Parallel Server) and databases (Distributed Architecture) are as follows: 3 Increased performance on most transactions. 3 Increased transaction handling. 3 Higher availability for the database system. 3 The flexibility to handle a larger user population. 3 Better backup and recovery strategies. 3 Distribution of the data processing throughout the database system.

Parallel Server
This Oracle8 Parallel Server architecture is designed to create multiple instances on the Oracle8 nodes. All Oracle8 instances share a single physical database. Each Parallel Server node has its own suite of Oracle8 instance background processes, including the Integrated Distributed Lock Manager (IDLM). The Oracle8 Parallel Server architecture divides large database transactions into smaller transactions that are executed concurrently on the Oracle8 Parallel Server nodes. Each independent transaction executes immediately on its respective nodes processor with no wait time. The Oracle8 Parallel Server can load balance the database transactions across the multiple nodes in the architecture, providing concurrent access to the data.

Oracle8 distributed architecture

An Oracle8 distributed database system is a set of Oracle8 databases stored on multiple computers that appear to applications and Users as a single Oracle8 database.

Chapter 21 3 Summary

553

Each Oracle8 database in a distributed database system efficiently cooperates with the other remote Oracle8 databases to maintain consistency of the globally distributed data. Net8 gels the network communications required between the distributed databases. The Oracle8 distributed model permits the integration of heterogeneous systems.