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).
IBM DB2

IBM DB2

This section describes the disaster recovery (DR) restrictions and limits for IBM DB2 protected objects.

DR for IBM DB2 protected objects can be conducted only when related version requirements are met. Before starting DR for an IBM DB2 database protected object, read version restrictions and limits listed in Table 1-9.
Table 1-9  DR restrictions and limits for IBM DB2 databases

Object

Restrictions and Limits

Compatibility

  • IBM DB2 versions: DB2 V9.1, DB2 V9.5, DB2 V9.7, and DB2 V10.1
  • IBM DB2 operating system: AIX, RedHat Linux, and HP-UX
  • DR for IBM DB2 protected objects is applicable to both standalone nodes and VCS/PowerHA/RHCS/ServiceGuard clusters. For VCS clusters, it is applicable to only failover clusters, and inapplicable to parallel processing clusters and hybrid clusters.
  • In the DR Star network scenario, when you create an DB2 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 IBM DB2 compatibility, see the OceanStor BCManager 6.5.0 eReplication Compatibility List.

Recovery modes

  • Recovery can be performed from one standalone IBM DB2 database to another. It means that both the production and the DR databases are deployed in standalone mode.
  • Recovery can be performed from an IBM DB2 cluster to a standalone IBM DB2 database. It means that the production database is deployed in a cluster and the DR database is deployed in standalone mode.

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

  • Recovery can be performed from one IBM DB2 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.
  • Recovery can be performed from a standalone IBM DB2 database to a cluster only after DR reprotection. In addition, after the DR reprotection, databases in the protected group cannot be added or removed.

Recovery operations

  • The active-passive DR solution based on mirroring (VIS) and asynchronous replication (SAN) does not support reprotection.
  • In the geo-redundant solution based on cascading replication (synchronous and asynchronous) or parallel replication (synchronous and asynchronous), reprotection cannot be implemented after services are switched over to the remote DR site.
  • In the geo-redundant solution based on cascading replication (asynchronous and asynchronous), reprotection cannot be implemented after services are switched over to the remote DR site.
  • In local protection solution based on clone (SAN), clones can be used only for data test or verification, not for recovery.

Database files

DR protection can be implemented for data files, online log files, and control files, when the following requirements are met:
  • All files are deployed on the same Huawei storage device.
  • 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.

Others

  • In a DB2 VCS/RHCS cluster, multiple databases of an instance must belong to one service group.
  • In a DB2 PowerHA cluster, multiple databases of an instance must belong to one resource group.
  • In a DB2 Serviceguard cluster, multiple databases of an instance must belong to one package.
  • The instance directories of DB2 database users must be installed on local disks or independent storage devices.
  • In a DB2 VCS cluster, no more than one database can be created in a logical volume manager (LVM) volume group (VG).
  • The DB2 databases on a host must belong to a same instance.
Translation
Download
Updated: 2019-05-21

Document ID: EDOC1100075861

Views: 10659

Downloads: 55

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