Before configuring DR services, check the database environments at the production and DR ends where Oracle databases reside, and the storage environment. If any environment does not meet requirements, modify its configurations.
Public Check Items
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 DR end does not support the standalone deployment mode.
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 at the production end may change after DR testing, planned migration, or fault recovery.
- When an Oracle database runs Windows, ensure the password of the Oracle database 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 the systool software 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 hosts.
- If the command output contains sysfsutils, for example, sysfsutils-2.0.0-6, the software has been installed on the host.
- If the command output does not contain sysfsutils, the software is not installed on the host. In this case, obtain the software package from the installation CD-ROM of Red Hat Linux to install the sysfsutils software.
Red Hat Linux 6.3 for x86_64 and the systool 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. For detailed operations, see System Maintenance > System Maintenance Commands > Starting the eReplication Agent in the OceanStor BCManager 8.2.0 eReplication User Guide.
- To configure environment variables for an Oracle database in Windows, perform the following steps:
- Log in to the application server as a user with the administrator rights.
- 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.
- To configure environment variables for an Oracle database running a non-Windows operating system, perform the following steps:
- The following uses the Oracle 12g R1 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 later, environmental variable ORACLE_HOME must be configured f 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 Configuration files that need to be modified for different shell types of operating systems 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 uses shell type bash as an example.
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
- Red Hat: .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 ~/. xxx_profile command to open the .profile file in the home directory of user rdadmin.For example, run the vi ~/.bash_profile command in the Red Hat operating system.
Set xxx based on the site requirements.
- 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.
- To configure environment variables for an Oracle database in Windows, perform the following steps:
- 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 end 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 value of the KERNEL parameter must contain 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.
- Renaming disks
- 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 database 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.
For single-instance Oracle 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. 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.
Check Items at the 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 running mode of a database.
- To configure the running mode of an Oracle database in Windows, perform the following steps:
- 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.
- 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 running mode to archive.
- 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.
- To configure the running mode of an Oracle database running a non-Windows operating system, perform the following steps:
- 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.
- 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 running mode to archive.
- 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.
- To configure the running mode of an Oracle database in Windows, perform the following steps:
- Check the database files at the production end.
Check whether 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 LUN where data files, log files, or control files reside or store temporary them on a LUN different from the LUNs where other database files are stored.
Check Items at the DR End
- Check the database environment at 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 at the DR end must be consistent with that at the production end.
Database
The database authentication modes on the DR and production ends must be the same.
Names, user names, and passwords of Oracle databases at the DR and production ends must be the same.
Non-Windows operating system (file system)
IDs and residing group IDs of Oracle users at the DR and production end must be the same.
Oracle RAC (Oracle 11g R2)
scan name of SCAN-IP at the production end must be consistent with that at the production end.
- Set up a 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 at the production and DR ends are the same, replicate necessary files from the Oracle user's directory at the production center to that at the DR end.
- Replicate db001-related files under the Oracle user-specified directory at 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.
- Under the specific directory at the DR end, create folder db001. Under the created folder, create the directory structure according to that at 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 later, create level-2 directories under the %ORACLE_BASE%\diag\rdbms according to the directory structure at 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 later, create level-2 directories under the $ORACLE_BASE/admin/diag/rdbms according to the directory structure at the production end, for example, $ORACLE_BASE/diag/rdbms/level-1 directory/level-2 directory.
- 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.
- 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:
- Map empty LUNs to DR hosts and scan for mapped LUNs on the DR hosts.
- 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 an ASM disk group the same as that at the production end.
- Create Oracle databases the same as those at the DR end.
- 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.
- 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.
- Remove LUN mappings from the DR end.
- 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.
- 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 Oracle Configuration (Configuring the pfile File).
Check Items at the Storage End
- Perform the checks on storage at the production and DR ends.
If you use storage array remote replication to implement DR protection for the database, establish a remote replication relationship on the storage device management software page between the production end and DR end and ensure that the initial synchronization is complete.
- Perform the checks on storage at the production end.
If remote replication is performed on data of the Oracle database at the production end, multiple LUNs used by one database at the production end must be in the same consistency group. If the database uses only one LUN, the LUN does not need to be added to a consistency group.
- Perform the checks on storage at the DR end.
- After setting up the application environment for the DR end, remove host mappings of the LUNs or volumes that store data files, control files, and log files of the applications.
- Ensure all file systems used by the Oracle databases that you want to recover on the DR hosts are unmounted.
- On the Huawei storage management software, ensure that the secondary LUN of the remote replication used by the DR database is not mapped to any host, host group, or mapping view.
- If the DR hosts run AIX, check the following:
- Check whether information about the volume group hosting the logic volume of the to-be-recovered database is deleted from the DR host.
- Check whether information about the physical volume used by the database and the corresponding device (hdiskx) is deleted from the DR host.