分类目录归档：ASM

使用ASM的数据库和使用文件系统的数据库在AIO上哪里不同？

发表于 2014 年 9 月 26 日 由 Lunar

昨天客户的一个重要应用切换到新的系统环境上，今天观察，发现部分异常等待： 从OS的CPU负载来看，定期会出现一个峰值，从ASH中可以看出，这个峰值对应的等待事件跟AWR的完全吻合。 因此，主要怀疑两个东西： 1，应用的SQL和对象的属性（比如table或者index的统计信息，并行度等等……） 2，系统的AIO设置 上面的第一条，已经提交给开发相应的SQL和其他信息 第二条，因为系统以前是11.2 RAC，使用了ASM，而现在是单机文件系统. 因此对比了这两种环境下AIO的异同，结论如下： 1，Linux下，ASM数据库和文件系统数据库的AIO设置差别： (1). ASM的AIO属性是不受 FILESYSTEMIO_OPTIONS 参数的影响（因为ASM会绕过文件系统buffer），只跟DISK_ASYNCH_IO有关系 (2). 文件系统的AIO属性跟 FILESYSTEMIO_OPTIONS 和 DISK_ASYNCH_IO 都有关系 2，FILESYSTEMIO_OPTIONS=NONE ： Bug 6733627 – Unaccounted Wait Time on “Direct Path” operations with FILESYSTEM_IO_OPTIONS=NONE (Doc ID 6733627.8) 3， db file … 继续阅读 →

发表在 ASM, FAQ | 标签为 , , , , | 留下评论

Standalone – 修改主机名和IP地址

发表于 2014 年 7 月 13 日 由 Lunar

新本本性能一般，用VM跑RAC很费劲，因此从朋友那里copy了一个STANDALONE（ASM+SINGLE DATABASE），然后直接修改主机名后，发现css信息异常，且HAS不能启动…… 直接修改主机名为lunar后，HAS的信息为： 重启has后，发现HAS启动不了，报错如下： 根据“error location: scrsearch1”和“cant open scr home dir scls_scr_getval”，可以看出这个跟修改主机名有关系，将主机名称修改会议前的dabaobao： 修改回到以前的主机名“dabaobao”以后，再次重启has，可以启动了，可见，HAS的架构非常简单…… 这里，出了ora.DATA.dg这个资源异常外，其他资源是正常状态，此时，我们使用roothas.pl删除HAS的配置： 然后，修改主机名为lunar，再次使用roothas.pl，让他自动根据当前的主机名和IP来生成配置信息： 可见，这里已经生产了节点名为lunar的has配置信息 添加asm： 添加ASM DISKGROUP： 这个错误是因为没有找到合适的disk，于是修改参数： 可以看到，现在磁盘组都mount上了 然后我们创建spfile，准备重启has： 重启HAS： 等待一会儿，一切ok了： 总结： 1，在发现has或者crs异常时，不要stop crs或者stop has 2，修改主机名或者IP时，发现错误了，不要stop crs或者stop has（后续的一些操作需要这些资源） 3，在HAS环境中修改主机名和IP的过程： （1）先用roothas.pl -deconfig -force清理老配置 （2）修改主机名（/etc/hosts，/etc/sysconfig/network，hostname等等） （3）./roothas.pl （自动根据当前配置生成新的配置信息） （4）添加ASM资源 （5）添加磁盘组 … 继续阅读 →

发表在 ASM, RAC | 标签为 , , | 留下评论

Exadata上，ASM的Req_mir_free_MB 是如何得到的？

发表于 2014 年 5 月 30 日 由 Lunar

Exadata上，ASM的Req_mir_free_MB 是如何得到的？ 首先，我们都知道，可通过v$asm_diskgroup来查看required_mirror_free_mb： 这里看到，实际上lsdg的输出跟v$asm_diskgroup是一致的（注意，早起的数据库版本由于rebalance时的bug，可能造成显示不一致，例如 Bug 7699985） 由于Exadata上，没有外部冗余，数据完全通过ASM镜像，那么就要考虑当磁盘故障或者cell故障时的数据保护，需要相应的根据Normal Redundancy或者High Redundancy来考虑分别两种情况： 1，在Normal Redundancy时，要考虑1块磁盘损坏或者1个cell不能启动时，如果修复时间超过缺省的3.6小时，需要使用现有系统中可用磁盘空间做Rebalance 2，在HighRedundancy时，要考虑2块磁盘损坏或者2个cell不能启动时，如果修复时间超过缺省的3.6小时，需要使用现有系统中可用磁盘空间做Rebalance Oracle根据内部算法，使用一个调解因子做系数，比如，不同版本的Oracle，评估方法不同： 如果数据库是11.2.0.3或者11.2.0.4，那么这个调解因子为1.10，如果是低于这个版本的数据库，调解因子是1.5（具体该因子的算法尚未知道） 对于每一个磁盘组，他们需要调解的空间大小（即，预留空间）=v$asm_diskgroup.required_mirror_free_mb * 调解因子 然后根据不同的镜像（Normal或者High），以及不同的Exadata配置（1/8，1/4、1/2，满配）再分别乘以一个系数，下面的代码根据每个磁盘组的最大的failgroup的大小来确定需要保留的空间： 然后，计算出来总共的需要“预留的空间”按照不同配置的Exadata乘以一个比例，就是我们这看到的 REQUIRED_MIRROR_FREE_MB： 对于Normal Redundancy： 对于High Redundancy： 完整的代码可在这里下载

发表在 ASM, FAQ, 内部机制 | 标签为 , , | 留下评论

Exadata和非Exadata平台上，ASM的可用空间如何计算？

发表于 2014 年 5 月 30 日 由 Lunar

曾经很多次，有客户问到ASM上可用的空闲空间问题，实际上，由于ASM带有3中冗余设置方式，分别应对不同场景的数据冗余情况，因此，通常在Exadata上的选择和非Exadata上的选择是不同的。 . 在非Exadata的环境中，通常我们会使用RAID，比如RAID10，因此ASM中使用External Redundancy，例如： ASMCMD> lsdg State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name MOUNTED EXTERN N 512 4096 1048576 51200 45862 0 45862 0 N CFARCH1/ MOUNTED EXTERN N 512 4096 1048576 51200 47653 … 继续阅读 →

发表在 ASM, FAQ, 内部机制 | 标签为 , , | 2 条评论

ASM disk和diskgroup等使用的限制

发表于 2014 年 5 月 9 日 由 Lunar

11.2 ASM磁盘和磁盘组的限制如下： Oracle ASM has the following limits on the number of disk groups, disks, and files: 63 disk groups in a storage system 10,000 Oracle ASM disks in a storage system 1 million files for each disk group Without … 继续阅读 →

发表在 ASM | 标签为 , , | 一条评论

Exadata的数据保护机制（冗余机制）-4-ASM PST

发表于 2014 年 3 月 17 日 由 Lunar

Exadata的数据保护机制（冗余机制）- 1 Exadata的数据保护机制（冗余机制）- 2 Exadata的数据保护机制（冗余机制）- 3- Failure Group 为了补充前面两篇的一些概念，这里，我们简单介绍下ASM的PST。 我们知道，asmfile extent是分布在多个磁盘之间，称为partner，Partner disk会存放在一个或者多个分离的failure group上。ASM自动选择Disk partner并限制其数量，这是受隐含参数”_asm_partner_target_disk_part”控制的。在10g中，每盘都会存在最多10个Disk partner，而在11gR2中每盘都会存在最多8个Disk partner。ASM会自动创建和维护Partner关系，如果磁盘损坏（failure），那么ASM会更新其extent map使今后的读取操作指向剩余的健康的partner。 对于external redundancy 的磁盘组，每个磁盘组只有一个PST table，对于normal redundancy 的磁盘组，每个磁盘组有3个PST table，对于high redundancy 的磁盘组，每个磁盘组有5个PST table。 . PST的信息是由GMON进程维护的。PST 包含了一个磁盘组中ASM disk的状态信息：disk number，status（online or offline），partner disk number，heartbeat的信息，11g的ASM中，PST 还引包含了failure group的信息。因此，ASM根据PST(Partner Status Table)的信息就知道哪个盘的partner是offline状态的。 … 继续阅读 →

发表在 ASM, 体系架构, 内部机制 | 标签为 , , | 留下评论

Exadata的数据保护机制（冗余机制）- 3-Failure Group

发表于 2014 年 3 月 17 日 由 Lunar

Exadata的数据保护机制（冗余机制）- 1 Exadata的数据保护机制（冗余机制）- 2 为了补充前面两篇的一些概念，这里，我们简单介绍下ASM的Failgroup。 ASM提供了3种冗余方法。 EXTERNAL，即ASM本身不做镜像，而依赖于底层存储阵列资深实现镜像；在External下任何的写错误都会导致Disk Group被强制dismount。在此模式下所有的ASM DISK必须都完好，否则Disk Group将无法MOUNT。 . NORMAL， 即ASM将为每一个asmfile extent创建一个额外的拷贝以便实现冗余；默认情况下所有的asmfile都会被镜像，这样每一个asmfile extent都有2份拷贝。若写错误发生在2个Disk上且这2个Disk是partners时将导致disk Disk Group被强制dismount。若发生失败的磁盘不是partners则不会引起数据丢失和不可用。 . HIGH， 即ASM为每一个asmfile extent创建两个额外的拷贝以便实现更高的冗余。2个互为partners的Disk的失败不会引起数据丢失，当然，不能有更多的partners Disk失败了。 数据镜像依赖于failure group和extent partnering实现。 . ASM在NORMAL 或 HIGH 冗余度下可以容许丢失一个failure group中所有的磁盘。 . 下面我来详细说下，Oracle如何通过failure group来提供数据的高可用性。 首先，ASM使用的镜像算法并不是镜像整个disk，而是作extent级的镜像。ASM会自动优化文件分布以降低设备故障造成数据丢失的可能性。 在normal redundancy模式下，ASM的按照extent进行striping时是在一个DiskGroup中完成的（即，在一个DG的2个Fail group之间完成的，而不是一个单独的FG中完成），ASM环境中每分配一个extent都会有一个primary copy和一个secondary copy，ASM的算法保证了secondary … 继续阅读 →

发表在 ASM, 体系架构, 内部机制 | 标签为 , , | 留下评论

看图说话——ASM实例和ASMB进程

发表于 2014 年 3 月 9 日 由 Lunar

先看一下ASM实例的大体部署： 我们都知道，ASM实例管理着元数据，普通数据库实例通过查询元数据的信息来访问相应的ASM文件。 ASM实例和数据库实例都可以访问一组普通的磁盘，这套磁盘被称为磁盘组。 然后，数据库实例直接访问ASM文件的内容，并在与ASM实例通信时获取有关这些文件的分布信息。 Group Services用于注册数据库实例查找ASM实例时所需要的连接信息： Group Services用于注册数据库实例查找ASM实例所需要的连接信息。 当ASM实例mount一个磁盘组时，它就将磁盘组的信息和连接串注册到Group Services。 数据库实例知道了磁盘组的名称，就可以找到应该连接到哪个ASM实例。 ASM实例有哪些独特地方： 1，INSTANCE_TYPE = ASM 2，startup = startup mount(11.2以后，可以直接对ASM实例 startup，但是本质还是startup mount)，对于ASM实例，mount选项不会去mount数据文件，而是mount在参数文件中ASM_DISKGROUPS指定的磁盘组 3，connect / as sysdba(10g) 和 connect / as sysasm(11.2) ASM的后台进程有很多，具体可以参考reference中的描述，这里只想研究一下数据库和ASM之间负责心跳机制的ASMB进程。 我们知道ASMB进程实际上是提供了一个数据库实例和ASM实例之间通信的桥梁，比如在数据库中创建、删除文件，或者修改文件等等的跟存储物理变化相关的操作。首先，我们观察下，他们在CRS,ASM和数据库启动过程中的启动顺序和先后关系： ASM的alert： DB的alert： ASM和数据库实例的ASMB进程都分别将信息注册到css中，参看ocssd.log: 这里，数据库启动时，ASMB的活动过程： 1，ASM实例的ASMB进程启动(spid: 3637，asm_asmb_+ASM1) 2，ASM实例的ASMB进程启动了一个连接到ASM实例的进程（spid：3641，oracle+ASM1_asmb_+asm1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))） … 继续阅读 →

发表在 ASM, Exadata | 标签为 , , | 留下评论

Exadata上验证ASM磁盘头备份的位置

发表于 2014 年 3 月 3 日 由 Lunar

我们都知道，从Oracle 10.2.0.5开始，ASM磁盘会自动备份磁盘头块，备份块的位置在第2个AU的倒数第2个块上。 通常，缺省情况下，AU SIZE是1M，每个AU可以有256个block（每个block 4k），256*4k()=1M 因此，第2个AU同样存放了256个block（0~255），其备份块的位置为 au=1 blkn=254(au和block都是从0开始计数的) 具体的恢复案例，可以参考： ASM磁盘头被fdisk损坏的修复过程 那么在exadata上，缺省的AU是4M，也就是每个AU可以存储 1024个block，即 block 0 ~ block 1023 那么第二个AU的倒数第二个block就是 au=1 blkn=1022 ( au和block都是从0开始计数的 ) 我们来检测一下是不是这样： 注意： 这里kfed命令中，需要指定ausz=4m，否则kfed缺省按照1M来计算，那么结果就是错误的了： 在kfed中指定ausz=4m，检测结果： 经过检查，我们发现，这个规律在exadata上依然有效，ASM除了缺省4M的AU，其余没什么变化，O(∩_∩)O哈哈~ 顺便介绍一个小方法，快速计算备份块的位置：（该方法根据ASM Support Guy修改而来）

发表在 ASM, 内部机制 | 标签为 , , | 一条评论

随心所欲的指定RAC中的节点号

发表于 2013 年 11 月 21 日 由 Lunar

考虑到节点逐出的规则，其中有一个跟节点号有关系，即缺省节点号小的被保留，大的被逐出（还有很多其他条件，比如分组等，这里不细说） 那天群里有人说了希望修改节点号的需求，今天忽然想起来试试看，结论如下： 1，可以使用ocrpatch任意指定任一个节点的节点号 2，不指定的情况，安装的节点为节点1，其余的顺次往下排 备份下当前OCR和VOT的信息： 这里，我们可以看见，节点1（rac1）的节点号是1，节点2（rac2）的节点号是2。。。 我打算把它修改为节点1（rac1）的节点号是2，节点2（rac2）的节点号是1 只读模式使用ocrpatch： 好了，现在我们来修改下 再开2个会话，分别用于停止节点1和节点2的crs： 注意这里，节点1，貌似hang住了。。 节点2已经clear shutdown了 于是想起来了，还有一个ocrpatch的窗口，退出后，大概几秒钟，继续shutdown： 在节点1以独占模式启动cluster： 把voting disk放到文件系统上： 以write read方式访问ocr： SYSTEM.css.nodenum_hint ，这个表示他们的 “preferred” node number ，这个是节点1，我们看到设置为1，现在，我们把它设置为2，然后观察下： 已经修改成功了。 ocrpatch> exit [OK] Exiting due to user request … [root@RAC1 tmp]# 现在，使用独占模式启动crs： 检查状态，都正常： 初始化votdisk： … 继续阅读 →

发表在 ASM, RAC | 标签为 , , | 留下评论