HP EVA4000/6000/8000 Customer Focused Testing: Five steps to improved Oracle a
HP EVA4000/6000/8000 Manual
 |
View all HP EVA4000/6000/8000 manuals
Add to My Manuals
Save this manual to your list of manuals |
HP EVA4000/6000/8000 manual content summary:
- HP EVA4000/6000/8000 | Customer Focused Testing: Five steps to improved Oracle a - Page 1
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 - HP EVA4000/6000/8000 | Customer Focused Testing: Five steps to improved Oracle a - Page 2
your arrays are within the same data center, building, site location, or city replication is possible over the SAN Fibre Channel link, which typically supports 1, 2, or 4 Gb/sec. For greater distances, FCIP may be necessary. It is also important to understand the link between your two sites. Do you - HP EVA4000/6000/8000 | Customer Focused Testing: Five steps to improved Oracle a - Page 3
controllers, so that, for example, DR group 1 is on Controller A and DR group 2 is on Controller B. • Size the write history log properly to support the business RPO and to avoid filling the log and forcing a fast copy. Customer Focused Testing: Five steps to improved Oracle array-based replication - HP EVA4000/6000/8000 | Customer Focused Testing: Five steps to improved Oracle a - Page 4
), Secure Path, or embedded Linux drivers. Typically, least service time or some similar multipathing algorithm gives optimal performance over basic end storage arrays. EVA RAID1 redundancy, with its virtualization striping, supports Oracle's best practice of Stripe and Mirror Everything (SAME). •
-
1 -
2 -
3 -
4
 |
 |
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