July 2006

Configuring Oracle ASM hidden parameters for EVA8000

By Tina Rose This knowledge brief explores configuring an Oracle 10g database on the Enterprise Virtual Array (EVA) by modifying a few Automated Storage Management (ASM) hidden parameters to see the effect of changing any of the default values. These ASM parameters are originally intended for use in very large databases (multiple TB to PB range) and are used to reduce the amount of metadata overhead on the ASM instance. Working with recommendations from Oracle engineering, Hewlett Packards Customer Focused Testing (CFT) evaluated variations of these parameters on smaller databases to see if it could affect or improve overall database performance. Please note the following ASM parameters must start with an _ (underscore): _asm_ausize (allocation unit) _asm_stripesize fine grain/coarse grain striping templates

For more information on setting and configuring these parameters, please view Oracle Metalink article number 368055.1.

Configuration
EVA8000, 2C12D, 168 drives, 146GB 15k ProLiant DL580G3, Windows 2003 R2 64-bit x86 Four, dual port HBAs, Storport driver 500GB database, Oracle 10.2.0.1, single instance

The following EVA configuration in Figure 1 was used for the testing. This configuration forces the special scenario of double-striping, in which both ASM and the EVA are striping the data across the same physical disks in the disk group. The configuration meets both HPs and Oracles best practices of having two separate disk groups: one for online/system data and the other for backup/recovery data. This best practice is not for performance purposes, but to ensure recovery efforts by separating these files. As such, a variation of this configuration was deployed for this test. Note: The second disk group was not used since recovery was not important for this testing.

Page: 1

Configuration 1
EVA 8000 (Logical View) 2 Disk Groups Disk Group Disk Group

LUN

LUN LUN LUN LUN

LUN

LUN LUN LUN

ASM Disk Group

ASM Disk Group

User Files System Files Control Files Online Redo Logs

Archive Logs Flashback Area RMAN Backups

Figure 1: ASM and EVA striping within the same EVA disk group

Problem Scenario
Is there a better way to manipulate ASMs striping algorithm to match the EVAs virtualization layer, and can it affect (hopefully improve) performance of the Oracle database? NOTE: This paper does not represent a performance test of the storage array. It is a configuration test of the Oracle database utilizing ASM parameters.

Method to Diagnose and Resolve

ASM offers the modification of two key parameters that affect the way data is striped across an ASM disk group. ASM Allocation Unit Size (_asm_ausize) determines the

Page: 2

extent size for all database files. For example, a 1GB data file using the default ausize of 1MB will consist of 1,024 extents of 1MB each. The same data file using an ausize of 8MB will consist of 128 extents of 8MB each. Data is striped across extents, which are distributed equally across the disks in the ASM disk group. ASM Stripe Size (_asm_stripsize) determines the I/O size for fine grain templates (coarse grain templates are always 1MB the Oracle maximum I/O size). Several configurations of ASM parameters were investigated. No changes to the default ASM parameters o o o Use ASM defaults for a baseline. The _asm_ausize default is 1MB. The _asm_stripesize default is 128KB for fine grain templates. All ASM templates remain at their defaults (for example, coarse grain for the data files, fine grain for the online logs, etc.).

Set _asm_ausize = 8MB o Change the allocation unit to 8MB which sets the size of the extents to 8MB for file allocation. Oracle will still perform I/O based on the file template defaults, but now it will send 8MB of data to the first extent (on the first LUN), and then the second 8MB to the next extent (on the second LUN), and so on. No changes are made to the ASM templates.

Set _asm_stripesize = 1MB o o o The default for fine-grain striped templates is 128KB stripes. This setting changes the stripe size to 1MB. In addition, all file templates for ASM are changed to fine-grain striping. It is not expected that this parameter will improve performance.

Set both parameters at once o o Set the _asm_ausize to 8MB and set the _asm_stripesize to 1MB. Leave the file templates (coarse, fine) to their defaults. This configuration takes advantage of the 8MB AU size for extent file allocations and increases the fine grain templates to a 1MB stripe size.

Two workloads were tested with these parameters. Small random reads/writes (OLTP-like workload) with 500 concurrent users Large sequential reads (DSS-like workload) with 25 concurrent users

What Was Discovered

The OLTP benchmark did not perform better with the ASM parameter changes. However, the DSS benchmark did improve when changing the _asm_ausize value.

Page: 3

Results
Random Reads/Writes (OLTP) The OLTP benchmark is based on Transaction per Second (TPS). It is benchmarked against the baseline configuration (ASM defaults). The results in Figure 2 show the effect of the various ASM parameter changes.
Random Read/Writes
125%

100% Performance % Against Baseline

100% 96% 96% 94%

75%

50%

25%

B A S E L I N E

0% ASM Defaults 8MB AU size Configuration 1MB stripe size Both

Figure 2 - OLTP Results The OLTP workload performed best without any changes to the ASM parameters, as shown by the left-most column. None of the other changes improved the overall results of the testing, nor did they have a substantial negative impact either. It is therefore recommended that the default ASM parameters not be changed unless absolutely necessary for very large databases. Sequential Reads (DSS) The results in Figure 3 summarize the large sequential read workload. Due to timeconstraints, CFT only focused on the _asm_ausize parameter. The last two configurations (1MB stripe size fine and both) were not tested as they were not expected to significantly impact the outcome of this particular workload. Of greatest interest is the second configuration, 8MB AU size. This benchmark consisted of running a single script against a non-indexed column to force a full table scan. The table consisted of 2,800,000,000 rows. It is measured by the completion time, and it is benchmarked against the baseline configuration (ASM defaults).

Page: 4

Sequential Reads
125% 116%

100% 100% Performance % Against Baseline

75%

50%

B A S E L I N E

ASM Defaults 8MB AU size

25%

0% ASM Defaults Configurations 8MB AU size

Figure 3 - DSS Results In this test, the DSS scripts completed much faster when the ASM allocation unit size was set to 8MB, as shown by the right-most column (it outperformed the baseline by completing in less time). The sequential reads appear to function better when the ASM allocation unit is set to 8MB. In this test, setting the ASM AU size improved overall DSS query performance by 16%.

Summary
The workload type will determine whether or not to set the ASM hidden parameters to values other than their defaults. For a random read/write (OLTP) workload, it is not recommended to change these parameters for small databases. For a sequential read (DSS) workload, queries performed better when the allocation unit parameter was set to 8MB. Our team recommends that customers look at this parameter in a pre-production environment to see if database performance is improved when running against their own data and workload.

About our team

HPs Customer Focused Testing explores in-depth Oracle solutions on HP servers and storage. Our efforts result in white papers, presentations, and demonstrations to our customers. For more information on our other, ongoing Oracle projects, please visit www.hp.com/go/hpcft.

Page: 5