ASM笔记2



2.3.3.3 如何启动ASM 实例
2.3.3.3.1 启动 ASM Instance 的选项说明
在启动之前我们需要注意以下几点：
（1）确认ORACLE_SID值。 对于ASM 的单实例，默认的ASM SID 是+ASM。如果RAC 环境，默认的实例就是+ASM1,+ASM2，这里的数字与我们的节点对应。
Oracle 建议不要修改默认的的ASM SID 名称。

（2）初始化参数中必须包含: INSTANCE_TYPE = ASM, 该参数控制实例的类型。

（3）执行startup命令启动ASM 实例，这个命令会尝试mount ASM disk groups。 当然也可以手工使用命令mount。

（4）在启动ASM 实例的时候，相关的数据库不能在运行。

ASM 实例的STARTUP 命令可以有如下选项：
1.Force：先shutdown abort ASM 实例，在启动。

2.MOUNT / OPEN：
这种模式会MOUNT ASM_DISKGROUPS参数指定的disk group。 默认就是这种启动模式。这两种是一样的。
如果在启动的时候没有找到disk group，那么就不会mount 任何的disk group，在启动之后，我们可以使用 ALTER DISKGROUP...MOUNT 命令来手工的mount disk group。

3.NOMOUNT：
启动ASM 实例，但不mount disk groups。

4.RESTRICT:
受限模式，在这种模式下，只有具有CREATE SESSION 和 RESTRICTED SESSSION 权限的用户才可以访问。 RESTRICT 可以和MOUNT,NOMOUNT ,OPEN 选择组合使用。
在受限模式下，数据库实例不能使用disk groups，数据库不能打开存放在disk group中的文件。 受限模式下mount 的disk group只能在被mount节点的ASM 实例访问，Cluster 环境下的其他节点不能访问。 因为这种模式可以用来做一些修复工作。

--重新启动
startup force

--关闭和启动
shutdown immediate
startup open

2.3.3.3.2 指定SPFILE来启动ASM 实例
create pfile from spfile='+DATA/asm/asmparameterfile/registry.253.814737973';
--使用pfile 来启动：
STARTUP PFILE= /u01/app/grid/11.2.0/dbs/init+ASM.ora

--设置启用哪个SPFILE
ASMCMD> spset +DATA/asm/asmparameterfile/asmspfile.ora

2.3.3.4 关闭ASM 实例(需要先关数据库)
1.NORMAL 选项

在这种模式下，dismount 所有disk group ，shutdown asm 实例之前，会等待任何连接的SQL 执行完成。 并且会等待所有正在连接ASM 实例的用户disconnect。如果有任何数据库实例连接在ASM 实例上，那么shutdown 命令会报错。
默认采用的就是NORMAL 模式。
2.IMMEDIATE / TRANSACTIONAL 选项
和NORMAL 选项一样，在dismount disk group，关闭ASM 实例之前也会等待任何正在进行的SQL 执行完成。 但不会等待当前的连接断开，如果数据实例正在连接ASM 实例，那么shutdown会返回错误。
因为ASM 实例不包含任何实物，所以TRANSACTIONAL 和 IMMEDIATE 模式功能一样。

3.ABORT 选项
ASM 实例会立即shutdown ASM 实例，而不会等待disk groups dismount。 这样会导致在下次启动ASM 实例时需要进行recovery操作。

如果此时有数据库实例正在连接，那么数据库实例也会被shutdown abort掉。

2.3.4  Oracle ASM 的权限认证管理
ORACLE ASM 实例没有数据字典，所以连接ASM 实例只能通过如下三种系统权限来进行连接: SYSASM,SYSDBA,SYSOPER.
可以通过如下三种模式来连接ASM 实例：
1.在操作系统上直接使用OS 认证。
2.在操作系统上使用口令文件认证。
3.通过Oracle Net Service远程+ 口令文件远程连接。
ASM 实例和数据库实例 在操作系统级别上必须有访问disk groups的权限。在Linux 和Unix 环境上，通过组成员来进行控制（OSASM）。 windows 环境就必须用Administrator来运行。

2.3.4.1 Oracle ASM 需要哪些权限
SYSDBA 权限不能用来管理ORACLE ASM 实例。 如果使用SYSDBA权限来管理ASM 实例，那么操作会返回错误。
SYSDBA的权限是数据库用来访问disk groups

2.3.4.1.1 对所有ASM 用户使用同一个操作系统group
如果不想把权限分成不同的操作系统group，可以创建一个OS group，并对这个group 授权：OSDBA,OSOPER,OSASM.

2.3.4.1.2 对ASM 用户使用独立的OS GROPS
1.OSASM 组
该组赋予了SYSASM 的权限，具有该权限的用户可以完全管理ASM 实例。
2.OSDBA 组
该组赋予了ASM 实例的SYSDBA权限，具有该权限就可以访问ASM 中的数据，该权限是OSASM 组权限的一个子集。
3.OSOPER 组
该组赋予了ASM 实例的SYSOPER权限，可以对ASM 实例进行管理操作，比如startup，shutdown，mount，dismount，check disk group等。 这个组的权限也是OSASM 的一个子集。 该组也可以改成ASMOPER.

2.3.4.1.3 管理 ASM 的SYSASM 权限
SYSASM 权限是一个系统权限，这样就可以把ASM 存储管理的权限从SYSDBA 的数据库管理的权限中分离出来。
具有SYSASM 权限的用户都放在一个操作系统的group下面，这个组就是OSASM 组。

这一点和SYSDBA 和SYSOPER 权限类似。 具有SYSDBA 权限都作为特定组的成员，如OSDBA 或者OSOPER group。 可以将这些系统权限归纳到一个group里，也可以每个系统权限一个独立的os group。
使用OS认证连接本地的ASM实例，直接执行如下命令：
sqlplus / AS SYSASM

也可以使用口令文件来连接远端的ASM 实例。

ASM 口令文件创建和oracle 实例一样：
$ orapwd file=$ORACLE_HOME/dbs/orapw+ASM password=oracle

2.3.4.1.4 管理 ASM 组件的 SYSDBA权限
可以在SQL*Plus中使用SYSDBA 来连接，或者使用ASMCMD 工具来管理与数据库相关的ASM 组件。 
当以SYSDBA 连接到数据库实例，那么以下ASM 操作是受限制的：
1） Create and delete files, aliases, directories, and templates
2）  Examine various Oracle ASM instance views
3） Operate on files that were created by this user or only access files to which another user had explicitly granted access
4） Granting Oracle ASM File Access Control to other users

2.3.4.2 创建具有SYSASM 权限的用户
当我们以SYSASM 登陆到ASM 实例后，就可以使用CREATE USER和 GRANT 命令来创建其他具有SYSASM 权限的用户。
可以使用REVOKE命令来移除用户的SYSASM 权限，或者使用drop user 命令从口令文件中删除一个用户。

2.4 如何管理Oracle ASM Disk Groups？

2.4.1 Disk Group有哪些属性？
Disk group的属性是与disk group 对应的，而不是和ASM 实例对应 ，也就是说每个disk group 可以有自己的属性。
 select name,value from v$asm_attribute where group_number=1;

2.4.2.1 ACCESS_CONTROL.ENABLED
该属性指定在disk group创建之后使用alter 命令修改。
该属性用来控制某个disk group 上ASM FILE Access Control。 该参数有2个值：true 和false。 默认为false。
当这个参数设置为true。 那么就必须访问权限的控制才能访问disk group上的ASM FILES。 如果是false，那么任何用户都可以访问disk group上的文件。

2.4.1.2 COMPATIBLE.RDBMS
该属性用来指定disk group 最小能够兼容的数据库实例，也就是最低能收使用该disk group的数据库实例版本。
在修改这个参数之前，必须先确保所有的数据库实例的COMPATIBLE 参数大于等于该参数的值。
ALTER DISKGROUP DATA SET ATTRIBUTE 'compatible.rdbms' = '11.2.0.0.0';
改高后就不能改低了。

2.4.1.3 ACCESS_CONTROL.UMASK
这个属性只能使用alter 命令修改。
该属性用来指定访问ASM 文件的权限。该参数值包含3个数字：{0|2|6} {0|2|6} {0|2|6}. 默认是066。
0： 表示具有读写的权限
2： 表示只读的权限
6： 表示不能读写

第一位表示文件所有者的权限；
第二位表示与文件所有在同一组用户对ASM 文件的权限；
第三位表示其他用户组的用户对ASM 文件的权限。
在设置磁盘组ACCESS_CONTROL.UMASK属性之前，必须先确保ACCESS_CONTROL.ENABLED 参数设置为TRUE。 启用文件访问权限控制后，才能设置该参数。
alter diskgroup DATA set attribute 'access_control.umask' = '666';

2.4.1.4 AU_SIZE
该参数只能在创建disk group的时候指定，一旦指定了就不能在修改了。 
AU(allocation units)是disk group 基本的分配单元。 一个file extent 由一个或者多个AU 单元组成，而一个ASM file 则由多个file extents组成。
select name, allocation_unit_size/1024/1024||'M' from v$asm_diskgroup;
增大AU_SIZE 可以带来如下的好处：
（1） Increased I/O through the I/O subsystem if the I/O size is increased to the AU size.
（2） Reduced SGA size to manage the extent maps in the database instance.
（3） Faster datafile initialization if the I/O size is increased to the AU size.
（4） Increased file size limits.
（5） Reduced database open time.

2.4.1.5 CELL.SMART_SCAN_CAPABLE
这个参数只能应用在Exadata 存储上。
select name,value from v$asm_attribute where group_number=1 and name like 'cell%';

2.4.1.6 COMPATIBLE.ASM
select name,value from v$asm_attribute where group_number=1 and name like 'compatible%';
COMPATIBLE.ASM 属性决定能够使用对应disk group 的最小的Oracle ASM 实例 软件的版本。
这个参数设置会影响磁盘上ASM metadata  的数据结构信息。

2.4.1.8 COMPATIBLE.ADVM
在设置这个属性之前，必须先确保COMPATIBL.ASM 属性值大于等于11.2.
默认情况下，该属性值为空。

2.4.1.9 CONTENT.TYPE
该属性用来标记disk group 的类型：data，recovery，system。
可以在创建时指定，或者使用alter 命令修改。 设置的新值只有在显示的进行disk group 时才会生效。
只有当disk group 设置为normal 或者 high redundancy 的时候，该属性才会有效。  并且还要求COMPATIBLE.ASM的属性值必须大于等于11.2.0.3。
该属性主要争对Oracle Exadata 存储。

该属性值也用来决定ASM 镜像复制到最近的failure group中disk 的距离。

该属性默认值是data，表示该disk group 到最近的failure goup disk 距离是1.
如果是recovery，则表示距离是3。
如果是system，则表示距离是3.
 
2.4.2.10 DISK_REPAIR_TIME
在Oracle 10g中，损坏的ASM磁盘会马上offline，进而这个损坏的磁盘立刻会被Oracle drop掉。

以后即便你修复了这块磁盘，重新加入原先磁盘组的时候，Oracle也会做rebalance操作来完全重构这个磁盘上的数据，这个rebalance操作可能会极为耗时。

那么如果这个损坏的磁盘仅仅是因为掉电或者仅仅损坏了几个块就需要完全重构，效率是非常低的。

为了避免这个问题，Oracle 在11g里引入了一个参数disk_repair_time，其默认值是3.6小时并且用户可以修改。
这个参数的单位可以是分钟(m or M)或者是小时(h or H)。 如果我们在指定属性时没有指定单位，那么默认单位是小时。
该属性只能通过ALTER 命令来进行修改。
这个属性的含义是当损坏的磁盘offline后，Oracle并不会马上将其drop，而是会等待参数disk_repair_time所表示的时间。
在这段时间内，Oracle会记录下对损坏的磁盘上的extent所做的修改，一旦这个offline的损坏的磁盘在disk_repair_time所表示的时间内重新online，则Oracle会将之前所记录的对这个磁盘上extent所做的修改重新同步到这块盘上，从而高效地同步了数据（因为这里只同步了offline后修改的extent上的数据），避免了极为耗时的重构全部数据的rebalance过程。
这个过程就是11g中的：快速镜像同步（Fast Mirror Reync）。
当出现disk 出现故障被offline 后，我们可以查看V$ASM_DISK视图的REPAIR_TIMER。 该列显示的是disk 被drop 之前的剩余时间，单位是秒。

一旦超过disk_repair_time指定的时间，disk 就会被drop 掉。那么我们就需要进行rebalance操作，而不能进行快速镜像同步。

当disk 因为磁盘故障进行了offline，或者手工执行SQL offline 了disk，并没有指定drop 选项，就会使用能够disk 的disk_repair_time 计算时间。

2.4.2.11 IDP.BOUNDARY 和 IDP.TYPE
disk group的这2个属性值是专门为Exadata storage 设计的。

2.4.2.12 SECTOR_SIZE
SECTOR_SIZE 只能在创建diskgroup 时来指定。 该属性可以设置为512, 4096 或者4k。 具体的默认值由不同的平台决定。
传统的磁盘每个扇区512字节，随着磁盘容量的不断增大，继续使用512byte，不再是那么的合理，于是将每个扇区512字节改为每个扇区4096 个字节，也就是现在常说的“4K扇区”。
如果要修改sector size值，那么就必须确保disk group的COMPATIBLE.ASM 和 COMPATIBLE.RDBMS 属性值大于等于11.2。
在同一个disk group内的disk 必须使用相同的sector size。 在我们 CREATE DISKGROUP, ALTER DISKGROUP ADD DISK, 和 ALTER DISKGROUP MOUNT 的时候会效验sector size。
如果我们在创建disk group的时候指定了sector_size 参数，那么ASM 就会验证所有disk的sector size 值，如果有不同，那么创建操作就会失败。

2.4.2.13 STORAGE.TYPE
该属性用来指定disk group中disk的类型。 该属性可以设置为如下值：AXIOM, ZFSSA 和OTHER。 如果设置为AXIOM 和ZFSSA，那么disk group中的所有磁盘都必须是这2中类型。 如果这是为other，那么disk可以是任何类型。
如果disk group 的STORAGE.TYPE 设置为AXIOM 或者 ZFSSA， 就可以启动Pillar Axiom 或者ZFS storage的HCC（Hybrid Columnar Compression）功能。
该特性是Oracle 11.2.0.3 中引入的，所以要设置STORAGE.TYPE属性，必须将COMPATIBLE.ASM 和 COMPATIBLE.RDBMS 属性设置大于等于 11.2.0.3。
该属性可以在创建数据库或者使用alert 命令修改。