Sizing Exadata - Oracle Exadata Recipes: A Problem-Solution Approach - page 115

The physical write statistics are handled the same was as physical reads , but the redo size metric is handled
a bit differently. Oracle's redo size metric represents the volume of redo generated, in bytes, so we simply divided
these values by (1024 * 1024) to arrive at our redo I/O bandwidth in units of MB/second.
Since these statistics are counter-based metrics that continuously increment over time, you need to subtract the
previous snapshot's value from the current snapshot's value and divide by the number of seconds between snapshots
to calculate your I/O bandwidth rates. In this recipe, we used Oracle's LAG function to achieve this. We also used 11g
PIVOT method to dynamically build a list of aliased columns for each of the metrics we wanted to capture. We like this
approach because it reduces the number of lines of code and reduces self-joining, potentially large AWR tables.
Additionally, similar to logic presented in Recipe 5-3, you need to adjust your write-related I/O bandwidth
numbers to account for either ASM normal or high redundancy. For example, write operations with normal
redundancy will write to both primary and mirrored extents, so a single physical write as measured from database-
level system statistics will translate to two physical writes inside the storage. When conducting I/O bandwidth
capacity planning for ASM, these additional mirrored writes will need to be considered and weighed against the
capabilities of the storage infrastructure.

5-4. Determining ASM Redundancy Requirements
Problem
You need to decide what type of Oracle ASM redundancy to configure for your ASM disk groups on Exadata.

Solution
Determining your ASM disk group redundancy configuration is a matter of understanding data protection levels
offered with normal or high ASM redundancy, forecasting your usable disk space needs for the databases you will
place on Exadata, and the economics involved with under-protecting or over-protecting your disk storage.

■ Note For additional details on Oracle aSM redundancy on Exadata, please see recipes 6-5 and 9-4.

With Oracle ASM normal redundancy, assuming you've spread your underlying Exadata grid disks evenly across
cell disks and storage cell, your databases can survive the failure or planned outage of an entire cell disk without
causing an availability outage. With ASM high redundancy, you can survive two simultaneous storage cell outages
without impacting data availability.
The decision to choose normal or high redundancy, or even no redundancy, is a matter of balancing your
organization's tolerance for risk and the economics of reduced storage capacity. For example, some companies select
a high redundancy ASM disk group configuration to protect against media failure that may occur during Exadata
Storage Server patching; when patching, it is usually necessary to take a storage server and all its disks offline. With
normal redundancy configurations, doing so will leave you vulnerable in the event another storage server or set of
disks fails while patching.

How It Works
Normal redundancy mirrors primary ASM extents on disks in a different storage cell, where high redundancy
establishes two primary extent mirrors on different storage cells. In each case, this reduces your total usable storage
capacity or database storage. With a normal redundancy configuration, you lose half of our raw capacity and with high
redundancy you lose two-thirds of your usable capacity. Table 5-2 provides a summary of total usable capacity based
on your Oracle ASM disk group redundancy configuration.