Currently, protection of Oracle 12c databases in Rapid Recovery Core release 6.2 and later is limited to using Volume Snapshot Service (VSS) in the ARCHIVELOG mode. In this mode, the database is configured to archive all online redo logs using the ARCH (archive) process. The Oracle VSS writer calls the Oracle service to archive the existing re-do logs to Oracle's fast_recovery_area folder, and creates a new archive log file.
ARCHIVELOG mode causes a substantial number of log files to accumulate on the database server, using valuable storage space. Each time a recovery point of the Oracle server is captured, the new Oracle logs generated since the last snapshot are included. This renders the local copies of the logs superfluous. For this reason, Rapid Recovery Core includes several methods for truncating Oracle logs.
- Enable Oracle log truncation on the Core as a nightly job. Rapid Recovery Core includes a nightly job setting called Log truncation for Oracle.This nightly job is disabled by default. If you enable this nightly job, Oracle ARCHIVELOGS are truncated according to the deletion policy specified in the settings for this job.
- Enable and customize Oracle log truncation as a nightly job. For each specific Oracle server protected on your Core, you can customize the Oracle log truncation nightly job configuration. As with the Core nightly job, you can select from any of the three deletion policies, described in the following section.
- Manually truncate logs on demand. Regardless of whether you set a log truncation schedule using nightly jobs, you can manually truncate Oracle ARCHIVELOGS on demand at any time.
Truncation of Oracle logs, by nightly job or on demand manually, occurs without requiring a transfer job.
When you specify truncation of Oracle logs by nightly jobs, truncation occurs according to the deletion policy at the time nightly jobs are scheduled to occur. Conversely, when you elect to manually truncate Oracle logs, a log truncation job queues. If the system is not busy, the job executes immediately and the logs are truncated.
Deletion policies for Oracle log truncation
When configuring log truncation for Oracle database servers, you can choose from one of three deletion policies:
- The Automatic deletion policy truncates all Oracle ARCHIVELOGS stored in the fast_recovery_area folder one time daily when nightly jobs run.
- The Keep newest deletion policy lets you specify the duration of time (n days, weeks, months, or years) to retain the Oracle logs before truncating. When the time period expires, log files past the threshold are then truncated one time daily when nightly jobs run.
- The Keep specified number deletion policy lets you specify a specific number of log files to retain. After that threshold is reached, newer logs are retained, and the older logs are then truncated one time daily when nightly jobs run.
If you need a truncated ARCHIVELOG file, you can obtain it from the latest recovery point captured prior to truncating the logs.
For more information about truncating jobs as a nightly job, see the topic Understanding nightly jobs.
For more information about manually truncating Oracle logs on demand, see Manually truncating Oracle database logs.
This procedure is only appropriate for Oracle database severs protected on your Core.
When protecting an Oracle database in ARCHIVELOG mode, substantial log files accumulate on the local database server. To support the protection of Oracle databases in
Rapid Recovery, you can enable a nightly job to truncate Oracle logs.
|
|
NOTE: Log truncation for Oracle is disabled by default. |
For any protected Oracle server, you can also manually truncate Oracle database logs on demand at any time, as described in this topic. Truncating will delete the logs from the local server. In each recovery point saved to your repository, the database logs persist to reflect the state of the database at the time the backup snapshot was captured.
Complete the steps in this procedure to manually truncate Oracle log files.
- Navigate to the protected Oracle machine in the Rapid Recovery Core Console.
The Summary page displays for the protected machine.
- On the Summary page, scroll down to the Oracle Server Information pane.
- In the table row representing the Oracle database instance for which you want to truncate logs, click the
![[More options]](/technical-documents/image/3372a907-0830-4785-9f31-0f8cf4f66b31)
(More options) drop-down list and select Force Log Truncation.
The Force Log Truncation dialog box displays.
- If you want to delete all of the Oracle logs from the local database server, from the Deletion policy drop-down menu, select Automatic, and then click Force.
A log truncation job queues. If the system is not busy, the job executes immediately and the logs are truncated.
- If you want to delete all of the locally stored logs from the Oracle server (copies of which are stored in the most recent recovery point), do the following:
- From the Deletion policy drop-down menu, select Keep newest.
- In the Keep logs for text field, enter a number, and then from the time period drop-down menu, select the relevant a period of time (days, weeks, months, or years).
- Click Force.
A log truncation job queues. If the system is not busy, the job executes immediately and the logs are truncated.
- If you want to keep a specific number of Oracle log files, and truncate the remaining logs, then do the following:
- From the Deletion policy drop-down menu, select Keep specified number.
- In the Number of archive files text field, enter a number representing the amount of the newest database logs to retain.
- Click Force.
A log truncation job queues. If the system is not busy, the job executes immediately and the logs are truncated.
- If you want to truncate logs for other database instances on this server, repeat step 3 through step 6 for each relevant database listed in the Oracle Server Information pane.
Options specific to Exchange Server and SQL Server appear in the Rapid Recovery Core Console only when an instance of the software and related files are detected on protected servers. In those cases, additional options are available when you select the protected machine in the Core Console.
For example, if you select a protected Exchange server in the left navigation menu, then the menu options that appear for that protected machine include an Exchange drop-down menu option.
If you select a protected SQL server in the left navigation menu, then the menu options that appear for that protected machine include a SQL drop-down menu.
While these options may work differently, there is some commonality. Functions you can accomplish for protected Exchange and SQL servers (and for no other protected machines) include:
- Forcing server log truncation. Both SQL servers and Exchange servers include server logs. The process of truncating SQL logs identifies available space on the server. When you truncate logs for an Exchange server, in addition to identifying the available space, the process frees up more space on the server.
- Setting credentials for the relevant server. Exchange servers allow you to set credentials for the protected machine on the Summary page for the protected server. SQL servers allow you to set credentials for a single protected SQL Server machine, or to set default credentials for all protected SQL servers.
- Viewing status for checks on recovery points from Exchange Server or SQL Server. Recovery points captured from a protected SQL or Exchange server have corresponding color status indicators. These colors indicate the success or failure of various checks relevant for SQL servers or Exchange servers.
This section includes the following topics specific to managing protected machines that use Exchange Server or SQL Server:
In Rapid Recovery, server cluster protection is associated with the Rapid Recovery protected machines installed on individual cluster nodes (that is, individual machines in the cluster) and the Rapid Recovery Core, which protects those machines, all as if they were one composite machine.
You can easily configure a Rapid Recovery Core to protect and manage a cluster. In the Core Console, a cluster is organized as a separate entity, which acts as a container that includes the related nodes. For example, in the left navigation area, under the Protected Machines menu, protected clusters are listed. Directly below each cluster, the associated individual nodes or agent machines appear. Each of these is a protected machine on which the Rapid Recovery Agent software is installed. If you click on the cluster, the Summary page for the cluster appears in the Core Console.
At the Core and cluster levels, you can view information about the cluster, such as the list of related nodes and shared volumes. When showing information for a cluster in the Core Console, you can click Protected Nodes in the top navigation menu to view a summary table of individual nodes in the cluster. From that summary table, for each node, you can perform functions such as forcing a snapshot; performing a one-time export or setting up virtual standby; mounting or viewing recovery points; restoring from a recovery point; converting the cluster node to its own protected machine; or removing the node from protection. If the node is an Exchange or SQL Server, you will also see the option to truncate logs.
At the cluster level, you can also view corresponding Exchange and SQL cluster metadata for the nodes in the cluster. You can specify settings for the entire cluster and the shared volumes in that cluster.
If you click on any node in the cluster from the left navigation menu, the information displayed in the Core Console is specific to that node of the cluster. Here you can view information specific to that node, or configure settings just for that node.
For more information about CSV clusters, see topics "Supported applications and cluster types" and "Support for Cluster-Shared Volumes" in the Rapid Recovery System Requirements Guide.
