Creating a Protected Group for Oracle Databases

Prerequisites

• At least one production site has been created.
• Hosts or host groups and storage devices for host applications have been added to the production site.

Context

The protected objects belonging to one protected group reside on the same storage device. Each protected object occupies independent storage LUNs or volumes.

• If multiple applications are deployed on one remote replication primary LUN or consistency group primary LUN, ensure that all the applications belong to one protected group. If they belong to different protected groups, some applications may become unavailable during data synchronization, planned migration, or fault recovery of protected groups.
• When I/O loads of applications are heavy, consistency protection with quiesced databases enabled may fail. Therefore, implement consistency protection for applications during off-peak hours or disable consistency protection.
• If eReplication Agentless is reinstalled after it is uninstalled from a host, you need to create a protected group for the host after eReplication Agentless is installed.

Procedure

1. In the menu bar, choose Protection.
2. Click Create.
3. Select a protected object type.
   1. Set Production Site and Production Host(Group).
   2. In the Available Database area, select a database to be protected.
   3. In the Verification dialog box that is displayed, enter necessary authentication information and click OK.

      Authentication mode: You need to set Authentication Mode. You can select Database Authentication or OS Authentication.

      • Database Authentication: based on an Oracle database user name.

        Enter the sys user name and its password as the authentication information. If you use another user name for authentication, the database cannot be started when you recover or test it.

      • OS Authentication: based on an operating system user name.
      

      For a single-instance database or Oracle RAC cluster deployed on ASM disk groups, you need to enable OS Authentication for the DR database as required by Oracle officially. After data is recovered, select Database Authentication for security purposes.

   4. In the Archive Log Protection list of the Available Database area, set whether to enable protection for archive logs.

      Archive logs record all operations on the databases. They are used to recover data of Oracle databases that are abnormally stopped, maximizing data security.

      

      • If the archive log mode is enabled for the Oracle database and Archive Log Protection is disabled for the database, disable the archive log mode or configure an archive directory for the database at the DR site. Otherwise, the database cannot be started during DR.
      • If the second-level period-based scheduling is used, enabling Archive Log Protection does not take effect.

4. Click Next.
5. Set a protection policy.

   The system automatically matches supported protection policies. Select a policy based on your data protection solution.

   Click Settings. In the Set Protection Policy dialog box, set the protection policy.

   For the ADGx synchronous replication (SAN) protection policy:

   1. In the Protection Policy area, click Set to set the protection policy for the protected group.

   2. Click the Replication Policy tab to set the remote replicate rate between storage arrays. Table 1 lists related parameters.
      

      Table 1 Replication policies

      Replication Policy	Description
      Default configuration	The remote replication rate is the default one set on the storage array.
      Manual configuration	Users can set the remote replication rate for each time segment. Configure the automatic remote replication rate of the storage based on the pre-set replication rate of time period. Select Manual configuration. Click a time color block to modify the replication rate during a time segment.

   3. (Optional) In the Expected RPO area, select Enable RPO Requirement Satisfaction Check. The actual RPO will be checked against the configured RPO. If the actual RPO exceeds the expected RPO, the system generates an alarm, indicating that the RPO requirement is not satisfied.

      Expected RPO can be set to 0 to 31 days, 0 to 23 hours, 0 to 59 minutes, and 0 to 59 seconds.

      

      • Generally, RPO indicates the latency in transferring the latest log file from the active database to the standby database.
      • If the LGWR/Async mode is used and the standby redo log real-time application is configured, RPO indicates the log application latency. If the data volume of the active database is large, the application of standby redo log may be delayed after the data is synchronized to the standby database.
      • After creating a protected group, click the created protected group and click the Abstract tab to view the actual and expected RPO values.
   4. Click OK.

6. Click Next.
7. Set Name and Description of the protected group.
   • Name: contains 4 to 32 characters, including letters, digits, underscores (_), and hyphens (-), but cannot start with a hyphen (-).
   • Description: contains 0 to 255 characters.

8. Optional: If you do not want to manually create a recovery plan for the protected group, select Automatically create a recovery plan after creating protected groups in the lower left corner.
9. Click Finish.
10. Click OK.

Related Operations

• If the protected objects of a protected group or their used storage devices change, on the menu bar, select Resources. Refresh resources or storage devices where the protected objects reside. Then go to the protected group page and refresh protected objects of the protected group by clicking More > Refresh. After the command for refreshing information is sent, you can view details about the command execution in Background Task.
  

  If a recovery plan has been created for a protected group, you can refresh protected objects only when the recovery plan status is Ready, Clearing completed, or Reprotection completed.

• Information about storage devices and hosts must be refreshed both at the production and DR ends where the protected group resides to ensure that information about the protected group is refreshed successfully.