Oracle9iR2 Remote Mirroring Hpevav1 1

Oracle Database 9i Remote
Mirroring Guide
EVA 3000/5000 Continuous
Access
Introduction

To ensure Oracle database compatibility with specialized storage technologies, Oracle
created the Oracle Storage Compatibility Program (OSCP). As part of OSCP, Oracle
selects appropriate storage technologies and vendors for compatibility validation. To
participate in the program, Oracle asks qualified vendors to satisfy requirements of their
self-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 Fiber
Channel 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 and
target at the same time, but one VDisk (Virtual Disk) can only be replicated in one
direction (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 in
the 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. The
mirroring happens in the background while applications continue to work.

S S| |I Ie e 8 8
FPT
FPT
FP2
FP2
S So or rv vo or r S SV VM MA A
F FC C s sw wl ll lc ch h
H HS SV V
C Cl ll lr r
H HS SV V
C Cl ll lr r
FPT
FPT
FP2
FP2
H HS SV V
C Cl ll lr r
H HS SV V
C Cl ll lr r
S So or rv vo or r S SV VM MA A
S S| |I Ie e A A
As previously mentioned, EVA CA can copy data online using synchronous and
asynchronous replication to a remote storage array. The big difference between the two
is in how each supports the recovery point objective (RPO); that is the amount of data at
risk should the primary site fail. Synchronous supports an RPO of zero, and
asynchronous 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, the
remote controller sends and acknowledgment to the primary controller which informs the
host about the I/O completion.

HcsI HcsI
CA FVA - Synchrcncus rep||ccI|cn
FC SAM FC SAM
CACHF CACHF
Vrllo Cp
Ack
Pr|mcry Pr|mcry S|Ie S|Ie 0esI|ncI|cn 0esI|ncI|cn S|Ie S|Ie
Sourco
DR Croups
Dosllnollon
DR Croups

Asynchronous Replication

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

Host Host
Sourco
DR Croups
Dosllnollon
DR Croups
CA FVA Asynchrcncus rep||ccI|cn
FC SAN FC SAN
CACHE CACHE
WrIte Dp
Ack
Pr|mcry S|Ie Pr|mcry S|Ie 0esI|ncI|cn 0esI|ncI|cn S|Ie S|Ie

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 properties
and are common to a single application instance: (that is a single application instance
may 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 and
target array. Basically, it is used in case the target array is not reachable and stores the
data the host has written during this time.
When the connection has been reestablished, the log information is written to the
destination VDisk. This process is also known as merge.
The target Log Disk is just need in case a failover takes place and the destination array
becomes 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 on
this 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 is
down, there are three possibilities:

Normal mode (failsafe-disabled mode) (default): in this case, if the link fails, the
host I/O will be written to the log file. The primary site keeps working normally
without disruptions. When the link is resumed, the log file will be merged on
destination (changes will be applied)
Primory sile
S So ou ur rc co o
Doloboso
Deslinolion sile
Sourco
Syslom
P Pr ri im mo or ry y s si il le e
D Do os sl ll ln no ol ll lo on n
S Sy ys sl lo om m
Deslinolion sile
D Do os sl ll ln no ol ll lo on n
Mlrror Doloboso
8eIcre Ic||cver
AIIer Ic||cver
F FV VA A A A F FV VA A 8 8
F FV VA A A A F FV VA A 8 8
Failsafe mode: the primary storage doesnt accept I/O when the access to the
destination site is disrupted. It ensures that primary and destination keep
synchronized. 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-UX
IPF (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 Access
2.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 the
production database and confirm that is being shipped to the standby database. All files
are 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))
)
)
)
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 = <secondary-host-name>)(PORT =
1521))
)
(CONNECT_DATA =
(SERVICE_NAME = oscp1.us.oracle.com)
)
)

sqlnet.ora

NAMES.DEFAULT_DOMAIN = us.oracle.com
automatic_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 database
in 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 are
mirrored) to convert the standby database to a read/write production database must be
created, 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 create
the 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 ARCHIVELOG
MAXLOGFILES 16
MAXINSTANCES 1
LOGFILE
GROUP 1 <location of redo logs> SIZE 10M,
GROUP 2 <location of redo logs> SIZE 10M
DATAFILE
'<$ORACLE_HOME location>dbs/dbs1oscp1.dbf',
'<$ORACLE_HOME location>dbs/rm_sys1.dbf',
'<$ORACLE_HOME location>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 = <primary-host-name>)(PORT =
1521))
)
(CONNECT_DATA =
(SERVICE_NAME = oscp1.us.oracle.com)
)
)

sqlnet.ora

NAMES.DEFAULT_DOMAIN = us.oracle.com
automatic_ipc=off
Scenario Guide Overview

Different remote mirroring systems have different capabilities. As far as using
Oracle 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 Compatibility
program (OSCP) for each of the three modes listed above, we verified that the
HP EVA remote mirroring system was compatible for mirroring both Oracle online
logs (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 automatically
splitting the mirror.

Firstly, if the intersite link breaks or replication is suspended, the pair is 'split' with
all pending writes kept in the write history log, for replay when the link is fixed or
resumed. This mode has failsafe disabled
Secondly, if failsafe mode is enabled and the link breaks or is manually
suspended, all I/O is stopped to both source and destination. Only those write in
progress at the time of the link break are pushed into the write history log for
replay when the link is fixed.
After recovery of the fault, the procedure for resychronising the data (via the
merge 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 longer
available in the Continuous Access UI.

At secondary site:

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 not
automatically change. To ensure you can mount the remote Vdisk on the
secondary system set Write Disk Attribute to No.
2. run ioscan -fnC disk
3. vgimport destination vdisk
4. 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 using
the OSCP Test Kit.

The scenarios that can be applied to a backup and recovery situations are
divided 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:
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.

Testing Scenarios:

Simple Primary to Secondary Site Failover & Atomic
Split

The standard procedures to create and setup a production database at the
primary 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 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).
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 of the online redo logs DR Group is
performed.

At the secondary site:

1. Shutdown the standby database.
shutdown immediate
or
shutdown abort

2. Failover to the secondary site. Vgimport the online redo log volume.
vgimport /<volume group name> /<special device name>

3. Run fsck for the replicated volume.
fsck y /dev/<volume_group>/<logical_volume>.

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

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

Start the database in nomount mode.
startup pfile=<relevant init.ora> nomount

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 successfully
started as the production database and the fail over succeeded. Same results
were obtained for all synchronous and asynchronous scenarios.

Manual Break of Mirror

1. The create control file with noresetlogs option script was generated in the
3. Write activity into the production database is generated.
4. Manually split the mirror as detailed above.


shutdown abort

2. Vgimport the online redo log volume.





Mount the database.


Open the database.

Results: The secondary site's standby database instance was successfully
started as the production database and the fail over succeeded. Same results
were 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 use
the primary site as the standby database. This is achieved by having the
production database fallback to the primary site by copying the datafiles back
from 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. The
create control file with noresetlogs option script was generated in the
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 the
primary system (in this case, the primary system has the standby database
and the secondary system has the production database.)


1. Shutdown the database.
shutdown normal

2. Startup the database.
startup pfile=<relevant init.ora> mount

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

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

At the primary site:

1. Start the database in the nomount state.

2. Mount it as a standby database.

3. Automatically recover standby database.


1. Start the second destination of archive log files (specified in init.ora file).
alter system set log_archive_dest_state_2 = enable
alter 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 backup
and recover the database at the primary site. This method avoids copying
datafiles across the network.

performed.


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


shutdown immediate

2. Startup the database.

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

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





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

2. Start transactions at the secondary site.


1. Recover the standby database.

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

Reverse Role via Recovery

This method of reverse role required neither copying the database across the
network nor restoring backups. This method can only be used if the following
conditions are true:
the online logs are mirrored synchronously
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.

performed.


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

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



alter 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).

2. Start transactions at the secondary site.


1. Recover the standby database.

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

Direct fallback via database copy scenario

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

performed.


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


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.


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


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

4. Open the database as a production one and start the database transactions.
alter database recover automatic database
alter database open

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

Direct fallback via restoring backup scenario

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

performed.
6. The primary system or network failure is resolved.


2. Restore the data files and control files from the backup taken before the
disaster.
3. Transfer the archived log files from the secondary site. (cp was used)
4. Start up the database in nomount mode.

5. Mount the database.
alter database mount

6. Recover the database.

shutdown immediate

2. Umount the replicated volume.
umount /<mount_point>


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

fsck y /dev/<volume_group>/<logical_volume>


4. Start and open as a normal production database, and verify the contents.
alter database open

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

Simple Site to Site Failover for Managed Recovery

In a Managed Standby Environment, the primary database automatically sends the
archive logs to a standby site via the Oracle 9i SQL*Net connection. When the standby
database 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 from
the 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 database
is being kept current. The drawback is that user errors or data corruptions may be
inadvertently propagated to the standby database.

1. The standard procedures to create and setup a production database at the primary
site and standby database at the secondary site were followed. The create control
file with noresetlogs option script was generated in the primary site and saved in the
standby site.
2. On the primary site issue alter database recover managed standby database; for
managed recovery mode.
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 of the online redo logs DR Group is performed


shutdown immediate
or
shutdown abort

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





Mount the database.


Open the database.

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 the
archive logs to a standby site via the Oracle 9iR2 SQL*Net connection. When the
standby database 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
from the primary site. The options and procedures of fallback using Managed Recovery
mode are the same as those for manual recovery mode.

standby site.
2. On the primary site the alter database recover managed standby database;
command for managed recovery mode is issued.
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.



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


1. Shutdown the database
shutdown immediate

2. Start the database
startup pfile=<relevant init.ora>

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

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


1. Start the database in nomount mode.

2. Recover the database.
alter database recover cancel

3. Verify that the database is current.


1. Start second destination for archive log files on the primary site

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 of
committed transactions. This scenario is only used for remote mirroring systems that
support the synchronous manual-split mode.

file with noresetlogs option script was generated in primary site 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).
a. drop and recreate test table
b. 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.


shutdown abort

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



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

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

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

Concurrent Transactions

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

standby site.
3. Data is being added to the database.
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 volume
group.



alter database open

Results: The standby database is up to date with the production database before the
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 mirroring
system, will ensure that the standby database is up to date with the production database
up until the time of a disaster.

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


group.



alter database open

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

Network Failure using Concurrent Transactions

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

site.
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 listener
b. startup pfile=<relevant init.ora> mount
c. Continue with loading data into the production database.


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


shutdown abort

group.



alter database open

Results: Successfully tested that all writes acknowledged as successful are persistent
on 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 the
mounted filesystem, /u4/dbs_dir, and the online redo logs onto the mounted file
system, /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 site
was followed.

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, are
vgimported and the filesystems mounted. The database is opened to verify
consistency.


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

2. Run fsck on the replicated volumes.

3. Mount the volumes at the mount points.

4. Open the database instance on the secondary site as a production database.
startup pfile=<relevant init??.ora>

5. Verify that the database is consistent.

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

Secondary Site to Primary Site Fall Back

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

vgimported and the filesystems mounted. The database is opened to verify
consistency.


shutdown

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



2. Verify the data is consistent.

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

Write Ordering for Whole Database Mirror

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

1. The standard procedure to create and setup a production database at the primary
site was followed.
vgimported and the filesystems mounted.


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

2. Run fsck on the replicated volumes.

3. Mount the volumes at the mount points.


5. Verify the consistency of the database.

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

Oracle9iR2 Remote Mirroring Hpevav1 1

Uploaded by

Copyright:

Available Formats

Oracle9iR2 Remote Mirroring Hpevav1 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle9iR2 Remote Mirroring Hpevav1 1

Uploaded by

Copyright:

Available Formats

Oracle Database 9i Remote

You might also like