| Oracle7 Parallel Server Concepts and Administrator's Guide |  Library |
 Product |
 Contents |
 Index |
| Oracle7 Parallel Server Concepts and Administrator's Guide | Library |
Product |
Contents |
Index |
To Create A Database for Parallel Server
See Also: "Creating a Database" in Oracle7 Server Administrator's Guide.
Attention: The CREATE DATABASE statement mounts and opens the newly created database, leaving the instance in exclusive mode. You must close and dismount the database, then remount it in shared mode.
Creating a Database in Exclusive Mode, Starting Up in Shared Mode
SVRMGR> SHUTDOWN
SVRMGR> STARTUP [ OPEN databasename ] SHARED
See Also: "Starting Up Instances" ![[*]](jump.gif)
.
See Also: "Parameters Which Must Be Identical on Multiple Instances" .
For a parallel server, you should set MAXINSTANCES to a value greater than the maximum number of instances you expect to run concurrently. In this way, if instance A fails and is being recovered by instance B, you will be able to start instance C before instance A is fully recovered.
For a parallel server, you should set MAXLOGFILES to the maximum number of threads possible, times the maximum anticipated number of groups per thread.
For a parallel server, you should set MAXLOGHISTORY to a large value, such as 1000. The control files can then only store information about this number of redo log files. When the log history exceeds this limit, the old history entries are overwritten in a circular fashion. The default for MAXLOGHISTORY is zero, which disables the log history.
See Also: Oracle7 Server SQL Reference for complete descriptions of the SQL statements CREATE DATABASE and ALTER DATABASE.
See your Oracle operating system-specific documentation for information on default values of CREATE DATABASE options.
"Threads of Redo" for more information about redo log groups and members.
"Redo Log History in the Control File" for more information on MAXLOGHISTORY.
Alternatively, you can reduce overhead by creating the database in NOARCHIVELOG mode (the default). Then change the mode to ARCHIVELOG with the ALTER DATABASE statement.
You cannot use the STARTUP command to change the database archiving mode. After creating a database, you can use the following Server Manager commands to change archiving mode and reopen the database in shared mode:
ALTER DATABASE CLOSE;
ALTER DATABASE ARCHIVELOG;
SHUTDOWN;
STARTUP PARALLEL;
See Also: "Archiving the Redo Log Files" .
You must create and bring online one additional rollback segment in the SYSTEM tablespace before you can create rollback segments in any other tablespace. The instance that creates the database can create this additional rollback segment and new tablespaces, but it cannot create database objects in non-SYSTEM tablespaces until you bring the additional rollback segment online in the SYSTEM tablespace. After the first additional rollback segment, you can create other rollback segments in any tablespace.
To create a public rollback segment, use the SQL statement CREATE PUBLIC ROLLBACK SEGMENT.
Typically, the parameter file for any particular instance does not specify public rollback segments because they are assumed to be available to any instance needing them. However, if another instance is not already using it, you can name a public rollback segment as a value of the ROLLBACK_SEGMENTS parameter.
Public rollback segments are identified in the data dictionary view DBA_ROLLBACK_SEGS as having the owner PUBLIC.
If the parameter file omits the ROLLBACK_SEGMENTS initialization parameter, the instance uses public rollback segments by default.
A public rollback segment is brought online when an instance that requires public rollback segments starts up and acquires it. However, starting an instance that uses public rollback segments does not ensure that any particular public rollback segment comes online, unless the instance acquires all of the available public rollback segments. Once acquired, a public rollback segment is used exclusively by the acquiring instance.
Bringing online, taking offline, creating, and dropping rollback segments, whether private or public, is the same in exclusive or shared mode.
Private rollback segments stay offline until brought online or the owning instance restarts. A public rollback segment stays offline until brought online for a specific instance or until an instance that requires a public rollback segment starts up and acquires it.
If you need to keep a public rollback segment offline and do not want to drop it and re-create it, you must ensure no instance starts up that requires public rollback segments.
Alternatively, you can query the dynamic performance views V$ROLLNAME and V$ROLLSTAT for information about the current instance's rollback segments.
Use the Server Manager command CONNECT @instance-path to change the current instance before using the MONITOR command or querying the V$ views. You must have SQL*Net installed to use the CONNECT command for an instance on a remote node.
You can also query the data dictionary views DBA_ROLLBACK_SEGS and DBA_SEGMENTS for information about the current status of all rollback segments in your database.
For example, to list all the current rollback segments, you can query DBA_ROLLBACK_SEGS with the following statement:
SELECT segment_name, segment_id, owner, status
FROM dba_rollback_segs This query displays the rollback segment's name, ID number, owner, and whether it is in use, as shown in the following example:
SEGMENT_NAME SEGMENT_ID OWNER STATUS ------------------------ ---------- ------ ------------ SYSTEM 0 SYS ONLINE PUBLIC_RS 1 PUBLIC ONLINE USERS1_RS 2 SYS ONLINE USERS2_RS 3 SYS OFFLINE USERS3_RS 4 SYS ONLINE USERS4_RS 5 SYS ONLINE PUBLIC2_RS 6 PUBLIC OFFLINE
In the above example, rollback segments identified as owned by user SYS are private rollback segments; the rollback segments identified as owned by user PUBLIC are public rollback segments. The view DBA_ROLLBACK_SEGS also includes information (not shown) about the tablespace containing the rollback segment, the datafile containing the segment header, and the extent sizes. The view DBA_SEGMENTS includes additional information about the number of extents in each rollback segment and the segment size.
See Also: Oracle7 Server Administrator's Guide for more information about rollback segments, and about connecting to a database.
Oracle Network Manager Administrator's Guide and your Oracle system-specific documentation for the format of the connect string in instance-path.
Oracle Server Manager User's Guide for information about the command MONITOR ROLLBACK.
"Data Dictionary Reference" chapter of Oracle7 Server Reference for a description of DBA_ROLLBACK_SEGS and DBA_SEGMENTS, and other dynamic performance views.
You must create each thread with at least two redo log files (or multiplexed groups), and you must enable the thread before an instance can use it.
The CREATE DATABASE statement creates thread number 1 as a public thread and enables it automatically. You must use the ALTER DATABASE statement to create and enable subsequent threads.
Each thread must be created with at least two redo log files, or multiplexed groups, and the thread must then be enabled before an instance can use it.
The CREATE DATABASE statement creates thread number 1 as a public thread and enables it automatically. Subsequent threads must be created and enabled with the ALTER DATABASE statement. For example, the following statements create thread 2 with two groups of three members each, as shown in Figure 6 - 1 :
ALTER DATABASE ADD LOGFILE THREAD 2
GROUP 4 (disk1_file4, disk2_file4, disk3_file4) SIZE 1M REUSE
GROUP 5 (disk1_file5, disk2_file5, disk3_file5) SIZE 1M REUSE;
ALTER DATABASE ENABLE PUBLIC THREAD 2;
If you omit the keyword PUBLIC when you enable the thread, it will be a private thread that cannot be acquired by default. Only one thread number may be specified in the ALTER DATABASE ADD LOGFILE statement, and the THREAD clause must be specified if the thread number of the current instance was chosen by default.
Whenever you disable a thread, Oracle marks its current redo log file as needing to be archived. If you want to drop that file, you might need to first archive it manually.
An error or failure while a thread is being enabled can result in a thread that has a current set of log files but is not enabled. These log files cannot be dropped or archived. In this case, you should disable the thread, even though it is already disabled, then enable it.
The redo log mode is associated with the database rather than with individual instances. For most purposes, all instances should use the same archiving method (automatic or manual) if the redo log is being used in ARCHIVELOG mode.
Any instance can add or rename redo log files (or members) of any group for any other instance. As long as there are more than two groups for an instance, a redo log group can be dropped from that instance by any other instance. Changes to redo log files and log members take effect on the next log switch.
See Also: "Archiving the Redo Log Files" .
Added datafiles use the unassigned locks which were created when values for GC_FILES_TO_LOCKS and GC_DB_LOCKS were set. If the remaining locks are not adequate to protect the new files and avoid contention, then you must provide more locks by adjusting these two GC parameters. Performance problems are likely if you neglect to make these adjustments.
Note that in a read-only database extra locks would not be necessary even if you added many new datafiles. In a database heavily used for inserts, however, you might very well need to provide for more locks.
To Provide Locks for Added Datafiles
|
Prev Next |
 Copyright © 1996 Oracle Corporation. All Rights Reserved. |
Library |
Product |
Contents |
Index |