Customer Focused Testing: Five steps to improved Oracle array-based replication with Continuous Access EVA (5697-7433, March 2008)

3Configure the EVA
The database files should be separated using two disk groups on the EVA.
• A general best p
ractice for databases is to have two EVA disk groups and two ASM disk groups,
with the online
files in the main group and the backup files in the second group. This is an HP
and Oracle gui
deline, 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 h
ttp://h71028.www7.hp.com/ERC/downloads/4AA0-9728ENW.pdf.This
best practice is not for performance purposes, but to ensure the success of recovery efforts by
separating t
hese files. Thus, if you were to lose the primary disk group, you could recover the
database fro
m the backup files in the second disk group. In addition, since the backup files are
accessed fa
r less than the database files,thebackupdiskgroupcouldusefewerdrives,lower
spindle rates, and even RAID5 to help customers maximize their investment.
• Be careful if you configure the flashback area in Oracle 11g—Oracle will automatically place
a mirrored copy of the online redo logs into the backup disk group, which may affect your
database performance. The simplest solution is to remove the mirrored copy online redo logs
from the backup disk group.
• HP recomm
ends placing all the LUNs from a single application into one DR group. It you have
multiple applications to replicate, it is easy to alternate the DR groups across controllers to
maintain a workload balance. Alternatively, the Oracle database replication can be split into two
DR groups
corresponding to the two EVA/ASM disk group mappings. It is imperative to keep the
online r
edo logs in the same DR group as the database files.
4 Tune the Oracle online redo logs
Use different sizes of online redo logs to determine the impact of replication.
• With a small redo log (for example, 512 KB), log switches take place more frequently. Each log
switch was shorter in duration and had a minimal impact on performance (1%). The write latency
increasedonthemaindiskgroupduringeachlogswitch;eventhoughbriefinduration,thesheer
number of switches still impacts the performance to some degree.
• Our baseline redo log size was 2 GB. This provided the optimal database performance for our
workload when performing array-based synchronous replication.
• The larger redo log size (4 GB) decreased performance by 7%. These log switches occur far less
frequently, but they are much longer in duration. Over sizing the online redo logs had an adverse
impact on the database performance during synchronous replication.
• Agoodruleistotestvariouslogsizesinyourenvironmenttoseeifyouhavethebestsizeforthe
replication solution.
5Fo
llow the documented HP Best Practices
HP improved the baseline performance on the OLTP workload by 15% with basic database tuning.
In addition, you need to select a network bandwidth appropriate for your workload. HP increased
the network link from OC6 to OC9 and saw a 16% improvement on the application performance
me
rely because the former bandwidth was inadequate for the workload being replicated. Finally, HP
re
commends using synchronous replication when link latency is 6 ms or less and bandwidth is sufficient.
Storage administrator best practices
• Create at least two EVA disk groups with multiple LUNs for the database.
• Create one or two DR groups, and do not split online redo logs into a third DR group. Keep
onlineredologsinthesameDRgroupasthedatabasefiles.
• Balance multiple DR groups across EVA 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 with Continuous Access
EVA
3