HP EVA4000 Customer Focused Testing: Five steps to improved Oracle array-based
HP EVA4000 Manual
View all HP EVA4000 manuals
Add to My Manuals
Save this manual to your list of manuals |
HP EVA4000 manual content summary:
- HP EVA4000 | Customer Focused Testing: Five steps to improved Oracle array-based - Page 1
downloaded at http://h71028.www7.hp.com/ERC/downloads/4AA1-5658ENW.pdf. By leveraging these recommendations and best practices, customers can select the optimal replication technology for their environment, optimize performance the time to fail over the replicated LUNs to the backup EVA, recover and - HP EVA4000 | Customer Focused Testing: Five steps to improved Oracle array-based - Page 2
replication). The next-generation EVAs (4x00/6x00/8x00) support both synchronous replication and a new feature known as enhanced asynchronous replication. • During synchronous replication, the array acknowledges input/output (I/O) completion after the data is cached on both the local and - HP EVA4000 | Customer Focused Testing: Five steps to improved Oracle array-based - Page 3
, as documented in the HP white paper HP Best practices for Oracle 10g with Automatic Storage Management (ASM) and HP StorageWorks 8000 Enterprise Virtual Array 8000 at http://h71028.www7.hp.com/ERC/downloads/4AA0-9728ENW.pdf. This best practice is not for performance purposes, but to ensure - HP EVA4000 | Customer Focused Testing: Five steps to improved Oracle array-based - Page 4
practices • Create at least two ASM disk groups. • Use external redundancy on the ASM disk groups. Normal or high mirroring with ASM software mirroring is not necessary with high-end storage arrays. EVA RAID1 redundancy, with its virtualization striping, supports Oracle's best practice of Stripe
banner
Customer Focused Testing: Five steps
to improved Oracle array-based
replication with Continuous Access EVA
Disk-array-based remote copy infrastructures have been available and in use for over a decade.
When properly con
fi
gured and deployed, they are capable of providing a timely recovery from
a variety of failures, including the loss of an entire data center site. This document provides
an overview of
fi
ve recommended steps that should be used when planning to deploy remote
replication solutions for Oracle 11g Enterprise Database using Continuous Access EVA as the
remote copy infrastructure. This document is meant as a companion to the HP whitepaper,
Replication Best Practices for Oracle 11g with ASM & EVA8x00, which can be downloaded
at
h
t
t
p
:
/
/
h
7
1
0
2
8
.
w
w
w
7
.
h
p
.
c
o
m
/
E
R
C
/
d
o
w
n
l
o
a
d
s
/
4
A
A
1
-
5
6
5
8
E
N
W
.
p
d
f
. By leveraging these
recommendations and best practices, customers can select the optimal replication technology for
their environment, optimize performance, and accelerate implementation, thereby reducing costs and
personnel resources.
1 Understand your environment
Before implementing any replication solution, it is important to understand your recovery goals and
the limitations of the available infrastructure. For Oracle Replication, the key information includes:
•
Recovery point objective (RPO) – RPO refers to the amount of data loss a customer can tolerate,
speci
fi
cally, the point in time to which the customer must be able to recover the data. Some
customers require an RPO of zero. That means that in the event of a site failure, the customer
cannot lose a single committed transaction; they must be able to recover the data back to the
exact time of the disaster. An RPO of greater than zero (for example, 30 minutes) can be handled
differently. An RPO of 30 minutes means the customer can tolerate losing the last 30 minutes
of transactions in the event of a site failure.
•
Recovery time objective (RTO) – RTO refers to the maximum amount of time it takes a customer to
get the backup site running after a complete failure at the primary site. This includes the time
to fail over the replicated LUNs to the backup EVA, recover and bring the backup database
online, and redirect any applications to the backup database server. A faster RTO can usually be
accomplished by pre-staging the backup site to the greatest extent possible.
•
Data Replication (DR) Group – A DR group is a logical group of virtual disks in a remote
replication relationship with a corresponding group on another array. The virtual disks in a DR
group fail over together, share a write history log (WHL), and preserve write-ordering within the
group. The write-ordering preservation is especially important in database applications in the
event of a failover and recovery. Moreover, it is a requirement for an Oracle database using
ASM, so that the remote copy can be brought online properly.
5697-7433
© Copyright 2008 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice. The only warranties
for HP products and services are set forth in the express warranty statements accompanying
such products and services. Nothing herein should be construed as constituting an additional
warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
Inc. Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation. Oracle is
a registered trademark of Oracle Corporation and/or its af
fi
liates.
The information in this document is subject to change without notice.
5697-7433
1st edition: March 2008