Oracle

Before configuring disaster recovery (DR) services, check the database environments of the production end and the DR end where Oracle databases reside, and the storage end environment. If the database environments do not meet requirements, modify database configurations.

Production End and DR End

The following configuration items must be checked and configured on databases at both the production and DR ends.

When the Oracle RHCS is used at the production end and the logical volume is managed in CLVM, the standalone deployment mode is not supported at the DR end.

If the host runs AIX and the user runs the rendev command to change the name of a physical volume at the production end to start with /dev/hdisk, the name of the device in the DR end may change after DR testing, planned migration, or fault recovery.

When an Oracle database runs Windows, check whether the password of the Oracle database meets the following requirement:
A password contains only letters, digits, tildes (~), underscores (_), hyphens (-), pounds (#), dollar signs ($), and asterisks (*).
When the host where an Oracle database resides runs Linux, AIX, or HP-UX, the mount points of the file system used by the database cannot be nested. For example, mount points /testdb/ and /testdb/database1/ are nested.
When a database environment is configured at the production end where hosts running Red Hat Linux are deployed and the hosts are connected to storage arrays through Fibre Channel links, check whether systool is installed on the production host and DR host.
Run the rpm -qa | grep sysfsutil command to check whether the systool software has been installed on the host.
- If the command output contains sysfsutils, for example, sysfsutils-2.0.0-6, the systool software has been installed on the host.
- If the command output does not contain sysfsutils the systool software is not installed on the host. In this case, obtain the sysfsutils software package from the installation CD-ROM of Red Hat Linux.
RedHat Linux 6.3 for x86_64 and the sysfsutils software package sysfsutils-2.1.0-6.1.el6.x86_64.rpm are used as examples. The installation command is subject to the actual environment.

Check and configure environment variables of the databases.

The eReplication Agent starts to protect the data consistency of an Oracle database only after you have configured environment variables for the Oracle database. Configure environment variables prior to the installation of the eReplication Agent. Otherwise, restart the eReplication Agent after you configure environment variables to make them effective.

To configure environment variables for an Oracle database in Windows, perform the following steps:
1. Log in to the the application server as a user with the administrator rights.
2. Check whether environment variables have been configured.
  Right-click My Computer and choose Properties from the drop-down list. On the Advanced tab page, click Environment Variables. If environment variables have been configured, a dialog box similar to Figure 1 is displayed. Check whether the PATH variable is the bin directory of the Oracle database.
  
  Figure 1 Environment variables

To configure environment variables for an Oracle database running a non-Windows operating system, perform the following steps:

The following uses the Oracle 12gR1 database as an example to describe how to configure environment variables in Linux. Log in to the application server as user root.
Run the su - oracle command to switch to user oracle.
Run the echo $ORACLE_BASE command to ensure that ORACLE_BASE has been configured.
```
oracle@linux:~> echo $ORACLE_BASE  
/u01/app/oracle
```
Run the echo $ORACLE_HOME command to ensure that ORACLE_HOME has been configured.
```
oracle@linux:~> echo $ORACLE_HOME  
/u01/app/oracle/product/12.1.0/dbhome_1
```

Run the echo $PATH command to ensure that ORACLE_HOME/bin has been added in the PATH variable.

oracle@linux:~> echo $PATH /u01/app/oracle/product/12.1.0/dbhome_1/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin

Run the exit command to log user oracle out.
Run the su - grid command to switch to user grid.
Run the echo $ORACLE_HOME command to ensure that ORACLE_HOME has been configured.
```
grid@linux:~> echo $ORACLE_HOME  
/u01/app/12.1.0/grid/
```
In Oracle 11g R2 or 12c, ORACLE_HOME must be configured in the environment variables of user grid.

Run the echo $PATH command to ensure that ORACLE_HOME/bin has been added in the PATH variable.

grid@linux:~> echo $PATH /u01/app/12.1.0/grid//bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin

Run the exit command to log user grid out.
Run the su - rdadmin command to switch to user rdadmin.

Run the echo $SHELL command to view the default shell type of user rdadmin.

The shell type can be bash, ksh, or csh. Table 1 describes configuration files that need to be modified based on shell types of operating systems.

Before configuring environment variables, check the default shell type of user rdadmin on the eReplication Agent. If the shell type is bash, modify the .profile or .bash_profile file under the rdadmin home directory. If the shell type is csh, modify the . cshrc file under the rdadmin home directory. This document describes how to modify the .profile file when the shell type is bash.

**Table 1** Configuration files that need to be modified for different shell types of operating systems
Operating System	Shell Type	Configuration File	Configuration Approach
Linux	sh/bash (default, recommended)	SUSE/Rocky: .profile Redhat: .bash_profile	export name=value
	csh	.cshrc	setenv name value
	ksh	.profile	export name=value
AIX/Solaris	sh/ksh (default, recommended)	.profile	export name=value
	csh	.cshrc	setenv name value
	bash	.profile	export name=value
HP-UX	sh/POSIX Shell (default, recommended)	.profile	export name=value
	csh	.cshrc	setenv name value
	ksh	.profile	export name=value
	bash	.profile	export name=value

Run the vi ~/.profile command to open the .profile file in the rdadmin home directory.
Press i to enter the editing mode and edit the .profile file.

Add the following content to the .profile file. Table 2 describes the related parameters.

ORA_CRS_HOME=/opt/oracle/product/10g/cluster 
PATH=$PATH:/bin:/sbin:/usr/sbin  
export ORA_CRS_HOME PATH

**Table 2** System variables
Name	Value	Description
ORA_CRS_HOME	/opt/oracle/product/10g/cluster	Indicates the installation directory for the CRS software of an Oracle database. This environment variable needs to be configured only when the version of the RAC environment is earlier than Oracle 11g R2 and Clusterware has been installed.
PATH	PATH=$PATH:/bin:/sbin:/usr/sbin	Indicates the command directory of the operating system on the host where the Oracle database resides.

After you have modified the file, press Esc and enter :wq! to save the changes and close the file.

If the host where the Oracle database resides runs Linux, check the disk mapping mode using udev.
When udev is used to map disks, the restrictions on disk mapping modes are as follows:
- Disks can only be mapped through disk partitioning.
- When udev is used to map ASM disks, use udev disks to serve as the member disks of the ASM disk group.
- The udev configuration rules at the production and DR ends must be in the 99-oracle-asmdevices.rules rule file (save path: /etc/udev/rules.d).
  Two mapping modes are available. The following uses SUSE Linux 10 (disks asm1 and asm2 involved) as an example to describe how to configure both mapping modes:
  - Renaming disks
```
KERNEL=="sd*1", BUS=="scsi", PROGRAM=="/sbin/scsi_id 
-g -u -s /block/$parent", RESULT=="36200bc71001f375519f5d2c0000000f9", 
NAME="asm1", OWNER="oracle",  GROUP="dba", MODE="0660"
```
  - Creating disk links
```
KERNEL=="sd*1", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s /block/$parent", 
RESULT=="36200bc71001f375519f5d2c0000000f9", SYMLINK+="asm1", OWNER="oracle",GROUP="dba", MODE="0660"
```
    The KERNEL parameter must be specified using wildcards (for example, KERNEL=="sd*1") and cannot be a fixed device partition name (for example: KERNEL="sda"). Otherwise, udev configuration rules cannot take effect.

Check the authentication mode of the database.

During the creation of the Oracle protected group, you can specify different authentication modes for different protected objects and RAC hosts. Currently, database authentication and operating system authentication are supported. Table 3 describes the configuration details.

**Table 3** Configuration requirements for authentication modes
Authentication Mode	Requirements
Database authentication	Authentication modes at the production and DR ends must be the same.
	In a cluster, authentication modes of all hosts must be the same.
	In a protected group, authentication modes of protected objects must be the same.
	During protected group creation, authentication mode specified on the eReplication must be the same as that used by the database.
Operating system authentication	In an Oracle RAC cluster deployed on ASM, the operating system authentication must be enabled so that the cluster at the DR end can be started normally upon DR.
Operating system authentication	For Oracle single-instance databases deployed on ASM, the following requirements must be met: For Unix-like operating systems, operating system authentication must be enabled if the password files of Oracle databases are configured to save in the ASM disk group, operating system authentication must be enabled. Alternatively, you can save the password files on the local file system. if neither method is adopted, the recovery plan corresponding to the Oracle protected group cannot be executed for testing, planning migration, and fault recovery. For Windows, operating system authentication must be enabled. Otherwise, the recovery plan corresponding to the Oracle protected group cannot be executed for testing, planned migration, and fault recovery.

Production End

Check the running mode of databases at the production end.
The eReplication Agent can ensure consistency between Oracle databases only when the databases are running in archive mode. Perform the following steps to check the operation mode of a database.
- To configure the running mode of an Oracle database in Windows, perform the following steps:
  1. Run the sqlplus command to log in to the Oracle database. In the example provided here, the user name is sys, the password is abc, and the instance name is db01.
    The following shows the command format and output:
```
C:\Documents and Settings\Administrator>sqlplus /nolog 
 
SQL*Plus: Release 10.2.0.1.0 - Production on Thu Jun 3 26 18:09:00 2020 
 
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved. 
 
SQL> conn sys/abc@db01 as sysdba 
Connected.
```
  2. Run the archive log list command to check whether the database is in archive mode.
    The following shows the command format and output:
```
SQL> archive log list; 
Database log mode            No Archive Mode 
Automatic archival           Enabled 
Archive destination          G:\oracle10g\product\10.2.0\db_1\RDBMS 
Oldest online log sequence 7 
Current log sequence         9     
```
    If Database log mode is Archive Mode, the database is in archive mode.
    If Database log mode is No Archive Mode, follow instructions in related Oracle database documents to change the operation mode to archive.
- To configure the running mode of an Oracle database running a non-Windows operating system, perform the following steps:
  1. Run the sqlplus command to log in to the Oracle database. In the example provided here, the user name is sys, the password is oracle, and the instance name is verify.
    The following shows the command format and output:
```
[oracle@rhcs218 ~]$ sqlplus /nolog 
 
SQL*Plus: Release 11.2.0.3.0 - Production on Fri Jun 26 10:30:34 2020 
 
Copyright (c) 1982, 2002, Oracle.  All rights reserved. 
 
SQL> conn sys/oracle@verify as sysdba 
Connected.
```
  2. Run the archive log list command to check whether the database is in archive mode.
    The following shows the command format and output:
```
SQL> archive log list; 
Database log mode             No Archive Mode 
Automatic archival            Enabled 
Archive destination           /oracle/archive 
Oldest online log sequence 7793 
Next log sequence to archive  7795 
Current log sequence          7795     
```
- If Database log mode is Archive Mode, the database is in archive mode.
- If Database log mode is No Archive Mode, follow instructions in related Oracle database documents to change the operation mode to archive.
Check the database files at the production end.
Check that the data files, log files, and control files of a database are stored on LUNs. If those files are not stored on LUNs, DR cannot be performed for the database. You are advised to store temporary tablespaces on the same LUN where data files, log files, or control files resides or store temporary tablespaces a LUN different from the LUNs where other database files are stored.

DR End

Check the database environment on the DR end.

If the database environments at the DR and production ends are different, modify the database environment at the DR end to be the same as that at the production end.

Table 4 lists the environmental requirements of databases at the DR end.

**Table 4** Environmental requirements of databases at the DR end
Check Item	Requirements
Oracle installation	Oracle databases on the DR and production ends must run the same operating system and of the same version.
	Versions of Oracle databases on the DR and production ends must be the same.
	The installation location of Oracle databases on the DR end must be consistent with that on the production end.
Database	The database authentication modes on the DR and production ends must be the same.
Database	Names, user names, and passwords of Oracle databases on the DR and production ends must be the same.
non-Windows operating system (file system)	IDs and residing group IDs of Oracle users on the DR and production end must be the same.
Oracle RAC	scan name of SCAN-IP on the production end must be consistent with that on the production end.

Set up database DR environment at the DR end.

The following shows two methods to set up database DR environment after Oracle database software has been installed on DR hosts.

Table 5 shows database directories in Windows and UNIX-like operating systems.

**Table 5** Oracle database directories in different operating systems of hosts
Operating System of the Host	Root Directory of the Database	Installation Directory of the Database	Query Method
Windows	%ORACLE_BASE%	%ORACLE_HOME%	Run the echo %ORACLE_BASE% command to query the root directory of the Oracle database. Run the echo %ORACLE_HOME% command to query the installation directory of the Oracle database.
UNIX-like operating system	$ORACLE_BASE	$ORACLE_HOME	Run the echo $ORACLE_BASE command to query the root directory of the Oracle database. Run the echo $ORACLE_HOME command to query the installation directory of the Oracle database.

Method 1: Manually replicate necessary files from the production end to the DR end (suppose the database instance name is db001).

To ensure the file permissions on the production and DR ends are the same, replicate necessary files from the Oracle user's directory on the production center to that at the DR end.
1. Replicate db001-related files under the Oracle user-specified directory on the production center to the corresponding directory on the DR center.
  - In Windows, the specific directory is %ORACLE_HOME%\database.
  - In a Unix-like operating system, the specific directory is $ORACLE_HOME/dbs.
2. Under the specific directory at the DR end, create folder db001. Under the created folder, create the directory structure according to that on the production end.
  - In Windows, the specific directory is %ORACLE_BASE%\ADMIN.
  - For Oracle 10g, create the alert_%SIDNAME%.ora file under the %ORACLE_BASE%\ADMIN\%DBName%\bdump directory.
  - For Oracle 11g or 12c, create level-2 directories under the %ORACLE_BASE%\diag\rdbms according to the directory structure on the production end, for example, %ORACLE_BASE%\diag\rdbms\level-1 directory\level-2 directory.
  - In a Unix-like operating system, the specific directory is $ORACLE_BASE/admin.
  - For Oracle 10g, create the alert_%SIDNAME%.ora file under the $ORACLE_BASE/admin/$dbName/bdump directory.
  - For Oracle 11g or 12c, create level-2 directories under the $ORACLE_BASE/admin/diag/rdbms according to the directory structure on the production end, for example, $ORACLE_BASE/diag/rdbms/level-1 directory/level-2 directory.
3. If databases at the DR end are clustered, you need to run the following two commands to register the databases and instances.
  - srvctl add database -d {DATABASENAME} -o {ORACLE_HOME}
  - srvctl add instance -d {DATABASENAME} -i {INSTANCENAME} -n {HOSTNAME}
    DATABASENAME is the database name, ORACLE_HOME is the installation directory of the database, INSTANCENAME is the database instance name, and HOSTNAME is the name of the host where the database resides.
  - For versions earlier than 12C, if the DR end is in the RAC environment, run a command to shut down the cluster, including database instances and ASM instances. Then check whether database instances on each node in the cluster have been shut down and whether ASM instances have been shut down. The bonding of raw devices must be canceled.
  - For 12C and later versions, ensure that the Oracle cluster at the DR site is running properly. To periodically refresh host resources, run the srvctl command to query Oracle application information.
4. You need to configure the pfile file in the following scenarios. For details about how to configure the file, see Oracle Configuration (Configuring the pfile file).
  - If there is an Oracle RAC at the production end but only a standalone Oracle database at the DR end, copy the pfile file of the Oracle database at the production end, after you have created databases at the DR end. And replace the cluster configuration information in the file with the information about the deployment mode of the standalone Oracle database at the DR end. Then use the copy of pfile to generate a spfile file and put the file on the local disk at the DR end.
  - If the save paths of the spfile files of both the production end and DR end are the same and the storage devices used by both spfile files are under DR protection (for example, the save paths of the spfile files of the production and DR ends are the same, and the spfile file and data files of the database are saved in the same ASM disk group), synchronizing data will cause the spfile file of the DR end to be overwritten by the spfile file of the production end. As a result, partial data of the DR end will be lost. In this manner, you are advised to save the spfile file of the DR end to the file system running on the DR host.
    In Windows, the spfile file is under the %ORACLE_HOME%\database directory.
    In a Unix-like operating system, the spfile file is under the $ORACLE_HOME/dbs directory.

Method 2: Create databases to generate files necessary for DR at the DR end, by performing the following steps at the DR end:
1. Map empty LUNs to DR hosts and scan for mapped LUNs on DR hosts.
2. If databases are installed on the file system at the production end, create a file system the same as the one at the production end, and mount the file system. If the production databases use ASM, create a ASM disk group the same as that at the production end.
3. Create Oracle databases the same as those at the DR end.
4. After databases are created, shut down them, and remove mapping relationships of file systems or ASM.
  - If databases use ASM, shut down ASM instances after you shut down the databases.
  - For versions earlier than 12C, if the DR end is in the RAC environment, run a command to shut down the cluster, including database instances and ASM instances. Then check whether database instances on each node in the cluster have been shut down and whether ASM instances have been shut down. The bonding of raw devices must be canceled.
  - For 12C and later versions, ensure that the Oracle cluster at the DR site is running properly. To periodically refresh host resources, run the srvctl command to query Oracle application information.
5. Remove LUN mappings from the DR end.
6. You need to configure the pfile file in the following scenarios. For details about how to configure the file, see Oracle Configuration (Configuring the pfile file).
  - If there is an Oracle RAC at the production end but only a standalone Oracle database at the DR end, copy the pfile file of the Oracle database at the production end, after you have created databases at the DR end. And replace the cluster configuration information in the file with the information about the deployment mode of the standalone Oracle database at the DR end. Then use the copy of pfile to generate a spfile file and put the file on the local disk at the DR end.
  - If the save paths of the spfile files of both the production end and DR end are the same and the storage devices used by both spfile files are under DR protection (for example, the save paths of the spfile files of the production and DR ends are the same, and the spfile file and data files of the database are saved in the same ASM disk group), synchronizing data will cause the spfile file of the DR end to be overwritten by the spfile file of the production end. As a result, partial data of the DR end will be lost. In this manner, you are advised to save the spfile file of the DR end to the file system running on the DR host.
    In Windows, the spfile file is under the %ORACLE_HOME%\database directory.
    In a Unix-like operating system, the spfile file is under the $ORACLE_HOME/dbs directory.
7. After creating a database at the DR end, check the names of the spfile files at both the production and DR ends.
  If the names are not the same, change the name of the spfile file at the DR end to that at the production end or save the spfile file at the DR end to a local disk, in order to prevent the database at the DR end from being overwritten after DR. For details, see Configuring Oracle 12.2 (Configuring the spfile File).

Storage End

In the HyperMetro (SAN) or HyperMetro (SAN) and backup (SAN) DR scenario, the archive logs and database files must be configured with a HyperMetro consistency group.

Check the storage environments of the production end and the DR end.
Before using HyperMetro to protect data, on the DeviceManager, check that the HyperMetro is normal.
- If the storage is T series V2R2 or later or 18000 series, the storage support automatically add host and storage mapping function. If the connection between the storage device and the host initiator is normal, the hosts, host groups, LUN mappings, and mapping view will be created in the storage device automatically.
- If the DR storage is T series V2 or later or 18000 series, the DR host can belong to only one host group that belongs to only one mapping view. The HyperMetro secondary LUN that corresponds to the storage LUN used by the protected applications can belong to only one LUN group, and the LUN group must belong to the same mapping view as the host group.
- If the storage array is T series V200R001C00, deselect Enable Inband Command to change the mapping view attribute after the mapping view is created.
Check the storage environments of the production end.
If the active-active mode is used to protect the data of the production-end Oracle database, multiple storage devices (LUNs) used by the production-end database must be in the same consistency group. If only one storage device (LUN) is used, you do not need to add the HyperMetro where the storage device resides to the consistency group.
Check the storage environments of the DR end.
1. After setting up an application environment on the DR end, delete the mapping between the host and the storage LUNs or volumes that store the data files, control files, and log files of the application.
2. Check whether all file systems used by the Oracle database to be recovered are unmounted from the DR host.
3. On the storage array management software, verify that the secondary LUN corresponding to the HyperMetro used by the DR database is not mapped to any host, host group, or mapping view.
4. For the AIX DR end host, you need to check the following items:
  - Check whether all logical volumes used by the database to be recovered and volume groups to which the logical volumes belong are deleted from the DR host.
  - Check whether all physical volumes used by the database to be recovered and devices (hdiskx) corresponding to the physical volumes are deleted on the DR host.
5. If the DR storage is the S5000 series or T series V1, map the initiator of the physical DR host to the logical host of the DR storage. In a cluster, add the logical host to the host group.
----End