ORACLE10g版本推出时，为了简化中存储端的配置，新推出了(Automatic Storage Management --自动存储)特性，该特性拥有易管理，高自动性，并且，拥有号称超越裸设备IO性能。升级到11gR2版本后，又被正名为传说中的ASMFS，这也说明了ORACLE对这一特性的重视程度。
因此从今天起，三思决定花个三二分钟时间，跟大学一块学学关于ASM的那点儿事儿，另注，本文操作的版本为10gR2。
1、About ASM 实例
ASM 实例与 ORACLE 实例差不多，都是 由 sga 和一堆后台进程组成，从功能上来看，区别在于oracle实例管理的是数据库，而asm实例只是管理asm盘阵。
通过Oracle EM或DBCA都可以对asm进行一些配置，不过三思觉着管理asm括弧实例的最佳工具仍是sql*plus，在进入sql*plus前也需要设置ORACLE_SID的环境变量，该环境变量通常是+ASM[node#] 。
ASM 实例没有数据字典之类的东东存储用户系统，因此最常见的连接认证方式就是操作系统认证as sysdba进入(OSDBA组的用户)。如果是通过远程连接的话( 比如远程通过tnsnames或OEM管理)，也可以使用密钥文件进行验证，该密钥文件直数据库的密钥文件在命名规则及使用规则上完全一模一样。如果使用dbca建库的话，默认就会创建asm的密钥文件，当然也可以自行手动通过orapwd命令进行创建，与数据库的密钥文件有所不同的是，asm 的密钥文件对应的用户只有一个----sys。
提示：什么是 ASMLib ！
即ASM support Library，是由ORACLE提供的简化管理操作系统管理的API 。
1.1、启动 / 关闭 ASM 实例
ASM 实例与DB实例高度相似，启动和停止实例的命令也一模一样，就启动来说，也同样拥有 NOMOUNT/MOUNT/OPEN /FORCE 几种状态。
- NOMOUNT ：仅启动实例；
- MOUNT 、OPEN：启动实例并加载磁盘，注意加载的是磁盘组(如果当前未创建或配置任何磁盘组，则提示敬告信息)，OPEN选项对于ASM实例无意义，等同于MOUNT。
- FORCE ：相当于先执行shutdown abort，然后再startup。
演示如下(注意别忘了先设置操作系统环境变量ORACLE_SID)，先启动到NOMOUNT：
[oracle@jssdbn1 ~]$ export ORACLE_SID=+ASM1
[oracle@jssdbn1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 - Production on Wed May 19 08:34:22 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to an idle instance.
SQL> startup nomount
ASM instance started
Total System Global Area 130023424 bytes
Fixed Size 2082208 bytes
Variable Size 102775392 bytes
ASM Cache 25165824 bytes
SQL> select name,state from v$asm_diskgroup;
NAME STATE
------------------------------ -----------
ASMDISK1 DISMOUNTED
ASMDISK2 DISMOUNTED
SQL> select instance_name,status from v$instance;
INSTANCE_NAME STATUS
---------------- ------------
+ASM1 STARTED
加载磁盘组，注意，不是alter database哟：
SQL> alter diskgroup all mount;
Diskgroup altered.
SQL> select name,state from v$asm_diskgroup;
NAME STATE
------------------------------ -----------
ASMDISK1 MOUNTED
ASMDISK2 MOUNTED
这样，该ASM就可以提供存储服务了。
提示一点，在版本中，ASM是依赖于CSS守护进程的，因此在启动ASM 实例前要确保css守护进程已经启动 。 CSS(Cluster Synchronization Services) 守护进程 用来维持ASM 及客户端数据库实例间的一致性 同步 ，如果是通过dbca建库的话，那么CSS守护进程默认即会启动(跟随系统reboot)。
检查css守护进程是否启动非常 简单 ，直接使用crsctl check cssd即可，如果启动的话会收到"CSS appears healthy"的返回消息，例如：
关闭ASM实例，简单了，NORMAL/IMMEDIATE/TRANSACTIONAL/ABORT几个选项的定义与关闭普通数据库实例完全一模一样！例如：
1.2、关于ASM实例的初始化参数
ASM 实例的初始化参数形式上与数据库的初始化参数相同，也分spfile和pfile，操作方式也完全相同，只不过具体的参数及参数值略有差异，大多数数据库的初始化参数在这里也能见到，并且某些参数意义都完全相同，同样也有一些参数虽然见到了，不过并不需要设置，这个可以理解，毕竟asm只有实例，相对比数据库的初始化参数要简单的多了，还有一些参数则是数据库初始化参数中没有的。比如ASM开头的那几个初始化参数，俺争取把差异的部分都列出来写明了。
ASM 实例在内存占用这块还是比较轻量级的，基本上有个100m空间就很充足了 ，因此内存这块相关参数就不说了，下面说说几个ASM实例特别需要的参数。
首先，初始化参数中的INSTANCE_TYPE，该参数必须被设置为ASM，如：
标识要启动的实例是ASM，而不是数据库实例(数据库实例对应类型为RDBMS)。
与ASM相关的初始化参数有三个：
- ASM_POWER_LIMIT ：指定磁盘rebalance的程度，有0-11个级别，默认值为1，指定的级别越高，则rebalance的操作就会越快被完成(当然这也意味着这个时间段内将占用更多的资源)，指定级别较低的话，虽然rebalance操作会耗时更久，但对当前系统的IO及负载影响会更少，这中间的度需要根据实际情况衡量。另外，这个参数指定的只是一个默认值，在操作过程中，即可以随便动态修改，也可以在语句级命令行时指定power，覆盖该默认值。
提示：关于rebalance操作，如果你没接触过，还不明白是什么意思，没关系，继续往下看！
- ASM_DISKSTRING ：用最简单的话说，就是设置ASM启动时检查的磁盘，该选项可以同时指定多个值，并且支持通配符。比如说，只检查/dev/dsk/下的设备，可以设置该参数如下：/dev/dsk/*，默认情况下该参数为空，为空的话，表示ASM将查找系统中所有ASM拥有读写权限的设备。
- ASM_DISKGROUPS ：指定实例启动或alter diskgroup all mount语句时要加载的磁盘组，如果为空的话，那么实际就仅启动到NOMOUNT状态了。如果是使用SPFILE的话，该参数一般不需要手动修改，ASM能够自动更新该初始化参数中的值。
修改 ASM 实例初始化参数文件的命令规则与数据库初始化参数完全相同 ，比如说：
2、管理磁盘
本节简单给大家描述下关于ASM磁盘组的操作，关于ASM磁盘组的管理其实非常简单(也非常少)，主要是由于10gR2中这个东西透明 度不够 ，ORACLE提供的功能有限，因此我们能够做的操作就更加有限了，因此三思决定随便写个几百W字大家凑和着看看就得了，不深入了。
OK ，下面步入正题。
ASM 磁盘组的管理方式呢也比较多，比如像DBCA、EM、SQL*PLUS等均可操作(不同工具 易用性不同，不过 功能也有差异)，除此之外ORACLE还专门提供了ASMCMD命令行方式，像操作文件系统一样来操作磁盘组。本节操作主要使用sql*plus命令行工具，关于asmcmd命令行中的命令，感兴趣的朋友可以期待本文外传~~~
在管理ASM之前不得不提与ASM相关的动态性能视图，这些视图将对我们后面的操作起到重要作用，查询中ASM相关视图可以通过下列语句：
SQL> select * from dict where table_name like 'V$ASM_%';
TABLE_NAME COMMENTS
------------------------------ ------------------------------------------
V$ASM_ALIAS Synonym for V_$ASM_ALIAS
V$ASM_CLIENT Synonym for V_$ASM_CLIENT
V$ASM_DISK Synonym for V_$ASM_DISK
V$ASM_DISKGROUP Synonym for V_$ASM_DISKGROUP
V$ASM_DISKGROUP_STAT Synonym for V_$ASM_DISKGROUP_STAT
V$ASM_DISK_STAT Synonym for V_$ASM_DISK_STAT
V$ASM_FILE Synonym for V_$ASM_FILE
V$ASM_OPERATION Synonym for V_$ASM_OPERATION
V$ASM_TEMPLATE Synonym for V_$ASM_TEMPLATE
9 rows selected
这其中，V$ASM_ALIAS视图中记录文件别名信息，V$ASM_CLIENT返回当前连接的客户端实例信息，V$ASM_DISK*相关视图中记录的是ASM管理的磁盘及磁盘组信息，V$ASM_OPERATION记录当前磁盘的操作信息，例如：
SQL> select group_number,name,state,total_mb,free_mb from v$asm_diskgroup;
GROUP_NUMBER NAME STATE TOTAL_MB FREE_MB
------------ ------------------------------ ----------- ---------- ----------
1 ASMDISK1 MOUNTED 20472 18667
2 ASMDISK2 MOUNTED 16378 14621
SQL> select header_status,name,failgroup,path,total_mb,free_mb from v$asm_disk where GROUP_NUMBER in(1,2);
HEADER_STATU NAME FAILGROUP PATH TOTAL_MB FREE_MB
------------ ------------------------------ ------------------------------ ------------------------------ ---------- ----------
MEMBER ASMDISK2_0000 ASMDISK2_0000 /dev/raw/raw5 8189 7309
MEMBER ASMDISK2_0001 ASMDISK2_0001 /dev/raw/raw6 8189 7312
MEMBER ASMDISK1_0000 ASMDISK1_0000 /dev/raw/raw1 10236 9333
MEMBER ASMDISK1_0001 ASMDISK1_0001 /dev/raw/raw2 10236 9334
在真正开始操作ASM之前呢，我觉着还是有必要先描述一下关于ASM磁盘总的原则供参考。
添加或删除磁盘的影响
当发生添加/删除磁盘组中磁盘的操作时，ASM能够自动平衡。对于普通的删除操作(无force选项)，被删除的磁盘在该上数据被有效处理前并不会立刻释放，同样，新增磁盘时，在重分配工作完成前，该盘也不会承担I/O负载的工作。
ASM 如何处理磁盘故障
ASM 中的磁盘组在三思看来可以分成两类：普通磁盘组和failure磁盘组，后者又与ASM的冗余方式有所关联。普通磁盘组就是标准的存储单元，ASM可以向其可访问的磁盘组中读写数据，failure磁盘组是为了提高数据的高可用性。ASM中的磁盘冗余策略非常简单，概要成三类：外部冗余、标准冗余和高度冗余，其中前者与failure磁盘组无关，如果设置了后者，那么该磁盘组就必须拥有failure磁盘组。听起来像在说failure磁盘组是普通磁盘组的子集，其实差不多可以这么理解，外部冗余的话磁盘属于磁盘组，内部冗余的话，磁盘属于磁盘组的同时，还属于某个(并且只能是一个)failure磁盘组。
比如说对于标准冗余(Normal Redundancy)，ASM要求该磁盘组至少要拥有两个failure磁盘组，即提供双倍镜像保护，对于同一份数据(ASM中镜像单位不是磁盘，也不是块，而是一种AU的单位，该单位大小默认是1M)将有主从两份镜像，并且ASM通过算法来自动确保主、从镜像不会存在于同一份failure磁盘组，这样就保障了就算整个failure磁盘组都损坏，数据也不会丢失。至于高度冗余(High Redundancy)就更安全了，它至少需要三个failure磁盘组，也就是一份AU有一主多从的镜像，理论上将更加安全。
如果磁盘发生损坏，那么损坏的磁盘默认自动offlice并被drop掉，不过该磁盘所在的磁盘组仍将保持MOUNT状态，如果该盘有镜像的话，那么应用不会有影响，镜像盘将自动实现接管--只要不是所有failure磁盘组都损坏掉，否则的话，该磁盘组将自动DISMOUNT。举个例子吧，某标准冗余的failure组有6个盘(对应6个裸设备)，假如说此时坏了一块盘，没关系，操作继续，坏了那块会被自动dropped，剩下的5块盘仍然能够负担起正常的读写操作。
ASM 扩展性
- 最多支持63个磁盘组；
- 最多支持10000个磁盘；
- 最大支持4pb/磁盘；
- 最大支持40 exabyte/ASM存储；
- 最大支持1百W个文件/磁盘组；
- 外部冗余时单个文件最大35tb，标准冗余时单个文件最大5.8tb，高冗余度时单个文件最大3.9tb。
2.1 添加磁盘组
DBCA 中创建磁盘组想必大家都很熟悉了，对，不过是点两下鼠标，SQL*PLUS下操作也很简单，主要是使用CREATE DISKGROUP语句，该语句的语法如下：
CREATE DISKGROUP diskgroup_name
[ { HIGH | NORMAL | EXTERNAL } REDUNDANCY ]
[ FAILGROUP failgroup_name ]
DISK [ NAME disk_name ] [ SIZE size_clause ] [ FORCE | NOFORCE ] ...;
语法很简单，大多数都是可选项：
- 首先要指定的就是磁盘组名称(diskgroup_name)；
- 指定冗余度，有三个选择：HIGH(高度冗余>三路)、NORMAL(标准冗余--双路)和EXTERNAL(外部存储冗余)；
- 选择是否指定FAILGROUP(如果选择非external则必须指定)；
- 指定该磁盘组中的成员(对应的LUN)，在指定成员时一般能够自动检测出磁盘的容量，不过如果DBA基于某些方面的考虑，希望限制ASM使用的空间的话，也可以在指定成员过程中，顺便指定大小(只要指定的大小不超出磁盘实际容量)，在添加成员时，ASM也会自动检查磁盘头以确定该磁盘是否被加入到其它的磁盘组中，当发现该盘已加入其它磁盘组的话，你可以通过FORCE选项来强制修改该盘所属磁盘组。
2.2 修改磁盘组
事物总是在变化中前进，这是事物的一般规律，磁盘组也不例外，在其创建完之后，保不齐什么时候可能就需要加或删个磁盘，或者修改某个盘的大小(如果还有机会改的话)。这时候你就需要ALTER DISKGROUP语句了，ALTER DISKGROUP语句的语法太简单(灵活)了，因此这里三思就不列了，后面通过几个实际应用的示例来说明其语法规则。
ASM 最好的一点就是，不管你是加还是删磁盘组中的磁盘，它都能自动进行平衡，确保该磁盘组中每块盘存储的数据量平均，以实现最优化的IO性能，并且这一过程不会对数据造成影响
2.2.1 添加磁盘
比如，添加一个磁盘到磁盘组asmdisk1，语句如下：
事实上，alter diskgroup添加磁盘时，也可以使用通配符，比如添加所有raw_a0开头的设备，可执行语句如下：
Alter diskgroup asmdisk1 add disk '/dev/raw/raw_a0*' ;
再比如添加raw_a5,raw_a6,raw_a7，可以执行语句如下：
Alter diskgroup asmdisk1 add disk '/dev/raw/raw_a[567]' ;
总之非常灵活，大家可以根据实际情况自行尝试以简化操作。这也属于优化着干活的范畴嘛。
注意哟，语句虽然执行了，不过ASM需要自动平均磁盘组中的数据，这必然需要消耗一定的时间(视数据量多少)，默认情况下ALTER DISKGROUP语句并不会等待所有工作全部完成才返回控制权，
要监控后台进行的操作，可以通过V$ASM_OPERATION视图查询。
如果希望ALTER DISKGROUP语句完成所有工作才返回的话，可以在执行时附加REBALANCE WAIT子句，这样该语句就会等待自动平衡的操作，直接所有操作完成才返回结果，当然在等待期间，如果你改主意了不愿意继续等待，CTRL+C中断即可获得控制权，而平衡的操作不受影响，会在后台继续进行。
2.2.2 删除磁盘
虽然删除磁盘也涉及到的重新平衡，因此删除跟添加还有点儿不同，就是当删除磁盘时，当ASM发现怎么平衡都平衡不过来时(比如剩下的磁盘空间不足以存放所有数据时)，删除操作也会失败。这种情况要么先删数据，要么取消删除的操作。
简单举个例子，比如说删除asmdisk2磁盘组中的asmdisk2_0001磁盘，操作如下：
不知道算不算是优点，由于前面提到的ASM自动平衡的特性，上述语句返回后并不代表磁盘已经被删除，此时后台可能由于正忙碌地执行着IO重平衡的工作，因此如果在这个当口，DBA忽然意识到操作失误，其实磁盘并不需要被删除，那也可以马上通过alter diskgroup dgname undrop disks语句来取消删除的操作，例如：
只要删除操作还没有真正完成，任何就会被取消，否则的话，上述语句也挽回不了什么了，如果希望挽回，那DBA只能再通过ADD语句将该磁盘重新加入到磁盘组了。
2.2.3 修改磁盘大小
ASM 中的磁盘也可以被RESIZE--扩大或缩小，不过需要注意的是，扩大的话，要确保该磁盘对应的裸卷确实有足够的空间去扩大(比如该卷原有20g，创建时仅用了，则最大可扩大到20g-块头占用的nM空间)；缩小的话，要确保缩小后剩余的空间仍以放的下当前磁盘上已存在的数据，不然操作就会报错。
具体的操作是很简单的，例如将磁盘组asmdisk2的磁盘asmdisk2_0000的磁盘空间调整为1000m(原为8189m)，操作如下：
2.2.4 手动平衡磁盘组
一般情况下ASM都会自动对其下的磁盘组进行平衡，不过ORACLE也提供了手动平衡磁盘组的方式，通过alter diskgroup ... power 语句。前面提到过磁盘组的平衡度有0到11多个级别，默认是按照ASM_POWER_LIMIT初始化参数中设置的值，手动平衡的话，设置的平衡度可以与初始化参数中并不相同，例如，设置磁盘组平衡度为5，语句如下：
手动平衡磁盘组可能涉及大量的工作，该操作可能费时较久，因此DBA在执行该语句时，一定要注意该操作对IO性能的影响。
另外再次强调，上述语句将很快返回diskgroup altered的提示，但这并不表示操作真正完成，它只是反馈语句提交而已，查看磁盘后台的操作，可以通过v$asm_operator视图，或者在语句执行时增加wait子句，这样ASM将会等到操作真正完成时，才返回提示信息。
2.3 mount/unmount 磁盘组
只有被mount的磁盘组才能被使用并执行add/drop等磁盘操作，中的磁盘组默认会在ASM实例启动时自动加载，当然也可以手动通过命令行语句mount/unmount磁盘组。
查询ASM实例中创建的磁盘组可以通过V$ASM_DISKGROUP视图查看，例如：
SQL> select group_number,name,state,total_mb,free_mb from v$asm_diskgroup;
GROUP_NUMBER NAME STATE TOTAL_MB FREE_MB
------------ ------------------------------ ----------- ---------- ----------
1 ASMDISK1 MOUNTED 20472 18667
2 ASMDISK2 MOUNTED 16378 14621
当前两个磁盘组均为MOUNT状态，要将其置为UNMOUNT，执行语句如下，例如将ASMDISK2磁盘组UNMOUNT：
SQL> alter diskgroup asmdisk2 dismount;
Diskgroup altered.
SQL> select group_number,name,state from v$asm_diskgroup;
GROUP_NUMBER NAME STATE
------------ ------------------------------ -----------
1 ASMDISK1 MOUNTED
0 ASMDISK2 DISMOUNTED
注意哟，UNMOUNT磁盘组的话务必慎重操作，要确保UNMOUNT的磁盘组中保存的文件对应的数据库当前未启动，而且该操作也会直接导致数据库SHUTDOWN。
再将其置回MOUNT状态，操作如下：
SQL> alter diskgroup asmdisk2 mount;
Diskgroup altered.
SQL> select group_number,name,state from v$asm_diskgroup;
GROUP_NUMBER NAME STATE
------------ ------------------------------ -----------
1 ASMDISK1 MOUNTED
2 ASMDISK2 MOUNTED
2.4目录及文件
ASM 磁盘组中文件和目录的管理自动化水平相当高，应该说基本上完全不需要DBA参与，它自己就能玩的很好，当然，如果你非要动动手，那也是可以的。
2.4.1 管理磁盘组目录
创建新目录：
修改目录名：
删除目录名：
实际上，ASM中目录和文件的管理，也可以通过ASMCMD命令行方式进行，该命令行进入之后，是一个类似文件系统的管理界面，ORACLE提供了一些最基础的，如cd、ls、mkdir、rm等等几个有限的操作命令，如果对这部分内容感兴趣，可以参考官方文档中的介绍，或者搭个环境实践操作，可用命令很少且简单，熟悉Linux/Unix的话极易上手。
2.4.2 管理别名(Alias Names)
别名就是外号，比如说当系统自动产生的名称太过复杂不怎么好记，DBA可以通过别名，为它创建一个简单化的名称，而又不会对其现有名称造成任何影响。ASM中创建别名是通过alter diskgroup的alias子句实现，支持增加/修改/删除等多项操作。V$ASM_ALIAS视图中可以查询到当前实例中创建的别名。
例如，增加别名：
SQL> alter diskgroup asmdisk2 add alias '+ASMDISK2/repdb/datafile/temp01.dbf' for '+ASMDISK2/repdb/TEMPFILE/TEMP.267.714576831';
Diskgroup altered.
修改别名：
SQL> alter diskgroup asmdisk2 rename alias '+ASMDISK2/repdb/datafile/temp01.dbf' to '+ASMDISK2/repdb/TEMPFILE/temp01.dbf';
Diskgroup altered.
删除别名：
不管是添加/删除或是修改别名，对原有文件路径均不会有影响。
2.4.3 删除磁盘组中文件/别名
破坏总是最简单的，当然我不是说删除就一定是破坏，不过从严谨的角度讲，删除这样的操作要少做(没说不做)，做前得再三确认，三思而行并留有，即使做错了，还有的可能。
当然啦，ASM中遇到删除文件这样需求的机率很低，但也不是完全没有，比如说执行了数据库不完全恢复操作后，某部分数据文件就不再需要，而恢复操作不会处理这部分文件，为合理利用空间，就会需要DBA手动删除这类文件，真遇到这样的需求，表急，语法也是黑简单的呐，例如，删除磁盘组2上的别名temp01：
没错，即能删文件也能删别名，只不过如果删除的是文件的话，其关联的别名(Alias)也会被自动删除。
2.4.4 删除磁盘组
太简单了，语法：drop diskgroup gpname即可！不演示了！需要注意一点，如果删除的diskgroup非空的话，直接执行上述语句会报错，这时候可以通过附加including contents子句，来自动删除该磁盘组中包含的文件。删除磁盘组的操作会自动修改spfile中ASM_DISKGROUPS初始化参数的值(如果使用了SPFILE的话)
3 、管理磁盘中的文件
ASM 中的磁盘与物理磁盘并非完全一一对应，由于ASM在存储数据时是打散处理，ASM中的(同一个)文件在保存时也并非保存在某个磁盘中，而是完全由ASM自动控制，甚至连创建文件时的文件名，都由ASM通过OMF(Oracle managed files)。
接下来，三思跟大家一起聊聊ASM中文件的那些事儿~~~
1 、ASM中支持的文件类型
大多数的ORACLE文件类型均能被ASM支持，注意，我说的是大多数，而没说全部，像trace文件、alert文件、dmp文件等还不能直接被存储到ASM中，注意，我说的是不能直接，没说不能间接。
下表列出了ASM直接支持的文件类型：
|
Control files |
|
Datafiles |
|
Redo log files |
|
Archive log files |
|
Trace files |
|
Temporary files |
|
Datafile backup pieces |
|
Datafile incremental backup pieces |
|
Archive log backup piece |
|
Datafile copy |
|
Persistent initialization parameter file (SPFILE) |
|
Disaster recovery configurations |
|
Flashback logs |
|
Change tracking file |
|
Pump dumpset |
|
Automatically generated control file backup |
|
Cross-platform. transportable datafiles |
如果想向ASM中存储任意类型的文件，FTP会是个好方式，yangtingkun的这篇BLOG详细描述了这一方法：http://space.itpub.net/4227/viewspace-448289，通过这一方式，可以将任意文件放入ASM中，而不用考虑是否能够被直接支持，这其实提供了很大的灵活度，ASM不再是个严丝合缝的黑匣子，它也是有缝儿的~~
２、ASM中的文件名
ASM 创建的文件均由系统自动命名，这种命名方式官方定义为 完全定义文件名 (Fully Qualified Filename) ，这种方式命名的文件包含完整的文件路径，比如像这样的形式：
+ASMDISK2/repdb/TEMPFILE/TEMP.267.714576831
上述名称是在文件创建时完全由ASM自动生成，事上述名称的生成格式为：
+diskgroup/dbname/file_type/file_type_tag.file.incarnation
- +diskgroup ：磁盘组名称；
- dbname ：的DB_UNIQUE_NAME参数值；
- file_type ：创建的文件类型，比如CONTROLFILE/DATAFILE/ONLINELOG/ARCHIVELOG/TEMPFILE/BACKUPSET/FLASHBACK等等，类型众多此处不一一例举；
- file_type_tag ：文件类型的标签，比如表空间对应的通常为该表空间名称；
- file.incarnation ：文件序号+incarnation，用来确保文件的唯一；
实际上，即使DBA在创建时想手动指定这样格式的文件名也是不行的(即使指定了，创建的也只是别名)，例如：
SQL> alter tablespace jsstbs add datafile '+ASMDISK2/repdb/datafile/jsstbs.280.722005095' size 100m;
alter tablespace jsstbs add datafile '+ASMDISK2/repdb/datafile/jsstbs.280.722005095' size 100m
*
ERROR at line 1:
ORA-01276: Cannot add file +ASMDISK2/repdb/datafile/jsstbs.280.722005095. File has an Oracle Managed Files file name.
指定非OMF格式的方式名：
看起来o了，其实不然，到asmcmd下查看一下实际创建的文件：
ASMCMD> pwd
+ASMDISK2/repdb/datafile
ASMCMD> ls -l jsstbs*
Type Redund Striped Time Sys Name
DATAFILE UNPROT COARSE JUN 18 12:00:00 Y JSSTBS.263.714575967
DATAFILE UNPROT COARSE JUN 18 13:00:00 Y JSSTBS.271.722005397
N jsstbs01.dbf => +ASMDISK2/repdb/datafile/JSSTBS.263.714575967
N jsstbs02.dbf => +ASMDISK2/repdb/datafile/JSSTBS.271.722005397
由上可以看出，系统虽然创建了名为jsstb02.dbf的文件，但只是别名，实际指向了由系统自动命名的 JSSTBS.271.722005397 。
即然文件创建时无法指定实际文件名及路径，那么创建语句当然还可以更简化，例如：
SQL> alter tablespace jsstbs add datafile '+ASMDISK2' size 10m;
Tablespace altered.
SQL> select file_name from dba_data_files where tablespace_name='JSSTBS';
FILE_NAME
--------------------------------------------------
+ASMDISK2/repdb/datafile/jsstbs01.dbf
+ASMDISK2/repdb/datafile/jsstbs02.dbf
+ASMDISK2/repdb/datafile/jsstbs.272.722005653
这样就完全由ORACLE的OMF控制和管理了。
如果设置了初始化参数db_create_file_dest，甚至连磁盘组名都不需要写了，例如：
SQL> show parameter db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string +ASMDISK2
SQL> alter tablespace jsstbs add datafile size 10m;
Tablespace altered.
通过上述示例，相信大家对于使用ASM做为存储的数据库，添加数据文件已无疑惑，不过如何添加其它类型文件，比如重做日志文件、归档文件(当然归档文件本来也就不需要特殊处理，只要LOG_ARCHIVE_DEST_n设置好即可)等还不明了，其实没有那么复杂，操作方式都是同理的。由上述示例可知，ASM中文件名完全可由其自行管理，因此在创建文件时，只需指定磁盘组路径即可，文件名嘛，就由ASM自己玩吧~~
对于现有系统想迁入ASM存储，最简单的方式，莫过于使用RMAN了，之前的系统文章中对此已有描述，此处不再重复深度，感兴趣的朋友可以翻看之前的三思笔记系统文章，或者浏览官方文档。
