No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OceanStor BCManager 6.5.0 eReplication User Guide 02

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Oracle

Oracle

This section introduces the DR restrictions for Oracle protected objects.

You must comply with version restrictions when implementing DR for a protected object supported by eReplication. Read description in Table 1-8 before implementing DR for an Oracle database protected object.
Table 1-8  DR restrictions for Oracle databases

Object

Restriction

Compatibility

  • Supported Oracle versions include 10.1, 10.2, 11.1, 11.2, 12.1, and 12.2.
  • Supported host operating systems include Windows, SUSE Linux, Red Hat Linux, AIX, HP-UX, and Oracle Linux, and Solaris.
  • A single host and clusters are both supported. Cluster types can be Oracle RAC, VCS, RHCS, PowerHA, ServiceGuard, and SUNCluster but cannot be PowerHA+RAC or ServiceGuard+RAC.
  • The Policy Managed policy of the Oracle RAC cluster cannot be used to manage the databases.
  • In the DR Star network scenario, when you create an Oracle protected group, only the storage with DR Star is supported (V3 series V500R007C20 and later versions, Dorado series V300R002C00 and later versions).
For details about Oracle compatibility, see the OceanStor BCManager 6.5.0 eReplication Compatibility List.

Recovery modes

  • Recovery can be performed from one standalone Oracle database to another. It means that both the production and the DR databases are standalone.

    For the Oracle database deployed on ASM, you can perform a data test on and mount copies to only one database at the production end. The operations can be performed on the next database only when you delete the data and unmount the copies from the database at the DR site.

  • Recovery can be performed from an Oracle cluster to a standalone Oracle database. It means that the production database is deployed in a cluster and the DR database is standalone.

    If Oracle RHCS cluster is used and logical volumes are managed in CLVM, the recovery from an Oracle RHCS cluster to a standalone Oracle database is not supported.

    For the Oracle database deployed on ASM, you can perform a data test on and mount copies to only one database at the production end. The operations can be performed on the next database only when you delete the data and unmount the copies from the database at the DR site.

  • Recovery can be performed from one Oracle cluster to another. It means that both the production and the DR databases are deployed in a cluster. The number of nodes at the production and DR sites can be different. For example, the database at the DR site can be deployed in a single-node cluster.

    For the Oracle database deployed on ASM, you can perform a data test on and mount copies to only one database at the production end. The operations can be performed on the next database only when you delete the data and unmount the copies from the database at the DR site.

  • Recovery can be performed from a standalone Oracle database to a cluster only after DR reprotection and databases in the protected group cannot be added or removed after the DR reprotection.

Recovery operations

  • Active-passive DR solution
    • The solution based on asynchronous replication (VIS) does not support reprotection.
    • The solution based on mirroring (VIS) and asynchronous replication (SAN) does not support reprotection.
  • Geo-redundant solution
    • In the solution based on cascading replication (synchronous and asynchronous) or parallel replication (synchronous and asynchronous), when services are switched over to the remote DR site, reprotection cannot be implemented.
    • In the solution based on cascading replication (asynchronous and asynchronous), when services are switched over to the remote DR site, reprotection cannot be implemented.
    • In the solution based on active-active (VIS) and asynchronous replication (SAN), when services are switched over to the remote DR site, reprotection cannot be implemented.

Database files

DR protection can be implemented for data files, log files, and control files. The requirements are as follows:
  • All files must be deployed on the same Huawei storage device and on a file system, a raw disk, or an ASM disk. Hybrid deployment is not allowed.
  • Deploying data files, control files, and online log files on a local file system or a raw disk are not supported.
  • In a array-based replication protection scenario, if multiple remote replications are created for all storage resources used by files, it is recommended that all these remote replications be configured in the same replication consistency group. In the DR Star network scenario, all protected files are required to be configured in one DR Star.

Archive logs

DR protection can be implemented for archive logs. However, protected archive logs will not be used to recover databases automatically. The requirements are as follows:
  • Only when the hot backup mode is enabled, DR protection for archive logs is supported.
  • Archive logs cannot be deployed on non-Huawei storage devices. Archive logs cannot be deployed on a local file system or a shared file system.
  • In a cluster scenario, the names of the archive log directories for different database instances on a node must be the same but the LUNs where these directories reside can be different.
  • Deploying data files, control files, and online log files on a local file system or a raw disk while deploying archive logs in an ASM disk group is not supported.
  • When archive logs are deployed on a shared storage device with data files, control files, online log files, protection for archive logs cannot be enabled. In this scenario, the system protects archive logs automatically.
  • If you want to enable protection for archive logs, archive logs, data files, control files, and online log files must be configured on different LUNs. In the DR Star network scenario, all protected files must be configured in different DR Stars.

Others

  • DR protection cannot be implemented for parameter files or flicker areas.
  • DR protection cannot be implemented for Oracle Cluster Register (OCR) or voting disks in Oracle RAC scenarios.
  • Configuring multiple Oracle databases in the same Logical Volume Manager (LVM) volume group is not supported.
  • All pluggable database (PDB)s of Oracle 12c container databases must be in the same protected group.
  • The user installing Oracle must be user oracle.
  • In Oracle 11gR2 or later, the user installing Grid must be user grid.
  • Do not delete the alert log file.
    NOTE:
    • The format of the alert log file is alert_instance name.log.
    • Run the sqlplus command to log in to the database, and then run the show parameter background_dump_dest command to view the archive directory of the alert log file.
  • In the Oracle RAC cluster scenario, when the copies at the database is rolled back, all databases in the RAC cluster must be placed in the same protected group.
Translation
Download
Updated: 2019-05-21

Document ID: EDOC1100075861

Views: 14595

Downloads: 70

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next