在Metalink上找到了一个Oracle Database 11gR1 和 10gR2 ASM Best Practices 的说明文档，一共是40页，花点时间，看了一下，主要讲的还是一些ASM的基础知识。 不过了解这些对理解ASM 是很有必要的。
看的时候，觉得一些注意的地方，都copy了一份，粘贴如下：
1. ASM 的限制：
ASM has the following size limits:
（1） 63 disk groups in a storage system
（2）10,000 ASM disks in a storage system
（3） 1 million files for each disk group
2. ASM 的镜像
ASM uses a unique mirroring algorithm. ASM does not mirror disks; rather, it mirrors extents. As Thus when a block is written to a file, each extent in the extent set is written in parallel. However, when a block is read from disk, it is always read from the primary extent, unless the primary extent cannot be read.
ASM 采用的是extent级别的镜像，而非disks，在写extent的时候，是并行写，但是读的时候，仅从primary extent进行读，除非primary extent 不可以用的时候才会去读mirror extent。
这一点和我们的RAID 镜像有一定的区别。
3. ASM 内存设置
The SGA parameters for database instance needs slight modification to support ASM extent maps and other ASM information. Note if the 10g Automatic Memory Management feature is being used on the database instance, then the following sizing data can be treated as informational only or as supplemental data in gauging appropriate values for the SGA. Oracle highly recommends using the Automatic Memory Management feature.
The following are guidelines for SGA sizing on the database instance:
（1）Processes = Add 16
（2）Shared_pool = Add additional 600k
（3）Large_pool – Additional memory is required to store extent maps. Aggregate the values from the following queries to obtain current database storage size that is either already on ASM or will be stored in ASM. Then determine the redundancy type that is used (or will be used), and calculate the shared_pool, using the aggregated value as input.
select sum(bytes)/(1024*1024*1024) from v$datafile;
select sum(bytes)/(1024*1024*1024) from v$logfile a, v$log b
where a.group#=b.group#;
select sum(bytes)/(1024*1024*1024) from v$tempfile where status='ONLINE';
For diskgroups using external redundancy = (Every 100Gb of space needs 1Mb of extra shared pool) + 2M
For diskgroups using Normal redundancy: (Every 50Gb of space needs 1Mb of extra shared pool) + 4M.
For diskgroups using High redundancy: (Every 33Gb of space needs 1Mb of extra shared pool) + 6M.
这个是一个10g RAC 测试平台的默认值：
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
+ASM1
SQL> show parameter processes
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
aq_tm_processes integer 0
db_writer_processes integer 1
gcs_server_processes integer 1
job_queue_processes integer 0
log_archive_max_processes integer 2
processes integer 40
SQL> show parameter share
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
hi_shared_memory_address integer 0
max_shared_servers integer
shared_memory_address integer 0
shared_pool_reserved_size big integer 2516582
shared_pool_size big integer 48M
shared_server_sessions integer
shared_servers integer 0
SQL> show parameter large_
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
large_pool_size big integer 12M
--这里的large pool 需要结合自己的业务进行调整
4. ASM 实例和DB 实例之间的关系
Since ASM manages diskgroups and hold the database files and its metadata, a shutdown of the ASM instance will cause all client-database instances to shutdown as well.
In normal shutdowns, the ASM instance will begin shutdown and wait for all sessions to disconnect, just as typical database instances.
Note, however that ASM has a persistent database instance connection, thus the database instances must be shutdown first, in order for ASM to complete shutdown.
--DB 实例先shutdown 之后 ASM 实例才能shutdown
In case of ASM SHUTDOWN IMMEDIATE or ABORT, ASM will immediately terminate any open connections (including the database instance connections), and as a result, all dependent databases will immediately abort; i.e., databases will ungracefully shutdown.
In a single ASM instance configuration, if the ASM instance fails while diskgroups are open for update, ASM instance recovery will be performed upon the restart of ASM by reading the disk group logs.
In RAC environments, with multiple ASM instances sharing disk groups, if one ASM instance should fail, another node’s ASM instance automatically recovers transient ASM metadata changes caused by the failed instance; i.e. performs instance recovery.