Release 8.0
A58238-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8 Parallel Server Concepts & Administration Release 8.0 A58238-01 |
|
This chapter describes features of Oracle database architecture that pertain to the multiple instances of a parallel server.
The following sections describe the features of control files, datafiles, and redo log files that apply to a parallel server.
All instances of a parallel server access the same control files. The control files hold the values of global constant initialization parameters, such as GC_DB_LOCKS, some of which must be identical for all instances running concurrently. As each instance starts up, Oracle compares the global constant initialization values in a common parameter file (or in parameter files for each instance) with those in the control file, and generates a message if the values are different.
All instances of a parallel server access the same datafiles. Database files are the same for Oracle in parallel mode as for Oracle in exclusive mode. You do not have to change the datafiles to start Oracle in exclusive or parallel mode.
To improve performance, you can control the physical placement of data so that the various instances use disjoint sets of data blocks. Free lists, for example, enable you to allocate space for inserts to particular instances.
Whenever an instance starts up, it verifies access to all online datafiles. The first instance to start up in a parallel server must verify access to all online files so that it can determine if media recovery is required. Additional instances can operate without access to all of the online datafiles, but any attempt to use an unverified file fails and a message is generated.
When an instance adds a datafile or brings an offline datafile online, all instances verify access to the file. If an instance adds a new datafile on a disk that other instances cannot access, verification fails, but the instances continue running. Verification can also fail if instances access different copies of the same datafile.
If verification fails for any instance, you need to diagnose and fix the problem, then use the ALTER SYSTEM CHECK DATAFILES statement to verify access. This statement has a GLOBAL option (the default), which makes all instances verify access to the online datafiles, and a LOCAL option, which makes the current instance verify access.
ALTER SYSTEM CHECK DATAFILES makes the online datafiles available to the instance or instances for which access is verified.
Oracle cannot recover from instance failure or media failure unless the instance that performs recovery can verify access to all of the required online datafiles.
Oracle automatically maps absolute file numbers to relative file numbers. Use of a parallel server does not affect these values. Query the V$DATAFILE view to see both numbers for your datafiles.
In a parallel server, each instance writes to its own set of online redo log files. The redo written by a single instance is called a thread of 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 to identify it during recovery.
A private thread is a redo log created using the ALTER DATABASE ADD LOGFILE command with the THREAD clause. A public thread is a redo log created using the ALTER DATABASE ADD LOGFILE, but no THREAD clause is specified.
If the THREAD initialization parameter is specified, the instance starting up acquires the thread identified by that value as a private thread. If THREAD is the default of zero, the instance acquires a public thread. Once acquired, a redo thread is used exclusively by the acquiring instance.
Online redo log files can be multiplexed (or "mirrored"). A multiplexed redo log consists of two or more groups of files, and all members of a group are written to concurrently when that group is active. Figure 6-1 shows the threads of redo for three instances of a parallel server.
Group numbers must be unique within the database, but the order of assigning groups to instances is arbitrary. For example, although in Figure 6-1 thread 1 contains groups 1, 2, and 3 while thread 2 contains groups 4 and 5, you could instead assign groups 2, 4, and 5 to thread 1 while assigning groups 1 and 3 to thread 2. The V$LOGFILE view displays the group number associated with each redo log file.
Although it is possible to have different numbers of groups and members per thread, Oracle Corporation recommends that all threads be configured to a common standard.
Different instances of a parallel server can have different degrees of mirroring (different numbers of members per group), and can also have different numbers of groups. For example, one instance could have three groups with two members per group, a second instance could have four log files that are not multiplexed, and a third instance could have two groups with four members per group. While such a configuration may be inconvenient to administer, it may be necessary in order to realize the full potential of the system.
Each instance must have at least two groups of online redo log files. When the current group fills, an instance begins writing to the next log file group. At a log switch, information is written to the control file that can be used to identify the filled group and its thread number after it has been archived.
The number of redo log files about which the control file can keep information is limited by the value of the MAXLOGHISTORY option of the CREATE DATABASE statement. Note that only one member per group is needed. MAXLOGHISTORY can be extremely useful for sites with very demanding availability requirements. This option can assist you in administration of recovery, especially when there are many instances and many log files.
Attention: In Oracle Parallel Server, you should set the value of MAXLOGHISTORY higher than in single instance Oracle, because in OPS the history of multiple redo log files must be tracked.
Each instance of a parallel server has a dictionary cache (row cache) containing data dictionary information in its SGA. The data dictionary structure is the same for Oracle instances in parallel mode as for an instance in exclusive mode. Instance locks coordinate the data dictionary activity of multiple instances.
This section describes the CREATE SEQUENCE statement and its options.
The SQL statement CREATE SEQUENCE establishes a database object from which multiple users can generate unique integers without waiting for other users to commit transactions that access the same sequence number generator.
A parallel server allows users on multiple instances to generate unique sequence numbers with minimal cooperation or contention among instances. Instances locks coordinate sequences across instances in a parallel server.
Sequence numbers are always unique, unless you use the CYCLE option. However, sequence numbers may be assigned out of order if you use the CACHE option without the ORDER option, as described in the following section.
See Also: Oracle8 SQL Reference.
The CACHE option of CREATE SEQUENCE pre-allocates sequence numbers so that they may be kept in an instance's SGA for faster access. You can specify the number of sequence numbers cached as an argument to the CACHE option; the default value is 20.
Caching sequence numbers significantly improves performance but can cause the loss of some numbers in the sequence. Losing sequence numbers is unimportant in some applications, such as when sequences are used to generate unique numbers for primary keys.
A cache for a given sequence is populated at the first request for a number from that sequence. After the last number in that cached set of numbers is assigned, the cache is repopulated.
Each instance keeps its own cache of sequence numbers in memory. When an instance shuts down, cached sequence values that have not been used in committed DML statements can be lost. The potential number of lost values can be as great as the value of the CACHE option times the number of instances shutting down. Cached sequence numbers can be lost even when an instance shuts down normally.
The initialization parameter SEQUENCE_CACHE_ENTRIES determines the number of sequences that can be cached in the SGA for a given instance. For highest concurrency, set SEQUENCE_CACHE_ENTRIES to the highest possible number of cached sequences that an instance uses at one time.
The ORDER option of CREATE SEQUENCE guarantees that sequence numbers are generated in the order of the requests. You can use the ORDER option for timestamp numbers and other sequences that must indicate the request order across multiple processes and instances.
If you do not require sequence numbers to be issued in order, the NOORDER option of CREATE SEQUENCE can significantly reduce overhead in a parallel server environment.
Attention: Oracle Parallel Server does not support the CACHE option with the ORDER option of CREATE SEQUENCE when the database is mounted in parallel mode. Oracle cannot guarantee an order if each instance has some sequence values cached. Therefore, if you should create sequences with both the CACHE and ORDER options, they will be ordered but not cached.
This section describes rollback segments as they relate to Oracle Parallel Server.
Rollback segments contain information required for read consistency and to undo changes made by transactions that roll back or abort. Each instance in a parallel server shares use of the SYSTEM rollback segment and requires at least one dedicated rollback segment.
Both private and public rollback segments are acquired at instance startup and used exclusively by the acquiring instance until taken offline or at the acquiring instance shutdown. Private rollback segments are unique to a particular instance and cannot be used by any other instance. A public rollback segment is offline and not used by any instance until an instance that needs an extra rollback segment starts up, acquires it, and brings it online; once online, a public rollback is used exclusively by the acquiring instance.
Only one instance writes to a given rollback segment (except for the SYSTEM rollback segment), but other instances can read from it to create read-consistent snapshots or to perform instance recovery.
A parallel server needs at least as many rollback segments as the maximum number of concurrent instances plus one (SYSTEM). An instance cannot start unless it has exclusive access to at least one rollback segment, whether it is public or private.
You can create new rollback segments in any tablespace. To reduce contention between rollback data and table data, you can partition your rollback segments in a separate tablespace. This also facilitates taking tablespaces offline, because a tablespace cannot be taken offline if it contains an active rollback segment.
In general, you should make all extents for rollback segments the same size by specifying identical values for the storage parameters INITIAL and NEXT.
The data dictionary view DBA_ROLLBACK_SEGS shows each rollback segment's name, segment ID number, and owner (PUBLIC or other).
See Also: "Creating Additional Rollback Segments" on page 14-5 for information about the rollback segments that are required when you create a database.
Oracle8 Administrator's Guide for information about contention for a rollback segment and the performance implications of adding rollback segments.
The following initialization parameters control the use of rollback segments:
There are no performance differences between public and private rollback segments. However, private rollback segments provide more control over the matching of instances with rollback segments, allowing you to locate the rollback segments for different instances on different disks to improve performance. You can therefore use private rollback segments to reduce disk contention in a high-performance system.
Public rollback segments form a pool of rollback segments that can be acquired by any instance needing an additional rollback segment. Using public rollback segments can be disadvantageous when instances are shutdown and started up at the same time. For example, instance X shuts down and releases public rollback segments. Instance Y starts up and acquires the released rollback segments. Instance X starts up and cannot acquire its original rollback segments.
By default a rollback segment is private and is used by the instance specifying it in the parameter file. Private rollback segments are specified using the parameter ROLLBACK_SEGMENTS.
Once a public rollback segment is acquired by an instance, it is then used exclusively by that instance.
Once created, both public and private rollback segments can be brought online using the ALTER ROLLBACK SEGMENT command.
Note: An instance needs at least one rollback segment or it will not be able to start up.
When an instance starts up, it uses the TRANSACTIONS and TRANSACTIONS_PER_ROLLBACK initialization parameters to determine how many rollback segments to acquire, as follows:
The total_rollback_segments_required number is rounded up.
At startup, an instance attempts to acquire rollback segments as follows.
