Best Practices - Oracle RAC iDataAgent
- Planning a Backup
- Creating Instances
- Creating Subclients
- Reconfiguring the Default Subclient Content
- Enabling a Full System Restore on the Default Subclient
- Restoring Control and SP Files
- Restoring Dependent Tables
- Restoring the Recovery Catalog
- Running Command Line Operations
- Obtaining Correct Instance Status
- Scheduling Log Backups
- If you are running in NOARCHIVELOG mode, you must back up the database offline.
- If you are running in ARCHIVELOG mode and database accessibility is a priority, an online backup of the database may be appropriate.
- If the database must be accessible and you have a small backup window, you can run a series of online backups in which different portions of the database are backed up at different times.
You can also combine all of these backup types in your backup strategy. Once you have determined your backup needs, you can define your backup strategy by creating one or more subclients for the database.
When creating/modifying an instances, make sure that you do not enter a “/” at the end of the string for Oracle Home path. Due to limitations in the Oracle application, having a “/” at the end of the string for Oracle Home path can cause backups to fail occasionally.
As a best practice, it is recommended that you create separate subclients to back up data that undergo frequent changes.
For example, if the EXAMPLE and USERS dbspaces undergo frequent changes, you can create a separate subclient for each database.
- User-defined subclient: Test1
- User-defined subclient: Test2
Distributing the client data using subclients as recommended above, can help improve backup performance by organizing the workload on the client into logical groupings.
We recommend that you do not re-configure the content of a default subclient because this would disable its capability to serve as a catch-all entity for client data. As a result, some data will not get backed up or scanned.
The default subclient for the Oracle instance usually includes all the objects in the instance. Once the default subclient is created, synchronize the recovery catalog with the control files. This would help in successfully performing a full system restore in the event of destroyed or damaged client.
Ensure that the database is in NOMOUNT mode when you restore the control/sp files. Ensure that you have previously configured auto backup of control files to restore the control file from auto backup. Restoring a control file will destroy all the previous backups. Hence, you need to perform a full backup after you restore a control file.
It is recommended to include the parent tables along with all the dependent tables for a successful restore operation. This will ensure the inclusion of all the reference constraints of the dependent tables along with parent tables.
When restoring backups with recovery catalog, the method you use to restore the Recovery Catalog depends on the method you have used to back up the Recovery Catalog.
If you have exported the Recovery Catalog using the exp command, you must import the Recovery Catalog into a new database using the imp command. If you have backed up the Recovery Catalog from the CommCell Console, use an appropriate restore method from the CommCell Console to restore the Recovery Catalog.
- Any RMAN command line operation can fail if the required media resource is unavailable due to a conflicting resource reservation by another backup/recovery process or when the resource is unavailable offline. If this happens, it is recommended to establish or verify the availability of the required resource and then rerun the RMAN command line operation.
- When performing backups using RMAN scripts from command line, it is recommended to use separate scripts for data and logs since only one data type can be passed through the argument file (i.e., data or log). This data type is used by the system to mark the archive files created by the backups as DATA or LOG in the CommServe database. Therefore, if you have scripts containing both data and logs, the archive files will be marked as either DATA or LOG depending on the data type mentioned in the argument file.
- Although you can combine data and log scripts in the same job, it is a best practice to run data and log scripts in separate jobs. The drive reservation and re-try mechanism will function more efficiently, if you use this method.
For the Oracle RAC iDataAgent, if you have custom SQL settings, you must turn off these settings to ensure that the instance browse works correctly and that the instance status is correctly secured. To do this, create and edit the cvlogin.sql file with the appropriate contents at ORACLE_HOME/sqlplus/admin. For example, run the following command:
edit file $ORACLE_HOME/sqlplus/admin/cvlogin.sql
Then include the following contents in the cvlogin.sql file:
set heading on;
set pause off;
Use the archive log subclient that the Commvault software creates by default, to run archive logs backup. Take the following into consideration when plan your log backup schedule:
- The number of transactions that the database generates
- The disk size for the log file destination
After you have that information, configure an automatic schedule to back up the logs before the archive log destination fills up to 80% of the space (Backup Task Options dialog box, Schedule Pattern tab, Start backup when disk at log destination is box). For information on how to configure an automatic schedule, see Creating an Automatic Schedule for Database Log Backups.
Use this feature only when the pseudo-client shares the same Oracle RAC physical nodes.
You can use multi-instances in an Oracle RAC One node or Policy Based Oracle RAC configuration as well.