干这行十来年ASM磁盘组的管理几乎每周都会碰到。今天想聊聊“Oracle ASM 命令行方式添加聚合磁盘”这件事。很多人看到“聚合磁盘”会愣一下因为Oracle官方文档里其实没有这个标准名词它更多是实践里的说法把多块物理裸盘交给ASM去统一管理组成一个磁盘组从数据库视角看就是一块能扩容、能均衡I/O的“聚合存储”。标题既然带了“添加”核心动作通常是往一个现成的磁盘组里追加新盘如果你是要新建磁盘组跑不掉的是同一套命令行体系本文会把两件事一起讲清楚。适合谁看刚接手Oracle库的运维新人、备库环境加过盘却不敢在生产动手的人或者每次都是图形界面点两下、搞不清背后发生了什么的人都可以认真读一遍。我会尽量把所有命令、查询、排查思路都按生产环境能直接执行的标准来写不搞花活。1. 先搞明白标题里的“聚合磁盘”到底指什么1.1 两种常见含义别一开始就做错在Oracle官方文档里你翻半天也找不到“聚合磁盘”这个术语。这个词通常是从存储领域借来的大家日常沟通中用“聚合”来指“把多块物理盘通过ASM聚合成一个磁盘组”的能力。更常见的说法是“添加磁盘到磁盘组”“扩展ASM磁盘组”“往DATA组里加盘”。所以接到这个标题的需求第一步不是敲命令而是跟需求方确认你要的是把一组新盘塞进现有磁盘组还是把一堆裸盘打包创建一个新磁盘组。这两个动作的语法有交集但后续影响、失败组划分方式、重平衡策略完全不同千万别会错意。如果你要的是前者核心命令是ALTER DISKGROUP ... ADD DISK如果是后者核心是CREATE DISKGROUP ... DISK。本文以“添加”为主线因为和“聚合”放在一起时大多数人实际是想给现有存储池扩容让新盘和旧盘融成一个逻辑整体。但为了方便查资料创建磁盘组的语法我也会单独写一节。实战里我对同事的要求向来是先把需求翻译成标准Oracle术语再谈操作能避免一半以上的误操作。1.2 加盘后ASM 内部到底发生了什么变化向一个非外部冗余NORMAL或HIGH的磁盘组添加新盘ASM会立刻把新盘纳入该磁盘组为它分配磁盘号、建立磁盘目录项然后触发一次重平衡。重平衡的本质是数据重新洗牌ASM会在整个磁盘组范围内把内部镜像的extent切分、搬运让分布更均匀。对NORMAL冗余来说每个extent有两份拷贝分别放在不同的失败组里。新增盘后一部分原本堆在旧盘上的副本会被搬到新盘目标是把I/O负载摊开。这也是为什么添加磁盘不是一个瞬时操作。盘少的时候几分钟完事盘多、数据量大时可能跑几小时甚至跨天期间I/O会有明显压力。生产环境对I/O敏感的话最好把重平衡Power调低或者直接安排在业务低峰。很多新手最容易忽略的就是这一点盘加进去SQL执行完并不等于安全落地要等V$ASM_OPERATION里没有正在运行的rebalance记录才算数。我后面会专门演示怎么查这个视图。2. 开工之前OS层磁盘准备与现场核查清单2.1 新盘在操作系统上必须满足的四个条件加盘不顺十有八九不是ASM命令写错了而是操作系统这一层没准备好。我习惯动手前按四步检查。第一OS必须能看到这块盘。Linux下用lsblkAIX下用lspv如果走的是多路径映射先确认多路径软件已经把盘生成出来。这里有个容易踩的坑存储侧把LUN映射给节点后机器未必自动识别需要重新扫描SCSI总线或者通过存储管理软件在存储侧额外操作。总之操作系统层面看不见ASM再厉害也没有用。第二盘的权限和属主必须和ASM实例的运行用户一致。Linux UDEV方式常用grid:asmadmin也有的环境是oracle:dba取决于你安装时怎么定义。文件权限一般是0660。如果盘的权限不对添加后ASM实例会报权限错误尤其在RAC里两台机器的盘权限不一致会出现一个节点正常、另一个节点报错排查起来非常痛苦。第三盘路径必须落在ASM_DISKSTRING的匹配范围内。例如参数值是/dev/oracleasm/disks/*你把一块盘配成了/dev/sdmASM根本不会去扫描它。这个在runbook里要特别标注先show parameter asm_diskstring再用ls -l核对路径别一上来就敲ALTER。第四磁盘头不能被旧数据污染。ASM要求新盘是“候选盘”状态如果盘头有残留信息ASM会拒绝使用。验证方式是用Kfed读盘头$ kfed read /dev/oracleasm/disks/ASMDATA09 | head -20如果输出异常说明盘头不干净。确认这块盘确实可以废弃后清掉前端数据再使用dd if/dev/zero of/dev/oracleasm/disks/ASMDATA09 bs1M count128注意dd清盘前必须百分百确认设备名没有写错一旦清错盘后果不用我多说。这步做完盘的状态才能重新被标记为CANDIDATE。2.2 磁盘组现状摸查往哪个失败组放新盘在ASM实例执行下面两条SQL先把家底盘清楚SELECT GROUP_NUMBER, NAME, TYPE, STATE, TOTAL_MB, FREE_MB, USABLE_FILE_MB FROM V$ASM_DISKGROUP; SELECT GROUP_NUMBER, DISK_NUMBER, NAME, PATH, FAILGROUP, STATE, HEADER_STATUS FROM V$ASM_DISK ORDER BY GROUP_NUMBER, FAILGROUP, DISK_NUMBER;第一条告诉你每个磁盘组的冗余类型、总量、剩余空间第二条告诉你现有盘各属于哪个失败组。为什么要看失败组NORMAL冗余要求同一个extent的两个副本不能落在同一个失败组里。如果你不加限定地往NORMAL冗余的磁盘组加盘ASM会按自己的策略把新盘分配到现有失败组一般也没问题。但如果你一次加了很多盘希望形成新的失败组来承载更多镜像对就需要在ADD语句里显式指定FAILGROUP否则ASM不一定会按你心里想的布局走。EXTERNAL冗余就简单得多没有镜像要求盘加进去直接扩充容量失败组通常就是每个磁盘自己。HIGH冗余则需要至少三个失败组扩展时最好成组加避免整个磁盘组因为失败组数量不足而无法满足冗余要求。这些判断在动手前就应该完成而不是等命令报错了再回头查。3. 命令行添加的核心操作CREATE / ALTER DISKGROUP 用法拆解3.1 添加磁盘的 SQL 语法逐项说明实际生产里用得最多的就是这一条ALTER DISKGROUP DATA ADD DISK /dev/oracleasm/disks/ASMDATA09 NAME DATA09;更完整的写法是这样带着失败组和power控制ALTER DISKGROUP DATA ADD DISK /dev/oracleasm/disks/ASMDATA10 NAME DATA10, DISK /dev/oracleasm/disks/ASMDATA11 NAME DATA11 FAILGROUP FGD01 REBALANCE POWER 4;几个参数值得展开说。NAME是给ASM磁盘组内的磁盘起逻辑名不写由ASM自动生成FAILGROUP指定失败组不指定由ASM安排REBALANCE POWER指定本次添加触发的重平衡强度范围受版本和CPU资源影响Power越大I/O开销越大、完成越快。生产环境如果不想让重平衡立刻抢占大量I/O可以先把Power设小之后再用REBALANCE命令调整。有一个容易忽略的细节如果磁盘头状态无法自动判定为候选盘ADD语句会报ORA-15033。这时可以在语句里加FORCE让ASM忽略磁盘头的部分信息强行加入。但FORCE有明确风险它可能让ASM错误覆盖还在使用的盘所以只应在新盘或确认无用的废弃盘上使用其他场景不要乱加。3.2 创建磁盘组时怎么“聚合”一片新盘空间如果需求确实是“新建一个聚合磁盘组”语法结构变成这样CREATE DISKGROUP FRA NORMAL REDUNDANCY FAILGROUP FG1 DISK /dev/oracleasm/disks/FRA01 NAME FRA01, DISK /dev/oracleasm/disks/FRA02 NAME FRA02 FAILGROUP FG2 DISK /dev/oracleasm/disks/FRA03 NAME FRA03, DISK /dev/oracleasm/disks/FRA04 NAME FRA04;CREATE DISKGROUP是对一批物理盘做“聚合”的正式入口它告诉ASM这些盘属于同一个磁盘组同时规定了镜像冗余级别和失败组边界。创建完成后存储层看到的就不是一个一个裸盘而是逻辑上的一个池子。数据库建数据文件、日志文件时只需要指定磁盘组名至于文件分配到哪块物理盘由ASM内部管理。如果是全新环境创建磁盘组的操作并不难难在规划失败组。我看到过太多人图方便把所有盘塞进一个失败组哪怕用的是NORMAL冗余镜像两份其实都落在同一批物理硬件上冗余效果约等于零。正确做法是至少把盘按存储框、按机柜、按控制器维度拆开让同一个extent的两份副本物理隔离这样省得以后真坏了一个控制器时连镜像一起丢。3.3 怎么确认重平衡真的跑完了添加语句执行成功后至少要看一次重平衡进度和最终磁盘状态。查重平衡用这条SQLSELECT GROUP_NUMBER, OPERATION, STATE, POWER, EST_RATE_MBPS, ACTUAL_RATE_MBPS, SOFAR, EST_WORK FROM V$ASM_OPERATION;输出里的STATE如果是“WAITING”或“RUN”说明还在重平衡直到没有记录返回或者STATE显示“DONE”重平衡才算完成。再查一次磁盘组空间SELECT NAME, TOTAL_MB, FREE_MB, USABLE_FILE_MB FROM V$ASM_DISKGROUP;如果TOTAL_MB刚好增加了你加进去的容量盘状态为ONLINE、HEADER_STATUS为MEMBER就可以放心告诉需求方盘已经到位。很多人在这里拉下检查第二天发现重平衡还在RUN、数据库I/O很高才知道命令结束不代表数据搬完。4. RAC多节点环境下的添加细节4.1 为什么所有节点都必须识别同一批磁盘有些环境加盘时只在其中一个节点操作另一个节点忘了扫盘或忘配UDEV结果就是ASM实例之间看到的磁盘拓扑不一致严重时直接报ORA-15032或磁盘组无法挂载。原因在于ASM是集群级组件每个节点都有自己的ASM实例磁盘组元数据由所有实例共同维护。盘只在节点A可见、节点B不可见就相当于这个磁盘组在节点B上“缺胳膊少腿”ASM的故障检查组关系也会跟着乱。所以RAC环境的标准流程是先在所有节点完成OS层的扫描、权限修改和多路径配置再执行UDEV重载或ASMLib重扫最后才在ASM实例层面执行添加命令。顺序一旦反了后续必然要返工。我在现场带人的时候几乎每次都要求操作者把两个节点的检查结果贴到同一页屏幕里对比确认再开始下一步。4.2 双节点实际操作流程以一个两节点的19c RAC为例完整流程大致这样。在节点1上确认OS层可见lsblk /dev/sdq /dev/sdr /dev/sds oracleasm listdisks然后分别在节点1和节点2上执行partprobe /dev/sdq /dev/sdr /dev/sds udevadm control --reload udevadm trigger检查权限ls -l /dev/oracleasm/disks/ASMDATA* crw-rw---- 1 grid asmadmin ...确认权限一致后从节点1的ASM实例执行添加语句。命令执行完不要只在一个节点上观察两个节点的ASM实例都查一下crsctl stat res -t或者直接SQL查询磁盘组状态。RAC环境尤其忌讳把重平衡Power调太高因为重平衡I/O是跨所有节点的集群级动作两个ASM实例都会参与I/O叠加效应比单实例明显。低峰期调到中等Power白天则保持较小Power这是比较稳的做法。5. 常见报错与避坑经验5.1 报错现象速查表现象/报错常见原因处理方式ORA-15032: not all alterations performed批量操作中有一条及以上失败看完整错误堆栈先解决根因再重跑ORA-15033: disk is not a candidate盘头状态不对或盘已属于其他磁盘组用kfed read检查盘头确认无误再使用FORCE或清盘头ORA-15085: ASM disk name conflicts自定义NAME和其他盘重名换新NAME或省略NAME让ASM自动生成ORA-15186: ASMLIB errorASMLib库、权限或设备路径异常检查oracleasm配置、asm_diskstring和/dev/oracleasm权限设备路径找不到ASM_DISKSTRING未覆盖该路径或系统还没扫描重扫SCSI总线、覆盖UDEV规则并触发reload添加后盘OFFLINE盘性能波动或节点间路径不一致查alert日志、多路径状态修复后执行ONLINE DISK重平衡长时间不结束Power太低、数据量太大或I/O被持续挤占在低峰期适度提高Power加速完成表里最容易被忽视的是最后两行。盘OFFLINE不一定代表这块盘物理坏了更多时候是它在重平衡或抖动期间的I/O响应时间超过阈值ASM把它踢出在线状态。这时候不要急着拔盘先看多路径、看存储端口、看OS层的I/O等待。重平衡时间过长也是同理Power调高只是让I/O更激进前提是存储后端确实扛得住别把压力全堆到业务高峰。5.2 实操习惯避免在生产环境翻车的几个约定第一个约定能一次加多块盘就不要一块一块加。每执行一次ADD都会触发一次重平衡一次加8块盘只重平衡一次拆成8次加等于让生产库的I/O被反复折腾。现场如果存储侧已经把盘都映射好了尽量在一条语句里把同一批盘全部添加。第二个约定加盘前先记录当前基准。比如查一下V$ASM_OPERATION有没有历史堆积看下AWR里的I/O基线加完后过一小时再对比及时发现异常。很多问题不是命令报错而是重平衡带来的长期性能损耗没有基线很难判断。第三个约定不要轻易把不同转速、不同型号的盘混在同一个失败组里。NORMAL或HIGH冗余下一个失败组的性能和容量往往决定磁盘组的下限慢盘会拖住所有镜像副本的写入。这个规则在“聚合磁盘”场景同样成立新盘容量和旧盘差异太大重平衡后可能出现容量水桶效应ASM会尽量均衡容量但总空间分配不会按物理容量百分之百跑满。6. 一次完整添加操作的现场复盘6.1 环境信息与动手前的判断用某个项目的生产环境举个例子信息已脱敏双节点RACOracle 19cDATA磁盘组NORMAL冗余原有12块盘分在两个失败组FG1和FG2当前可用空间约占60%。存储团队新挂了8块盘需要加入DATA组扩容。因为新盘类型和旧盘接近现场决定让它们均匀分布到FG1和FG2避免集中到某一个失败组导致冗余布局失衡。动手前先做三道确认所有节点OS能看见8块盘权限统一为grid:asmadmin盘头未被旧数据污染。确认没问题后在节点1的ASM实例里把8块盘的ADD语句组织成一次操作。注意这一步我刻意不看图形界面全走命令行因为命令行日志留痕清晰出了事能追溯。6.2 从扫描盘到重平衡完成的命令记录节点A上执行ls /dev/oracleasm/disks/ ASMDATA13 ASMDATA14 ASMDATA15 ASMDATA16 ASMDATA17 ASMDATA18 ASMDATA19 ASMDATA20节点B同样执行确认返回一致。然后分别在两个节点上udevadm control --reload udevadm trigger进入ASM实例执行添加ALTER DISKGROUP DATA ADD DISK /dev/oracleasm/disks/ASMDATA13 NAME DATA13 FAILGROUP FG1, DISK /dev/oracleasm/disks/ASMDATA14 NAME DATA14 FAILGROUP FG2, DISK /dev/oracleasm/disks/ASMDATA15 NAME DATA15 FAILGROUP FG1, DISK /dev/oracleasm/disks/ASMDATA16 NAME DATA16 FAILGROUP FG2, DISK /dev/oracleasm/disks/ASMDATA17 NAME DATA17 FAILGROUP FG1, DISK /dev/oracleasm/disks/ASMDATA18 NAME DATA18 FAILGROUP FG2, DISK /dev/oracleasm/disks/ASMDATA19 NAME DATA19 FAILGROUP FG1, DISK /dev/oracleasm/disks/ASMDATA20 NAME DATA20 FAILGROUP FG2;执行完立刻查重平衡SELECT OPERATION, STATE, POWER, EST_WORK, SOFAR, EST_RATE_MBPS FROM V$ASM_OPERATION;当时输出大致是REBAL RUN 8 386000 1200 40这表示重平衡正在跑。因为是在低峰期操作Power设在8观察最终没有新的V$ASM_OPERATION记录后再做一次验证SELECT NAME, TOTAL_MB, FREE_MB, USABLE_FILE_MB FROM V$ASM_DISKGROUP WHERE NAMEDATA;TOTAL_MB比原来增加了约2400000MB8块300G盘按ASM容量计算8块新盘HEADER_STATUS都是MEMBERSTATE为ONLINE。到这里这次操作才算真正落地。任何变更日志只写到“SQL执行成功”都算半截必须加上重平衡完成和磁盘状态验证。7. 添加完之后我习惯顺手做的几件事7.1 记录与归档即便重平衡已经完成我也不会急着关终端。当次的盘符、设备路径、新建的ASM磁盘名、FAILGROUP划分、添加日期全部记到变更文档里。很多环境半年后排查存储时发现某个失败组的盘数量不对称靠的就是这些记录。只看V$ASM_DISK能看到的是现状看不到的是当时的规划意图所以文档必须写清楚为什么这样分。另外ASM磁盘组的元数据有备份价值。如果环境允许我会顺手把当前磁盘组配置导出一份SELECT NAME, FAILGROUP, PATH FROM V$ASM_DISK;留着以后排查或者做环境克隆时用省事不少。7.2 后续观测添加完盘的24小时内重点观察两件事一是重平衡是否真的结束二是加盘后数据库的I/O有没有明显波动。如果用了很低的重平衡Power可能出现“看似结束第二天又继续跑”的情况。ASM会把重平衡操作分成多个批次V$ASM_OPERATION里偶尔会出现新纪录不用慌确认Power设置和I/O等待合理即可。另一个观察点是磁盘组的空间分布。新盘容量如果和旧盘差异比较大重平衡后个别盘可能接近写满这时需要主动调整数据文件布局或再一次做extent迁移。我个人在实际操作中的体会是命令行方式加盘并不难难的是把“加盘”当成一次完整的存储变更来对待准备、执行、验证、记录一个环节都不能省。尤其是RAC环境多节点一致性永远是第一优先级任何只在一台机器上确认的动作都等于没确认。
干这行十来年ASM磁盘组的管理几乎每周都会碰到。今天想聊聊“Oracle ASM 命令行方式添加聚合磁盘”这件事。很多人看到“聚合磁盘”会愣一下因为Oracle官方文档里其实没有这个标准名词它更多是实践里的说法把多块物理裸盘交给ASM去统一管理组成一个磁盘组从数据库视角看就是一块能扩容、能均衡I/O的“聚合存储”。标题既然带了“添加”核心动作通常是往一个现成的磁盘组里追加新盘如果你是要新建磁盘组跑不掉的是同一套命令行体系本文会把两件事一起讲清楚。适合谁看刚接手Oracle库的运维新人、备库环境加过盘却不敢在生产动手的人或者每次都是图形界面点两下、搞不清背后发生了什么的人都可以认真读一遍。我会尽量把所有命令、查询、排查思路都按生产环境能直接执行的标准来写不搞花活。1. 先搞明白标题里的“聚合磁盘”到底指什么1.1 两种常见含义别一开始就做错在Oracle官方文档里你翻半天也找不到“聚合磁盘”这个术语。这个词通常是从存储领域借来的大家日常沟通中用“聚合”来指“把多块物理盘通过ASM聚合成一个磁盘组”的能力。更常见的说法是“添加磁盘到磁盘组”“扩展ASM磁盘组”“往DATA组里加盘”。所以接到这个标题的需求第一步不是敲命令而是跟需求方确认你要的是把一组新盘塞进现有磁盘组还是把一堆裸盘打包创建一个新磁盘组。这两个动作的语法有交集但后续影响、失败组划分方式、重平衡策略完全不同千万别会错意。如果你要的是前者核心命令是ALTER DISKGROUP ... ADD DISK如果是后者核心是CREATE DISKGROUP ... DISK。本文以“添加”为主线因为和“聚合”放在一起时大多数人实际是想给现有存储池扩容让新盘和旧盘融成一个逻辑整体。但为了方便查资料创建磁盘组的语法我也会单独写一节。实战里我对同事的要求向来是先把需求翻译成标准Oracle术语再谈操作能避免一半以上的误操作。1.2 加盘后ASM 内部到底发生了什么变化向一个非外部冗余NORMAL或HIGH的磁盘组添加新盘ASM会立刻把新盘纳入该磁盘组为它分配磁盘号、建立磁盘目录项然后触发一次重平衡。重平衡的本质是数据重新洗牌ASM会在整个磁盘组范围内把内部镜像的extent切分、搬运让分布更均匀。对NORMAL冗余来说每个extent有两份拷贝分别放在不同的失败组里。新增盘后一部分原本堆在旧盘上的副本会被搬到新盘目标是把I/O负载摊开。这也是为什么添加磁盘不是一个瞬时操作。盘少的时候几分钟完事盘多、数据量大时可能跑几小时甚至跨天期间I/O会有明显压力。生产环境对I/O敏感的话最好把重平衡Power调低或者直接安排在业务低峰。很多新手最容易忽略的就是这一点盘加进去SQL执行完并不等于安全落地要等V$ASM_OPERATION里没有正在运行的rebalance记录才算数。我后面会专门演示怎么查这个视图。2. 开工之前OS层磁盘准备与现场核查清单2.1 新盘在操作系统上必须满足的四个条件加盘不顺十有八九不是ASM命令写错了而是操作系统这一层没准备好。我习惯动手前按四步检查。第一OS必须能看到这块盘。Linux下用lsblkAIX下用lspv如果走的是多路径映射先确认多路径软件已经把盘生成出来。这里有个容易踩的坑存储侧把LUN映射给节点后机器未必自动识别需要重新扫描SCSI总线或者通过存储管理软件在存储侧额外操作。总之操作系统层面看不见ASM再厉害也没有用。第二盘的权限和属主必须和ASM实例的运行用户一致。Linux UDEV方式常用grid:asmadmin也有的环境是oracle:dba取决于你安装时怎么定义。文件权限一般是0660。如果盘的权限不对添加后ASM实例会报权限错误尤其在RAC里两台机器的盘权限不一致会出现一个节点正常、另一个节点报错排查起来非常痛苦。第三盘路径必须落在ASM_DISKSTRING的匹配范围内。例如参数值是/dev/oracleasm/disks/*你把一块盘配成了/dev/sdmASM根本不会去扫描它。这个在runbook里要特别标注先show parameter asm_diskstring再用ls -l核对路径别一上来就敲ALTER。第四磁盘头不能被旧数据污染。ASM要求新盘是“候选盘”状态如果盘头有残留信息ASM会拒绝使用。验证方式是用Kfed读盘头$ kfed read /dev/oracleasm/disks/ASMDATA09 | head -20如果输出异常说明盘头不干净。确认这块盘确实可以废弃后清掉前端数据再使用dd if/dev/zero of/dev/oracleasm/disks/ASMDATA09 bs1M count128注意dd清盘前必须百分百确认设备名没有写错一旦清错盘后果不用我多说。这步做完盘的状态才能重新被标记为CANDIDATE。2.2 磁盘组现状摸查往哪个失败组放新盘在ASM实例执行下面两条SQL先把家底盘清楚SELECT GROUP_NUMBER, NAME, TYPE, STATE, TOTAL_MB, FREE_MB, USABLE_FILE_MB FROM V$ASM_DISKGROUP; SELECT GROUP_NUMBER, DISK_NUMBER, NAME, PATH, FAILGROUP, STATE, HEADER_STATUS FROM V$ASM_DISK ORDER BY GROUP_NUMBER, FAILGROUP, DISK_NUMBER;第一条告诉你每个磁盘组的冗余类型、总量、剩余空间第二条告诉你现有盘各属于哪个失败组。为什么要看失败组NORMAL冗余要求同一个extent的两个副本不能落在同一个失败组里。如果你不加限定地往NORMAL冗余的磁盘组加盘ASM会按自己的策略把新盘分配到现有失败组一般也没问题。但如果你一次加了很多盘希望形成新的失败组来承载更多镜像对就需要在ADD语句里显式指定FAILGROUP否则ASM不一定会按你心里想的布局走。EXTERNAL冗余就简单得多没有镜像要求盘加进去直接扩充容量失败组通常就是每个磁盘自己。HIGH冗余则需要至少三个失败组扩展时最好成组加避免整个磁盘组因为失败组数量不足而无法满足冗余要求。这些判断在动手前就应该完成而不是等命令报错了再回头查。3. 命令行添加的核心操作CREATE / ALTER DISKGROUP 用法拆解3.1 添加磁盘的 SQL 语法逐项说明实际生产里用得最多的就是这一条ALTER DISKGROUP DATA ADD DISK /dev/oracleasm/disks/ASMDATA09 NAME DATA09;更完整的写法是这样带着失败组和power控制ALTER DISKGROUP DATA ADD DISK /dev/oracleasm/disks/ASMDATA10 NAME DATA10, DISK /dev/oracleasm/disks/ASMDATA11 NAME DATA11 FAILGROUP FGD01 REBALANCE POWER 4;几个参数值得展开说。NAME是给ASM磁盘组内的磁盘起逻辑名不写由ASM自动生成FAILGROUP指定失败组不指定由ASM安排REBALANCE POWER指定本次添加触发的重平衡强度范围受版本和CPU资源影响Power越大I/O开销越大、完成越快。生产环境如果不想让重平衡立刻抢占大量I/O可以先把Power设小之后再用REBALANCE命令调整。有一个容易忽略的细节如果磁盘头状态无法自动判定为候选盘ADD语句会报ORA-15033。这时可以在语句里加FORCE让ASM忽略磁盘头的部分信息强行加入。但FORCE有明确风险它可能让ASM错误覆盖还在使用的盘所以只应在新盘或确认无用的废弃盘上使用其他场景不要乱加。3.2 创建磁盘组时怎么“聚合”一片新盘空间如果需求确实是“新建一个聚合磁盘组”语法结构变成这样CREATE DISKGROUP FRA NORMAL REDUNDANCY FAILGROUP FG1 DISK /dev/oracleasm/disks/FRA01 NAME FRA01, DISK /dev/oracleasm/disks/FRA02 NAME FRA02 FAILGROUP FG2 DISK /dev/oracleasm/disks/FRA03 NAME FRA03, DISK /dev/oracleasm/disks/FRA04 NAME FRA04;CREATE DISKGROUP是对一批物理盘做“聚合”的正式入口它告诉ASM这些盘属于同一个磁盘组同时规定了镜像冗余级别和失败组边界。创建完成后存储层看到的就不是一个一个裸盘而是逻辑上的一个池子。数据库建数据文件、日志文件时只需要指定磁盘组名至于文件分配到哪块物理盘由ASM内部管理。如果是全新环境创建磁盘组的操作并不难难在规划失败组。我看到过太多人图方便把所有盘塞进一个失败组哪怕用的是NORMAL冗余镜像两份其实都落在同一批物理硬件上冗余效果约等于零。正确做法是至少把盘按存储框、按机柜、按控制器维度拆开让同一个extent的两份副本物理隔离这样省得以后真坏了一个控制器时连镜像一起丢。3.3 怎么确认重平衡真的跑完了添加语句执行成功后至少要看一次重平衡进度和最终磁盘状态。查重平衡用这条SQLSELECT GROUP_NUMBER, OPERATION, STATE, POWER, EST_RATE_MBPS, ACTUAL_RATE_MBPS, SOFAR, EST_WORK FROM V$ASM_OPERATION;输出里的STATE如果是“WAITING”或“RUN”说明还在重平衡直到没有记录返回或者STATE显示“DONE”重平衡才算完成。再查一次磁盘组空间SELECT NAME, TOTAL_MB, FREE_MB, USABLE_FILE_MB FROM V$ASM_DISKGROUP;如果TOTAL_MB刚好增加了你加进去的容量盘状态为ONLINE、HEADER_STATUS为MEMBER就可以放心告诉需求方盘已经到位。很多人在这里拉下检查第二天发现重平衡还在RUN、数据库I/O很高才知道命令结束不代表数据搬完。4. RAC多节点环境下的添加细节4.1 为什么所有节点都必须识别同一批磁盘有些环境加盘时只在其中一个节点操作另一个节点忘了扫盘或忘配UDEV结果就是ASM实例之间看到的磁盘拓扑不一致严重时直接报ORA-15032或磁盘组无法挂载。原因在于ASM是集群级组件每个节点都有自己的ASM实例磁盘组元数据由所有实例共同维护。盘只在节点A可见、节点B不可见就相当于这个磁盘组在节点B上“缺胳膊少腿”ASM的故障检查组关系也会跟着乱。所以RAC环境的标准流程是先在所有节点完成OS层的扫描、权限修改和多路径配置再执行UDEV重载或ASMLib重扫最后才在ASM实例层面执行添加命令。顺序一旦反了后续必然要返工。我在现场带人的时候几乎每次都要求操作者把两个节点的检查结果贴到同一页屏幕里对比确认再开始下一步。4.2 双节点实际操作流程以一个两节点的19c RAC为例完整流程大致这样。在节点1上确认OS层可见lsblk /dev/sdq /dev/sdr /dev/sds oracleasm listdisks然后分别在节点1和节点2上执行partprobe /dev/sdq /dev/sdr /dev/sds udevadm control --reload udevadm trigger检查权限ls -l /dev/oracleasm/disks/ASMDATA* crw-rw---- 1 grid asmadmin ...确认权限一致后从节点1的ASM实例执行添加语句。命令执行完不要只在一个节点上观察两个节点的ASM实例都查一下crsctl stat res -t或者直接SQL查询磁盘组状态。RAC环境尤其忌讳把重平衡Power调太高因为重平衡I/O是跨所有节点的集群级动作两个ASM实例都会参与I/O叠加效应比单实例明显。低峰期调到中等Power白天则保持较小Power这是比较稳的做法。5. 常见报错与避坑经验5.1 报错现象速查表现象/报错常见原因处理方式ORA-15032: not all alterations performed批量操作中有一条及以上失败看完整错误堆栈先解决根因再重跑ORA-15033: disk is not a candidate盘头状态不对或盘已属于其他磁盘组用kfed read检查盘头确认无误再使用FORCE或清盘头ORA-15085: ASM disk name conflicts自定义NAME和其他盘重名换新NAME或省略NAME让ASM自动生成ORA-15186: ASMLIB errorASMLib库、权限或设备路径异常检查oracleasm配置、asm_diskstring和/dev/oracleasm权限设备路径找不到ASM_DISKSTRING未覆盖该路径或系统还没扫描重扫SCSI总线、覆盖UDEV规则并触发reload添加后盘OFFLINE盘性能波动或节点间路径不一致查alert日志、多路径状态修复后执行ONLINE DISK重平衡长时间不结束Power太低、数据量太大或I/O被持续挤占在低峰期适度提高Power加速完成表里最容易被忽视的是最后两行。盘OFFLINE不一定代表这块盘物理坏了更多时候是它在重平衡或抖动期间的I/O响应时间超过阈值ASM把它踢出在线状态。这时候不要急着拔盘先看多路径、看存储端口、看OS层的I/O等待。重平衡时间过长也是同理Power调高只是让I/O更激进前提是存储后端确实扛得住别把压力全堆到业务高峰。5.2 实操习惯避免在生产环境翻车的几个约定第一个约定能一次加多块盘就不要一块一块加。每执行一次ADD都会触发一次重平衡一次加8块盘只重平衡一次拆成8次加等于让生产库的I/O被反复折腾。现场如果存储侧已经把盘都映射好了尽量在一条语句里把同一批盘全部添加。第二个约定加盘前先记录当前基准。比如查一下V$ASM_OPERATION有没有历史堆积看下AWR里的I/O基线加完后过一小时再对比及时发现异常。很多问题不是命令报错而是重平衡带来的长期性能损耗没有基线很难判断。第三个约定不要轻易把不同转速、不同型号的盘混在同一个失败组里。NORMAL或HIGH冗余下一个失败组的性能和容量往往决定磁盘组的下限慢盘会拖住所有镜像副本的写入。这个规则在“聚合磁盘”场景同样成立新盘容量和旧盘差异太大重平衡后可能出现容量水桶效应ASM会尽量均衡容量但总空间分配不会按物理容量百分之百跑满。6. 一次完整添加操作的现场复盘6.1 环境信息与动手前的判断用某个项目的生产环境举个例子信息已脱敏双节点RACOracle 19cDATA磁盘组NORMAL冗余原有12块盘分在两个失败组FG1和FG2当前可用空间约占60%。存储团队新挂了8块盘需要加入DATA组扩容。因为新盘类型和旧盘接近现场决定让它们均匀分布到FG1和FG2避免集中到某一个失败组导致冗余布局失衡。动手前先做三道确认所有节点OS能看见8块盘权限统一为grid:asmadmin盘头未被旧数据污染。确认没问题后在节点1的ASM实例里把8块盘的ADD语句组织成一次操作。注意这一步我刻意不看图形界面全走命令行因为命令行日志留痕清晰出了事能追溯。6.2 从扫描盘到重平衡完成的命令记录节点A上执行ls /dev/oracleasm/disks/ ASMDATA13 ASMDATA14 ASMDATA15 ASMDATA16 ASMDATA17 ASMDATA18 ASMDATA19 ASMDATA20节点B同样执行确认返回一致。然后分别在两个节点上udevadm control --reload udevadm trigger进入ASM实例执行添加ALTER DISKGROUP DATA ADD DISK /dev/oracleasm/disks/ASMDATA13 NAME DATA13 FAILGROUP FG1, DISK /dev/oracleasm/disks/ASMDATA14 NAME DATA14 FAILGROUP FG2, DISK /dev/oracleasm/disks/ASMDATA15 NAME DATA15 FAILGROUP FG1, DISK /dev/oracleasm/disks/ASMDATA16 NAME DATA16 FAILGROUP FG2, DISK /dev/oracleasm/disks/ASMDATA17 NAME DATA17 FAILGROUP FG1, DISK /dev/oracleasm/disks/ASMDATA18 NAME DATA18 FAILGROUP FG2, DISK /dev/oracleasm/disks/ASMDATA19 NAME DATA19 FAILGROUP FG1, DISK /dev/oracleasm/disks/ASMDATA20 NAME DATA20 FAILGROUP FG2;执行完立刻查重平衡SELECT OPERATION, STATE, POWER, EST_WORK, SOFAR, EST_RATE_MBPS FROM V$ASM_OPERATION;当时输出大致是REBAL RUN 8 386000 1200 40这表示重平衡正在跑。因为是在低峰期操作Power设在8观察最终没有新的V$ASM_OPERATION记录后再做一次验证SELECT NAME, TOTAL_MB, FREE_MB, USABLE_FILE_MB FROM V$ASM_DISKGROUP WHERE NAMEDATA;TOTAL_MB比原来增加了约2400000MB8块300G盘按ASM容量计算8块新盘HEADER_STATUS都是MEMBERSTATE为ONLINE。到这里这次操作才算真正落地。任何变更日志只写到“SQL执行成功”都算半截必须加上重平衡完成和磁盘状态验证。7. 添加完之后我习惯顺手做的几件事7.1 记录与归档即便重平衡已经完成我也不会急着关终端。当次的盘符、设备路径、新建的ASM磁盘名、FAILGROUP划分、添加日期全部记到变更文档里。很多环境半年后排查存储时发现某个失败组的盘数量不对称靠的就是这些记录。只看V$ASM_DISK能看到的是现状看不到的是当时的规划意图所以文档必须写清楚为什么这样分。另外ASM磁盘组的元数据有备份价值。如果环境允许我会顺手把当前磁盘组配置导出一份SELECT NAME, FAILGROUP, PATH FROM V$ASM_DISK;留着以后排查或者做环境克隆时用省事不少。7.2 后续观测添加完盘的24小时内重点观察两件事一是重平衡是否真的结束二是加盘后数据库的I/O有没有明显波动。如果用了很低的重平衡Power可能出现“看似结束第二天又继续跑”的情况。ASM会把重平衡操作分成多个批次V$ASM_OPERATION里偶尔会出现新纪录不用慌确认Power设置和I/O等待合理即可。另一个观察点是磁盘组的空间分布。新盘容量如果和旧盘差异比较大重平衡后个别盘可能接近写满这时需要主动调整数据文件布局或再一次做extent迁移。我个人在实际操作中的体会是命令行方式加盘并不难难的是把“加盘”当成一次完整的存储变更来对待准备、执行、验证、记录一个环节都不能省。尤其是RAC环境多节点一致性永远是第一优先级任何只在一台机器上确认的动作都等于没确认。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
