Oracle9iR2 Remote Mirroring Hpevav1 1

8/3/2019 Oracle9iR2 Remote Mirroring Hpevav1 1

1/28

Oracle Database 9i Remote

Mirroring Guide

EVA 3000/5000 Continuous

Access


2/28

Introduction

To ensure Oracle database compatibility with specialized storage technologies, Oraclecreated the Oracle Storage Compatibility Program (OSCP). As part of OSCP, Oracleselects appropriate storage technologies and vendors for compatibility validation. To

participate in the program, Oracle asks qualified vendors to satisfy requirements of theirself-test suite of products developed to ensure compatibility with Oracle databases.

As a member of OSCP, HP has successfully completed the Oracle Database 9i self test,meeting compatibility requirements for the remote mirroring test suite.

Enterprise Virtual Array Continuous Access

HP Storage Works Enterprise Virtual Array Continuous Access (EVA CA) is a FiberChannel controller-based replication for disaster tolerant environments.EVA CA copies data using synchronous or asynchronous replication to remote sites.The copy is performed in a local or extended SAN.

Data replication can take place in both directions; one storage array can be source andtarget at the same time, but one VDisk (Virtual Disk) can only be replicated in onedirection (i.e. can only be source or target of the replication)

To be able to configure the storage replication, a source VDisk needs to be specified inthe primary storage system. EVA CA will then create a target VDisk on the remote array.As data is written to the source VDisk, it is mirrored to the destination VDisk. Themirroring happens in the background while applications continue to work.


3/28

As previously mentioned, EVA CA can copy data online using synchronous andasynchronous replication to a remote storage array. The big difference between the twois in how each supports the recovery point objective (RPO); that is the amount of data atrisk should the primary site fail. Synchronous supports an RPO of zero, andasynchronous supports an RPO of near zero, buffering at most MByte of data.

Synchronous Replication

The host writes its data to disk. The array controller writes the data into its cache.EVA CA copies the data to the remote controller which writes it into its cache. Then, theremote controller sends and acknowledgment to the primary controller which informs thehost about the I/O completion.


4/28

Asynchronous Replication

The main difference with the synchronous replication is that, the primary controller willinform the host about I/O completion when the data is written to its cache. In this case, itdoesnt wait for the I/O to be written to the remote controller cache.

HostHost

FC SANFC SAN

CACHE CACHE

Copy Set, Data Replication (DR) Groups, Log Disk

VDisks which are replicated using EVA CA need to be part of a pairing relationship,which define a pair of VDisks, the source and the target which are being replicated.

Data Replication (DR) groups are groups of Copy Sets which share the same propertiesand are common to a single application instance: (that is a single application instancemay use one or more Vdisks, and all of those Vdisks MUST be in the same DR group)

Replicate to the same storage array Failover at the same time. Share the same Log disk. Guarantee data consistency and write ordering across the ISL and into the

destination copy of the data

Every DR group allocates automatically a LOG (log disk) on each side, source andtarget array. Basically, it is used in case the target array is not reachable and stores thedata the host has written during this time.


5/28

When the connection has been reestablished, the log information is written to thedestination VDisk. This process is also known as merge.The target Log Disk is just need in case a failover takes place and the destination arraybecomes primary.

Failover

Based on the reason for the failover, we can distinguish between

Planned Failover Unplanned Failover

In a failover scenario, the destination Storage Array becomes the primary and stays onthis role until another failover takes place.

In case a planned failover is need, here are some steps which need to be followed:

The VDisks of the DR group need to be unpresented to the primary host Perform the failover of the DR group Verify the VDisks are presented at the destination site

Based on the behavior of EVA CA when the link between primary and destination sites isdown, there are three possibilities:

Normal mode (failsafe-disabled mode) (default): in this case, if the link fails, thehost I/O will be written to the log file. The primary site keeps working normallywithout disruptions. When the link is resumed, the log file will be merged ondestination (changes will be applied)

!

!!


6/28

Failsafe mode: the primary storage doesnt accept I/O when the access to thedestination site is disrupted. It ensures that primary and destination keepsynchronized. Failsafe is only available when using synchronous replication

Oracle Setup

Hardware

Install Oracle 9202 for HP-UX Itanium on two HP RX5670 nodes running HP-UXIPF (11.23).

Install the 9205 patchset on both servers. Install the OSCP test-kit.

Initial Setup of HP EVA using Command View 4.x and Continuous Access2.x

Vdisk created on Source. Data replication is established between the pair. Presented Source Vdisk to primary site. Presented Destination Vdisk to secondary site. Ran ioscan -fnC disk on primary site. Vgimported the source LUN on primary site and created the relevant volume

group and file system. Mounted the file system. Created the Oracle database putting the online redo logs onto the mounted file

system.

Oracle Configuration Files

Setup the Standby Database by editing the following files. Generate redo on theproduction database and confirm that is being shipped to the standby database. All filesare located in the $ORACLE_HOME/network/admin directory.

Primary site

listener.ora

LISTENER =(DESCRIPTION_LIST =

(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = IPC)(KEY = oscp1)))(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = < primary-host-name>)(PORT =1521))))


7/28

)SID_LIST_LISTENER =(SID_LIST =(SID_DESC =(GLOBAL_DBNAME = oscp1.us.oracle.com)(ORACLE_HOME = < location of $ORACLE_HOME >)

(SID_NAME = oscp1)))

tnsnames.ora

OSCP1.US.ORACLE.COM =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT =1521)))

(CONNECT_DATA =(SERVICE_NAME = oscp1.us.oracle.com)))

sqlnet.ora

NAMES.DEFAULT_DOMAIN = us.oracle.comautomatic_ipc=off

Prepare a new init.ora file and the script for creating a control

file.

After setting up the production and standby database systems, put the standby databasein managed recovery mode by issuing recover managed standby database; command.To prepare for failover the script for a control file to apply the current redo logs (that aremirrored) to convert the standby database to a read/write production database must becreated, and a new init.ora file for activation of the standby database as a primary one.This init.ora should use a different location for the control file. The script used to createthe new control file at the standby site must meet the following requirements: All datafiles in the script must point to the datafiles of the standby database. All log files in the script must point to the online log files remotely mirrored. The

script must include all online log files mirrored and all multiplexed log members. The create control file script must use the noresetlogs option.

For example:$cat control.sql

CREATE CONTROLFILE REUSE DATABASE "oscp1" NORESETLOGS ARCHIVELOGMAXLOGFILES 16MAXINSTANCES 1


8/28

LOGFILEGROUP 1 SIZE 10M,GROUP 2 SIZE 10M

DATAFILE'dbs/dbs1oscp1.dbf','dbs/rm_sys1.dbf',

'dbs/rm.dbf'

CHARACTER SET US7ASCII;

Secondary site

listener.ora

LISTENER =(DESCRIPTION_LIST =

(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = < secondary-host-name>)(PORT= 1521)))))SID_LIST_LISTENER =(SID_LIST =(SID_DESC =(GLOBAL_DBNAME = oscp1.us.oracle.com)(ORACLE_HOME = < $ORACLE_HOME location >)

(SID_NAME = oscp1)))

tnsnames.ora

OSCP1.US.ORACLE.COM =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT =1521)))

(CONNECT_DATA =(SERVICE_NAME = oscp1.us.oracle.com)))

sqlnet.ora

NAMES.DEFAULT_DOMAIN = us.oracle.comautomatic_ipc=off


9/28

Scenario Guide Overview

Different remote mirroring systems have different capabilities. As far as usingOracle database is concerned, there are three major capabilities:

Synchronous mirroring with automatic-split mode Synchronous mirroring with manual-split mode. Asynchronous mirroring

By successfully running the tests supplied by the Oracle Storage Compatibilityprogram (OSCP) for each of the three modes listed above, we verified that theHP EVA remote mirroring system was compatible for mirroring both Oracle onlinelogs (for standby database) as well as a complete Oracle database.

Synchronous Automatic Split

In the HP EVA remote mirroring system there are two options for automaticallysplitting the mirror.

Firstly, if the intersite link breaks or replication is suspended, the pair is 'split' withall pending writes kept in the write history log, for replay when the link is fixed orresumed. This mode has failsafe disabled

Secondly, if failsafe mode is enabled and the link breaks or is manuallysuspended, all I/O is stopped to both source and destination. Only those write inprogress at the time of the link break are pushed into the write history log forreplay when the link is fixed.

After recovery of the fault, the procedure for resychronising the data (via themerge process)is automatic once the fault has been fixed

Synchronous Manual Split

To manually split the mirror:

At primary site:

1. Select the source Vdisk of the pair.

2. Select the Data Replication tab.3. Select Remove Member.4. Select Keep Remote Vdisk

The mirror is now broken. The Data Replication Group of this Vdisk is no longeravailable in the Continuous Access UI.

At secondary site:


10/28

1. When manually breaking the LUN out by dissolving the DR Group and using

the option to preserve the remote vdisk, that Write-Protect attribute does notautomatically change. To ensure you can mount the remote Vdisk on thesecondary system set Write Disk Attribute to No.

2. run ioscan -fnC disk3. vgimport destination vdisk4. Run fsck.5. Mount the volume group.

Tests that represent the key Oracle database backup and recovery scenarios,which are supported by HP EVA technologies, were tested and validated usingthe OSCP Test Kit.

The scenarios that can be applied to a backup and recovery situations aredivided into two sections, Mirroring Online Redo Logs and Mirroring the Whole

Database.

Mirroring Online Redo Logs: Simple Primary Site to Secondary Site Failover /Atomic Split of Mirror Manual Break of Mirror Reverse Role via Database Copy Reverse Role via Restoring Backup Reverse Role via Recovery Direct Fallback via Database Copy

Direct Fallback via Restoring Backup Simple Primary Site to Secondary Site Failover for Managed Recovery

Reverse Role via Restoring Backup for Managed Recovery No loss of Committed Transaction Concurrent Transaction Write Ordering Network Failure using Concurrent Transactions

Mirroring the Whole Database Simple Primary Site to Secondary Site Failover for Whole database Mirror Simple Secondary Site to Primary Fallback for Whole database Mirror Write Ordering for Whole Database Mirror

Mirroring of the Online Redo Logs

Setup Production Database and Standby Database

This test sets up the production and standby database:


11/28

It copies database files, control files and init.ora files needed to the correctdirectories for both production and standby databases.

Starts the production database and creates a standby control file. Copies files to the secondary site. It then verifies that the standby

database can run in automatic recovery mode.

Testing Scenarios:

Simple Primary to Secondary Site Failover & AtomicSplit

The standard procedures to create and setup a production database at theprimary site and standby database at the secondary site were followed.

1. The create control file with noresetlogs option script is generated in the

primary site and saved in the standby site.2. Users are accessing the primary site (production). The source LUN on theprimary site is vgimported. The file system to be used for the online redo logs(/u2/redo_dir) is mounted. (Fsck is run, if required).

3. There is a primary system crash (created by disconnecting the power cableon primary site) or a failure of the network.

4. At the primary site the production database, if it is running, is shutdown usingthe shutdown abort command.

5. A fail over to the secondary site of the online redo logs DR Group isperformed.

At the secondary site:

1. Shutdown the standby database.shutdown immediateorshutdown abort

2. Failover to the secondary site. Vgimport the online redo log volume.vgimport / /

3. Run fsck for the replicated volume.fsck y /dev//.

4. Mount the volume at the mount point.mount /

6. Open the secondary standby database as a production database.

Start the database in nomount mode.startup pfile= nomount


12/28

Mount the database.alter database mount standby database

Recover the database.alter database recover automatic standby database

Open the database.alter database activate standby database

Results: The secondary site's standby database instance was successfullystarted as the production database and the fail over succeeded. Same resultswere obtained for all synchronous and asynchronous scenarios.

Manual Break of Mirror

1. The create control file with noresetlogs option script was generated in theprimary site and saved in the standby site.

2. Users are accessing the primary site (production). The source LUN on theprimary site is vgimported. The file system to be used for the online redo logs(/u2/redo_dir) is mounted. (Fsck is run, if required).

3. Write activity into the production database is generated.4. Manually split the mirror as detailed above.


1. Shutdown the standby database.shutdown abort

2. Vgimport the online redo log volume.vgimport / /




Start the database in nomount mode.startup pfile= nomount




13/28


Results: The secondary site's standby database instance was successfullystarted as the production database and the fail over succeeded. Same resultswere obtained for all synchronous and asynchronous scenarios.

Reverse role via database copy scenario

To reverse role is to use the secondary site as the production database and usethe primary site as the standby database. This is achieved by having theproduction database fallback to the primary site by copying the datafiles backfrom the secondary to primary sit.

1. The standard procedures to create and setup a production database at the

primary site and standby database at the secondary site were followed. Thecreate control file with noresetlogs option script was generated in theprimary site and saved in the standby site.




5. A fail over to the secondary site of the online redo logs DR Group is

performed.6. After the primary system or network failure is resolved, the roles of the

systems are reversed by copying files from the secondary system to theprimary system (in this case, the primary system has the standby databaseand the secondary system has the production database.)


1. Shutdown the database.shutdown normal

2. Startup the database.startup pfile= mount

3. Create a standby control file and make the archive log current.alter database create standby control filealter system archive log current

4. Transfer the data files and control file to the primary site (cp was used for thispurpose using automounter).


14/28

At the primary site:

1. Start the database in the nomount state.startup pfile= nomount

2. Mount it as a standby database.alter database mount standby database

3. Automatically recover standby database.alter database recover automatic standby database


1. Start the second destination of archive log files (specified in init.ora file).alter system set log_archive_dest_state_2 = enablealter system set log_archive_min_succeed_dest = 2

2. Start the transaction activities at the secondary site.

Results: The role reversals of the primary and secondary sites succeeded.

Reverse role via restoring backup scenario

To reverse role via restoring backup, the user must restore a local full backupand recover the database at the primary site. This method avoids copyingdatafiles across the network.

1. The standard procedures to create and setup a production database at theprimary site and standby database at the secondary site were followed. Thecreate control file with noresetlogs option script was generated in theprimary site and saved in the standby site.






1. Restore the backup that was taken before the disaster.



15/28

1. Shutdown the database.

shutdown immediate

2. Startup the database.startup pfile= mount

3. Create a standby control file and make the archive log current.alter database create standby control filealter system archive log current

4. Transfer the data files and control file to the primary site (cp was used).


1. Start the database in the nomount state.

startup pfile= nomount

2. Mount it as a standby database.alter database mount standby database


1. Start the second destination of the archive log files (specified in the init.orafile).

alter system set log_archive_dest_state_2 = enablealter system set log_archive_min_succeed_dest = 2

2. Start transactions at the secondary site.


1. Recover the standby database.alter database recover automatic standby database

Results: Successfully reversed the roles of the primary and secondary sites byrestoring the backup at the primary site and applying the logs obtained from thesecondary site.

Reverse Role via Recovery

This method of reverse role required neither copying the database across thenetwork nor restoring backups. This method can only be used if the followingconditions are true:

the online logs are mirrored synchronously


16/28

manual-split mode is used and the mirror is established when the disaster happened and no-one has started the database at the primary site after the disaster.

1. The standard procedures to create and setup a production database at the

primary site and standby database at the secondary site were followed. Thecreate control file with noresetlogs option script was generated in theprimary site and saved in the standby site.




5. A fail over to the secondary site of the online redo logs DR Group is

performed.


1. Create standby controlfile and make the archive log current.alter database create standby controlfilealter system archive log currentalter database backup controlfile to trace noresetlogs

3. Transfer the standby control file ad archive logs to the primary site (cp was used).


1. Start the database in the nomount state.startup pfile= nomount

2. Mount it as a standby database.alter database recover automatic standby databasealter database recover cancel

3. Verify that the standby database is current.


1. Start the second destination of the archive log files (specified in the init.ora file).alter system set log_archive_dest_state_2 = enablealter system set log_archive_min_succeed_dest = 2

2. Start transactions at the secondary site.



17/28

1. Recover the standby database.

alter database recover automatic standby database

Results: Successfully reversed the roles of the primary and secondary sites viarecovery.

Direct fallback via database copy scenario

This approach requires shutting down the production database on the secondarysite before performing the fallback to the primary site. It also requires the setupof the standby database on the secondary site again after the successful fallbackto primary site

1. The standard procedures to create and setup a production database at theprimary site and standby database at the secondary site were followed. The

create control file with noresetlogs option script was generated in theprimary site and saved in the standby site.






1. Remove the old archive logs using the Unix rm command.


1. Shutdown the database.shutdown immediate

2. Take a cold backup of the database.

3. Transfer the data files and the control file to the primary site.4. Unmount the redo logs replication volume.

umount /< mount point >

5. Startup the database as the standby database.startup pfile= nomountalter database mount standby databasealter database recover automatic standby database


18/28


1. Failover to the primary site. Vgimport the online redo log volume group.vgimport / /


3. Mount the volume.mount / < mount point >

4. Open the database as a production one and start the database transactions.startup pfile= mountalter database recover automatic databasealter database open

Results: Successfully completed the fallback operation to the primary site fromthe secondary site.

Direct fallback via restoring backup scenario

This approach requires shutting down the production database on the secondarysite before performing the fallback.

1. The standard procedures to create and setup a production database at theprimary site and standby database at the secondary site were followed. Thecreate control file with noresetlogs option script was generated in the

primary site and saved in the standby site.2. Users are accessing the primary site (production). The source LUN on the

primary site is vgimported. The file system to be used for the online redo logs(/u2/redo_dir) is mounted. (Fsck is run, if required).




6. The primary system or network failure is resolved.


1. Remove the old archive logs using the Unix rm command.2. Restore the data files and control files from the backup taken before thedisaster.3. Transfer the archived log files from the secondary site. (cp was used)4. Start up the database in nomount mode.


19/28


5. Mount the database.alter database mount

6. Recover the database.alter database recover automatic database

At the secondary site:1. Shutdown the database.

shutdown immediate

2. Umount the replicated volume.umount /


1. Failover to the primary site. Vgimport the online redo log volume group.vgimport / /

2. Run fsck for the replicated volume.fsck y /dev//


4. Start and open as a normal production database, and verify the contents. startup pfile= mountalter database recover automatic database

alter database open

Results: The primary site succeeded in retrieving the database data from thesecondary site.

Simple Site to Site Failover for Managed Recovery

In a Managed Standby Environment, the primary database automatically sends thearchive logs to a standby site via the Oracle 9i SQL*Net connection. When the standbydatabase is configured to run in Managed Recovery mode, Oracle automatically applies

the archive logs to the database in the standby site at the time they are received fromthe primary site. The advantage of the Managed Recovery mode is that the recovery,which activating the standby database, takes much less time since the standby databaseis being kept current. Thedrawback is that user errors or data corruptions may beinadvertently propagated to the standby database.

1. The standard procedures to create and setup a production database at the primarysite and standby database at the secondary site were followed. The create control


20/28

file with noresetlogs option script was generated in the primary site and saved in thestandby site.

2. On the primary site issue alter database recover managed standby database; formanaged recovery mode.

3. There is a primary system crash (created by disconnecting the power cable onprimary site) or a failure of the network.

4. At the primary site the production database, if it is running, is shutdown using theshutdown abort command.

5. A fail over to the secondary site of the online redo logs DR Group is performed


1. Shutdown the standby database.shutdown immediateorshutdown abort

2. Failover to the secondary site. If necessary, vgimport the online redo log volume

site.vgimport / /




Start the database in nomount mode.





Results: Successfully tested managed recovery of the secondary site.

Reverse Role via Backup Restore for Managed Recovery

In a managed standby environment, the primary database automatically sends thearchive logs to a standby site via the Oracle 9iR2 SQL*Net connection. When thestandby database is configured to run in Managed Recovery mode, Oracle automaticallyapplies the archive logs to the database in the standby site at the time they are received


21/28

from the primary site. The options and procedures of fallback using Managed Recoverymode are the same as those for manual recovery mode.

1. The standard procedures to create and setup a production database at the primarysite and standby database at the secondary site were followed. The create controlfile with noresetlogs option script was generated in the primary site and saved in the

standby site.2. On the primary site the alter database recover managed standby database;

command for managed recovery mode is issued.3. There is a primary system crash (created by disconnecting the power cable on

primary site) or a failure of the network.4. At the primary site the production database, if it is running, is shutdown using the

shutdown abort command.5. A fail over to the secondary site is performed. The LUN on the secondary site is

vgimported, fsck is run and the filesystem is mounted.


1. Remove the old archive logs using the Unix rm command.

2. Restore the data files and control files from the backup taken before the disaster.


1. Shutdown the databaseshutdown immediate

2. Start the databasestartup pfile=

3. Create standby control file and set the archive log current.alter database create standby controlfilealter system archive log currentalter database backup controlfile to trace noresetlogs

4. Transfer standby control file and archive logs to primary site.


1. Start the database in nomount mode.startup pfile= nomount

2. Recover the database.alter database recover automatic standby databasealter database recover cancel

3. Verify that the database is current.



22/28

1. Start second destination for archive log files on the primary sitealter system set log_archive_dest_state_2 = enablealter system set log_archive_min_succeed_dest = 2

2. Start the transaction activities at the secondary site.


1. Recover standby database.alter database recover managed standby database

2. Verify the contents of the standby database.

Results: Successfully tested reverse role via restore of backup for managed recovery.

No loss of Committed Transaction Test

By performing the following actions one can verify that, after failover, there is no loss ofcommitted transactions. This scenario is only used for remote mirroring systems thatsupport the synchronous manual-split mode.

1. The standard procedures to create and setup a production database at the primarysite and standby database at the secondary site were followed. The create controlfile with noresetlogs option script was generated in primary site saved in the standbysite.

2. Users are accessing the primary site (production). The source LUN on the primarysite is vgimported. The file system to be used for the online redo logs (/u2/redo_dir)is mounted. (Fsck is run, if required).

3. Write activity into the production database is generated.a. drop and recreate test tableb. load data into production database

4. While the data is being added to the production database there is an outage of sorts,either a power failure or network failure.


1. Shutdown the databaseshutdown abort

2. Failover to the secondary site. Vgimport the online redo log volume group.

vgimport / /



5. Start and open as a standby database, and verify the contents.


23/28

startup pfile= mountalter database recover automatic databasealter database open

6. Manually verify that the data in the test table on the standby database is the same asthat on the primary.

Results: Successfully tested that there is no loss of committed transactions after failover.

Concurrent Transactions

By performing the following actions, one can verify that when placing concurrenttransactions on the databases, the HP EVA remote mirroring system will ensure that thestandby database is up to date with the production database up until the time of adisaster.

1. The standard procedures to create and setup a production database at the primarysite and standby database at the secondary site were followed. The create controlfile with noresetlogs option script was generated in the primary site and saved in thestandby site.


3. Data is being added to the database.4. There is a primary system crash (created by disconnecting the power cable on


shutdown abort command.6. A fail over to the secondary site of the online redo logs DR Group is performed.


1. Failover DR Group to the secondary site. Vgimport the online redo log volumegroup.

vgimport / /



4. Start and open as a standby database, and verify the contents.startup pfile= mountalter database recover automatic databasealter database open

Results: The standby database is up to date with the production database before the


24/28

outage.

Write Ordering

By performing the following actions, one can verify that when placing data into the

production database by spawning multiple processes, the HP EVA remote mirroringsystem, will ensure that the standby database is up to date with the production databaseup until the time of a disaster.



3. Write activity into the production database is generated.

a. drop and recreate test tableb. load data into production database

4. There is a primary system crash (created by disconnecting the power cable onprimary site) or a failure of the network.

5. At the primary site the production database, if it is running, is shutdown using theshutdown abort command.

6. A fail over to the secondary site of the online redo logs DR Group (DR Group 001) isperformed.


7. Failover DR Group to the secondary site. Vgimport the online redo log volume

group.vgimport / /



10. Start and open as a standby database, and verify the contents.startup pfile= mountalter database recover automatic database

alter database open

Results: Successfully preserved write ordering when propogating writes issued fromone side of the mirror to the remote side.

Network Failure using Concurrent Transactions


25/28

By performing the following actions one can verify that, while the mirror is established, allwrites acknowledged to applications as successful are persistent on both local andremote mirrors. When the link fails the storage system must either return errors for allsubsequent writes, or let those writes hang, until I/O is re-enabled. This scenario is onlyused for remote mirroring systems that support the synchronous manual-split mode.



3. Write activity into the production database is generated.a. drop and recreate test tableb. load data into production database

4. There is a failure of the network.5. Make sure Oracle either crashes or hangs.

6. Repair the fault.7. If Oracle hangs:

a. Restart the listenerb. startup pfile= mountc. Continue with loading data into the production database.


1. Transfer database files, standby control file and the archive logs to the secondarysite.


1. Shutdown the databaseshutdown abort

2. Failover DR Group to the secondary site. Vgimport the online redo log volumegroup.

vgimport / /



5. Start and open as a standby database, and verify the contents.startup pfile= mountalter database recover automatic databasealter database open


26/28

Results: Successfully tested that all writes acknowledged as successful are persistenton both local and remote mirrors.

Simple Primary Site to Secondary Site Failover in Whole

database Mirror

Initial Setup:1. Two LUNs created on Source one for the online redo logs, and one for the data

files and control files.2. Data replication is established between the pair.3. Presented both Source Vdisks to the primary site.4. Presented both Destination Vdisks to the secondary site.5. Ran ioscan -fnC disk on the primary site.6. Vgimported the Vdisks on the primary site and created the relevant volume groups

and file systems.

7. Mounted the two file systems - /u2/redo_dir and /u4/dbs_dir. Linked /u4/dbs_dir to$ORACLE_HOME/dbs.

8. Created the Oracle database putting the database files and control files onto themounted filesystem, /u4/dbs_dir, and the online redo logs onto the mounted filesystem, /u2/redo_dir.

Setup Production Database and Standby Database

This test sets up the production and standby database: It copies database files, control files and init.ora files needed to the correct

directories for both production and standby databases.

Starts the production database and creates a standby control file. Copies files to the secondary site. It then verifies that the standby database can

run in automatic recovery mode.

Simple Primary to Secondary Site Fail Over

The standard procedure to create and setup a production database at the primary sitewas followed.

1. Write activity into the production database is generated.2. There is a primary system crash (created by disconnecting the power cable on

primary site) or a failure of the network.3. At the primary site the production database, if it is running, is shutdown using theshutdown abort command.

4. A fail over to the secondary site is performed. The two DR Groups, one for theonline redo logs and the other containing the data files and control files, arevgimported and the filesystems mounted. The database is opened to verifyconsistency.


27/28


1. Failover to the secondary site. Vgimport the online redo log and the dbs volume.vgimport / /

2. Run fsck on the replicated volumes.fsck y /dev//.

3. Mount the volumes at the mount points.mount /

4. Open the database instance on the secondary site as a production database.startup pfile=

5. Verify that the database is consistent.

Results: The secondary site's database was opened as the production database andthe fail-over was successful.

Secondary Site to Primary Site Fall Back

The standard procedure to create and setup a production database at the primary sitewas followed.



shutdown abort command.4. A fail over to the secondary site is performed. The two DR Groups, one for the

online redo logs and the other containing the data files and control files, arevgimported and the filesystems mounted. The database is opened to verifyconsistency.


1. Shutdown the databaseshutdown

2. Copy the database files, redo logs and control file to the primary database.



2. Verify the data is consistent.


28/28

Results: The fallback was successful. The primary site was opened as a productiondatabase after the fallback was performed.

Write Ordering for Whole Database Mirror

By performing the following actions, one can verify that when placing data into theproduction database by spawning multiple processes, the HP EVA remote mirroringsystem, will ensure that the standby database is up to date with the production databaseup until the time of a disaster.

1. The standard procedure to create and setup a production database at the primarysite was followed.



shutdown abort command.5. A fail over to the secondary site is performed. The two DR Groups, one for theonline redo logs and the other containing the data files and control files, arevgimported and the filesystems mounted.


1. Failover DR Group 001 and 002 to the secondary site. Vgimport the online redo logand the dbs volume.

vgimport / /

2. Run fsck on the replicated volumes.

fsck y /dev//.

3. Mount the volumes at the mount points.mount /


5. Verify the consistency of the database.

Results: The secondary site database was successfully opened as the productiondatabase.

Oracle9iR2 Remote Mirroring Hpevav1 1

Documents