)
6. Mount as Real Application Cluster is not supported for RAC One Node database replicas.
7. In Advanced Replication settings, select SP file in the Copy parameter file to RM Server option. The SPfile can be a global SPfile on shared location and not referencing the local SID (RAC instance) or the SPfile of a RAC instance running on the node selected for job creation.
Replication Manager does not support use of init file in Copy parameter file to RM Server option.
Note: Support for Oracle 11g R2 ASM RAC to RAC mount feature on AIX is available from Replication Manager 5.4.4 onwards. For details, refer the EMC Replication Manager Product Guide.
Automatic Storage Management
Automatic Storage Management (ASM) is a logical volume manager introduced as a feature of Oracle 10g. It provides a diskgroup capability for storing Oracle database components. This section of the paper describes how Replication Manager interacts with ASM. In addition to the information provided here, other sections of this paper provide more details about how ASM interacts with Replication Manager restores, mounts, and RAC environments.
Interactions with the production host ASM instance
Just like the database instance manages the database, there is a specialized ASM instance that manages the ASM diskgroups. So, in configurations that include ASM, Replication Manager must communicate to both the database and ASM instances.
Replication Manager communicates with the ASM instance using the same tools that it uses otherwise. OCI calls run queries against common ASM views such as
v$asm_disk and v$asm_diskgroup, and SQL*Plus internal scripts perform operations such as dismounting and remounting certain diskgroups.
The section ASM connection and authentication describes the extra set of credentials that are required for Replication Manager to communicate with the ASM instance.
From there, Replication Manager has the tools to replicate, mount, and restore databases built on ASM diskgroups.
40 EMC Replication Manager Integration with Oracle Database Server Figure 8 The Replication Manager Oracle agent interacts with both database and ASM instances when ASM diskgroups are involved
Using an alternate ORACLE_HOME for ASM
Replication Manager version 5.2 and later support the use of two separate
ORACLE_HOME directories, one for ASM instances and one for Oracle databases if you follow these guidelines:
Prior to version 5.2.3, Replication Manager required the same Oracle operating system user and group for both the database ORACLE_HOME and ASM
ORACLE_HOME. Replication Manager version 5.2.3 and later support a separate operating system user and group to access the database ORACLE_HOME and ASM ORACLE_HOME on UNIX and Linux platforms.
The environment must list the ASM instance explicitly in the /etc/oratab file.
On Linux platforms, if you plan to mount a Real Application Cluster, dual home
environments are allowed. Prior to version 5.3.1, the OS user on the target RAC had to be the same for ASM and Oracle databases. With version 5.3.1 and later, this
restriction has been removed.
Limitations
There is a list of special considerations to keep in mind when implementing Replication Manager in ASM environments.
Note: Replication Manager does not support ASM on Windows platforms at this time.
Raw disks only on UNIX platforms
Replication Manager supports the replication and handling of ASM diskgroups when those diskgroups are created using exclusively raw disks. The use of raw volumes managed by third-party or native LVMs as source disks to create ASM diskgroups is
41 EMC Replication Manager Integration with Oracle Database Server not supported by Replication Manager. For Linux platforms specifically, the use of
ASMlib disks is supported and recommended as of Replication Manager 5.1 SP2.
No character device file
Replication Manager does not support the use of character files created manually using commands such as mknod as a means to identify a disk and subsequently map ASM diskgroups to that disk. An example is /usr/asm/mydisks/disk1 where disk1 is a character file defining a disk by using its minor and major number. This method is not compatible with the current model that Replication Manager uses to map ASM diskgroups.
# cd /usr/asm/mydisks
# mknod disk1 c 32 20
# ls -l /usr/asm/mydisks
crw-r--r-- 1 root other 32, 20 May 7 07:50 disk1
The use of the ASMlib driver and creation of ASMlib disks (that is. ORCL:VOL1) to use with ASM is supported and recommended as of Replication Manager 5.1 SP2. The use of raw disks with ASM in the following way is also supported.
For example on Linux: /dev/raw/raw1 Or on Solaris: /dev/rdsk/c5t6d36s6 ASMlib driver support on Linux platforms
ASMlib is a driver for the Linux platforms that allows user-friendly configuration and management of volumes that can be presented to ASM on which it can create
diskgroups. Instead of binding character raw devices to block devices like /dev/sdb1, use ASMlib to create ORCL:MYVOL1 on /dev/sdb1 and have ASM address this disk as such.
ASMlib version 2.0 and later come with an "oracleasm" script that, given the
corresponding arguments, can perform operations such as listing ASMlib volumes, labeling new ASMlib volumes, renaming volumes, querying for the corresponding block device from an ASMlib volume, and so on. Replication Manager has integrated calls to that aforementioned script to perform basic operations that must occur to allow replications, restores, and mounts of Oracle databases built on ASM diskgroups using the ASMlib driver (Replication Manager 5.1 SP2).
The following sections give additional details on various aspects of the ASMlib integration:
ASMlib volumes are renamed during mount ASMlib volumes are renamed during restore Production host ASMlib volumes clobbering
42 EMC Replication Manager Integration with Oracle Database Server
External mirroring
Because Replication Manager is tightly integrated with the array replication
technologies and those rely on a precise understanding of which LUNs are involved in a particular replication operation, Replication Manager cannot support ASM
diskgroups that use normal or high redundancy.
Active ASM disks within a diskgroup can be very volatile in setups where normal or high redundancy is used. That makes it difficult for Replication Manager to replicate those diskgroups as units.
Figure 9 shows an ASM diskgroup made of disk1, disk2, and disk3. The diskgroup is using normal redundancy, which means there is one mirror disk for each disk. In this scenario, disk2 has failed and disk2' is rebalancing its extents with disk1 and disk3.
The diskgroup at this point is actively represented by disk 1, disk2', and disk3.
Replication Manager cannot support this configuration because it would be
replicating the diskgroup at the disk level and in this case targeting disk1, 2 and 3, thus creating a bad copy of the ASM diskgroup since disk 2 is suddenly faulty.
Figure 9 Normal redundancy ASM diskgroup with one failed disk Replication of ASM diskgroups
This section describes issues to be aware of when replicating ASM diskgroups using Replication Manager.
Discovering ASM diskgroups
When the database is stored on ASM diskgroups, the Oracle agent performs an additional mapping in order to decompose a diskgroup into disks that can be
replicated. It uses OCI to query the ASM instance to map the diskgroups to the disks.
For example, on Linux, +DG1 might map to ORCL:Vol1, ORCL:Vol2 and ORCL:Vol3.
These volumes further correspond to LUNs on the array (one-to-one mapping).
D
43 EMC Replication Manager Integration with Oracle Database Server Rebalancing issues
Rebalancing is a very important ASM feature that consists of constantly redistributing data extents within a given ASM diskgroup, across all the disks of the diskgroup, in order to optimize load on the different disks.
Replications of ASM-based Oracle databases should use the consistent split option.
Thanks to the array level I/O consistency, the rebalancing of extents from one disk to another never causes an inconsistency within a diskgroup as all the I/Os will be frozen at the same time during a split operation.
When not using the consistent split option, the Replication Manager Oracle agent performs an additional step to counter the fact that I/O consistency is not ensured at the array level. The agent sets the rebalancing power to 0 before the split and
monitors the rebalancing activity surrounding the involved diskgroups. Replication proceeds when the rebalancing activity has stopped, the non-consistent split occurs across the disks of the diskgoup, and the rebalancing power gets reset to the default after the split is complete.
While this greatly minimizes the chances of I/O consistency problems, the non-consistent split solution is not guaranteed to maintain consistency under all
circumstances, as a rebalancing operation may occur anyway, when initiated outside of Replication Manager, or if a disk is added to the diskgroup. For this reason, the consistent split method is highly recommended.
Figure 10 ASM diskgroup with data extents being redistributed from disk1 to disk2 to disk3