立即与支持人员聊天
与支持团队交流

Rapid Recovery 6.6 - User Guide

Introduction to Rapid Recovery The Core Console Repositories Core settings Protecting machines
About protecting machines with Rapid Recovery Understanding the Rapid Recovery Agent software installer Deploying Agent to multiple machines simultaneously from the Core Console Using the Deploy Agent Software Wizard to deploy to one or more machines Modifying deploy settings Understanding protection schedules Protecting a machine About protecting multiple machines Enabling application support Settings and functions for protected Exchange servers Settings and functions for protected SQL servers
Managing protected machines Snapshots and recovery points Managing privacy Encryption Credentials Vault Replication Events Reporting VM export Restoring data Bare metal restore
About bare metal restore Differences in bare metal restore for Windows and Linux machines Understanding boot CD creation for Windows machines Managing a Linux boot image Performing a bare metal restore using the Restore Machine Wizard Using the Universal Recovery Console for a BMR Performing a bare metal restore for Linux machines Verifying a bare metal restore
Managing aging data Archiving Cloud accounts Core Console references REST APIs Glossary

About protecting Oracle database servers

Rapid Recovery includes application support of Agent-based protection of Oracle 12c and oracle 18c relational database management systems (RDBMS). You can protect an Oracle database server and all of its databases, and perform related tasks.

In this release, the following restrictions apply:

  • Oracle 12c and Oracle 18c are the only tested and supported versions for protection on the Rapid Recovery Core. Use any other Oracle versions at your own risk.
  • Protected Oracle database servers must run 64-bit versions of Windows Server 2012 R2or Windows Server 2016.
  • You must install the Rapid Recovery Agent software (release 6.2 or later) on your Oracle server. Agentless protection is planned for a future release.
  • Protection of Oracle 12c and Oracle 18c databases is limited to using Volume Snapshot Service (VSS) in the ARCHIVELOG mode.

NOTE: Support for NOARCHIVELOG (the default Oracle database log mode) is planned for a future release. Oracle databases with ARCHIVELOG mode enabled must also be set to archive all online redo logs using the ARCH (archive) process. A database administrator (DBA) can change the mode and set archiving of redo logs using Oracle SQL*Plus or Oracle Enterprise Manager. For more information about enabling ARCHIVELOG mode and archiving, see Oracle documentation or consult a qualified Oracle 12c or 18c DBA.

To fully protect Oracle servers, perform the following tasks:

  • Install the Rapid Recovery Agent software (release 6.2 or later) on your Oracle server and begin protection. Use the Protect Machine Wizard to locate the Oracle server on your network, deploy the Agent software, and establish a protection schedule. For more information, see About protecting machines with Rapid Recovery.
  • Enter credentials for each database in the Rapid Recovery Core Console. The Core securely caches your credentials and lets you access the metadata from the UI. Before you enter credentials, you cannot view details for databases on your protected Oracle server. For more information, see Entering or editing credentials for Oracle databases.
  • Enable ARCHIVELOG mode for the protected Oracle server, and verify the Oracle VSS writer, from the Core Console. For more information, see Enabling archive log mode and adding VSS writer for protected Oracle databases.
  • Review log truncation deletion policies offered in Rapid Recovery Core and implement a log truncation regime. When an Oracle database is set to ARCHIVELOG mode, the logs accumulate quickly and consume substantial disk space. You can truncate Oracle logs manually on demand, or configure automatic log truncation using the "Log truncation for Oracle" nightly job. Both methods offer the same Deletion policies for Oracle log truncation. To avoid eventual errors and snapshot failures when storage for the logs is full, implement a consistent approach for managing Oracle logs. For more information, see About truncating Oracle logs.

    You can also truncate Oracle database logs manually on demand. For more information about this procedure, see Manually truncating Oracle database logs.

Once you install the Agent, protect the machine in your Core, and configure settings properly, you can do the following:

  • View metadata. From the protected machine Summary page, you can view metadata about each database on your Oracle server, including connection and status for each log file, control file and data file.
  • Check database integrity. You can perform integrity checks from the Core Console using the DBVERIFY utility.
  • Truncate archive logs, using one of three deletion policies.
  • Restore databases. Restore entire volumes, or volumes that contain selected databases. Once you enable Archive log mode, snapshots of the Oracle database are crash-consistent from the point of view of the Oracle service.
  • Perform virtual export. You can make a one-time export, or set up a virtual standby VM that continually updates a VM with new information as backups on your protected database are captured.

    If you boot up a VM of an Oracle database, you may have to manually start the database services, and manually disable backup mode for database data files.

Entering or editing credentials for Oracle databases

Before performing this procedure, you must first add an Oracle database server to protection on your Core.

To enter or edit Oracle database credentials:

  • The Windows user account of the Rapid Recovery user performing this procedure must have SYSDBA privileges on the protected database server.
  • The database must be accessible to the Rapid Recovery Core server, and a connection must be successfully established.

NOTE: SYSDBA is an Oracle systems database administrative privilege required to perform high-level administrative operations. These functions include creating, starting up, shutting down, backing up, or recovering an Oracle database.

After protecting your Oracle database server, you cannot access database metadata or view database details until you enter credentials for each database. This one-time step caches your database credentials securely and provides the Core Console with access to status information about all protected transaction log files, control files, and data files that comprise your Oracle databases.

For example, on the Summary page for the protected Oracle machine, before entering credentials, you cannot expand details about any of the protected databases in the Oracle Server Information pane.

NOTE: This is a one-time step required for each new protected Oracle database.

Complete the steps in this procedure to provide the Rapid Recovery Core Console with access to the required metadata for your protected Oracle databases.

  1. Navigate to the protected Oracle machine in the Rapid Recovery Core Console.
    The Summary page displays for the protected machine.
  2. On the Summary page, scroll down to the Oracle Server Information pane.
  3. For the first database in the table, click the [More options] (More options) drop-down list and select Edit Credentials.
    The Edit Instance Credentials dialog box displays.
  4. Two connection types are supported: basic, and Transparent Network Substrate (TNS, a proprietary Oracle networking technology). Do one of the following:
    • To connect using a basic connection, enter the information in the following table:
    Option Description
    Connection Type Basic
    Host Name Enter the host name or IP address.
    Port Enter the appropriate port. The default port open for this purpose is 1521.
    SID or Service Name Select the appropriate connection method. You can use one of the following:
    • SID. The Oracle System Identifier (SID) is a unique ID that uniquely identifies your database instance.
    • Service Name. The service name is the TNS alias used to remotely connect to your database.

    NOTE: The service name can be found in the TNSNAMES.ORA file.

    Service Name The service name is the TNS alias that you give when you remotely connect to your database and this Service
    • To connect using TNS, enter the information in the following table:
      Option Description
      Connection Type TNS
      Network Alias Select this drop-down menu to view database aliases available to the network, and select the appropriate alias.
  5. Two credential types are supported: Oracle, and Operating System. Do one of the following:
    • To connect with Oracle credentials, enter the user name and password for the Oracle database in the relevant text fields.

      NOTE: Your Windows user account must have SYSDBA privileges.

    • To connect using cached credentials from the operating system, select Operating System.

      NOTE: Your Windows user account must be a member of the ORA_DBA local group, which ensures the user has SYSDBA privileges.

  6. To verify credentials, click Verify.
    A dialog box displays, indicating if the test connection was successful.
  7. Do one of the following:
    • If the verification succeeded, click OK to close the message dialog box.
    • If not successful, close the dialog box and revise the instance credentials until connection is verified. Consult your system administrator if you have questions about credentials.
  8. In the Edit Instance Credentials dialog box, after successful verification, click OK.
    The dialog box closes, and Rapid Recovery Core Console immediately applies and caches the credentials. Very soon afterward, metadata is available in the Core Console, and the status indicator for the selected database displays a green (online) status.
  9. Repeat step 3 through step 8 for each database listed in the Oracle Server Information pane.

After entering and caching credentials for all databases on this protected Oracle machine, perform the procedures described in the topic Enabling archive log mode and adding VSS writer for protected Oracle databases.

Enabling archive log mode and adding VSS writer for protected Oracle databases

Before performing this procedure, you must first add an Oracle database server to protection on your Core, and enter credentials for each database into the Core Console.

Database applications require the presence of a combination of specific files (such as configuration, log, and control files), each set to a specific state, to be able application-consistent. In Rapid Recovery Core release 6.2 and later, Oracle databases require archive log mode to be enabled. Until you perform this procedure, your snapshots of the database server will be crash-consistent, but not application-consistent.

Oracle VSS writer captures snapshots using Volume Snapshot Service. This writer must be enabled.

NOTE: These are one-time steps required for each new protected Oracle database.

Complete the steps in this procedure to verify if archive log mode is enabled; to enable that mode if required; and to add VSS writer to your Core.

  1. Navigate to the protected Oracle machine in the Rapid Recovery Core Console.
    The Summary page displays for the protected machine.
  2. On the Summary page, scroll down to the Oracle Server Information pane.
  3. In the Oracle Server Information pane, if you see a warning notification that archive log mode is disabled, click Enable archive log mode for these databases and then click to confirm restart of the database instances.

    NOTE: Enabling archive mode causes the relevant database instances to restart. This could take a few minutes.

  4. In the Oracle Server Information pane, if you see a warning notification that the Oracle VSS writer is excluded from snapshots, click Include Oracle VSS Writer and then click to confirm.
    The warning message closes, and the VSS writer is added to your Core.
  5. Optionally, you can track the progress towards enabling archive log mode or adding a VSS writer. For more information, see Viewing tasks.

About truncating Oracle logs

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.

  1. 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.
  2. 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.
  3. 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.

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级