【技术开发 技术文章】
管理Oracle RAC中的存储（1）
1、什么是自动存储管理
自动存储管理（automatic storage Management ASM）是Oracle 10g的新特性。它对文件系统和逻辑卷标管理（logical volume Manager LVM）提供了纵向的管理，专门为Oracle Database文件建立。ASM可以为single SMP提供管理，也可为cluster中的多节点提供Oracle RAC支持。
ASM自动的将I/O分配到所有的可用资源，从而优化性能，免除了需要手工调节I/O的需要。ASM帮助DBA管理动态Database environment，可以实现在不关闭Database的情况下增大Database的size调节存储分配。
ASM可以维护冗余的data副本，从而提高可用性，可以被建立在卖方提供的存储机器之上。data 管理是通过选择data对可靠性和性能特点的类型来进行的，而不是对每个文件进行与人的交互选择实现的。
1）它的特点与好处
ASM将文件分成pieces，并将其分配到不同的磁盘上。ASM通过一个索引技术来跟踪每个piece的位置。传统的striping技术使用数学函数进行stripe的划分，从而实现逻辑卷标。
当改变存储能力时，ASM无需重新restripe所有数据，但会成比例的将一定的存储data添加或是移出，从而均匀的分配文件，维持磁盘I/O的平衡。这些是可以在Database运行期间进行的。
可以调节平衡操作的速度，加快它的速度或是降低对I/O子系统的影响。
ASM包括了镜像保护，不需要购买第三方的逻辑卷标管理。ASM特有的优点是其镜像是在文件的基础之上的。而不是以卷标为基础的。因此，相同的磁盘组可以通过镜像含有文件的保护或是根本不保护。
ASM支持data files、log files、control files、archive logs、RMAN的backup set和其他Oracle Database文件类型。ASM支持RAC，从而可以取代cluster的逻辑卷标管理器或是cluster file system（CFS）。
ASM是与Database绑定在一起的，没有单独作为用户安装的选项。它在企业版和标准版中都可获得。
2）ASM的新概念
ASM并没有阻碍已经存在的数据库功能。新的文件可以被创建作为ASM文件，同时已经存在的由旧的方法管理的文件可以被迁移到ASM中。
图中描述了Oracle Database中各种存储部件的关系。图的左边和中部显示的是以前发布的版本中的存储关系，右边显示了ASM引入的新概念，并且这些新概念只是针对文件的存储。Database files可被作为ASM文件存储。
在ASM中的存储层次上，顶层是ASM 磁盘组，，每个ASM file都只能包含在一个disk group中。然而，一个disk group可能包含的files是属于几个Databases的，并且一个Database可以使用多个disk groups存储data。如图所示，一个disk group是有多个ASM disks组成的，每个ASM disk只能属于一个disk group。一个ASM files总是被分配到同一个disk group的所有ASM disks中。ASM disks被分配成每1MB为一个分配单元（AU）。一个AU是ASM分配的最小的连续逻辑空间。ASM不允许物理 blocks 被分开存储在不同的AUs中。
3）ASM的一般结构
为了使用ASM，必须在打开Database Instance前先打开一个特殊的叫做ASM的Instance。ASM Instance并不加载Databases，但它对ASM 文件进行有效的元数据管理，从而使普通的Database Instance对其进行访问。ASM Instance和Database Instance需要访问的共同的disks的集合被称作disk groups。Database Instances直接访问ASM files的内容，它与ASM Instance交互只是得到关于这些files的布局信息。
一个ASM信息包含两类新的后台进程。一类用于协调disk groups的再平衡，被称作RBAL。另一类进程用于执行AU的移动，从而获得真正的再平衡。在同一时刻，可以有多个此类进程，被称作ARB0、ARB1等。一个ASM Instance也有很多与Database Instance相同的进程，如SMON、PMON、LGWR等。
每个使用ASM的Database Instance又增加了两类后台进程，分别是ASMB和RBAL。RBAL主要是用于全局的打开disk groups上的disks。在Database Instance startup时，ASMB作为一个前台进程，与ASM Instance连接。所有的Database和ASM Instance交互都是通过这个桥梁完成的。这包含物理文件的变更，如data file的创建、删除。并且通过此链接，定期交换更新统计信息，从而确保两Instance的可用性。
group Services被用于注册那些Database Instance需要的用于找到ASM Instance的连接。当一个ASM Instance加载一个disk group，它会向group Services注册相应的disk group和一个连接字符串。Database Instance知道disk group的名字，即可由此查到ASM Instance正确的连接信息。
像RAC一样，ASM Instances自身可以通过使用存在的Global cache Services（GCS）被clustered。在cluster中，每个node会有一个ASM Instance。正如现存的RAC配置，ASM需要OS使得disks在所有的ASM Instances上是全局可见的，不论节点。如果在一个节点上几个Database的不同Database Instance，则它们可以共享同一个ASM Instance。如果一个node上的ASN Instance失败了，所有与其连接的Database Instance也都将失败。与RAC一样，在其他节点上的ASM和Database Instance恢复那个失败的节点，并继续运行。
2、在RAC中的ASM Instance和Crash 恢复
每个disk group是自我描述的，包含了自己的文件目录、磁盘目录和其他数据，如元数据的日志信息。ASM自动的通过使用镜像技术（和外部磁盘组冗余一样）保护这些元数据。
对于多ASM Instance加载相同的disk groups的情况，如果一个ASM Instance失败，其他ASM Instance自动恢复由失败的Instance造成的暂时的ASM元数据的变更。这种情况叫做ASM Instance恢复，并且它是被Global cache Service自动的、及时的监控的。
对于多个ASM Instance挂载不同disk groups的情况，或是单个ASM Instance配置的情况，如果一个ASM Instance失败，并且此时ASM 元数据正在被打开用于更改，则那些尚未被加载到其他ASM Instance的disk groups将不被恢复，直到其被再次加载。当一个ASM Instance加载了一个失败的disk group，它会读取disk group log并恢复暂时的更改操作。这被称作是ASM crash恢复。
因此，在使用ASM clustered Instance，推荐将所有的ASM Instance都挂载相同的disk groups。然而，可能存在这样的情况，一个disk group在本地加载的磁盘上，只有当前node可见。
note：在这里，一个Oracle Database Instance的失败并会有重大影响，因为只有ASM Instance才可以更新ASM 元数据。
3、ASMLibs
它是一个用于ASM的支持库。其目的就是为了提供更好的高效的机制用于辨识和访问ASM disk groups中的块设备。此API 可以作为一个OS标准接口的替代物。
ASMLib可以被分成三个功能集合：
* 设备的发觉功能：在任何ASMLib中，必须被执行查找字符串经常包含了标识符前缀。对于Oracle提供的Linux ASMLib，前缀是ORCL。
* I/O处理功能扩展了OS接口，并提供了非常好的化的安排I/O操作的异步接口并管理I/O操作完成事件。这个功能被作为OS的内核应用于设备驱动程序
* 性能和可靠性功能，使用I/O处理控制结构在Oracle Database和后面的存储设备之间传送元数据，允许后面的存储有额外的逻辑。
对于ASMLib安装的过程，我就不累述了，在配置RAC是，已经用过了。
要说的是有两个packages，分别是oracleasmlib（提供实际的ASM库）和oracleasm（提供配置和ASM驱动程序使用的工具）。在执行/etc/init.d/oracleasm configure命令后，它创建了/dev/oracleasm加载点用于ASMLib与ASM驱动程序交互。在使用RAC时，它的安装和配置必须在所有节点上进行。
4、ASM管理——ASM Instance
1）ASM Instance功能
ASM Instance的主要目的是管理disk groups、保护其数据。ASM Instances也会将文件的布局信息传输给Database Instances。这样，Database Instance就可以直接访问存储在disk groups上的。
有几个新的disk group管理命令，都需要SYSDBA权限才能执行，并且必须从ASM Instance上发起。
可以添加新disk groups（CREATE DISKGROUP），可以修改已经存在的disk groups，为其添加、移除disks，等其他操作（ALTER DISKGROUP）。也可删除已经存在的disk groups（DROP DISKGROUP）。最后，可以阻止Database Instance与ASM Instance的链接。当ALTER SYSTEM ENABLE RESTRICTED SESSION 命令向ASM Instance发出，Database Instance就无法链接到ASM Instance上了。相反的，ALTER SYSTEM DISABLE RESTRICTED SESSION命令就可以从Database Instance上建立连接到ASM Instance上了。此命令是出于维护的目的，阻止Database Instances对disk groups的访问，ASM Instance可以start up并加载disk groups。
2）ASM Instance的创建
当创建一个ASM-enabled Database，DBCA会确定一个ASM Instance是否已经在主机上存在。如果存在，会显示一个disk groups列表，可以选择ASM-enabled Database要使用存储的disk groups。当没有发现ASM，DBCA会创建一个ASM Instance。作为ASM Instance创建过程的一部分，DBCA自动创建会在oratab文件中自动创建一个平台支持的实体，主要是用于discovery的目的。同时，ASM Instance参数文件和ASM Instance 密码文件也会自动创建。在创建ASM Instance前，可能需要指明部分ASM Instance的部分初始化参数。在ASM Instance被创建后，DBCA允许创建新的disk groups，用于存储 Database。
note：ASM Instance远远小于Database Instance。64MB 的 SGA对于最大的ASM Instance就已经足够了。
3）ASM Instance初始化参数
参数文件在$ORACLE_HOME/dbs中。
* INSTANCE_TYPE：对于ASM Instances应该设置为ASM
* DB_UNIQUE_NAME：指明ASM Instance管理disk groups的Service provider的名称。默认是 +ASM。
* ASM_POWER_LIMIT：它控制了rebalance 操作的速度。可选值的范围是1到11，其中11是最快的。如果省略该值，则默认是1。用于进行rebalance 操作的从属进程会根据手动的rebalance 命令指明的并发级别或是此参数指明的数量创建。
* ASM_DISKSTRING：它是一个依赖操作系统的值，用于限定ASM在发现disks集合。当新的disk被加载到一个disk group，每个已经加载此disk group的ASM Instance必须可以通过ASM_DISKSTRING发现该新加入的disk。如果没有设置，则被认为是NULL，并且ASM磁盘discovery会查找所有ASM Instance曾读写访问过的disks。
* ASM_DISKGROUPS：是ASM Instance启动或执行ALTER DISKGROUP ALL MOUNT命令时加，载到上的disk groups的名字列表。
note：ASM Instances使用的内部包是在LARGE POOL中执行的，所以，必须设置初始化参数LARGE_POOL_SIZE，并至少为8MB。对于其他buffer参数，可以使用其默认值。
具体实例：
INSTANCE_TYPE = ASM
DB_UNIQUE_NAME = +ASM
ASM_POWER_LIMIT = 1
ASM_DISKSTRING = ‘/dev/rdsk/*s2′, ‘/dev/rdsk/c1*’
ASM_DISKGROUPS = dgroupA, dgroupB
LARGE_POOL_SIZE = 8MB
PROCESSES = 25 + 15*<#DB inst using ASM for their storage>
4）RAC和ASM Instance
使用DBCA在cluster中创建ASM Instance，其步骤基本和single Instance环境是一致的。只是需要先选择oracle real Application clusters Database选项，再选择cluster中的所有节点。DBCA会自动在每个选择的节点上创建ASM Instance。第一个节点为+ASM1，第二个为+ASM2，等等。
相关的参数有：
* CLUSTER_DATABASE：在RAC环境中的每个ASM Instance中，此参数必须设置为TRUE。这使得全局缓存服务在每个ASM Instance上被打开。
* ASM_DISKGROUP：多个Instance可以有不同的设置值。但出于之前恢复的因素考虑，建议所有的ASM Instance都加载相同的disk groups集合。此外，所有用于存储RAC Database的disk groups必须被cluster中的所有ASM Instances共享。
如果在ASM Instance之间共享disk groups，它们的ASM_DISKSTRING初始化参数必须指向相同集合的物理媒介。然而，这个参数无需在每个节点有相同的设置。例如，假设在node A上一个disk group的物理磁盘被映射到/dev/rdsk/c1tld0s2，而在node B上映射到/dev/rdsk/c2tld0s2上，尽管两个节点有不同的disk string设置，它们却通过OS的映射定位到相同的设备上。这种情况可能会出现在node A和node B硬件配置不同的情况下。
ASM_POWER_LIMIT：多个Instances可有不同的设置值。
5）用EM发现新的ASM Instance
如果一个ASM Instance被加入一个已经存在的RAC环境中，它不会被自动Database control发现。必须执行下面的步骤令ASM target被发现：
①创建一个XML文件，具体格式如下：
<Target TYPE=”osm_instance” NAME=”+ASMn” DISPLAY_NAME=”+ASMn”>
<Property NAME=”SID” VALUE=”+ASMn”/>
<Property NAME=”MachineName” VALUE=”clusnode1_vip”/>
<Property NAME=”OracleHome” VALUE=”/u01/app/oracle/…”/>
<Property NAME=”UserName” VALUE=”sys”/>
<Property NAME=”password” VALUE=”manager” ENCRYPTED=”FALSE”/>
<Property NAME=”Role” VALUE=”sysdba”/>
<Property NAME=”Port” VALUE=”1521″/>
</Target>
其中：NAME，是ASM target名字，一般是hostname_ASMSid；DISPLAY_NAME，ASM target显示的名字，一般是+ASMn；SID，ASM SID（一般是+ASMn）；MachineName，主机名，在RAC环境中使用相应的VIP；OracleHome，ASM oracle Home；UserName，ASM Instance的用户名，默认是sys；password，ASM用户的密码；Role，ASM用户的角色，默认是SYSDBA；Port，ASM 端口号，默认是1521
②执行下面的命令
$ emctl config agent addtarget <filename>
③重启agent
$emctl stop agent
$emctl stop agent
note：这个步骤需要在每个node中执行，并且使用6一致的ASM Instance名字。
6）访问ASM Instance
ASM Instance不存在数据字典，所以只能通过SYSDBA身份使用OS验证这种方法与其建立连接。如果是建立远程连接，需要使用密码文件。
一般，SYSDBA权限是通过OS group进行授权的。在UNIX上，典型的是dba group。默认情况下，dba group的成员在节点的所有Instances上有SYSDBA权限，并有管理访问系统所有disk groups的权限。
7）额外的动态性能视图
在ASM Instance中，V$ASM_CLIENT为每一个使用通过此ASM Instance管理的disk group的Database Instance包含了一条记录。在Database Instance，每一个带有Database name和ASM Instance name的disk group都包含一条记录。在ASM Instance中V$ASM_DISKGROUP为每个被ASM Instance 发现的disk group 保存一条记录。在Database Instance中，V$ASM_DISKGROUP含有所有加载或是没有加载的disk groups的记录。
在ASM Instance中，V$ASM_TEMPLATE为每个加载到ASM Instance的disk group中的当前模版都会保留一条记录。在Database Instance中，会包含加载的disk groups的所有模版的记录。
在ASM Instance中，V$ASM_DISK为ASM Instance发现的每个disk保存一条记录，包括不属于任何disk group的disk。在Database Instance中，保存了Database Instance使用的disk groups中包含的disk的所有记录。
在ASM Instance中，V$ASM_FILE为加载到ASM Instance中的所有disk groups中的每个ASM file都保存一条记录。在Database Instance中，此视图无记录。
在ASM Instance中，V$ASM_ALIAS保存了每个加载到ASM Instance中的disk group现存的alias的记录。在Database Instance中，此视图无记录。
8）ASM Instance的开启与关闭
①ASM Instance会在Database Instance被打开的同时被打开。除非初始化参数文件包含了INSTANCE_TYPE=ASM。该参数设置为ASM时，会告知oracle 只打开ASM Instance而不是Database Instance。此外，对于ASM Instance，startup时的mount选项会尝试加载ASM_DISKGROUPS参数指明的disk groups，此时数据库没有被加载。
对于ASM Instance的STARTUP的其他子句与Database Instance是类似的。例如RESTRICT避免Database Instance与ASM Instance建立连接。OPEN对于ASM Instance是无效的。NOMOUNT对于ASM Instance，不会加载任何disk group。
②ASM Instance的关闭
只要与ASM Instance连接的Database Instances没有stop，shutdown ASM Instance的命令就不会执行。SHUTDOWN NORMAL命令在ASM中，ASM Instance会开始shutdown，并等待所有sessions断开，就像标准的Database Instance。SHUTDOWN IMMEDIATE | TRANSACTIONAL | ABORT命令对于ASM，它会立即终断连接的Database Instance，则所有连接的Database Instance立即被abort。但IMMEDIATE和TRANSACTIONAL时，ASM等待所有进程中的ASM sql完成后才会关闭asm Instance。在single ASM Instance设置中，如果在disk groups被打开并更新时ASM Instance失败，则在ASM Instance被重新初始化后，它会读取disk group的log，恢复所有的暂时的改变。对于多个ASM Instances共享disk groups，如果一个ASM Instance失败，其他ASM Instance会自动恢复由刚失败的ASM Instance发起的暂时的ASM 元数据改变。Database Instance的失败不会对ASM Instance有影响。一般希望ASM Instance总是在主机上运行。当主机重启了，一个ASM Instance必须被自动的开启。ASM的自动startup机制需要OS底层的支持。
5、ASM管理——disk groups和disks
1）ASM disk group
它作为管理一组disks集合的一个逻辑单元。ASM disks存储被从disk groups中添加和删除。每个ASM disk有一个ASM disk name，这个name对于对于cluster中的所有nodes都是一致的。ASM disk name的提取是十分必要的，因为对于不同主机可能使用不同的OS命名参照相同的disk。
ASM总是以1MB的AU块均匀的在一个disk group中的所有disks中分配文件。这被称为粗糙分带（COARSE striping）。这样ASM就避免了手工调节disk的需要。然而，在一个disk group中的disks应该有相同的size和性能特征，以便获得I/O调节的非常好的化。
一般情况下只有少量disk groups，例如，一个disk group用于work area，另一个作为回复area。
对于要求较低等待的files，ASM提供了细粒度fine-grained（128 KB）striping。FINE striping对每个AU继续划分。FINE striping将中级的I/O操作划分为多个小规模的I/O操作进行并发执行。
当files和disks增长的时候，只需管理不变数量的disk groups。从Database的角度看，disk group可以看做是一个指定的Database中创建files的默认位置。
note：每个disk group是自己描述的，它包含了自己的文件目录、磁盘目录和其他目录。
2）failure group
Oracle通过failure group来提供数据的高可用性。ASM使用的镜像算法并不是镜像整个disk，而是作AU级的镜像。所以很明显如果为各个failure group使用不同容量的disk是不明智的，因为这样在Oracle分配下一个AU的时候可能就会出现问题。在normal redundancy模式下，ASM环境中每分配一个AU都会有一个primary copy和一个second copy，ASM的算法保证了second copy和primary copy一定是在不同的failure group中，这就是failure group的意义。通过这个算法，ASM保证了即使一个failure group中的所有disk都损坏了，数据也是毫发无伤的。 对于没有使用外部冗余的系统，ASM通过故障组（failure group）提供了自己的内部的冗余机制，提高可用性。一个故障组，是一个磁盘组的子集，是由于其相关组件的故障导致不可用而被定义的一个磁盘集合。因此，对于给定的diskgroups，在两个不同的故障组中的disks一定不共享共同的故障组件。如果定义了diskgroup的故障组，ASM容忍同一个故障组中的多个disks同时发生故障。
3）disk group 镜像
正如前面所述，ASM提供三种冗余方式：外部冗余——external redundancy、普通冗余——normal redundancy、高冗余——high redundancy。外部冗余在ASM中不提供镜像，冗余是通过硬件来实现的。normal redundancy提供两倍镜像，至少需要两个failure groups。high redundancy提供三倍镜像，至少需要三个failure groups。
ASM使用了独特的镜像算法。它不是镜像磁盘，而是镜像AU。所以，为了对故障提供连续的保障，只需要diskgroup中剩余的容量，而不是一个热磁盘备份。不建议创建大小不同的故障组，因为这在分配二级AU时可能会引来问题。当ASM在diskgroup中的一个磁盘上给一个文件首次分配主AU时，会在diskgroup的另一个disk上分配一个该AU的镜像副本。一个给定的disk上的每个主AU都会在diskgroup上的几个其他disks的一个中存在相应的镜像AU。ASM会确保主AU和它的镜像AU不会存储在同一个故障组中。diskgroups的冗余要么可以是默认的普通冗余（文件是被两路镜像，至少需要两个故障组）；要么是高冗余，通过三路镜像提供高度的保护（至少需要三个故障组）。一旦一个diskgroup被建立，其冗余级别就不能被改变了。为了改变一个diskgroup的冗余级别，只能创建新的diskgroup，其有相应的适当的冗余级别，随后将datafiles通过RMAN或是DBMS_FILE_TRANSFER进行迁移。
下面将通过示例显示将如何创建使用故障组的diskgroup。在该示例中，在具有4个内部托盘的存储阵列上部署ASM普通冗余，其中每个托盘都有4个磁盘。隔离的失败组件是存储托盘，因此故障组的界限就是存储托盘，也就是说，每个存储托盘将与一个故障组关联。
SQL> create diskgroup DATA_NRML normal redundancy
FAILGROUP flgrp1 disk
‘/dev/rdsk/c3t19d3s4′,’/dev/rdsk/c3t19d4s4′,’/dev/rdsk/c3t19d5s4′,
‘/dev/rdsk/c3t19d6s4′
FAILGROUP flgrp2 disk
‘/dev/rdsk/c4t20d3s4′,’/dev/rdsk/c4t20d4s4′,’/dev/rdsk/c4t20d5s4′,
‘/dev/rdsk/c4t19ds4′
FAILGROUP flgrp3 disk
/dev/rdsk/c5t21d3s4′,’/dev/rdsk/c5t21d4s4′,’/dev/rdsk/c5t21d5s4′,
‘/dev/rdsk/c5t21ds4′
FAILGROUP flgrp4 disk
/dev/rdsk/c6t22d3s4′,’/dev/rdsk/c6t22d4s4′,’/dev/rdsk/c6t22d5s4′,
‘/dev/rdsk/c6t22ds4′;
创建为普通或高冗余diskgroups，分别包含的files有两个或三个镜像。分配的第一个文件AU被选作为主AU，镜像的AU被称作次AU。在高冗余的情况下，将会有两个次AU。这种主次AU的逻辑分组被称作AUset。一个AU set总是包含相同的data，因为他们是彼此的镜像版本。因此，当一个block被写，在AU set中的每个AU将并发的执行写操作。然而，当block被读取时，总是从主AU中读取，除非主AU不可读。需要明确，在diskgroup（和故障组）中的每个磁盘包含几乎相同数量的主次AU。这使得read I/O能够在所有disks上均匀的分布。这不同于其他常见的逻辑卷标管理，会区分主次disk sets。
综上，故障组用于隔离了组件故障，所以需要了解发生故障的组件。如果无法确定发生故障的组件，或发生故障的组件就是disk本身（而不是阵列控制器或存储托盘），则定义普通或高冗余diskgroups时，不定义任何故障组是明智的方法。这样，每个ASM磁盘被分配为一个自己的故障组，ASM会内部确定磁盘的镜像关系。如果存储阵列有完全的冗余组件，并且有两条路径通向磁盘，则最好不要指定故障组，而是让ASM管理磁盘的镜像伙伴关系。
在前面的示例中，假设故障组flgrp1的一块disk发生故障，则failed disk中的内容将通过在备份AU中冗余数据进行重建，从而重新获得平衡。在恢复平衡的过程中，如果database实例需要访问在failed disk中相应的primary AU，则database将从其他故障组的适当disk中读取镜像副本。一旦恢复平衡，database实例将只读取主AU。
disk是机械设备，所以就可能fail。当设备发生故障或是发生零星的I/O errors时，database的corruption的可能性就增大。ASM将主动的处理相关的I/O errors，而不考虑使用故障组。对于持久的I/O错误，在设备驱动器中进行一些处理尝试后，只会通过信号通知调用者(Oracle I/O进程)。如果在Oracle写操作期间引发了持久的磁盘I/O错误，ASM就会从磁盘组中隔离受影响的磁盘，从而防止更多的应用程序故障。如果磁盘丢失导致数据丢失，ASM将自动卸载磁盘组以保护磁盘组数据的完整性。
4）disk group的动态重整
在disk group添加或删除disks时，ASM会进行自动重整，使其处于平衡状态。这一过程无需DBA的干涉，而是通过所以技术在AUs上的应用来实现的。ASM无需对data进行重新的stripe，只是对一定比例的data 进行移动即可。
5）创建和删除disk group
前面已经有了创建的一个例子，下面在上一个：
CREATE DISKGROUP dgroupA NORMAL REDUNDANCY
FAILGROUP controller1 DISK
‘/devices/A1′ NAME diskA1 SIZE 120G FORCE,
’/devices/A2′,
’/devices/A3′
FAILGROUP controller2 DISK
’/devices/B1′,
’/devices/B2′,
’/devices/B3′;
上例中使用了NORMAL REDUNDANCY子句，这是默认的冗余级别。此外可以选择提供disk name，否则，ASM会创建一个默认的name，形式是<group_name>_n。同时，还可提供磁盘大小的可选信息，如果没有提供，ASM会进行自动的检测，如果检测失败，则创建操作也会失败，返回error。FORCE暗示可以使指定的disk被加载到disk group中，尽管它已经被作为AMS disk group的member格式化了。如果使用FORCE的disk没有被作为AMS disk group的member格式化，则会报error。
DROP DISKGROUP dgroupA INCLUDING CONTENTS;
上面这句主要用于删除disk group。此时disk group必须是被mount的。当确定所有的disk group files没有被open，group和所有的驱动程序被从disk group中移除，随后，每个磁盘的header被覆盖，从而剔除ASM的格式化信息。
6）项disk group添加disk
先上例子
ALTER DISKGROUP dgroupA ADD DISK
‘/dev/rdsk/c0t4d0s2′ NAME A5,
’/dev/rdsk/c0t5d0s2′ NAME A6,
’/dev/rdsk/c0t6d0s2′ NAME A7,
’/dev/rdsk/c0t7d0s2′ NAME A8;
ALTER DISKGROUP dgroupA ADD DISK ‘/devices/A*’;
当向一个disk group添加disk时，ASM Instance会确定该disk是可寻址的并且是可用的。随后，disk被格式化并rebalanced。rebalancing 过程是比较长的，因为要移动AU每个file到新disk上。
7）其他的alter命令
ALTER DISKGROUP dgroupA DROP DISK A5;
从disk group中删除disk。
ALTER DISKGROUP dgroupA
DROP DISK A6
ADD FAILGROUP fred DISK ‘/dev/rdsk/c0t8d0s2′ NAME A9;
在一条语句中同时删除并添加disk，这样可以节省rebalance的开支，两个操作后的rebalance同时进行。
ALTER DISKGROUP dgroupA UNDROP DISKS;
取消对disks的删除操作，此句只对尚未完成的drop操作有效。
ALTER DISKGROUP dgroupB REBALANCE POWER 5;
rebalance某个disk group，并发度是5。因为添加、删除或是resize disks后都会自动的进行rebalance，所以一般不会使用此命令，但通过此句可以覆盖默认的和最大的（由ASM_POWER_LIMIT定义的）rebalance并发速度。可以通过此句对已经正在进行的rebalance操作进行重新的等级设置。如果power的参数设置为0，将会挂起该命令，直到重新发出此命令。
ALTER DISKGROUP dgroupA DISMOUNT;
通过mount和dismount命令选项可以使Database Instance访问或不能访问disk group。
ALTER DISKGROUP dgroupA CHECK ALL;
用于验证disk group 元数据的内部一致性，并修复找到的error。如果只是想获得报警信息，也可使用NOREPAIR子句。此句会验证disk group中的所有disks，也可指定要验证的disk或是file。此命令要求disk group是mount的。如果查找到error，将会显示信息摘要，具体的细节将写入alert log中。
8）使用V$ASM_OPERATION视图监控长期运行的操作
该视图的字段含义如下表：
6、ASM管理——ASM file
ASM file是存储在ASM disk groups中的Database files。当一个文件被创建，某些file属性被永久的设定。这些属性是它的保护策略和striping策略。
ASM files是oracle-managed files。任何由ASM创建的file，在其不被需要时，就会被自动删除。然而，那些被user指定了alias的ASM files不认为是oracle-managed file，将不会被自动的删除。
当ASM 创建一个data file用于永久的tablespace（或是临时file用于临时tablespace），data file被设置为可自动增长到无限的、size为100MB的。一个AUTOEXTEND子句可以覆盖此默认设置。
在Database必须创建新的file的所有情况允许指定disk group自动产生一个唯一的文件名。
对于ASM，file操作是通过Database objects指定的。对数据库的管理是无需知道file name的，尽管这些文件名是可以通过查询某些data dictionary 视图或是通过backup controlfile获得的。
因为每个file在物理上是被分配到disk group上的所有disks上的，对一个disk的backup是无用的。对ASM files的Database backup必须通过RMAN。
1）ASM file name
ASM file name有六种不同的形式，分别适合于不同的使用环境。
三种使用环境是：
* 引用一个已经存在的file
* 一个将要被创建的file
* 多个将要被创建的files
具体情况使用的file name形式如下图：
图中六中file name的语法如下：
①fully qualified ASM file names：主要用于已经存在的ASM files。具体形式：
+<group>/<dbname>/<file_type>/<tag>.<file#>.<incarnation#>
其中：
<group> 是disk group的name
<dbname> 是file所属的Database的name
<file_type> 是oracle 的文件类型（CONTROLFILE，DATAFILE等）
<tag> 关于file的特定类型信息（例如data file的tablespace名）
<file>.<incarnation> 是file/incarnation 号码对，是唯一的
一个具体的实例为：+dgroupA/db1/controlfile/CF.257.8675309
fully qualified name是为在文件创建时为每个ASM file自动生成的。这些names可以在与alias names相同的等级的目录结构中找到。所有在name中的信息都是ASM自动派生出来的。它也可被称为是系统alias，表明此name是由ASM创建并维护的。终端用户不能对其进行修改。
②number ASM file names：用于引用已经存在的ASM file。具体形式：
+<group>.<file#>.<incarnation#>
此name不会出现在ASM的目录中。它们是从fully qualified name中派生出来的。ASM不会提供此类name的report，但此类name可以被用于许多需要使用已存在的file的接口中。具体实例：+dgroupA.257.8675309
③alias ASM file name：即可用于指引已经存在的ASM file，也可用于创建新的ASM file。具体形式：
+<group>/<diretory1>/…/<directoryn>/<file_name>
alias names不同于fully qualified 或是numberic name，不含有以“.”间隔的数据对结尾。它便于用户人性化的引用file。它是通过/分隔的层级目录结构组成的。file_name是UTF-8格式的，最长为48 bytes，不可含有/。整个alias file name不可超过256 bytes。
每个ASM file在创建时都会根据其属性为其创建一个fully qualified name。管理员可以在创建file时，为其添加一个alias name，或是通过ALTER DISKGROUP ADD ALIAS命令为已经存在的file创建一个alias。alias ASM file name一般会在CONTROL_FILES中的初始化参数中使用。
④alias ASM file names with templates：只能用于ASM的创建操作。这里template（模版）name请见后续的部分介绍。具体形式：
+<group>/<directiory1>/…/<directoryn>/<file_name>(<temp>)
⑤incomplete ASM file names：只用于文件的创建操作。ASM通过其文件类型，使用默认的template为Incomplete ASM file names定义name。具体形式：
+<group>
⑥Inomplete ASM file names with template：也只用与文件的创建操作。使用指导的template为ASM file创建name。具体形式：
+<group>(<temp>)
2）ASM file name的映射
ASM支持Database所需的绝大多数file类型。每个文件类型都关联一个相应的模板template。上表显示了ASM所支持的文件类型和它们相应的命名约定。ASM应用在创建是指明的文件属性选用相应的默认模板。
3）ASM file 模板（template）
它是在创建文件时使用的用于命名的文件属性的集合。template通过将复杂的文件属性映射到指定的简单的name上来简化file的创建工作。在应用于files上时，template是与disk group相关联的。
当创建disk group时，ASM会建立初始的系统默认template集合，这是与disk group相关联的。这些template为oracle Database各种文件类型包含了默认的属性。管理员可以改变默认template的属性。此外，管理员可以添加自己的template。但是系统默认的template是不能被删除的。
如果需要改变一个已经被创建的文件的属性，则此文件必须通过RMAN拷贝到新的具有新属性的文件中。这是改变文件属性的唯一方法。
依赖disk group冗余特征的定义，系统template被创建如下表：
当定义或是修改template时，可以指明files是否被镜像。也可指明被创建的files是细粒度还是粗粒度的被striped。
note：对于ASM 元数据文件的冗余和striping方式是由ASM预先定义的，是不能改变的。
4）一些template和alias的实例
ALTER DISKGROUP dgroupA ADD TEMPLATE reliable ATTRIBUTES (MIRROR);
#创建dgroupA上的template —— reliable，它是two-way镜像的
ALTER DISKGROUP dgroupA DROP TEMPLATE reliable;
#删除template reliable
ALTER DISKGROUP dgroupA DROP FILE ‘+dgroupA.268.8675309′;
#从disk group中删除指定的file
ALTER DISKGROUP dgroupA ADD DIRECTORY ‘+dgroupA/mydir’;
#创建user的目录MYDIR
ALTER DISKGROUP dgroupA ADD ALIAS ‘+dgroupA/mydir/datafile.dbf’ FOR ‘+dgroupA.274.38745′;
#为指定的文件创建alias name
ALTER DISKGROUP dgroupA DROP ALIAS ‘+dgroupA/mydir/datafile.dbf’;
#删除相应的alias name
5）aliases的获取
SELECT reference_index INTO :alias_id FROM V$ASM_ALIAS WHERE name = ‘+dgroupA’;
SELECT reference_index INTO :alias_id FROM V$ASM_ALIAS WHERE parent_index = :alias_id AND name = ‘mydir’;
SELECT name FROM V$ASM_ALIAS WHERE parent_index = :alias_id;
通过上面的三条sql，可以获得+dgroupA/mydir路径下的files的alias
7、Database Instance parameter 的改变
主要有：
INSTANCE_TYPE = RDBMS –默认是RDBMS
LOG_ARCHIVE_FORMAT –如果参数LOG_ARCHIVE_DEST被设置为一个不完整的ASM file name（如+dGroupA）此参数的设置将被忽略；如果LOG_ARCHIVE_DEST被设置为ASM 目录（如 +dGroupA/myarchlogdir/）则LOG_ARCHIVE_FORMAT将被使用并且文件时non-OMF的。归档日志的唯一的file name将由oracle Database自动被创建。
DB_BLOCK_SIZE –必须被设置为标准block size之一（2KB、4KB、8KB、16KB、32KB），不支持非标准的block size
下面的参数可以接受multifile creation context form的ASM file names的值
DB_CREATE_ONLINE_DEST_n
DB_CREATE_FILE_DEST_n
DB_RECOVERY_FILE_DEST
CONTROL_FILES
LOG_ARCHIVE_DEST_n
LOG_ARCHIVE_DEST
STANDBY_ARCHIVE_DEST
此外，SGA相关参数需要做稍微的修改，以支持ASM AUs映射和ASM的其他信息。主要注意如下：
* 至少增大600KB的LARGE_POOL_SIZE，并且该值至少为8MB
* 为了存储AU maps，需要增加额外的shared pool 。通过下面的查询语句获得当前Database 存储 size（DB_SPACE），Database要么是已经在ASM上，或是将要在ASM上。随后确定冗余的类型，增加相应的shared pool size。
SELECT d+l+t DB_SPACE
FROM (SELECT SUM(bytes)/(1024*1024*1024) d FROM v$datafile),
(SELECT SUM(bytes)/(1024*1024*1024) l FROM v$logfile a, v$log b WHERE a.group#=b.group#),
(SELECT SUM(bytes)/(1024*1024*1024) t FROM v$tempfile WHERE status=’ONLINE’);
对于使用external 冗余的disk groups：每100GB空间，需要1MB额外的shared pool，再加上固定的2MB的shared pool需求
对于normal redundancy：每50GB空间需要1MB额外的shared pool，再加上固定的4MB的shared pool需求
对于使用high redundancy的情况：每33GB空间需要1MB额外的shared pool，再加上固定的6MB的shared pool需求
* 为PROCESSES初始化参数的设置至少增加16
如果是使用自动内存管理（AMM）特性，则上述data的sizing可以进作为信息对待，或是追加SGA的最好值。oracle公司强烈推荐使用AMM。
管理Oracle RAC中的存储（2）
1、ASM和RAC的SRVCTL
通过SRVCTL可以完成如下的ASM管理操作：
* ADD操作向一个运行的CRS中添加关于ASM Instance的oracle cluster registry（OCR）信息。此操作也同时执行的相应的ENABLE
例：$ srvctl add asm -n clusnode1 -i +ASM1 -o /ora/ora10
note：这里的-o参数指明的是Instance的ORACLE_HOME，-i指明的是Instance的name
* ENABLE操作使运行在CRS中的ASM Instance可以自动的startup或是restart
* DISABLE操作阻止了CRS对相应的ASM Instance不必要的自动重启restart
例：$ srvctl disable asm -n clusnode1 -i +ASM1
* START操作start一个CRS-enabled的ASM Instance。SRVCTL使用的是SYSDBA连接来执行此操作
例：$ srvctl start asm -n clusnode1 -i +ASM1 -o open
* STOP操作stop一个ASM Instance，可选的shutdown方式有normal、transactional、immediate和abort
例：$ srvctl stop asm -n clusnode1 -i +ASM1 -o immediate
* CONFIG选项显示了OCR中存储的特定ASM Instance的配置信息。
* STATUS选项可以获得ASM Instance的当前状态
* REMOVE选项将删除一个ASM Instance的配置信息，以及它相关联的Instance。在remove一个ASM Instance前，必须先stop并disable它
note：在使用DBCA创建ASM Instance时，会自动执行ASM Instance的ADD和ENABLE操作。
2、向ASM的迁移
1）overview
当需要将已存在的Database转移为ASM的，只能用RMAN工具。因为存储在disk group上的每个file都是物理延伸到该group上的所有disks上的，而RMAN命令可以使non-ASM files被重新分配到ASM的disk group上。
尽管不是必须的，但多数情况下会将目标数据库迁移ASM时分配到两个disk groups上：一个存储所有的Database files，另一个用于存储flash recovery area的文件。
可行的迁移方法可分为冷、热两种。冷迁移适用于无需关心停机时间长短的情况。如果希望尽量缩短服务停止时间，可选用热迁移。但，是不可能做的完全的在线迁移的。
此外，迁移方法的选择还要看可用的磁盘空间能力。最简单的方法是有足够的磁盘空间，同时在file system和ASM存储两份Database。然而，即使是无法在系统中添加disks的情况，也是可以将Database向ASM做迁移的。
2）使用额外空间做ASM的迁移
具体步骤：
① 创建ASM Instance
② 创建data和recovery area disk groups
③ 设置Database file和back up OMF参数
④ 创建一个Database的副本到ASM上，并转换控制文件和data file到ASM
⑤ 重建闪回Database logs、临时文件，并改变追踪文件到ASM中
⑥ 可选择的将以前的backups迁移到ASM中
⑦ drop并re-create online redo log groups到ASM中
如果Database相对较小，上述方法的停止服务时间是最少的。服务的停止时间是在第四步道第六步。只有flashback logs的重构是需要offline的。
当然这里已经假设Database已经使用了闪回区，并且有足够的磁盘空间。
下面上个例子，这里假设已经完成了ASM Instance的创建以及用于存放data file的DATA disk group和存放recovery file的RECOV disk group的创建和加载。并假设使用的是SPFILE。
例子从③开始：
③使用sql*plus设置OMF参数
ALTER DATBASE DISALBE BLOCK CHANGE TRACKING;
ALTER SYSTEM SET db_create_file_dest=’+DATA’ SCOPE=SPFILE;
ALTER SYSTEM SET db_recovery_file_dest=’+RECOV’ SCOPE=SPFILE;
ALTER SYSTEM SET control_files=” SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
注：可以在open的任何一个Database Instance上执行上述命令，但需要立即关闭所有Instances。上述脚本中关闭了block change tracking机制，同时改变每个Instance的OMF参数使其指向新的disk groups。同时设置了新的CONTROL_FILES，确保OMF控制文件被创建到ASM中。
④当Database被关闭后，可以用RMAN执行下面的脚本：
CONNECT TARGET
STARTUP NOMOUNT;
RESTORE CONTROLFILE FROM ‘filename_of_old_control_file’;
ALTER DATABASE MOUNT;
BACKUP AS COPY DATABASE FORMAT ‘+DATA’;
SWITCH DATABASE TO COPY;
RECOVER DATABASE;
注：此脚本创建了两个多路复用的OMF控制文件，存储在DATA和RECOV中。filename_of_old_control_file 指明了至今仍在使用的一个控制文件名，当然，它也可是通过ALTER DATABASE BACKUP CONTROLFILE TO 得来的。随后使用新的控制文件加载Database，备份已经存在的文件系统的Database到DATA中作为镜像副本。之后将控制文件的指针切换到ASM Database的镜像副本中。
⑤在sql*plus中做flashback logs的迁移，改变tracking file和临时文件
ALTER DATABASE FLASHBACK OFF;
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;
ALTER TABLESPACE temp ADD TEMPFILE;
ALTER DATABASE TEMPFILE ‘filename_of_old_tempfile’ DROP;
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
注：首先通过关闭再打开flashback loggi ng，在RECOV上重建了flashback logs。此外因为RMAN不会对临时表空间进行备份，所以需要对所有已经存在的临时表空间进程重建，只需对每个临时表空间添加至少一个tempfile，并删除以前在文件系统中的旧临时文件。最后一句将在DATA中重建change-tracking 文件。
⑥使用RMAN迁移已经存在的backups（这是可选的操作，但是推荐使用）
CONNECT TARGET
BACKUP AS COPY ARCHIVELOG ALL DELETE INPUT;
BACKUP DEVICE TYPE DISK BACKUPSET ALL DELETE INPUT;
BACKUP AS COPY DATAFILECOPY ALL DELETE INPUT;
首先是移动所有的当前尚未被备份的归档日志文件，随后移动所有的当前的备份集。最后，移动所有的数据文件副本。
⑦使用sql*plus迁移online redo log files
DECLARE
cursor logfile_cur is select l.thread#, l.group#, l.bytes from v$log l;
type numTab_t is table of number index by binary_integer;
grouplist numTab_t; threadlist numTab_t; byteslist numTab_t;
BEGIN
open logfile_cur;
fetch logfile_cur bulk collect into threadlist, grouplist, byteslist;
close logfile_cur;
for i in 1 .. threadlist.count loop
migrateorl(threadlist(i), grouplist(i), byteslist(i) );
end loop;
END;
注意，这里的migrateorl存储过程具体如下：
CREATE PROCEDURE migrateorl(thread# number, group# number, bytes number) is
stmt varchar2(1024):=’alter database add logfile thread’|| thread#||’ size ‘||bytes;
asalc varchar2(1024):=’alter system archive log current’;
BEGIN
execute immediate stmt;
stmt := ‘alter database drop logfile group ‘||group#;
for i in 1 .. 5 loop
begin
execute immediate stmt;
exit;
exception
when others then execute immediate asalc;
end;
end loop;
END;
具体存储过程的解释我就不罗嗦了，应该都看得懂的。
3）表空间的迁移
依然假设假设已经完成了ASM Instance的创建以及用于存放data file的DATA disk group创建和加载。具体过程如下：
①用RMAN 连接到target Database
②将target tablespace设置为OFFLINE或READ ONLY
③拷贝表空间到ASM 的disk group上
④切换控制文件的指针到ASM的副本上
⑤将target tablespace设置为ONLINE或READ WRITE
具体在RMAN上执行的脚本如下：
CONNECT TARGET
SQL “ALTER TABLESPACE tbsname OFFLINE”;
BACKUP AS COPY TABLESPACE tbsname FORMAT ‘+DGROUP1′;
SWITCH TABLESPACE tbsname TO COPY;
SQL “ALTER TABLESPACE tbsname ONLINE”;
4）SPFILE向ASM的迁移
可以将SPFILEs存储在ASM disk group中。具体迁移过程如下：
①通过已经存在的SPFILE创建一个PFILE到file system中。
CREATE PFILE=’initORCL.ora’ FROM SPFILE;
②添加一个意味深长的directory
ALTER DISKGROUP dgroup1 ADD DIRECTORY ‘+DGROUP1/ORCL/SPFILE’;
③在新的Directory中创建新的SPFILE文件
CREATE SPFILE=’+DGROUP1/ORCL/SPFILE/spfileORCL.ora’ FROM PFILE=’initORCL.ora’；
④创建一个新的PFILE，只有SPFILE参数指向新的SPFILE文件。此PFILE文件将用于Instance的startup。
spfile=+DGROUP1/ORCL/SPFILE/spfileORCL.ora
3、ASM disk 元数据的需求
必须添加额外的disk 空间用于存放ASM的元数据。可以使用下面的公式计算对于空disk group来说需要的额外的disk 空间，单位是MB。
* 对于normal和high redundancy需要：
15 + (2 * #_disks) + ( 126 * #_ASM_insts)
* 对于external redundancy
5 + (2 * #_disks) + (42 * #_ASM_insts)
根据上面的公式，假设有4个节点的RAC，使用三个disks的high-redundancy disk group，需要额外的disk space为525MB（15+2*3+126*4）。
当文件被创建，会有额外的元数据开支：
* 对于high redundancy，大于20MB的file要增加3MB的元数据存储，并且该file每多增加42GB，会多占用3MB空间
* 对于normal redundancy，大于30MB的file要增加3MB的元数据存储，并且该file每多增加64GB，会多占用3MB空间
* 对于external redundancy，大于60MB的file要增加1MB的元数据存储，并且该file每多增加128GB，会多占用1MB空间
4、ASM和可传输（transportable）表空间
可以将存储在机器上的一个ASM disk group中的data file复制到另一台机器上的ASM disk group中，具体通过DBMS_FILE_TRANSFER包在一个Database Instance上的执行。该操作可以被直接执行而无需隐藏data file。
但，如果要将传统的file system中的data file传输到其他机器上的ASM disk group中时，则需要通过典型的传输表空间过程锁住目标Database的data file，再使用RMAN迁移被加锁的表空间到ASM中。
具体的过程其他文章中补充吧，这里先跳过了。
5、ASM和存储阵列
使用ASM并不意味这抛弃过去的存储方式，用新的东西取代它。
虽然ASM 提供镜像的功能，但如果可以将这些任务交给外部的存储阵列（支持镜像或是raid 5等技术），将是非常好的实践。ASM可以被设置为使用external redundancy机制来保护数据。
server-level的striping可以用于补充storage-level striping的性能。这种技术被称作double striping。因为server-level striping穿过storage level的后端，提供了一个均匀分布的I/O。并且通过可用的channel，动态多路径提供了动态分配。
对recovery area使用ASM提供了更有特色的file system。它提供了自动的文件命名、分布和data file的自动扩涨。与recovery area相互结合，将不会有比ASM更好的cluster file system用于oracle Database files。
6、ASM 的可扩展性
ASM增加了下面的限制：
* 一个存储系统中最多有63个disk groups
* 一个存储系统，最多有10000个ASM disks
* 每个ASM disk的最大存储量不可超过4 petabyte
* 每个存储系统最大存储量不超过40 exabyte
* 每个disk group最多可存放1百万个files
* 每个file最大可存放2.4 terabyte的数据
7、redo log files和RAC
对于RAC，每个Instance向自己的online redo log files集合写入data，被一个Instance写入的redo 被称作一个thread redo，或一个thread。因此，每个Instance使用的redo log file group是与由初始化参数THREAD的设定一致的thread number决定的。如果THREAD参数设置为非0值，则给Instance在下次start时将使用该thread。推荐为每个Instance设置不同的THREAD参数值。
可以通过ALTER DATABASE ADD LOGFILE THREAD语句将一个thread number与一个redo log file group相关联。通过ALTER DATABASE ENABLE THREAD语句启用一个thread number。在启用某个thread之前，它必须至少有两个redo log file groups。
默认情况下，一个Database创建的同时会启用一个公共的thread。启用一个公共的thread，可以使用下面的语句：ALTER DATABASE ENABLE PUBLIC THREAD。该thread可以被所有THREAD参数设置为0的Instance所获得。
所以，当添加Instance到Database中时，需要创建新并启用新的thread。
NOTE：THREAD参数可设置的最大值要受到CREATE DATABASE时MAXINSTANCES参数的值的限制。
8、RAC和自动Undo 管理
oracle Database可以自动管理在分配给该Instance的特定undo tablespace中的undo segments。在正常环境中，只有被分配的Instance可以修改该undo tablespace的内容。而所有的Instances可以读取所有的undo blocks从而达到一致读的目的。同时，在事务恢复时，任何Instance可以更新任何undo tablespace，只要该undo tablespace当前没有被其他Instance用于写入undo或是做事务恢复。
你通过指明RAC Database中的不同Instance的UNDO_TABLESPACE参数（在SPFILE或是各自的PFILEs）来分配undo tablespaces。如果没有设置UNDO_TABLESPACE参数，则每个Instance使用第一个可用的undo tablespace。如果没有可用的tablespace，则会使用SYSTEM回滚段。
可以通过执行ALTER SYSTEM SET UNDO_TABLESPACE 语句动态的切换分配undo tablespace，其中用SID子句指明相应的Instance。可以在任何Instance中执行此句。在图中的例子里当分配新的undo tablespace时，将被挂起使用直到最后一个transaction被提交。挂起的offline tablespace将对于其他Instances是不可用的，直到其上的所有transaction被提交。
note：在RAC中，不可同时使用自动undo 管理（AUM）和手工undo管理。高度推荐使用AUM模式。
