Re: ASM on SAN

From: Karl Arao <karlarao_at_gmail.com>
Date: Mon, 22 Feb 2010 10:44:45 +0800
Message-ID: <12ee65601002211844w67a9580aw7a43db9a81f55d5c_at_mail.gmail.com>



Hi Chen,

I'm doing the same thing as Freek, minimum ASM disks of 4 and depends on the DB growth...
also I create 2x size of my "data" LUNs for my on-disk "backup" area and also you could have allowance for your Data Pump exports...

I recommend reading the doc "Oracle Database 10gR2 ASM Overview and Technical Best Practices"...
on the page 22 here are some good points:

ASM and database deployment Best Practices



ASM provides out-of-the-box enablement of redundancy and optimal performance. However, the
following items should be considered to increase performance and/or availability:
1. Implement multiple access paths to the storage array using two or more HBAs or initiators.
2. Deploy multi-pathing software over these multiple HBAs to provide IO load-balancing and
failover capabilities.
3. Use diskgroups with similarly sized and performing disks. A diskgroup containing large number
of disks provides a wide distribution of data extents, thus allowing greater concurrency for I/O and
reduces the occurrences of hotspots. Since a large diskgroup can easily sustain various I/O
characteristics and workloads, a single (database area) diskgroup can be used to house database
files, logfiles, and controlfiles.
4. Use diskgroups with four or more disks, and making sure these disks span several backend disk
adapters.
5. As stated earlier, Oracle generally recommends no more than two diskgroups. For example, a
common deployment can be four or more disks in a database diskgroup (DATA diskgroup for
example) spanning all back-end disk adapters/directors, and 8-10 disks for the Flash Recovery
Area Diskgroup. The size of the Flash area will depend on what is stored and how much; i.e., full
database backups, incremental backups, flashback database logs and archive logs. Note, an active
copy of the controlfile and one member of each of the redo log group are stored in the Flash
Recovery Area. Received on Sun Feb 21 2010 - 20:44:45 CST

Original text of this message