| Oracle7 Parallel Server Concepts and Administrator's Guide |  Library |
 Product |
 Contents |
 Index |
| Oracle7 Parallel Server Concepts and Administrator's Guide | Library |
Product |
Contents |
Index |
See Also: Oracle7 Server Concepts
"Parameters Which Must Be Identical on Multiple Instances" ![[*]](jump.gif)
.
"Using a Common Parameter File for Multiple Instances" .
"Initialization Parameters" .
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.
See Also: "Using Free List Groups to Partition Data" .
"Access to Datafiles for Instance Failure" .
"Setting GC_FILES_TO_LOCKS" .
"Setting GC_DB_LOCKS" .
Online redo log files can be multiplexed (or "mirrored") as shown in Figure 6 - 1 . 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.
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 option can be extremely useful for sites with very demanding availability requirements. This option provides the history of the session, which can assist you in administration of recovery. It is especially useful 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.
See Also: "Threads of Redo" .
"Archiving the Redo Log Files" .
"Recovery Structures" in Oracle7 Server Concepts for a full description of multiplexed redo log files.
Distributed locks coordinate the data dictionary activity of multiple instances.
A parallel server allows users on multiple instances to generate unique sequence numbers with minimal cooperation or contention among instances. Distributed 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: Oracle7 Server SQL Reference.
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.
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.
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" for information about the rollback segments that are required when you create a database.
Oracle7 Server Administrator's Guide for information about contention for a rollback segment and the performance implications of adding rollback segments.
."Data Blocks, Extents, and Segments" in Oracle7 Server Concepts.
"Initialization Parameters" .
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.
Note: An instance needs at least one rollback segment or it will not be able to start up.
Once created, both public and private rollback segments can be brought online using the ALTER ROLLBACK SEGMENT command.
This total_rollback_segments_required number is rounded up.
At startup, an instance attempts to acquire rollback segments as follows.
See Also: "Monitoring Rollback Segments" .
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.
Figure 6 - 1 shows the threads of redo for three instances of a parallel server:
The V$LOGFILE view displays the group number associated with each redo log file.
Figure 6 - 1. Threads of Redo
See Also: "Recovery Structures" in Oracle7 Server Concepts.
"Redo Log Files" for general information about redo log files.
"Checkpoints and Log Switches" .
"Recovery from Media Failure" .
|
Prev Next |
 Copyright © 1996 Oracle Corporation. All Rights Reserved. |
Library |
Product |
Contents |
Index |