Hardware sizing for Oracle EBS
Sizing hardware is always a challenge. The issue here is that production sized hardware usually needs to be procured even before the project has started. This is usually the case with organizations where Oracle and Oracle EBS is being installed for the first time. There is no prior version of the application, to benchmark against.
Most of the hardware vendors provide sizing spreadsheets that can be filled out, and a rough estimate of the computing power needed can be reached. This exercise usually helps in clarifying the SAN and disaster recovery architecture, but does not get to the specifics of the production hardware.
Each organization has unique access patterns and transaction patterns, and hence it is genuinely difficult to extrapolate hardware sizing between different organizations. The best approach is to procure the production database server (since this can usually be sized with a fair degree of accuracy) or the post-production development server. These can be used to start the implementation process, and once a certain level of organization specific configuration has bene completed, then production benchmarking can be accomplished.
There is some assistance available in the for of white papers and benchmarking for typical transaction loads. This link has a list of white papers on sizing for IBM, HP and Sun machines. This link provides detailed performance information for representative transaction loads.
When it comes to estimating the network bandwidth requirements the information is very scattered. There are no bench marks and thumb rules need to be applied. A usual CRM/imodule would have the same bandwidth requirements as a normal internet user. HOwever, power users, especially in the demand planning and forecasting space will require a higher bandwidth
Thursday, May 26, 2011
Tuesday, May 24, 2011
Oracle10g / 11g - Getting Started with Recovery Manager (RMAN)
Oracle10g / 11g - Getting Started with Recovery Manager (RMAN) [ID 360416.1]
Modified 08-FEB-2011 Type BULLETIN Status PUBLISHED
In this Document
Purpose
Scope and Application
Oracle10g / 11g - Getting Started with Recovery Manager (RMAN)
Overview of the RMAN Environment
Deciding Whether to Use a Flash Recovery Area (FRA)
Deciding Whether to use a Recovery Catalog
Starting and Exiting RMAN
Configuring Persistent Settings for the RMAN Environment
Backing up the Controlfile and Spfile
Backing up Database Files
Backing Up Archived Redo Logs
Restoring and Recovering Database Files
Reporting on RMAN Operations
Managing the RMAN Repository
Crosschecking and Deleting Backups
References
Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.2.0.0 - Release: 10.1 to 11.2
Information in this document applies to any platform.
Checked for relevance on 05-August-2009
Purpose
Note : In Oracle 11G are new features available, but the Oracle10G procedure is still valid for 11G.
See for more details on the 11g New Features : Note 809867.1 RMAN 11gR1 : New Features
To introduce the basic concepts of Oracle10g and 11g Recovery Manager (RMAN), the tool that Oracle recommends that you use for your backup and recovery. Because of the enormous flexibility of RMAN, all details cannot be covered here. The information within this article is a general overview of items to consider and of which to be aware. It is recommended that more details are reviewed in the following documentation:
Oracle Database Backup and Recovery Reference
Oracle Database Backup and Recovery Quick Start Guide
Oracle Database Backup and Recovery Basics
Oracle Database Backup and Recovery Advanced User's Guide
Scope and Application
Article is intended for DBAs familiar with backup and recovery concepts who are interested in implementing server managed backup and recovery with RMAN.
RMAN backup and recovery can be performed via Enterprise Manager. This tool is not discussed in this article.
Oracle10g / 11g - Getting Started with Recovery Manager (RMAN)
Overview of the RMAN Environment
Installed with the database, Recovery Manager (RMAN) is an Oracle database client which performs backup and recovery tasks on your databases and automates administration of your backup strategies. It greatly simplifies backing up, restoring, and recovering the database.
The RMAN environment consists of the utilities and databases that play a role in backing up your data. At a minimum, the environment for RMAN must include the following:
The target database. This is the database to be backed up by RMAN.
The RMAN client is a command-line-oriented database client, much like SQL*Plus, with its own command syntax. From the RMAN client you can issue RMAN commands and some SQL statements to perform and report on backup and recovery operations.
Some environments will also use these optional components:
A flash recovery area: a disk location in which the database can store and manage files related to backup and recovery.
Media management software: software provided by media manager vendors which is required for RMAN to interface with backup devices such as tape drives.
A recovery catalog database: a separate database schema used to record RMAN activity against one or more target databases.
Deciding Whether to Use a Flash Recovery Area (FRA)
It is recommended that you take advantage of the FRA to store as many backup and recovery-related files as as possible, including disk backups and archived redo logs.
Some features of Oracle database backup and recovery, such as Oracle Flashback Database and guaranteed restore points, require the use of an FRA. However, having an FRA for use by these features does not force you to use it to store all recovery-related files.
Even when its use is not required, however, the FRA offers a number of advantages over other on-disk backup storage methods. Backups moved to tape from the flash recovery area (via RMAN and media manager) are retained on disk until space is needed for other required files, reducing the need to restore backups from tape. At the same time, obsolete files no longer needed to meet your recoverability goals and files backed up to tape become eligible for deletion and are deleted when space is needed. These deletions are managed by Oracle when space is required. The DBA no longer has to manually delete old backups, and, it is less likely that a DBA accidentally deletes redundancy set files. Note that if backups written to the FRA are not copied via RMAN and media manager to tape, the automatic deletion of obsolete backups does not occur and pre-Oracle10g cleanup methods are required.
Knowledgebase Article Reference:
Note:305817.1 FAQ - Flash Recovery Area feature of 10G
Deciding Whether to use a Recovery Catalog
RMAN maintains metadata about the target database and its backup and recovery operations in the RMAN repository. Among other things, RMAN stores information about its own configuration settings, the target database schema, archived redo logs, and all backup files on disk or tape. RMAN's LIST, REPORT, and SHOW commands display RMAN repository information.
The primary store for RMAN repository data is always the control file of the target database. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter controls how long backup records are kept in the control file before those records are re-used to hold information about more recent backups.
Another copy of the RMAN repository data can also be saved in the recovery catalog.
Using a recovery catalog preserves RMAN repository information if the control file is lost, making it much easier to restore and recover following the loss of the control file. (A backup control file may not contain complete information about recent available backups.) The recovery catalog can also store a much more extensive history of your backups than the control file, due to limits on the number of control file records.
In addition to RMAN repository records, the recovery catalog can also hold RMAN stored scripts, sequences of RMAN commands for common backup tasks. Centralized storage of scripts in recovery catalog can be more convenient than working with command files.
Except for stored scripts, all of RMAN's features work equally well with or without a recovery catalog.
Oracle10g Documentation References:
Oracle Database Backup and Recovery Advanced User's Guide Guide - more information about the recovery catalog
Oracle Database Backup and Recovery Reference - CREATE CATALOG command syntax
Starting and Exiting RMAN
The RMAN client is started by issuing the rman command at the command prompt of your operating system.
RMAN must connect to a target database (with SYSDBA privileges) to perform backup and recovery tasks. RMAN can also connect to a recovery catalog database if you are using one. Specify target and recovery catalog databases using command line options or using the CONNECT command.
This command illustrates connecting RMAN to a target database and a recovery catalog at startup:
% rman TARGET / CATALOG cat_usr/pwd@cat_str
Connect to a target database without using a recovery catalog:
% rman TARGET SYS/pwd@target_str
Starting RMAN without connecting to a database:
% rman
Once started, RMAN displays an "RMAN>" prompt for your commands.
Configuring Persistent Settings for the RMAN Environment
You can use the RMAN CONFIGURE command to create persistent settings in the RMAN environment, which apply to all subsequent operations, even if you exit and restart RMAN. These configured settings can specify disk and SBT channel behavior, backup destinations, policies affecting backup strategy, and others.
This command shows all configurable settings:
RMAN> SHOW ALL;
Knowledgebase Article:
Note 305565.1 Persistent Controlfile Configurations for RMAN in 9i and 10g
Oracle10g Documentation Reference
Oracle Database Backup and Recovery Basics - more information about configuration settings.
Backing up the Controlfile and Spfile
The control file can be automatically backed up after each RMAN backup and database structure change as a way to protect the RMAN repository. If an spfile is being used, it is also backed up. When using RMAN without a recovery catalog, it is recommended that the controlfile autobackup be set to ON. The following command configures RMAN to create these control file autobackups:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
By default, RMAN automatically generates names for control file autobackups and stores them in the FRA if defined. The following command configures RMAN to write control file autobackups to the /mybackupdir directory:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO '/mybackupdir/cf%F';
The %F element of the format string combines the DBID, day, month, year, and sequence number to generate a unique filename. %F must be included in any control file autobackup format.
You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version. If CONFIGURE CONTROLFILE AUTOBACKUP is ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The controlfile autobackup contains metadata about the previous backup, which is crucial for disaster recovery. Configuring controlfile autobackup on is recommended and is the only way RMAN can restore a controlfile backup if all controlfiles are lost and there is no recovery catalog in use.
If the autobackup feature is not set, then you must manually back up the control file in one of the following ways:
Run BACKUP CURRENT CONTROLFILE
Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command
Back up datafile 1, because RMAN automatically includes the control file and SPFILE in backups of datafile 1 when the controlfile autobackup is set to OFF.
A manual backup of the control file is not the same as a control file autobackup. In manual backups, only RMAN repository data for backups within the current RMAN session is in the control file backup, and a manually backed-up control file cannot be automatically restored.
Oracle10g Documentation Reference:
Oracle Database Backup and Recovery Advanced User's Guide - more information about control file autobackups
Backing up Database Files
Use the RMAN BACKUP command to back up files. You can configure default devices and channels in advance. The BACKUP command backs up your data to the configured default device and channels for the type of backup requested.
If you specify BACKUP AS COPY, then RMAN copies the files as image copies, bit-for-bit copies of database files created on disk. These are identical to copies of the same files that you can create with operating system commands like cp on Unix or COPY on Windows. However, using BACKUP AS COPY will be recorded in the RMAN repository and RMAN can use them in restore operations. Image copies cannot be created on tape.
This command creates image copy backups of all datafiles in the database:
RMAN> BACKUP AS COPY DATABASE;
If you specify BACKUP AS BACKUPSET, then RMAN stores its backups in backup sets. A backup set, consisting of one or more backup pieces, contains the physical file data being backed up. This backupset is written in a format that only RMAN can access. Only RMAN can create and restore backup sets. Backup sets can be written to disk or tape, and they are the only type of backup which RMAN can use to write backups to tape.
The following command creates a backup of the database and archived logs on tape, in backup set format, using the configured channels:
RMAN> BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
Note:
Backing up datafiles as backup sets on disk can save disk space and time because RMAN will skip backing up some unused datafile blocks. Backup sets, once written on disk, can be moved to tape with the BACKUP BACKUPSET command. See the description of unused block compression in Oracle Database Backup and Recovery Reference for details.
Backing Up Individual Files
You can back up individual tablespaces, datafiles and control files, server parameter files, and backup sets with various options, as in these examples:
RMAN> BACKUP ARCHIVELOG from time 'sysdate-2';
RMAN> BACKUP TABLESPACE system, users, tools;
RMAN> BACKUP AS BACKUPSET DATAFILE
'ORACLE_HOME/oradata/trgt/users01.dbf',
'ORACLE_HOME/oradata/trg/tools01.dbf';
RMAN> BACKUP DATAFILE 1,3,5;
RMAN> BACKUP CURRENT CONTROLFILE TO '/backup/curr_cf.copy';
RMAN> BACKUP SPFILE;
RMAN> BACKUP BACKUPSET ALL;
Backup Options
Here are some often-used BACKUP command options:
Parameter Example Explanation
FORMAT FORMAT'/tmp/%U' Specifies a location and name for backup pieces and copies. You must use substitution variables to generate unique filenames.
Parameter Example Explanation
TAG TAG 'monday_bak' Specifies a user-defined string as a label for the backup. If you do not specify a tag, then RMAN assigns a default tag with the date and time.
The following BACKUP commands illustrate these options:
RMAN> BACKUP FORMAT='AL_%d/%t/%s/%p' ARCHIVELOG LIKE '%arc_dest%';
RMAN> BACKUP TAG 'weekly_full_db_bkup' DATABASE MAXSETSIZE 10M;
RMAN> BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;
Incremental Backups :
If you specify BACKUP INCREMENTAL, RMAN will create incremental backups of your database. Incremental backups capture on a block-by-block basis changes in your database since a previous incremental backup. The starting point for an incremental backup strategy is a level 0 incremental backup, which backs up all blocks in the database. Level 1 incremental backups, taken at regular intervals, contain only changed blocks since a previous incremental backup. These can be cumulative (including all blocks changed since the most recent level 0 backup) or differential (including only blocks changed since the most recent incremental backup, whether it is level 0 or level 1).
Incremental backups are generally smaller and faster to create than full database backups. Recovery from an incremental backup is faster than recovery using redo logs alone. During a restore from incremental backup, the level 0 backup is used as the starting point, then changed blocks are updated based on level 1 backups where possible to avoid re-applying changes from redo one at a time. Recovering with incremental backups requires no additional effort on your part. If incremental backups are available, RMAN will use them during recovery.
Enterprise Edition includes RMAN's change tracking feature for incremental backups which improves incremental backup performance by recording changed blocks in each datafile in a change tracking file. If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan every block in the datafile.
Knowledgebase Article Reference:
Note 262853.1 10G RMAN Fast Incremental Backups
Incrementally Updated Backups:
RMAN's incrementally updated backups feature allows for a more efficient incremental backup routine. Changes from level 1 backups can be used to roll forward an image copy level 0 incremental backup, so that it includes all changes as of the SCN at which the level 1 incremental backup was created. Recovery using the updated level 0 incremental backup is faster, because all changes from the level 1 incremental backup have already been applied.
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics - more details and examples for incremental backups and incrementally updated backups.
Oracle Database Backup and Recovery Reference - complete BACKUP command syntax.
Backing Up Archived Redo Logs
Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs with BACKUP ARCHIVELOG, or back up logs while backing up datafiles and control files by specifying BACKUP ... PLUS ARCHIVELOG.
To back up archived redo logs, use the BACKUP ARCHIVELOG command at the RMAN prompt. This example uses a configured disk or sbt channel to back up one copy of each log sequence number for all archived redo logs:
RMAN> BACKUP ARCHIVELOG ALL;
Even if your redo logs are being archived to multiple destinations and you use RMAN to back up archived redo logs, RMAN selects only one copy of the archived redo log file to include in the backup set. (Since logs with the same log sequence number are identical, there is no need to include more than one copy.)
You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example:
RMAN> BACKUP ARCHIVELOG
FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7';
You can specify the DELETE INPUT or DELETE ALL INPUT clauses for the BACKUP ARCHIVELOG command to delete archived logs after they are backed up, eliminating the separate step of manually deleting the archived redo logs. With DELETE INPUT, RMAN only deletes the specific copy of the archived redo log chosen for the backup set. With DELETE ALL INPUT, RMAN will delete each backed-up archived redo log file from all log archiving destinations.
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics - more details regarding archived log backups
Oracle Database Backup and Recovery Reference - complete BACKUP and archivelogRecordSpecifier command syntax
Restoring and Recovering Database Files
Use the RESTORE and RECOVER commands for RMAN restore and recovery of physical database files. Restoring datafiles is retrieving them from backups as needed for a recovery operation. Recovery is the application of changes from redo logs and incremental backups to a restored datafile, to bring the datafile to a desired SCN (point in time) or to current time.
Recovering the Whole Database :
Use the RESTORE DATABASE and RECOVER DATABASE commands on the whole database. For example:
RMAN> STARTUP FORCE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;
Note that the database must not be open when restoring or recovering the entire database.
Recovering Current Tablespaces :
Use the RESTORE TABLESPACE and RECOVER TABLESPACE commands on individual tablespaces when the database is open. Take the tablespace that needs recovery offline, restore and then recover the tablespace, and bring the recovered tablespace online. The following steps recover the users tablespace:
RMAN> SQL 'ALTER TABLESPACE users OFFLINE';
RESTORE TABLESPACE users;
RECOVER TABLESPACE users;
SQL 'ALTER TABLESPACE users ONLINE;
Recovering Current Datafiles :
Use the RESTORE DATAFILE and RECOVER DATAFILE commands on individual current datafiles when the database open. Take the datafile that needs recovery offline, restored recover the datafile, and bring the datafile online. For example, to restore and recover datafile 7:
RMAN> SQL 'ALTER DATABASE DATAFILE 7 OFFLINE';
RESTORE DATAFILE 7;
RECOVER DATAFILE 7;
SQL 'ALTER DATABASE DATAFILE 7 ONLINE';
Recovering Individual Data Blocks :
RMAN can recover individual corrupted datafile blocks. When RMAN performs a complete scan of a file for a backup, any corrupted blocks are listed in V$DATABASE_BLOCK_CORRUPTION. Corruption is usually reported in alert logs, trace files or results of SQL queries. Use BLOCKRECOVER to repair all corrupted blocks:
RMAN> BLOCKRECOVER CORRUPTION LIST;
You can also recover individual blocks, as shown in this example:
RMAN> BLOCKRECOVER DATAFILE 7 BLOCK 233, 235 DATAFILE 4 BLOCK 101;
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics - more details regarding restore and recovery operations
Oracle Database Backup and Recovery Reference - complete RESTORE;and RECOVER command syntax
NOTE: Only an entire database can be recovered to a point in time, there is a separate procedure for recovering a tablespace to a point in time.
Oracle Database Backup and Recovery Advanced User's Guide - information on RMAN Tablespace Point-in-Time Recovery (TSPITR)
Reporting on RMAN Operations
The RMAN LIST and REPORT commands, generate reports on backup activities based on the RMAN repository. Use SHOW ALL to display the current RMAN configuration.
Listing Backups
Use LIST to display information about backup sets, proxy copies, and image copies recorded in the repository. The LIST command displays the files against which you can run CROSSCHECK and DELETE commands. Use this command to list:
Backups and copies that do not have the status AVAILABLE in the RMAN repository
Backups and copies of datafiles that are available and can possibly be used in a restore operation
Specified archived logs, backup sets, backup pieces, control file copies, datafile copies, and proxy copies
Backups and copies restricted by tag, completion time, recoverability, or device
Incarnations of a specified database or of all databases known to the repository
Stored scripts in the recovery catalog
Reporting on Database Files and Backups
The REPORT command performs more complex analysis than LIST. Use the REPORT command to answer questions such as the following:
Which files need a backup?
Which files have not had a backup for some time?
Which files are not recoverable due to unrecoverable operations?
Which backup files can be deleted?
What was the physical schema of the database at a previous time
Oracle10g Documentation References:
See Oracle Database Backup and Recovery Basics - learn how to make lists and reports
See Oracle Database Backup and Recovery Reference - complete LIST and REPORT command syntax
Managing the RMAN Repository
RMAN repository metadata is always recorded in the control file of the target database. You can also create a recovery catalog in a separate database, and RMAN will record its metadata there as well.
Monitoring Control File Records :
If you do not use a recovery catalog, then eventually RMAN control file records are overwritten. Set this initialization parameter in the parameter file of the target database to determine how long records are kept:
CONTROL_FILE_RECORD_KEEP_TIME =
You can configure a retention policy to be used by RMAN to determine which backups are considered obsolete. This allows you to remove files from the repository that are no longer needed to meet your retention requirements. This policy can be based on a recovery window (the maximum number of days into the past for which you can recover) or redundancy (how many copies of each backed-up file to keep).
The RECOVERY WINDOW parameter of the CONFIGURE command specifies the number of days between the current time and the earliest point of recoverability. RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RMAN retains all archived logs and level 1 incremental backups that are needed to recover to a random point within the window.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt. This example ensures that you can recover the database to any point within the last week:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS
The REDUNDANCY parameter of the CONFIGURE RETENTION POLICY command specifies how many backups of each datafile and control file that RMAN should keep. In other words, if the number of backups for a specific datafile or control file exceeds the REDUNDANCY setting considers the extra backups as obsolete. The default retention policy is REDUNDANCY=1.
As you produce more backups, RMAN keeps track of which ones to retain and which are obsolete. RMAN retains all arcd logs and incremental backups that are needed to recover the nonobsolete backups.
Assume that you make a backup of datafile 7 on Monday, Tuesday, Wednesday, and Thursday. You now have four backups of the datafile. If REDUNDANCY is 2, then the Monday and Tuesday backups are obsolete. If you make another backup on Friday, then the Wednesday backup becomes obsolete.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt, as in the following example:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
RMAN does not automatically delete backups rendered obsolete by the retention policy. Instead, RMAN shows them as OBSOLETE in the REPORT OBSOLETE output and in the OBSOLETE column of V$BACKUP_FILES. RMAN deletes obsolete files if you run the DELETE OBSOLETE command.
Note, backups in the flash recovery area are susceptible to deletion based on RMAN retention policy configuration.
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics- more information regarding retention policies and deleting obsolete files
Crosschecking and Deleting Backups
Crosscheck is needed when an archivelog file or backup is manually removed, i.e., not deleted by RMAN. This command ensures that data about backups in the recovery catalog or control file is synchronized with corresponding data on disk or in the media management catalog. The CROSSCHECK command operates only on files that are recorded in the recovery catalog or the control file.
The CROSSCHECK command does not delete any files that it is unable to find, but updates their repository records to EXPIRED. Then, you can run DELETE EXPIRED to remove the repository records for all expired files as well as any existing physical files whose records show the status EXPIRED.
If some backup pieces or copies were erroneously marked as EXPIRED, for example, because the media manager was misconfigured, then after ensuring that the files really do exist in the media manager, run the CROSSCHECK BACKUP command again to restore those files to AVAILABLE status.
Crosschecking Backups
RMAN> # checks RMAN backups on configured devices
CROSSCHECK BACKUP;
# checks RMAN image copies on configured devices>
CROSSCHECK COPY;
If backups are stored with a media manager and sbt channels are not configured, then you must allocate maintenance channel before CROSSCHECK and DELETE commands on sbt devices:
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP;
The DELETE command removes RMAN backups and copies from DISK and sbt devices, marks theects as DELETED in the control file, and removes the records from the recovery catalog (if you use a catalog). For example:
RMAN> DELETE BACKUPSET 101, 102, 103;
DELETE CONTROLFILECOPY '/tmp/cf.cpy';
DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 7300;
DELETE BACKUP OF SPFILE TABLESPACE users DEVICE TYPE sbt;
DELETE BACKUP OF DATABASE LIKE '/tmp%'; # pattern match
DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics - more information regarding crosschecking and deleting files.
Oracle Database Backup and Recovery Reference - complete DELETE and CROSSCHECK command syntax
Modified 08-FEB-2011 Type BULLETIN Status PUBLISHED
In this Document
Purpose
Scope and Application
Oracle10g / 11g - Getting Started with Recovery Manager (RMAN)
Overview of the RMAN Environment
Deciding Whether to Use a Flash Recovery Area (FRA)
Deciding Whether to use a Recovery Catalog
Starting and Exiting RMAN
Configuring Persistent Settings for the RMAN Environment
Backing up the Controlfile and Spfile
Backing up Database Files
Backing Up Archived Redo Logs
Restoring and Recovering Database Files
Reporting on RMAN Operations
Managing the RMAN Repository
Crosschecking and Deleting Backups
References
Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.2.0.0 - Release: 10.1 to 11.2
Information in this document applies to any platform.
Checked for relevance on 05-August-2009
Purpose
Note : In Oracle 11G are new features available, but the Oracle10G procedure is still valid for 11G.
See for more details on the 11g New Features : Note 809867.1 RMAN 11gR1 : New Features
To introduce the basic concepts of Oracle10g and 11g Recovery Manager (RMAN), the tool that Oracle recommends that you use for your backup and recovery. Because of the enormous flexibility of RMAN, all details cannot be covered here. The information within this article is a general overview of items to consider and of which to be aware. It is recommended that more details are reviewed in the following documentation:
Oracle Database Backup and Recovery Reference
Oracle Database Backup and Recovery Quick Start Guide
Oracle Database Backup and Recovery Basics
Oracle Database Backup and Recovery Advanced User's Guide
Scope and Application
Article is intended for DBAs familiar with backup and recovery concepts who are interested in implementing server managed backup and recovery with RMAN.
RMAN backup and recovery can be performed via Enterprise Manager. This tool is not discussed in this article.
Oracle10g / 11g - Getting Started with Recovery Manager (RMAN)
Overview of the RMAN Environment
Installed with the database, Recovery Manager (RMAN) is an Oracle database client which performs backup and recovery tasks on your databases and automates administration of your backup strategies. It greatly simplifies backing up, restoring, and recovering the database.
The RMAN environment consists of the utilities and databases that play a role in backing up your data. At a minimum, the environment for RMAN must include the following:
The target database. This is the database to be backed up by RMAN.
The RMAN client is a command-line-oriented database client, much like SQL*Plus, with its own command syntax. From the RMAN client you can issue RMAN commands and some SQL statements to perform and report on backup and recovery operations.
Some environments will also use these optional components:
A flash recovery area: a disk location in which the database can store and manage files related to backup and recovery.
Media management software: software provided by media manager vendors which is required for RMAN to interface with backup devices such as tape drives.
A recovery catalog database: a separate database schema used to record RMAN activity against one or more target databases.
Deciding Whether to Use a Flash Recovery Area (FRA)
It is recommended that you take advantage of the FRA to store as many backup and recovery-related files as as possible, including disk backups and archived redo logs.
Some features of Oracle database backup and recovery, such as Oracle Flashback Database and guaranteed restore points, require the use of an FRA. However, having an FRA for use by these features does not force you to use it to store all recovery-related files.
Even when its use is not required, however, the FRA offers a number of advantages over other on-disk backup storage methods. Backups moved to tape from the flash recovery area (via RMAN and media manager) are retained on disk until space is needed for other required files, reducing the need to restore backups from tape. At the same time, obsolete files no longer needed to meet your recoverability goals and files backed up to tape become eligible for deletion and are deleted when space is needed. These deletions are managed by Oracle when space is required. The DBA no longer has to manually delete old backups, and, it is less likely that a DBA accidentally deletes redundancy set files. Note that if backups written to the FRA are not copied via RMAN and media manager to tape, the automatic deletion of obsolete backups does not occur and pre-Oracle10g cleanup methods are required.
Knowledgebase Article Reference:
Note:305817.1 FAQ - Flash Recovery Area feature of 10G
Deciding Whether to use a Recovery Catalog
RMAN maintains metadata about the target database and its backup and recovery operations in the RMAN repository. Among other things, RMAN stores information about its own configuration settings, the target database schema, archived redo logs, and all backup files on disk or tape. RMAN's LIST, REPORT, and SHOW commands display RMAN repository information.
The primary store for RMAN repository data is always the control file of the target database. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter controls how long backup records are kept in the control file before those records are re-used to hold information about more recent backups.
Another copy of the RMAN repository data can also be saved in the recovery catalog.
Using a recovery catalog preserves RMAN repository information if the control file is lost, making it much easier to restore and recover following the loss of the control file. (A backup control file may not contain complete information about recent available backups.) The recovery catalog can also store a much more extensive history of your backups than the control file, due to limits on the number of control file records.
In addition to RMAN repository records, the recovery catalog can also hold RMAN stored scripts, sequences of RMAN commands for common backup tasks. Centralized storage of scripts in recovery catalog can be more convenient than working with command files.
Except for stored scripts, all of RMAN's features work equally well with or without a recovery catalog.
Oracle10g Documentation References:
Oracle Database Backup and Recovery Advanced User's Guide Guide - more information about the recovery catalog
Oracle Database Backup and Recovery Reference - CREATE CATALOG command syntax
Starting and Exiting RMAN
The RMAN client is started by issuing the rman command at the command prompt of your operating system.
RMAN must connect to a target database (with SYSDBA privileges) to perform backup and recovery tasks. RMAN can also connect to a recovery catalog database if you are using one. Specify target and recovery catalog databases using command line options or using the CONNECT command.
This command illustrates connecting RMAN to a target database and a recovery catalog at startup:
% rman TARGET / CATALOG cat_usr/pwd@cat_str
Connect to a target database without using a recovery catalog:
% rman TARGET SYS/pwd@target_str
Starting RMAN without connecting to a database:
% rman
Once started, RMAN displays an "RMAN>" prompt for your commands.
Configuring Persistent Settings for the RMAN Environment
You can use the RMAN CONFIGURE command to create persistent settings in the RMAN environment, which apply to all subsequent operations, even if you exit and restart RMAN. These configured settings can specify disk and SBT channel behavior, backup destinations, policies affecting backup strategy, and others.
This command shows all configurable settings:
RMAN> SHOW ALL;
Knowledgebase Article:
Note 305565.1 Persistent Controlfile Configurations for RMAN in 9i and 10g
Oracle10g Documentation Reference
Oracle Database Backup and Recovery Basics - more information about configuration settings.
Backing up the Controlfile and Spfile
The control file can be automatically backed up after each RMAN backup and database structure change as a way to protect the RMAN repository. If an spfile is being used, it is also backed up. When using RMAN without a recovery catalog, it is recommended that the controlfile autobackup be set to ON. The following command configures RMAN to create these control file autobackups:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
By default, RMAN automatically generates names for control file autobackups and stores them in the FRA if defined. The following command configures RMAN to write control file autobackups to the /mybackupdir directory:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO '/mybackupdir/cf%F';
The %F element of the format string combines the DBID, day, month, year, and sequence number to generate a unique filename. %F must be included in any control file autobackup format.
You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version. If CONFIGURE CONTROLFILE AUTOBACKUP is ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The controlfile autobackup contains metadata about the previous backup, which is crucial for disaster recovery. Configuring controlfile autobackup on is recommended and is the only way RMAN can restore a controlfile backup if all controlfiles are lost and there is no recovery catalog in use.
If the autobackup feature is not set, then you must manually back up the control file in one of the following ways:
Run BACKUP CURRENT CONTROLFILE
Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command
Back up datafile 1, because RMAN automatically includes the control file and SPFILE in backups of datafile 1 when the controlfile autobackup is set to OFF.
A manual backup of the control file is not the same as a control file autobackup. In manual backups, only RMAN repository data for backups within the current RMAN session is in the control file backup, and a manually backed-up control file cannot be automatically restored.
Oracle10g Documentation Reference:
Oracle Database Backup and Recovery Advanced User's Guide - more information about control file autobackups
Backing up Database Files
Use the RMAN BACKUP command to back up files. You can configure default devices and channels in advance. The BACKUP command backs up your data to the configured default device and channels for the type of backup requested.
If you specify BACKUP AS COPY, then RMAN copies the files as image copies, bit-for-bit copies of database files created on disk. These are identical to copies of the same files that you can create with operating system commands like cp on Unix or COPY on Windows. However, using BACKUP AS COPY will be recorded in the RMAN repository and RMAN can use them in restore operations. Image copies cannot be created on tape.
This command creates image copy backups of all datafiles in the database:
RMAN> BACKUP AS COPY DATABASE;
If you specify BACKUP AS BACKUPSET, then RMAN stores its backups in backup sets. A backup set, consisting of one or more backup pieces, contains the physical file data being backed up. This backupset is written in a format that only RMAN can access. Only RMAN can create and restore backup sets. Backup sets can be written to disk or tape, and they are the only type of backup which RMAN can use to write backups to tape.
The following command creates a backup of the database and archived logs on tape, in backup set format, using the configured channels:
RMAN> BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;
Note:
Backing up datafiles as backup sets on disk can save disk space and time because RMAN will skip backing up some unused datafile blocks. Backup sets, once written on disk, can be moved to tape with the BACKUP BACKUPSET command. See the description of unused block compression in Oracle Database Backup and Recovery Reference for details.
Backing Up Individual Files
You can back up individual tablespaces, datafiles and control files, server parameter files, and backup sets with various options, as in these examples:
RMAN> BACKUP ARCHIVELOG from time 'sysdate-2';
RMAN> BACKUP TABLESPACE system, users, tools;
RMAN> BACKUP AS BACKUPSET DATAFILE
'ORACLE_HOME/oradata/trgt/users01.dbf',
'ORACLE_HOME/oradata/trg/tools01.dbf';
RMAN> BACKUP DATAFILE 1,3,5;
RMAN> BACKUP CURRENT CONTROLFILE TO '/backup/curr_cf.copy';
RMAN> BACKUP SPFILE;
RMAN> BACKUP BACKUPSET ALL;
Backup Options
Here are some often-used BACKUP command options:
Parameter Example Explanation
FORMAT FORMAT'/tmp/%U' Specifies a location and name for backup pieces and copies. You must use substitution variables to generate unique filenames.
Parameter Example Explanation
TAG TAG 'monday_bak' Specifies a user-defined string as a label for the backup. If you do not specify a tag, then RMAN assigns a default tag with the date and time.
The following BACKUP commands illustrate these options:
RMAN> BACKUP FORMAT='AL_%d/%t/%s/%p' ARCHIVELOG LIKE '%arc_dest%';
RMAN> BACKUP TAG 'weekly_full_db_bkup' DATABASE MAXSETSIZE 10M;
RMAN> BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;
Incremental Backups :
If you specify BACKUP INCREMENTAL, RMAN will create incremental backups of your database. Incremental backups capture on a block-by-block basis changes in your database since a previous incremental backup. The starting point for an incremental backup strategy is a level 0 incremental backup, which backs up all blocks in the database. Level 1 incremental backups, taken at regular intervals, contain only changed blocks since a previous incremental backup. These can be cumulative (including all blocks changed since the most recent level 0 backup) or differential (including only blocks changed since the most recent incremental backup, whether it is level 0 or level 1).
Incremental backups are generally smaller and faster to create than full database backups. Recovery from an incremental backup is faster than recovery using redo logs alone. During a restore from incremental backup, the level 0 backup is used as the starting point, then changed blocks are updated based on level 1 backups where possible to avoid re-applying changes from redo one at a time. Recovering with incremental backups requires no additional effort on your part. If incremental backups are available, RMAN will use them during recovery.
Enterprise Edition includes RMAN's change tracking feature for incremental backups which improves incremental backup performance by recording changed blocks in each datafile in a change tracking file. If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan every block in the datafile.
Knowledgebase Article Reference:
Note 262853.1 10G RMAN Fast Incremental Backups
Incrementally Updated Backups:
RMAN's incrementally updated backups feature allows for a more efficient incremental backup routine. Changes from level 1 backups can be used to roll forward an image copy level 0 incremental backup, so that it includes all changes as of the SCN at which the level 1 incremental backup was created. Recovery using the updated level 0 incremental backup is faster, because all changes from the level 1 incremental backup have already been applied.
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics - more details and examples for incremental backups and incrementally updated backups.
Oracle Database Backup and Recovery Reference - complete BACKUP command syntax.
Backing Up Archived Redo Logs
Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs with BACKUP ARCHIVELOG, or back up logs while backing up datafiles and control files by specifying BACKUP ... PLUS ARCHIVELOG.
To back up archived redo logs, use the BACKUP ARCHIVELOG command at the RMAN prompt. This example uses a configured disk or sbt channel to back up one copy of each log sequence number for all archived redo logs:
RMAN> BACKUP ARCHIVELOG ALL;
Even if your redo logs are being archived to multiple destinations and you use RMAN to back up archived redo logs, RMAN selects only one copy of the archived redo log file to include in the backup set. (Since logs with the same log sequence number are identical, there is no need to include more than one copy.)
You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example:
RMAN> BACKUP ARCHIVELOG
FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7';
You can specify the DELETE INPUT or DELETE ALL INPUT clauses for the BACKUP ARCHIVELOG command to delete archived logs after they are backed up, eliminating the separate step of manually deleting the archived redo logs. With DELETE INPUT, RMAN only deletes the specific copy of the archived redo log chosen for the backup set. With DELETE ALL INPUT, RMAN will delete each backed-up archived redo log file from all log archiving destinations.
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics - more details regarding archived log backups
Oracle Database Backup and Recovery Reference - complete BACKUP and archivelogRecordSpecifier command syntax
Restoring and Recovering Database Files
Use the RESTORE and RECOVER commands for RMAN restore and recovery of physical database files. Restoring datafiles is retrieving them from backups as needed for a recovery operation. Recovery is the application of changes from redo logs and incremental backups to a restored datafile, to bring the datafile to a desired SCN (point in time) or to current time.
Recovering the Whole Database :
Use the RESTORE DATABASE and RECOVER DATABASE commands on the whole database. For example:
RMAN> STARTUP FORCE MOUNT;
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN;
Note that the database must not be open when restoring or recovering the entire database.
Recovering Current Tablespaces :
Use the RESTORE TABLESPACE and RECOVER TABLESPACE commands on individual tablespaces when the database is open. Take the tablespace that needs recovery offline, restore and then recover the tablespace, and bring the recovered tablespace online. The following steps recover the users tablespace:
RMAN> SQL 'ALTER TABLESPACE users OFFLINE';
RESTORE TABLESPACE users;
RECOVER TABLESPACE users;
SQL 'ALTER TABLESPACE users ONLINE;
Recovering Current Datafiles :
Use the RESTORE DATAFILE and RECOVER DATAFILE commands on individual current datafiles when the database open. Take the datafile that needs recovery offline, restored recover the datafile, and bring the datafile online. For example, to restore and recover datafile 7:
RMAN> SQL 'ALTER DATABASE DATAFILE 7 OFFLINE';
RESTORE DATAFILE 7;
RECOVER DATAFILE 7;
SQL 'ALTER DATABASE DATAFILE 7 ONLINE';
Recovering Individual Data Blocks :
RMAN can recover individual corrupted datafile blocks. When RMAN performs a complete scan of a file for a backup, any corrupted blocks are listed in V$DATABASE_BLOCK_CORRUPTION. Corruption is usually reported in alert logs, trace files or results of SQL queries. Use BLOCKRECOVER to repair all corrupted blocks:
RMAN> BLOCKRECOVER CORRUPTION LIST;
You can also recover individual blocks, as shown in this example:
RMAN> BLOCKRECOVER DATAFILE 7 BLOCK 233, 235 DATAFILE 4 BLOCK 101;
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics - more details regarding restore and recovery operations
Oracle Database Backup and Recovery Reference - complete RESTORE;and RECOVER command syntax
NOTE: Only an entire database can be recovered to a point in time, there is a separate procedure for recovering a tablespace to a point in time.
Oracle Database Backup and Recovery Advanced User's Guide - information on RMAN Tablespace Point-in-Time Recovery (TSPITR)
Reporting on RMAN Operations
The RMAN LIST and REPORT commands, generate reports on backup activities based on the RMAN repository. Use SHOW ALL to display the current RMAN configuration.
Listing Backups
Use LIST to display information about backup sets, proxy copies, and image copies recorded in the repository. The LIST command displays the files against which you can run CROSSCHECK and DELETE commands. Use this command to list:
Backups and copies that do not have the status AVAILABLE in the RMAN repository
Backups and copies of datafiles that are available and can possibly be used in a restore operation
Specified archived logs, backup sets, backup pieces, control file copies, datafile copies, and proxy copies
Backups and copies restricted by tag, completion time, recoverability, or device
Incarnations of a specified database or of all databases known to the repository
Stored scripts in the recovery catalog
Reporting on Database Files and Backups
The REPORT command performs more complex analysis than LIST. Use the REPORT command to answer questions such as the following:
Which files need a backup?
Which files have not had a backup for some time?
Which files are not recoverable due to unrecoverable operations?
Which backup files can be deleted?
What was the physical schema of the database at a previous time
Oracle10g Documentation References:
See Oracle Database Backup and Recovery Basics - learn how to make lists and reports
See Oracle Database Backup and Recovery Reference - complete LIST and REPORT command syntax
Managing the RMAN Repository
RMAN repository metadata is always recorded in the control file of the target database. You can also create a recovery catalog in a separate database, and RMAN will record its metadata there as well.
Monitoring Control File Records :
If you do not use a recovery catalog, then eventually RMAN control file records are overwritten. Set this initialization parameter in the parameter file of the target database to determine how long records are kept:
CONTROL_FILE_RECORD_KEEP_TIME =
You can configure a retention policy to be used by RMAN to determine which backups are considered obsolete. This allows you to remove files from the repository that are no longer needed to meet your retention requirements. This policy can be based on a recovery window (the maximum number of days into the past for which you can recover) or redundancy (how many copies of each backed-up file to keep).
The RECOVERY WINDOW parameter of the CONFIGURE command specifies the number of days between the current time and the earliest point of recoverability. RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RMAN retains all archived logs and level 1 incremental backups that are needed to recover to a random point within the window.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt. This example ensures that you can recover the database to any point within the last week:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS
The REDUNDANCY parameter of the CONFIGURE RETENTION POLICY command specifies how many backups of each datafile and control file that RMAN should keep. In other words, if the number of backups for a specific datafile or control file exceeds the REDUNDANCY setting considers the extra backups as obsolete. The default retention policy is REDUNDANCY=1.
As you produce more backups, RMAN keeps track of which ones to retain and which are obsolete. RMAN retains all arcd logs and incremental backups that are needed to recover the nonobsolete backups.
Assume that you make a backup of datafile 7 on Monday, Tuesday, Wednesday, and Thursday. You now have four backups of the datafile. If REDUNDANCY is 2, then the Monday and Tuesday backups are obsolete. If you make another backup on Friday, then the Wednesday backup becomes obsolete.
Run the CONFIGURE RETENTION POLICY command at the RMAN prompt, as in the following example:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
RMAN does not automatically delete backups rendered obsolete by the retention policy. Instead, RMAN shows them as OBSOLETE in the REPORT OBSOLETE output and in the OBSOLETE column of V$BACKUP_FILES. RMAN deletes obsolete files if you run the DELETE OBSOLETE command.
Note, backups in the flash recovery area are susceptible to deletion based on RMAN retention policy configuration.
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics- more information regarding retention policies and deleting obsolete files
Crosschecking and Deleting Backups
Crosscheck is needed when an archivelog file or backup is manually removed, i.e., not deleted by RMAN. This command ensures that data about backups in the recovery catalog or control file is synchronized with corresponding data on disk or in the media management catalog. The CROSSCHECK command operates only on files that are recorded in the recovery catalog or the control file.
The CROSSCHECK command does not delete any files that it is unable to find, but updates their repository records to EXPIRED. Then, you can run DELETE EXPIRED to remove the repository records for all expired files as well as any existing physical files whose records show the status EXPIRED.
If some backup pieces or copies were erroneously marked as EXPIRED, for example, because the media manager was misconfigured, then after ensuring that the files really do exist in the media manager, run the CROSSCHECK BACKUP command again to restore those files to AVAILABLE status.
Crosschecking Backups
RMAN> # checks RMAN backups on configured devices
CROSSCHECK BACKUP;
# checks RMAN image copies on configured devices>
CROSSCHECK COPY;
If backups are stored with a media manager and sbt channels are not configured, then you must allocate maintenance channel before CROSSCHECK and DELETE commands on sbt devices:
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
CROSSCHECK BACKUP;
The DELETE command removes RMAN backups and copies from DISK and sbt devices, marks theects as DELETED in the control file, and removes the records from the recovery catalog (if you use a catalog). For example:
RMAN> DELETE BACKUPSET 101, 102, 103;
DELETE CONTROLFILECOPY '/tmp/cf.cpy';
DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 7300;
DELETE BACKUP OF SPFILE TABLESPACE users DEVICE TYPE sbt;
DELETE BACKUP OF DATABASE LIKE '/tmp%'; # pattern match
DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
Oracle10g Documentation References:
Oracle Database Backup and Recovery Basics - more information regarding crosschecking and deleting files.
Oracle Database Backup and Recovery Reference - complete DELETE and CROSSCHECK command syntax
Manually configure the Oracle 10g EM dbconsole
Manually configure the Oracle 10g EM dbconsole
Overview
When you choose to create a preconfigured database during the Oracle 10g installation, you can select the Oracle Enterprise Manager (OEM) interface that you want to use to manage the database. The following options are available:
Database Grid Control
This option is available only if an Oracle Management Agent is installed on the system. When the Installer detects an Oracle Management Agent on the system, it allows you to choose this option and specify the Oracle Management Service that you want to use to manage the database.
If an Oracle Management Agent is not installed, you must choose to use Database Control to manage the database. However, if you install Oracle Management Agent after you install Oracle Database, you can then use Grid Control to manage this database.
Database Control
This option is selected by default if an Oracle Management Agent is not installed on the system. However, even if a Management Agent is installed, you can still choose to configure Database Control to manage the database.
Custom installation
If you choose the Custom installation type or the Advanced database configuration option during the installation, the Installer does not display the OEM setup screens. Instead, it runs the Database Configuration Assistant (DBCA) in interactive mode, which enables you to create a custom database.
DBCA also enables you to specify the Oracle Enterprise Manager interface that you want to use. Furthermore, you can also use DBCA after the installation to configure Database Control for a database that was not previously configured to use it.
However, if you decide to setup your own Database, you must install the Database Control manually.
Setup your own Database and manually install the Database Control
The Database Control relies on various underlying technologies to discover, monitor, and administer the Oracle Database environment.
From the Database Control, you can monitor and administer a single Oracle Database instance.
The Database Control Framework consists of the Database Control and its underlying technologies:
A local version of the Oracle Management Service designed to work with the local database or clustered database.
A local Oracle Management Repository installed in the local database and designed to store management data for the Database Control.
The following steps have to be performed.
Create your own Database
More information to setup your own Database can be found here:
For Windows 2000
For Linux
Create the Database Control Repository and setup the OC4J Application Server
Make sure, that you can connect to the Repository Database (Test it with SQL*Plus). Examples for Setup Files can be found here:
Windows
Linux
LISTENER.ORA listener.ora
SQLNET.ORA sqlnet.ora
TNSNAMES.ORA tnsnames.ora
Now start the Oracle EM dbconsole Build Script ($ORACLE_HOME/bin/emca for Linux and $ORACLE_HOME\Bin\emca.bat for Windows).
$ emca -repos create
$ emca -config dbcontrol db
STARTED EMCA at Fri May 14 10:43:22 MEST 2004
Enter the following information about the database
to be configured.
Listener port number: 1521
Database SID: AKI1
Service name: AKI1.WORLD
Email address for notification: martin dot zahn at akadia dot ch
Email gateway for notification: mailhost
Password for dbsnmp: xxxxxxx
Password for sysman: xxxxxxx
Password for sys: xxxxxxx
---------------------------------------------------------
You have specified the following settings
Database ORACLE_HOME: /opt/oracle/product/10.1.0
Enterprise Manager ORACLE_HOME: /opt/oracle/product/10.1.0
Database host name ..........: akira
Listener port number .........: 1521
Database SID .................: AKI1
Service name .................: AKI1
Email address for notification: martin dot zahn at akadia dot ch
Email gateway for notification: mailhost
---------------------------------------------------------
Do you wish to continue? [yes/no]: yes
AM oracle.sysman.emcp.EMConfig updateReposVars
INFO: Updating file ../config/repository.variables ...
Now wait about 10 Minutes to complete!
M oracle.sysman.emcp.EMConfig createRepository
INFO: Creating repository ...
M oracle.sysman.emcp.EMConfig perform
INFO: Repository was created successfully
M oracle.sysman.emcp.util.PortQuery findUsedPorts
INFO: Searching services file for used port
AM oracle.sysman.emcp.EMConfig getProperties
...........
...........
INFO: Starting the DBConsole ...
AM oracle.sysman.emcp.EMConfig perform
INFO: DBConsole is started successfully
INFO: >>>>>>>>>>> The Enterprise Manager URL is http://akira:5500/em <<<<<<<<<<<
Enterprise Manager configuration is completed successfully
FINISHED EMCA at Fri May 14 10:55:25 MEST 2004
Try to connect to the database Control
http://akira:5500/em
If you look at the installed schemas, you can now find the SYSMAN schema, which is the database Control Repository.
Troubleshooting
If you have troubles to connect, check your local configuration which can be found in $ORACLE_HOME/_. For Example our DbConsole Setup Directory looks as follows:
$ pwd
/opt/oracle/product/10.1.0/akira_AKI1/sysman/config
$ ls -l
-rw-r--r-- b64InternetCertificate.txt
-rw-r--r-- emagentlogging.properties
-rw-r--r-- emd.properties
-rw-r--r-- emomsintg.xml
-rw-r--r-- emomslogging.properties
-rw-r--r-- emoms.properties
-rw-r--r-- OUIinventories.add
The most important file is emoms.properties, where you can find all the configuration parameters.
#Fri May 14 10:54:49 CEST 2004
oracle.sysman.emSDK.svlt.ConsoleServerName=
akira_Management_Service
oracle.sysman.eml.mntr.emdRepPwd=0b878f6184e8319d
emdrep.ping.pingCommand=/bin/ping
oracle.sysman.eml.mntr.emdRepPort=1521
oracle.sysman.eml.mntr.emdRepDBName=AKI1.WORLD
oracle.sysman.emSDK.svlt.ConsoleMode=standalone
oracle.sysman.emRep.dbConn.statementCacheSize=30
oracle.sysman.db.isqlplusUrl=
http\://akira\:5560/isqlplus/dynamic
oracle.sysman.emSDK.svlt.ConsoleServerPort=5500
oracle.sysman.eml.mntr.emdRepRAC=FALSE
oracle.sysman.emSDK.emd.rt.useMonitoringCred=true
oracle.sysman.eml.mntr.emdRepPwdEncrypted=TRUE
oracle.sysman.db.isqlplusWebDBAUrl=
http\://akira\:5560/isqlplus/dba/dynamic
oracle.sysman.emSDK.svlt.ConsoleServerHost=akira
oracle.sysman.emSDK.svlt.ConsoleServerHTTPSPort=5500
oracle.sysman.eml.mntr.emdRepServer=akira
oracle.sysman.eml.mntr.emdRepSID=AKI1
oracle.sysman.emSDK.sec.ReuseLogonPassword=true
oracle.sysman.eml.mntr.emdRepConnectDescriptor=
(DESCRIPTION\=(ADDRESS_LIST\=
(ADDRESS\=(PROTOCOL\=TCP)(HOST\=akira)(PORT\
=1521)))(CONNECT_DATA\=(SERVICE_NAME\=AKI1)))
oracle.sysman.eml.mntr.emdRepUser=SYSMAN
oracle.sysman.db.adm.conn.statementCacheSize=2
oracle.sysman.db.perf.conn.statementCacheSize=30
Automatically start and stop the DB-Console
$ emctl start dbconsole
$ emctl stop dbconsole
$ emctl status dbconsole
Oracle Enterprise Manager 10g Database
Control Release 10.1.0.2.0
Copyright (c) 1996, 2004 Oracle Corporation.
All rights reserved.
http://akira:5500/em/console/aboutApplication
Oracle Enterprise Manager 10g is running.
---------------------------------------------------
Logs are generated in directory
/opt/oracle/product/10.1.0/akira_AKI1/sysman/log
Overview
When you choose to create a preconfigured database during the Oracle 10g installation, you can select the Oracle Enterprise Manager (OEM) interface that you want to use to manage the database. The following options are available:
Database Grid Control
This option is available only if an Oracle Management Agent is installed on the system. When the Installer detects an Oracle Management Agent on the system, it allows you to choose this option and specify the Oracle Management Service that you want to use to manage the database.
If an Oracle Management Agent is not installed, you must choose to use Database Control to manage the database. However, if you install Oracle Management Agent after you install Oracle Database, you can then use Grid Control to manage this database.
Database Control
This option is selected by default if an Oracle Management Agent is not installed on the system. However, even if a Management Agent is installed, you can still choose to configure Database Control to manage the database.
Custom installation
If you choose the Custom installation type or the Advanced database configuration option during the installation, the Installer does not display the OEM setup screens. Instead, it runs the Database Configuration Assistant (DBCA) in interactive mode, which enables you to create a custom database.
DBCA also enables you to specify the Oracle Enterprise Manager interface that you want to use. Furthermore, you can also use DBCA after the installation to configure Database Control for a database that was not previously configured to use it.
However, if you decide to setup your own Database, you must install the Database Control manually.
Setup your own Database and manually install the Database Control
The Database Control relies on various underlying technologies to discover, monitor, and administer the Oracle Database environment.
From the Database Control, you can monitor and administer a single Oracle Database instance.
The Database Control Framework consists of the Database Control and its underlying technologies:
A local version of the Oracle Management Service designed to work with the local database or clustered database.
A local Oracle Management Repository installed in the local database and designed to store management data for the Database Control.
The following steps have to be performed.
Create your own Database
More information to setup your own Database can be found here:
For Windows 2000
For Linux
Create the Database Control Repository and setup the OC4J Application Server
Make sure, that you can connect to the Repository Database (Test it with SQL*Plus). Examples for Setup Files can be found here:
Windows
Linux
LISTENER.ORA listener.ora
SQLNET.ORA sqlnet.ora
TNSNAMES.ORA tnsnames.ora
Now start the Oracle EM dbconsole Build Script ($ORACLE_HOME/bin/emca for Linux and $ORACLE_HOME\Bin\emca.bat for Windows).
$ emca -repos create
$ emca -config dbcontrol db
STARTED EMCA at Fri May 14 10:43:22 MEST 2004
Enter the following information about the database
to be configured.
Listener port number: 1521
Database SID: AKI1
Service name: AKI1.WORLD
Email address for notification: martin dot zahn at akadia dot ch
Email gateway for notification: mailhost
Password for dbsnmp: xxxxxxx
Password for sysman: xxxxxxx
Password for sys: xxxxxxx
---------------------------------------------------------
You have specified the following settings
Database ORACLE_HOME: /opt/oracle/product/10.1.0
Enterprise Manager ORACLE_HOME: /opt/oracle/product/10.1.0
Database host name ..........: akira
Listener port number .........: 1521
Database SID .................: AKI1
Service name .................: AKI1
Email address for notification: martin dot zahn at akadia dot ch
Email gateway for notification: mailhost
---------------------------------------------------------
Do you wish to continue? [yes/no]: yes
AM oracle.sysman.emcp.EMConfig updateReposVars
INFO: Updating file ../config/repository.variables ...
Now wait about 10 Minutes to complete!
M oracle.sysman.emcp.EMConfig createRepository
INFO: Creating repository ...
M oracle.sysman.emcp.EMConfig perform
INFO: Repository was created successfully
M oracle.sysman.emcp.util.PortQuery findUsedPorts
INFO: Searching services file for used port
AM oracle.sysman.emcp.EMConfig getProperties
...........
...........
INFO: Starting the DBConsole ...
AM oracle.sysman.emcp.EMConfig perform
INFO: DBConsole is started successfully
INFO: >>>>>>>>>>> The Enterprise Manager URL is http://akira:5500/em <<<<<<<<<<<
Enterprise Manager configuration is completed successfully
FINISHED EMCA at Fri May 14 10:55:25 MEST 2004
Try to connect to the database Control
http://akira:5500/em
If you look at the installed schemas, you can now find the SYSMAN schema, which is the database Control Repository.
Troubleshooting
If you have troubles to connect, check your local configuration which can be found in $ORACLE_HOME/
$ pwd
/opt/oracle/product/10.1.0/akira_AKI1/sysman/config
$ ls -l
-rw-r--r-- b64InternetCertificate.txt
-rw-r--r-- emagentlogging.properties
-rw-r--r-- emd.properties
-rw-r--r-- emomsintg.xml
-rw-r--r-- emomslogging.properties
-rw-r--r-- emoms.properties
-rw-r--r-- OUIinventories.add
The most important file is emoms.properties, where you can find all the configuration parameters.
#Fri May 14 10:54:49 CEST 2004
oracle.sysman.emSDK.svlt.ConsoleServerName=
akira_Management_Service
oracle.sysman.eml.mntr.emdRepPwd=0b878f6184e8319d
emdrep.ping.pingCommand=/bin/ping
oracle.sysman.eml.mntr.emdRepPort=1521
oracle.sysman.eml.mntr.emdRepDBName=AKI1.WORLD
oracle.sysman.emSDK.svlt.ConsoleMode=standalone
oracle.sysman.emRep.dbConn.statementCacheSize=30
oracle.sysman.db.isqlplusUrl=
http\://akira\:5560/isqlplus/dynamic
oracle.sysman.emSDK.svlt.ConsoleServerPort=5500
oracle.sysman.eml.mntr.emdRepRAC=FALSE
oracle.sysman.emSDK.emd.rt.useMonitoringCred=true
oracle.sysman.eml.mntr.emdRepPwdEncrypted=TRUE
oracle.sysman.db.isqlplusWebDBAUrl=
http\://akira\:5560/isqlplus/dba/dynamic
oracle.sysman.emSDK.svlt.ConsoleServerHost=akira
oracle.sysman.emSDK.svlt.ConsoleServerHTTPSPort=5500
oracle.sysman.eml.mntr.emdRepServer=akira
oracle.sysman.eml.mntr.emdRepSID=AKI1
oracle.sysman.emSDK.sec.ReuseLogonPassword=true
oracle.sysman.eml.mntr.emdRepConnectDescriptor=
(DESCRIPTION\=(ADDRESS_LIST\=
(ADDRESS\=(PROTOCOL\=TCP)(HOST\=akira)(PORT\
=1521)))(CONNECT_DATA\=(SERVICE_NAME\=AKI1)))
oracle.sysman.eml.mntr.emdRepUser=SYSMAN
oracle.sysman.db.adm.conn.statementCacheSize=2
oracle.sysman.db.perf.conn.statementCacheSize=30
Automatically start and stop the DB-Console
$ emctl start dbconsole
$ emctl stop dbconsole
$ emctl status dbconsole
Oracle Enterprise Manager 10g Database
Control Release 10.1.0.2.0
Copyright (c) 1996, 2004 Oracle Corporation.
All rights reserved.
http://akira:5500/em/console/aboutApplication
Oracle Enterprise Manager 10g is running.
---------------------------------------------------
Logs are generated in directory
/opt/oracle/product/10.1.0/akira_AKI1/sysman/log
Saturday, May 21, 2011
Step-By-Step Installation of 9.2.0.5 RAC on Linux
| Step-By-Step Installation of 9.2.0.5 RAC on Linux [ID 184821.1] | |||||
| Modified 05-OCT-2010 Type REFERENCE Status ARCHIVED | |||||
Step-By-Step Installation of 9.2.0.5 RAC on Linux
Note: This note was created for 9i RAC. The 10g Oracle documentation provides installation instructions for 10g RAC. These instructions can be found on OTN:
Purpose
This document will provide the reader with step-by-step instructions on how to install a cluster, install Oracle Real Application Clusters (RAC) (Version 9.2.0.5), and start a cluster database on Linux. For additional explanation or information on any of these steps, please see the references listed at the end of this document.
Disclaimer: If there are any errors or issues prior to step 2, please contact your Linux distributor.
The information contained here is as accurate as possible at the time of writing.
- 1. Configuring the Cluster Hardware
- 1.1 Minimal Hardware list / System Requirements
- 1.2 Installing the Shared Disk Subsystem
- 1.3 Configuring the Cluster Interconnect and Public Network Hardware
- 2. Creating a cluster
- 2.1 UNIX Pre-installation tasks
- 2.2 Configuring the Shared Disks
- 2.3 Run the Oracle Universal Installer to install the 9.2.0.4 ORACM (Oracle Cluster Manager)
- 2.4 Configure the hangcheck-timer
- 2.5 Install Version 10.1.0.2 of the Oracle Universal Installer
- 2.6 Run the 10.1.0.2 Oracle Universal Installer to patch the Oracle Cluster Manager (ORACM) to 9.2.0.5
- 2.7 Modify the ORACM configuration files to utilize the hangcheck-timer
- 2.8 Start the ORACM (Oracle Cluster Manager)
- 3. Installing RAC
- 3.1 Install 9.2.0.4 RAC
- 3.2 Patch the RAC Installation to 9.2.0.5
- 3.3 Start the GSD (Global Service Daemon)
- 3.4 Create a RAC Database using the Oracle Database Configuration Assistant
- 4. Administering Real Application Clusters Instances
- 5. References
1. Configuring the Clusters Hardware<>
1.1 Minimal Hardware list / System Requirements
Please check the RAC/Linux certification matrix for information on currently supported hardware/software.
- Requirements:
- Refer to the RAC/Linux certification matrix for information on supported configurations. Ensure that the system has at least the following resources:
- 400 MB in /tmp
- 512 MB of Physical Memory (RAM)
- Three times the amount of Physical Memory for Swap space (unless the system exceeds 1 GB of Physical Memory, where two times the amount of Physical Memory for Swap space is sufficient)
An example system disk layout is as follows:-
| Slice | Contents | Allocation (in Mbytes) |
| 0
| / | 2000 or more |
| 1 | /boot | 64 |
| 2 | /tmp | 1000 |
| 3 | /usr | 3000-7000 depending on operating system and packages installed |
| 4 | /var | 512 (can be more if required) |
| 5 | swap | Three times the amount of Physical Memory for Swap space (unless the system exceeds 1 GB of Physical Memory, where two times the amount of Physical Memory for Swap space is sufficient). |
| 6 | /home | 2000 (can be more if required) |
- For RAC on Linux support, consult the operating system vendor and see the RAC/Linux certification matrix.
- Make sure you have make and rsh-server packages installed, check with:
$rpm -q rsh-server make
rsh-server-0.17-5
make-3.79.1-8
If these are not installed, use your favorite package manager to install them.
Consult with your operating system vendor to get on the latest patch version of the kernel.
1.2 Installing the Shared Disk Subsystem
This is highly dependent on the subsystem you have chosen. Please refer to your hardware documentation for installation and configuration instructions on Linux. Additional drivers and patches might be required. In this article we assume that the shared disk subsystem is correctly installed and that the shared disks are visible to all nodes in the cluster.
1.3 Configuring the Cluster Interconnect and Public Network Hardware
If not already installed, install host adapters in your cluster nodes. For the procedure on installing host adapters, see the documentation that shipped with your host adapters and node hardware.
Each system will have at least an IP address for the public network and one for the private cluster interconnect. For the public network, get the addresses from your network manager. For the private interconnect use 1.1.1.1 , 1.1.1.2 for the first and second node. Make sure to add all addresses in /etc/hosts.
[oracle@opcbrh1 oracle]$ more /etc/hosts
ex:
9.25.120.143 rac1 #Oracle 9i Rac node 1 - public network
9.25.120.143 rac2 #Oracle 9i Rac node 2 - public network
1.1.1.1 int-rac1 #Oracle 9i Rac node 1 - interconnect
1.1.1.2 int-rac2 #Oracle 9I Rac node 2 - interconnect
Use your favorite tool to configure these adapters. Make sure your public network is the primary (eth0).
Interprocess communication is an important issue for RAC since cache fusion transfers buffers between instances using this mechanism. Thus, networking parameters are important for RAC databases. The values in the following table are the recommended values. These are NOT the default on most distributions.
| Parameter | Meaning | Value |
| /proc/sys/net/core/rmem_default | The default setting in bytes of the socket receive buffer | 262144 |
| /proc/sys/net/core/rmem_max | The maximum socket receive buffer size in bytes | 262144 |
| /proc/sys/net/core/wmem_default | The default setting in bytes of the socket send buffer | 262144 |
| /proc/sys/net/core/wmem_max | The maximum socket send buffer size in bytes | 262144 |
You can see these settings with:
$ cat /proc/sys/net/core/rmem_default
Change them with:
$ echo 262144 > /proc/sys/net/core/rmem_default
This will need to be done each time the system boots. Some distributions already have setup a method for this during boot. On Red Hat , this can be configured in /etc/sysctl.conf (like : net.core.rmem_default = 262144).
On Linux, the cluster software required to run Real Application Clusters is included in the Oracle distribution.
The Oracle Cluster Manager (ORACM) installation process includes eight major tasks.
- UNIX pre-installation tasks.
- Configuring the shared disks
- Run the Oracle Universal Installer to install the 9.2.0.4 ORACM (Oracle Cluster Manager)
- Configure the hangcheck-timer.
- Install version 10.1.0.2 of the Oracle Universal Installer
- Run the 10.1.0.2 Oracle Universal Installer to patch the Oracle Cluster Manager (ORACM) to 9.2.0.5
- Modify the ORACM configuration files to utilize the hangcheck-timer.
- Start the ORACM (Oracle Cluster Manager)
2.1 UNIX Pre-installation tasks
These steps need to be performed on ALL nodes.
- First, on each node, create the Oracle group. Example:
# groupadd dba -g 501
- Next, make the Oracle user's home directory. Example:
# mkdir -p /u01/home/oracle
- On each node, create the Oracle user. Make sure that the Oracle user is part of the dba group. Example:
# useradd -c "Oracle Software Owner" -G dba -u 101 -m -d /u01/home/oracle -s /bin/csh oracle
- On each node, Create a mount point for the Oracle software installation (at least 2.5 GB, typically /u01). The oracle user should own this mount point and all of the directories below the mount point. Example:
# mkdir /u01
# chown -R oracle.dba /u01
# chmod -R ug=rwx,o=rx /u01
- Once this is done, test the permissions on each node to ensure that the oracle user can write to the new mount points. Example:
# su - oracle
$ touch /u01/test
$ ls -l /u01/test
-rw-rw-r-- 1 oracle dba 0 Aug 15 09:36 /u01/test
- Depending on your Linux distribution, make sure inetd or xinetd is started on all nodes and that the ftp, telnet, shell and login (or rsh) services are enabled (see /etc/inetd.conf or /etc/xinetd.conf and /etc/xinetd.d). Example:
# more /etc/xinetd.d/telnet
# default: on
# description: The telnet server serves telnet sessions; it uses \
# unencrypted username/password pairs for authentication.
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
}
In this example, disable should be set to 'no'.
- On the node from which you will run the Oracle Universal Installer, set up user equivalence by adding entries for all nodes in the cluster, including the local node, to the .rhosts file of the oracle account, or the /etc/hosts.equiv file.
Sample entries in /etc/hosts.equiv file:
rac1
rac2
int-rac1
int-rac2
- As oracle user, check for user equivalence for the oracle account by performing a remote copy (rcp) to each node (public and private) in the cluster. Example:
RAC1:
$ touch /u01/test
$ rcp /u01/test rac2:/u01/test1
$ rcp /u01/test int-rac2:/u01/test2
RAC2:
$ touch /u01/test
$ rcp /u01/test rac1:/u01/test1
$ rcp /u01/test int-rac1:/u01/test2
$ ls /u01/test*
/u01/test /u01/test1 /u01/test2
RAC1:
$ ls /u01/test*
/u01/test /u01/test1 /u01/test2
| Note: If you are prompted for a password, you have not given the oracle account the same attributes on all nodes. You must correct this because the Oracle Universal Installer cannot use the rcp command to copy Oracle products to the remote node's directories without user equivalence. |
System Kernel Parameters
Verify operating system kernel parameters are set to appropriate levels:
| Kernel Parameter | Setting | Purpose |
| SHMMAX | 2147483648 | Maximum allowable size of one shared memory segment. |
| SHMMIN | 1 | Minimum allowable size of a single shared memory segment. |
| SHMMNI | 100 | Maximum number of shared memory segments in the entire system. |
| SHMSEG | 10 | Maximum number of shared memory segments one process can attach. |
| SEMMNI | 100 | Maximum number of semaphore sets in the entire system. |
| SEMMSL | 250 | Minimum recommended value. SEMMSL should be 10 plus the largest PROCESSES parameter of any Oracle database on the system. |
| SEMMNS | 1000 | Maximum semaphores on the system. This setting is a minimum recommended value. SEMMNS should be set to the sum of the PROCESSES parameter for each Oracle database, add the largest one twice, plus add an additional 10 for each database. |
| SEMOPM | 100 | Maximum number of operations per semop call. |
You will have to set the correct parameters during system startup, so include them in your startup script (startoracle_root.sh):
$ export SEMMSL=100
$ export SEMMNS=1000
$ export SEMOPM=100
$ export SEMMNI=100
$ echo $SEMMSL $SEMMNS $SEMOPM $ SEMMNI > /proc/sys/kernel/sem
$ export SHMMAX=2147483648
$ echo $SHMMAX > /proc/sys/kernel/shmmax
Check these with:
$ cat /proc/sys/kernel/sem
$ cat /proc/sys/kernel/shmmax
You might want to increase the maximum number of file handles, include this in your startup script or use /etc/sysctl.conf :
$ echo 65536 > /proc/sys/fs/file-max
To allow your oracle processes to use these file handles, add the following to your oracle account login script (ex.: .profile)
$ ulimit -n 65536
| Note: This will only allow you to set the soft limit as high as the hard limit. You might have to increase the hard limit on system level. This can be done by adding ulimit -Hn 65536 to /etc/initscript. You will have to reboot the system to make this active. Sample /etc/initscript:
|
Establish Oracle environment variables: Set the following Oracle environment variables:
| Environment Variable | Suggested value |
| ORACLE_HOME | eg /u01/app/oracle/product/920 |
| ORACLE_TERM | xterm |
| PATH | /u01/app/oracle/product/9.2.0/bin: /usr/ccs/bin:/usr/bin/X11/:/usr/local/bin and any other items you require in your PATH |
| DISPLAY | (review Note:153960.1 for detailed information) |
| TMPDIR | Set a temporary directory path for TMPDIR with at least 100 Mb of free space to which the OUI has write permission. |
| ORACLE_SID | Set this to what you will call your database instance. This should be UNIQUE on each node. |
It is best to save these in a .login or .profile file so that you do not have to set the environment every time you log in.
- Create the directory /var/opt/oracle and set ownership to the oracle user. Example:
$ mkdir /var/opt/oracle
$ chown oracle.dba /var/opt/oracle
- Set the oracle user's umask to "022" in you ".profile" or ".login" file. Example:
$ umask 022
| Note: There is a verification script InstallPrep.sh available which may be downloaded and run prior to the installation of Oracle Real Application Clusters. This script verifies that the system is configured correctly according to the Installation Guide. The output of the script will report any further tasks that need to be performed before successfully installing Oracle 9.x DataServer (RDBMS). This script performs the following verifications:-
. ./InstallPrep.sh You are currently logged on as oracle
/tmp test passed
Note: If you get an error like this: InstallPrep.sh: line 45: syntax error near unexpected token `fi' or ./InstallPrep.sh: Command not found. Then you need to copy the script into a text file (it will not run if the file is in binary format). |
2.2 Configuring the Shared Disks
For 9.2 Real Application Clusters on Linux, you can use either OCFS (Oracle Cluster Filesystem), RAW, or NFS (Redhat and Network Appliance Only) for storage of Oracle database files.
- For more information on setting up OCFS for RAC on Linux, see the following MetaLink Note:
Note 220178.1 - Installing and setting up ocfs on Linux - Basic Guide
- For more information on setting up RAW for RAC on Linux, see the following MetaLink Note:
Note 246205.1 - Configuring Raw Devices for Real Application Clusters on Linux
2.3 Run the Oracle Universal Installer to install the 9.2.0.4 ORACM (Oracle Cluster Manager)
These steps only need to be performed on the node that you are installing from (typically Node 1).
- If you are using OCFS or NFS for your shared storage, pre-create the quorum file and srvm file. Example:
# dd if=/dev/zero of=/ocfs/quorum.dbf bs=1M count=20
# dd if=/dev/zero of=/ocfs/srvm.dbf bs=1M count=100
# chown root:dba /ocfs/quorum.dbf
# chmod 664 /ocfs/quorum.dbf
# chown oracle:dba /ocfs/srvm.dbf
# chmod 664 /ocfs/srvm.dbf
- Verify the Environment - Log off and log on as the oracle user to ensure all environment variables
are set correctly. Use the following command to view them:
% env | more
| Note: If you are on Redhat Advanced Server 3.0, you will need to temporarily use an older gcc for the install: mv gcc gcc3.2.3
|
- Before attempting to run the Oracle Universal Installer, verify that you can successfully run the following command:
% /usr/bin/X11/xclock
- If this does not display a clock on your display screen, please review the following article:
Note 153960.1 FAQ: X Server testing and troubleshooting
- Start the Oracle Universal Installer and install the RDBMS software - Follow these procedures to use the Oracle Universal Installer to install the Oracle Cluster Manager software. Oracle9i is supplied on multiple CD-ROM disks. During the installation process it is necessary to switch between the CD-ROMS. OUI will manage the switching between CDs.
Use the following commands to start the installer:
% cd /tmp
% /cdrom/runInstaller
Or cd to /stage/Disk1 and run ./runInstaller
Respond to the installer prompts as shown below:
- At the "Welcome Screen", click Next.
| If this is your first install on this machine:
|
- At the "File Locations Screen", verify the destination listed is your ORACLE_HOME directory. Also enter a NAME to identify this ORACLE_HOME. The NAME can be anything.
- At the "Available Products Screen", Check "Oracle Cluster Manager". Click Next.
- At the public node information screen, enter the public node names and click Next.
- At the private node information screen, enter the interconnect node names. Click Next.
- Enter the full name of the file or raw device you have created for the ORACM Quorum disk information. Click Next.
- Press Install at the summary screen.
- You will now briefly get a progress window followed by the end of installation screen. Click Exit and confirm by clicking Yes.
| Note: Create the directory $ORACLE_HOME/oracm/log (as oracle) on the other nodes if it doesn't exist. |
2.4 Configure the hangcheck-timer
These steps need to be performed on ALL nodes.
Some kernel versions include the hangcheck-timer with the kernel. You can check to see if your kernel contains the hangcheck-timer by running:
# /sbin/lsmod
Then you will see hangcheck-timer listed. Also verify that hangcheck-timer is starting in your /etc/rc.local file (on Redhat) or /etc/init.d/boot.local (on United Linux). If you see hangcheck-timer listed in lsmod and in the rc.local file or boot.local, you can skip to section 2.5.
If hangcheck-timer is not listed here and you are not using Redhat Advanced Server, see the following note for information on obtaining the hangcheck-timer:
Note 232355.1 - Hangcheck Timer FAQ
If you are on Redhat Advanced Server, you can either apply the latest errata version (> 12) or go to MetaLink - Patches:
Enter 2594820 in the Patch Number field.
Click Go.
Click Download.
Save the file p2594820_20_LINUX.zip to the local disk, such as /tmp.
Unzip the file. The output should be similar to the following:
inflating: hangcheck-timer-2.4.9-e.3-0.4.0-1.i686.rpm
inflating: hangcheck-timer-2.4.9-e.3-enterprise-0.4.0-1.i686.rpm
inflating: hangcheck-timer-2.4.9-e.3-smp-0.4.0-1.i686.rpm
inflating: README.TXT
Run the uname -a command to identify the RPM that corresponds to the kernel in use. This will show if the kernel is single CPU, smp, or enterprise.
The p2594820_20_LINUX.zip file contains four files. The following describes the files:
hangcheck-timer-2.4.9-e.3-0.4.0-1.i686.rpm is for single CPU machines
hangcheck-timer-2.4.9-e.3-enterprise=0.4.0-1.i686.rpm is for multi-processor machines with more than 4 GB of RAM
hangcheck-timer-2.4.9-e.3-smp-0.4.0-1.i686.rpm is for multi-processor machines with 4 GB of RAM or less
The three RPMs will work for the e3 kernels in Red Hat Advanced Server 2.1 gold and the e8 kernels in the latest Red Hat Advanced Server 2.1 errata release. These RPMs are for Red Hat Advanced Server 2.1 kernels only.
Transfer the relevant hangcheck-timer RPM to the /tmp directory of the Oracle Real Applications Cluster node.
Log in to the node as the root user.
Change to the /tmp directory.
Run the following command to install the module:
#rpm -ivh hangcheck-timer RPM name | If you have previously installed RAC on this cluster, remove or disable the mechanism that loads the softdog module at system start up, if that module is not used by other software on the node. This is necessary for subsequent steps in the installation process. This step may require log in as the root user. One method for setting up previous versions of Oracle Real Applications Clusters involved loading the softdog module in the /etc/rc.local (on Redhat) or /etc/init.d/boot.local (on United Linux) file. If this method was used, then remove or comment out the following line in the file: /sbin/insmod softdog nowayout=0 soft_noboot=1 soft_margin=60 |
Append the following line to the /etc/rc.local file (on Redhat) or /etc/init.d/boot.local (on United Linux):
/sbin/insmod hangcheck-timer hangcheck_tick=30 hangcheck_margin=180 Load the hangcheck-timer kernel module using the following command as root user:
# /sbin/insmod hangcheck-timer hangcheck_tick=30 hangcheck_margin=180 Repeat the above steps on all Oracle Real Applications Clusters nodes where the kernel module needs to be installed.
Run dmesg after the module is loaded. Note the build number while running the command. The following is the relevant information output:
build 334adfa62c1a153a41bd68a787fbe0e9 The build number is required when making support calls.
2.5 Install Version 10.1.0.2 of the Oracle Universal Installer
These steps need to be performed on ALL nodes.
Download the 9.2.0.5 patchset from MetaLink - Patches:
Enter 3501955 in the Patch Number field.
Click Go.
Click Download.
- Place the file in a patchset directory on the node you are installing from. Example:
$ mkdir $ORACLE_HOME/9205
$ cp p3501955_9205_LINUX.zip $ORACLE_HOME/9205
- Unzip the file:
$ cd $ORACLE_HOME/9205
$ unzip p3501955_9205_LINUX.zip
Archive: p3501955_9205_LINUX
inflating: 9205_lnx32_release.cpio
inflating: README.html
inflating: ReleaseNote9205.pdf
- Run CPIO against the file:
$ cpio -idmv < 9205_lnx32_release.cpio
Run the installer from the 9.2.0.5 staging location:
$ cd $ORACLE_HOME/9205/Disk1
$ ./runInstaller
Respond to the installer prompts as shown below:
- At the "Welcome Screen", click Next.
- At the "File Locations Screen", Change the $ORACLE_HOME name from the dropdown list to the 9.2 $ORACLE_HOME name. Click Next.
- On the "Available Products Screen", Check "Oracle Universal Installer 10.1.0.2. Click Next.
- Press Install at the summary screen.
- You will now briefly get a progress window followed by the end of installation screen. Click Exit and confirm by clicking Yes.
| Remember to install the 10.1.0.2 Installer on ALL cluster nodes. Note that you may need to ADD the 9.2 $ORACLE_HOME name on the "File Locations Screen" for other nodes. It will ask if you want to specify a non-empty directory, say "Yes". |
2.6 Run the 10.1.0.2 Oracle Universal Installer to patch the Oracle Cluster Manager (ORACM) to 9.2.0.5
These steps only need to be performed on the node that you are installing from (typically Node 1).
The 10.1.0.2 OUI will use SSH (Secure Shell) if it is configured. If it is not configured it will use RSH (Remote Shell). If you have SSH configured on your cluster, test and make sure that you can SSH and SCP to all nodes of the cluster without being prompted. If you do not have SSH configured, skip this step and run the installer from $ORACLE_BASE/oui/bin as noted below.
SSH Test:
As oracle user, check for user equivalence for the oracle account by performing a secure copy (scp) to each node (public and private) in the cluster. Example:
RAC1:
$ touch /u01/sshtest
$ scp /u01/sshtest rac2:/u01/sshtest1
$ scp /u01/sshtest int-rac2:/u01/sshtest2
RAC2:
$ touch /u01/sshtest
$ scp /u01/sshtest rac1:/u01/sshtest1
$ scp /u01/sshtest int-rac1:/u01/sshtest2
$ ls /u01/sshtest*
/u01/sshtest /u01/sshtest1 /u01/sshtest2
RAC1:
$ ls /u01/sshtest*
/u01/sshtest /u01/sshtest1 /u01/sshtest2
Run the installer from the 9.2.0.5 oracm staging location:
$ cd $ORACLE_HOME/9205/Disk1/oracm
$ ./runInstaller
Respond to the installer prompts as shown below:
- At the "Welcome Screen", click Next.
- At the "File Locations Screen", make sure the source location is to the products.xml file in the 9.2.0.5 patchset location under Disk1/stage. Also verify the destination listed is your ORACLE_HOME directory. Change the $ORACLE_HOME name from the dropdown list to the 9.2 $ORACLE_HOME name. Click Next.
- At the "Available Products Screen", Check "Oracle9iR2 Cluster Manager 9.2.0.5.0". Click Next.
- At the public node information screen, enter the public node names and click Next.
- At the private node information screen, enter the interconnect node names. Click Next.
- Click Install at the summary screen.
- You will now briefly get a progress window followed by the end of installation screen. Click Exit and confirm by clicking Yes.
2.7 Modify the ORACM configuration files to utilize the hangcheck-timer.
These steps need to be performed on ALL nodes.
Modify the $ORACLE_HOME/oracm/admin/cmcfg.ora file:
Add the following line:
KernelModuleName=hangcheck-timer
Adjust the value of the MissCount line based on the sum of the hangcheck_tick and hangcheck_margin values. (> 210)
MissCount=210
Make sure that you can ping each of the names listed in the private and public node name sections from each node. Example:
$ ping rac2
PING opcbrh2.us.oracle.com (138.1.137.46) from 138.1.137.45 : 56(84) bytes of data.
64 bytes from opcbrh2.us.oracle.com (138.1.137.46): icmp_seq=0 ttl=255 time=1.295 msec
64 bytes from opcbrh2.us.oracle.com (138.1.137.46): icmp_seq=1 ttl=255 time=154 usec
Verify that a valid CmDiskFile line exists in the following format:
CmDiskFile=file or raw device name
In the preceding command, the file or raw device must be valid. If a file is used but does not exist, then the file will be created if the base directory exists. If a raw device is used, then the raw device must exist and have the correct ownership and permissions. Sample cmcfg.ora file:
ClusterName=Oracle Cluster Manager, version 9i
MissCount=210
PrivateNodeNames=int-rac1 int-rac2
PublicNodeNames=rac1 rac2
ServicePort=9998
CmDiskFile=/u04/quorum.dbf
KernelModuleName=hangcheck-timer
HostName=int-rac1
| Note: The cmcfg.ora file should be the same on both nodes with the exception of the HostName parameter which should be set to the local (internal) hostname. |
Make sure all of these changes have been made to all RAC nodes. More information on ORACM parameters can be found in the following note:
Note 222746.1 - RAC Linux 9.2: Configuration of cmcfg.ora and ocmargs.ora
| Note: At this point it would be a good idea to patch to the latest ORACM, especially if you have more than 2 nodes. For more information see:
Note 278156.1 - ORA-29740 or ORA-29702 After Applying 9.2.0.5 Patchset on RAC / Linux |
2.8 Start the ORACM (Oracle Cluster Manager)
These steps need to be performed on ALL nodes.
Cd to the $ORACLE_HOME/oracm/bin directory, change to the root user, and start the ORACM.
$ cd $ORACLE_HOME/oracm/bin
$ su root
# ./ocmstart.sh
oracm &1 >/u01/app/oracle/product/9.2.0/oracm/log/cm.out &
Verify that ORACM is running with the following:
# ps -ef | grep oracm
On RHEL 3.0, add the -m option: # ps -efm | grep oracm You should see several oracm threads running. Also verify that the ORACM version is the same on each node:
# cd $ORACLE_HOME/oracm/log
# head -1 cm.log
oracm, version[ 9.2.0.2.0.49 ] started {Fri May 14 09:22:28 2004 }
The Real Application Clusters installation process includes four major tasks.
- Install 9.2.0.4 RAC.
- Patch the RAC Installation to 9.2.0.5.
- Start the GSD.
- Create and configure your database.
These steps only need to be performed on the node that you are installing from (typically Node 1).
| Note: Due to bug 3547724, temporarily create a symbolic link /oradata directory pointing to an oradata directory with space available as root prior to running the RAC install: # mkdir /u04/oradata
|
Install 9.2.0.4 RAC into your $ORACLE_HOME by running the installer from the 9.2.0.4 cd or your original stage location for the 9.2.0.4 install.
Use the following commands to start the installer:
% cd /tmp
% /cdrom/runInstaller
Or cd to /stage/Disk1 and run ./runInstaller
Respond to the installer prompts as shown below:
- At the "Welcome Screen", click Next.
- At the "Cluster Node Selection Screen", make sure that all RAC nodes are selected.
- At the "File Locations Screen", verify the destination listed is your ORACLE_HOME directory and that the source directory is pointing to the products.jar from the 9.2.0.4 cd or staging location.
- At the "Available Products Screen", check "Oracle 9i Database 9.2.0.4". Click Next.
- At the "Installation Types Screen", check "Enterprise Edition" (or whichever option your prefer), click Next.
- At the "Database Configuration Screen", check "Software Only". Click Next.
- At the "Shared Configuration File Name Screen", enter the path of the CFS or NFS srvm file created at the beginning of step 2.3 or the raw device created for the shared configuration file. Click Next.
- Click Install at the summary screen. Note that some of the items installed will say "9.2.0.1" for the version, this is normal because only some items needed to be patched up to 9.2.0.4.
- You will now get a progress window, run root.sh when prompted.
- You will then see the end of installation screen. Click Exit and confirm by clicking Yes.
| Note: You can now remove the /oradata symbolic link: # rm /oradata |
3.2 Patch the RAC Installation to 9.2.0.5
These steps only need to be performed on the node that you are installing from.
Run the installer from the 9.2.0.5 staging location:
$ cd $ORACLE_HOME/9205/Disk1
$ ./runInstaller
Respond to the installer prompts as shown below:
- At the "Welcome Screen", click Next.
- View the "Cluster Node Selection Screen", click Next.
- At the "File Locations Screen", make sure the source location is to the products.xml file in the 9.2.0.5 patchset location under Disk1/stage. Also verify the destination listed is your ORACLE_HOME directory. Change the $ORACLE_HOME name from the dropdown list to the 9.2 $ORACLE_HOME name. Click Next.
- At the "Available Products Screen", Check "Oracle9iR2 PatchSets 9.2.0.5.0". Click Next.
- Click Install at the summary screen.
- You will now get a progress window, run root.sh when prompted.
- You will then see the end of installation screen. Click Exit and confirm by clicking Yes.
3.3 Start the GSD (Global Service Daemon)
These steps need to be performed on ALL nodes.
Start the GSD on each node with:
% gsdctl start
Successfully started GSD on local node
Then check the status with:
% gsdctl stat
GSD is running on the local node
If the GSD does not stay up, try running 'srvconfig -init -f' from the OS prompt. If you get a raw device exception error or PRKR-1064 error then see the following note to troubleshoot:
Note 212631.1 - Resolving PRKR-1064 in a RAC Environment
| Note: After confirming that GSD starts, if you are on Redhat Advanced Server 3.0, restore gcc296: rm /usr/bin/gcc
|
3.4 Create a RAC Database using the Oracle Database Configuration Assistant
These steps only need to be performed on the node that you are installing from (typically Node 1).
The Oracle Database Configuration Assistant (DBCA) will create a database for you. The DBCA creates your database using the optimal flexible architecture (OFA). This means the DBCA creates your database files, including the default server parameter file, using standard file naming and file placement practices. The primary phases of DBCA processing are:-
- Verify that you correctly configured the shared disks for each tablespace (for non-cluster file system platforms)
- Create the database
- Configure the Oracle network services
- Start the database instances and listeners
Oracle Corporation recommends that you use the DBCA to create your database. This is because the DBCA preconfigured databases optimize your environment to take advantage of Oracle9i features such as the server parameter file and automatic undo management. The DBCA also enables you to define arbitrary tablespaces as part of the database creation process. So even if you have datafile requirements that differ from those offered in one of the DBCA templates, use the DBCA. You can also execute user-specified scripts as part of the database creation process.
| Note: Prior to running the DBCA it may be necessary to run the NETCA tool or to manually set up your network files. To run the NETCA tool execute the command netca from the $ORACLE_HOME/bin directory. This will configure the necessary listener names and protocol addresses, client naming methods, Net service names and Directory server usage. |
If you are using OCFS or NFS, launch DBCA with the -datafileDestination option and point to the shared location where Oracle datafiles will be stored. Example:
% cd $ORACLE_HOME/bin
% dbca -datafileDestination /ocfs/oradata
If you are using RAW, launch DBCA without the -datafileDestination option. Example:
% cd $ORACLE_HOME/bin
% dbca
Respond to the DBCA prompts as shown below:
- Choose Oracle Cluster Database option and select Next.
- The Operations page is displayed. Choose the option Create a Database and click Next.
- The Node Selection page appears. Select the nodes that you want to configure as part of the RAC database and click Next.
- The Database Templates page is displayed. The templates other than New Database include datafiles. Choose New Database and then click Next. Note: The Show Details button provides information on the database template selected.
- DBCA now displays the Database Identification page. Enter the Global Database Name and Oracle System Identifier (SID). The Global Database Name is typically of the form name.domain, for example mydb.us.oracle.com while the SID is used to uniquely identify an instance (DBCA should insert a suggested SID, equivalent to name1 where name was entered in the Database Name field). In the RAC case the SID specified will be used as a prefix for the instance number. For example, MYDB, would become MYDB1, MYDB2 for instance 1 and 2 respectively.
- The Database Options page is displayed. Select the options you wish to configure and then choose Next. Note: If you did not choose New Database from the Database Template page, you will not see this screen.
- Select the connection options desired from the Database Connection Options page. Click Next.
- DBCA now displays the Initialization Parameters page. This page comprises a number of Tab fields. Modify the Memory settings if desired and then select the File Locations tab to update information on the Initialization Parameters filename and location. The option Create persistent initialization parameter file is selected by default. If you have a cluster file system, then enter a file system name, otherwise a raw device name for the location of the server parameter file (spfile) must be entered. The button File Location Variables… displays variable information. The button All Initialization Parameters… displays the Initialization Parameters dialog box. This box presents values for all initialization parameters and indicates whether they are to be included in the spfile to be created through the check box, included (Y/N). Instance specific parameters have an instance value in the instance column. Complete entries in the All Initialization Parameters page and select Close. Note: There are a few exceptions to what can be altered via this screen. Ensure all entries in the Initialization Parameters page are complete and select Next.
- DBCA now displays the Database Storage Window. This page allows you to enter file names for each tablespace in your database.
- The Database Creation Options page is displayed. Ensure that the option Create Database is checked and click Finish.
- The DBCA Summary window is displayed. Review this information and then click OK. Once you click the OK button and the summary screen is closed, it may take a few moments for the DBCA progress bar to start. DBCA then begins to create the database according to the values specified.
| During the database creation process, you may see the following error: ORA-29807: specified operator does not exist This is a known issue (bug 2925665). You can click on the "Ignore" button to continue. Once DBCA has completed database creation, remember to run the 'prvtxml.plb' script from $ORACLE_HOME/rdbms/admin independently, as the user SYS. It is also advised to run the 'utlrp.sql' script to ensure that there are no invalid objects in the database at this time. |
A new database now exists. It can be accessed via Oracle SQL*PLUS or other applications designed to work with an Oracle RAC database.
Additional database configuration best practices can be found in the following note:
Note 240575.1 - RAC on Linux Best Practices
4.0 Administering Real Application Clusters Instances
Oracle Corporation recommends that you use SRVCTL to administer your Real Application Clusters database environment. SRVCTL manages configuration information that is used by several Oracle tools. For example, Oracle Enterprise Manager and the Intelligent Agent use the configuration information that SRVCTL generates to discover and monitor nodes in your cluster. Before using SRVCTL, ensure that your Global Services Daemon (GSD) is running after you configure your database. To use SRVCTL, you must have already created the configuration information for the database that you want to administer. You must have done this either by using the Oracle Database Configuration Assistant (DBCA), or by using the srvctl add command as described below.
To display the configuration details for, example, databases racdb1/2, on nodes racnode1/2 with instances racinst1/2 run:-
$ srvctl config
racdb1
racdb2
$ srvctl config -p racdb1 -n racnode1
racnode1 racinst1 /u01/app/oracle/product/9.2.0
$ srvctl status database -d racdb1
Instance racinst1 is running on node racnode1
Instance racinst2 is running on node racnode2
Examples of starting and stopping RAC follow:-
$ srvctl start database -d racdb2
$ srvctl stop database -d racdb2
$ srvctl stop instance -d racdb1 -i racinst2
$ srvctl start instance -d racdb1 -i racinst2
For further information on srvctl and gsdctl see the Oracle9i Real Application Clusters Administration manual.
- 9.2.0.5 Patch Set Notes
- Tips for Installing and Configuring Oracle9i Real Application Clusters on Red Hat Linux Advanced Server
- Note 201370.1 - LINUX Quick Start Guide - 9.2.0 RDBMS Installation
- Note 252217.1 - Requirements for Installing Oracle 9iR2 on RHEL3
- Note 240575.1 - RAC on Linux Best Practices
- Note 222746.1 - RAC Linux 9.2: Configuration of cmcfg.ora and ocmargs.ora
- Note 212631.1 - Resolving PRKR-1064 in a RAC Environment
- Note 220178.1 - Installing and setting up ocfs on Linux - Basic Guide
- Note 246205.1 - Configuring Raw Devices for Real Application Clusters on Linux
- Note 153960.1 FAQ: X Server testing and troubleshooting
- Note 232355.1 - Hangcheck Timer FAQ
- RAC/Linux certification matrix
- Oracle9i Real Application Clusters Administration
- Oracle9i Real Application Clusters Concepts
- Oracle9i Real Application Clusters Deployment and Performance
- Oracle9i Real Application Clusters Setup and Configuration
- Oracle9i Installation Guide Release 2 for UNIX Systems: AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, and Sun Solaris
| Products
| ||
Related
Back to topCopyright (c) 2007, 2010, Oracle. All rights reserved. Legal Notices and Terms of Use | Privacy Statement
Subscribe to:
Posts (Atom)