HP AutoRAID 12H configuring an array for a database, here is a typical process for setting up a traditional array:

section 1	hp storage white paper
In addition, the same processes must be followed	administrators oftentimes don’t have all the critical
whenever disk drives are added or the environment	information. They don’t know the precise database
changes. Plus, these additional factors must be	performance requirements for each of the pieces,
considered:	behavior
	and they don’t know the performance1
	of the array in its multitude of configurations.
• current configuration

•desired additional capacity, performance, and availability

•whether the new disks will be stripe extensions of existing disks or be independent groups

here is a typical process for setting up a traditional array:

1.Determine number of disks, number of RAID groups, disks and disk type per RAID group, RAID level of each group, total LUNs, LUNs per RAID group, stripe depth.

2.Determine volume manager configuration, stripe size and depth, LUNs per logical volume.

3.Using the command station, set up the LUNs and their RAID levels and assign them to particular disks.

4.Set up the cache page size depending on the size of the I/Os coming in from the host.

5.Finally, before the new LUNs can be used, disks must be formatted, which can take many hours per array.

configuring an array for a database

Properly configuring an array for a database typically involves a large problem set with many variables. Many database administrators have been taught to isolate different pieces of the database in an attempt to optimize performance, availability, and recovery. This process, although based on sound objectives, is far too error-prone. This typically involves a large problem set with many, many variables. Unfortunately, database

In these real-world environments, it is typically far too time-consuming to try a number of different storage configurations, so database administrators typically apply rules from previous installations. The changing characteristics of newer versions of the database typically result in an unbalanced configuration that has “hot spots” that limit the performance of the system.

This entire process can take from a few hours to several days, depending on the skill of the administrator and the number and size of the LUNs. During much of this time the array is either unusable or must operate in a degraded performance mode. In other words, LUNs cannot be utilized until they have been formatted. This formatting takes up a lot of the array’s internal resources and bandwidth. After a LUN has been formatted, it can be used; but as long as other LUNs in the array are also going through their format process, the entire array will suffer from degraded performance.

Now, a short word about human error. Every step of this process has the potential for human error. Except in the grossest cases, errors would probably not result in data loss, but every miscalculation in this process would easily result in a decline in performance. Some of these declines could be huge. For example, miscalculating the RAID levels or the cache page size could severely degrade the array’s performance.

1.3