Planning a Backup
-
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.
Creating Instances
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.
Creating Subclients
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.
Example:
-
User-defined subclient: Test1
Content: EXAMPLE
-
User-defined subclient: Test2
Content: USERS
Distributing the client data using subclients as recommended above, can help improve backup performance by organizing the workload on the client into logical groupings.
Reconfiguring Default Subclient Content
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.
Enabling a Full System Restore on the Default Subclient
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.
Restoring Control and SP Files
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.
Restoring Dependent Tables
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.
Restoring the Recovery Catalog
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.
Running Command Line Operations
-
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.
Obtaining Correct Instance Status
If you have custom SQL settings, then you must turn off the settings so that the software can correctly perform the following operations:
-
An instance browse
-
Retrieving the instance status
Create the cvlogin.sql file in the <software_installation_path>/iDataAgent directory.
From the command line, edit the file
edit file $ORACLE_HOME/sqlplus/admin/cvlogin.sql
Make sure that the following lines are in the file:
set heading on;
set pause off;
Scheduling Log Backups
Use the archive log subclient that the Commvault software creates by default, to run archive logs backup. Take the following into consideration when planning 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.
Multi-Instances
Use this feature only when the pseudoclient shares the same Oracle RAC physical nodes.
You can use multi-instances in an Oracle RAC One node configuration or a policy-based Oracle RAC configuration as well.
In addition, Commvault recommends that you configure Oracle Data Guard instances under separate pseudoclients. This simply involves configuring Data Guard instances under the Data Guard pseudoclient type and all other instance types under the RAC pseudoclient type.