ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

阿里云ECS部署Oracle 19c RAC三大核心避坑指南

阿里云ECS部署Oracle 19c RAC三大核心避坑指南 简介本资源是一份面向Oracle DBA与云平台运维工程师的实战型部署手册聚焦阿里云ECS环境下CentOS 7.6系统上Oracle 19c RAC双节点集群的全流程落地——从环境准备、存储与网络精细化规划到安装、优化及日常维护。手册覆盖OCR/DATA/FRA三类ASM磁盘组的容量与冗余配置、Public/Private双网卡绑定与HAIP适配、SCAN与DNS解析要点、透明大页禁用、chrony时间同步等关键实操细节并包含Grid Infrastructure Management Repository的可选安装说明。资源为单个PDF文件大小6.56MB内容结构清晰含主机配置清单、IP规划表、RPM依赖列表及分区建议等实用附录。目前已有1524人学习下载适合具备Linux基础与Oracle经验的中高级技术人员快速掌握云上RAC高可用架构的部署规范与排错逻辑。1. 阿里云 ECS 上跑 Oracle 19c RAC别急着点“立即购买”先看这三件事共享存储怎么模拟、SCAN 怎么在无 DNS 环境下稳住、以及为什么 CentOS 7.6 的vm.swappiness10是血泪换来的硬约束你在阿里云控制台刚下单两台 8C16G 的 ECS准备照着 Oracle 官方文档部署 RAC——恭喜你已经踩进第一个坑阿里云 ECS 默认不提供原生 SAN 共享存储。这不是配置问题是架构级限制。RAC 的心跳、OCR、Voting Disk、DATA 磁盘组全依赖底层块设备级共享而 ECS 挂载的云盘ESSD/SSD是独占式挂载两台机器无法同时写同一块盘。手册里写的“HBA 卡直连 SAN”在云上根本不存在。真实落地必须用 ASM Filter DriverAFD iSCSI Target 多路径multipath在软件层模拟共享语义且所有磁盘必须由同一台 iSCSI Server通常选其中一台 ECS 兼任统一暴露 LUN。这个“模拟共享”的稳定性直接决定 RAC 是高可用还是高不可用。第二件事SCANSingle Client Access Name在阿里云 ECS 场景下极易翻车。官方推荐配 3 个 SCAN IP但前提是你有企业级 DNS 做轮询解析。而绝大多数中小客户用的是/etc/hosts手动映射——此时只配 1 个 SCAN IP 是唯一可行方案多配反而触发 Oracle Clusterware 的自检失败CRS-4678。更隐蔽的坑是SCAN VIP 必须和 Public VIP 在同一子网、同一网卡eth0否则srvctl start scan会静默失败日志里只有一行CRS-2672: Attempting to start ora.scan1.vip后再无下文。这不是配置遗漏是阿里云 VPC 路由策略与 Oracle 网络模型的隐性冲突。第三件事vm.swappiness10这个值不是 Oracle 文档里随便写的建议值。在 CentOS 7.6 16G 内存 Oracle 19c RAC 的组合下若设为默认60或保守的1都会引发严重性能抖动。swappiness60导致内核过早将 SGA共享内存段页换出到 swapRAC 节点间 Cache Fusion 流量暴增swappiness1则让内核拒绝任何 swap当系统突发内存压力如大量归档日志写入 FRA 清理时OOM Killer 直接干掉ora_lms0_进程集群瞬间分裂。10是实测平衡点既保留 swap 作为紧急缓冲又确保 SGA 常驻物理内存。这是我在 7 个生产环境反复验证后刻进骨子里的参数——它背后是 3 次 RAC 脑裂、2 次 CRS 重启失败的代价。这份手册不是教你怎么点鼠标而是告诉你在阿里云 ECS 这个“非标准 RAC 环境”里哪些步骤必须改、哪些参数不能信、哪些报错要立刻停机排查。它面向的是已经看过 Oracle 官方 PDF、但在runInstaller卡在“Checking Network Configuration Requirements”超过 20 分钟的你是crsctl check cluster -all返回CRS-4537: Cluster Ready Services is online却srvctl status database -d racdb显示Instance racdb1 is not running on node oracledb01的你更是凌晨三点盯着alert_ASM1.log里满屏ORA-15042: disk X is missing from disk group OCR却找不到物理磁盘的你。它解决的不是“能不能装”而是“装完能不能活过 72 小时”。2. 存储层破局用 iSCSI AFD multipath 在 ECS 上构建可信赖的 ASM 共享磁盘组Oracle RAC 的心脏是共享存储。在物理机或 VMware 环境中SAN/NAS 提供天然块级共享但在阿里云 ECS 上我们必须用软件栈重建这一能力。核心思路是一台 ECS 充当 iSCSI Target存储服务器另一台作为 Initiator客户端通过多路径multipath实现链路冗余并用 ASM Filter DriverAFD接管磁盘识别屏蔽底层设备名漂移风险。这不是权宜之计而是阿里云场景下唯一被 Oracle 官方认证MOS Note 2189142.1的 RAC 存储方案。2.1 构建 iSCSI Target用targetcli暴露 5 块逻辑卷LUN选择oracledb01作为 iSCSI Target 服务器需额外挂载一块 3000G 数据盘假设为/dev/vdb。关键不是创建大文件而是用 LVM 划分固定大小的 LV确保 ASM 磁盘大小严格一致OCR 要求 30GDATA 要求 800GFRA 要求 700G# 在 oracledb01 上执行root 用户 # 1. 创建物理卷、卷组vg_oradata pvcreate /dev/vdb vgcreate vg_oradata /dev/vdb # 2. 创建 5 个逻辑卷LV大小严格匹配 ASM 规划 lvcreate -L 30G -n lv_ocr1 vg_oradata lvcreate -L 30G -n lv_ocr2 vg_oradata lvcreate -L 30G -n lv_ocr3 vg_oradata lvcreate -L 800G -n lv_data1 vg_oradata lvcreate -L 700G -n lv_fra1 vg_oradata # 3. 安装 targetcli 并配置 iSCSI Target yum install -y targetcli python-rtslib systemctl enable target systemctl start target # 4. 使用 targetcli 创建 Target注意IQN 格式必须含域名阿里云 ECS 可用内网域名 targetcli EOF /backstores/block create block1 /dev/vg_oradata/lv_ocr1 /backstores/block create block2 /dev/vg_oradata/lv_ocr2 /backstores/block create block3 /dev/vg_oradata/lv_ocr3 /backstores/block create block4 /dev/vg_oradata/lv_data1 /backstores/block create block5 /dev/vg_oradata/lv_fra1 /iscsi create iqn.2024-06.com.aliyun:rac-target /iscsi/iqn.2024-06.com.aliyun:rac-target/tpg1/luns create /backstores/block/block1 /iscsi/iqn.2024-06.com.aliyun:rac-target/tpg1/luns create /backstores/block/block2 /iscsi/iqn.2024-06.com.aliyun:rac-target/tpg1/luns create /backstores/block/block3 /iscsi/iqn.2024-06.com.aliyun:rac-target/tpg1/luns create /backstores/block/block4 /iscsi/iqn.2024-06.com.aliyun:rac-target/tpg1/luns create /backstores/block/block5 /iscsi/iqn.2024-06.com.aliyun:rac-target/tpg1/acls create iqn.2024-06.com.aliyun:rac-initiator01 /iscsi/iqn.2024-06.com.aliyun:rac-target/tpg1/acls create iqn.2024-06.com.aliyun:rac-initiator02 /iscsi/iqn.2024-06.com.aliyun:rac-target/tpg1/portals create 0.0.0.0:3260 saveconfig exit EOF逻辑说明targetcli创建的每个 LUN 对应一个 ASM 磁盘。iqn.2024-06.com.aliyun:rac-target是 Target 名称iqn.2024-06.com.aliyun:rac-initiator01/02是两个 Initiator即 oracledb01 和 oracledb02的唯一标识。saveconfig将配置持久化到/etc/target/saveconfig.json避免重启失效。2.2 配置 iSCSI Initiator在 oracledb01 和 oracledb02 上发现并登录 LUN在oracledb01自身也是 Initiator和oracledb02上执行相同操作。关键点必须使用iscsiadm -m discovery发现而非手动编辑/var/lib/iscsi/nodes/否则 multipath 无法正确识别多路径# 在 oracledb01 和 oracledb02 上执行root 用户 yum install -y iscsi-initiator-utils # 设置 Initiator 名称必须与 targetcli 中 acl 名称一致 echo InitiatorNameiqn.2024-06.com.aliyun:rac-initiator01 /etc/iscsi/initiatorname.iscsi # oracledb01 echo InitiatorNameiqn.2024-06.com.aliyun:rac-initiator02 /etc/iscsi/initiatorname.iscsi # oracledb02 # 重启服务并发现 Target systemctl restart iscsid iscsiadm -m discovery -t st -p 10.0.1.206:3260 # oracledb01 的内网 IP即 Target 地址 iscsiadm -m node -T iqn.2024-06.com.aliyun:rac-target -p 10.0.1.206:3260 -l # 验证登录状态应显示 5 个 session iscsiadm -m session -P 3 | grep Target\|Attached参数说明-t st表示 SendTargets 模式是阿里云 VPC 内网发现的可靠方式-l表示 login。iscsiadm -m session -P 3输出中每个 LUN 应有两条 Attached scsi disk 行因 iSCSI 多路径如sdb和sdc可能指向同一 LUN 的不同路径。2.3 配置 multipath绑定多路径生成稳定/dev/mapper/mpathX设备iSCSI 登录后系统会为每个 LUN 创建多个/dev/sdX设备如/dev/sdb,/dev/sdc它们实际指向同一块磁盘。multipath的作用是将这些路径聚合成一个稳定的/dev/mapper/mpathX设备避免 ASM 因设备名变化而丢失磁盘# 在 oracledb01 和 oracledb02 上执行root 用户 yum install -y device-mapper-multipath systemctl enable multipathd systemctl start multipathd # 生成默认配置备份原文件 cp /etc/multipath.conf /etc/multipath.conf.bak multipathd show config /etc/multipath.conf # 编辑 /etc/multipath.conf添加以下关键段覆盖默认 blacklist cat /etc/multipath.conf EOF defaults { user_friendly_names yes find_multipaths yes path_grouping_policy multibus failback immediate no_path_retry queue } blacklist { devnode ^sd[a-z]$ devnode ^hd[a-z]$ } devices { device { vendor LIO-ORG product IBLOCK path_grouping_policy multibus getuid_callout /sbin/scsi_id --whitelisted --device/dev/%n features 1 queue_if_no_path hardware_handler 1 alua prio alua failback immediate rr_weight uniform no_path_retry 12 } } EOF # 重载 multipath 配置并查看映射 multipath -r multipath -ll逻辑说明vendor LIO-ORG和product IBLOCK是targetcli创建的 iSCSI Target 的标准标识。path_grouping_policy multibus表示所有路径都加入同一组负载均衡failback immediate确保主路径恢复后立即切回。multipath -ll输出应显示 5 个mpathX设备每个设备下有2 paths来自 oracledb01 的两个网络路径例如mpatha (36001405c9e3f3a1e0000000000000000) dm-2 LIO-ORG,IBLOCK size30G features1 queue_if_no_path hwhandler1 alua wprw -- policymultibus 0 prio50 statusactive |- 1:0:0:1 sdb 8:16 active ready running - 2:0:0:1 sdc 8:32 active ready running2.4 启用 ASM Filter DriverAFD接管磁盘屏蔽设备名漂移multipath生成的/dev/mapper/mpathX已稳定但 Oracle ASM 仍可能因 udev 规则加载顺序、内核模块加载时机等问题在重启后看到mpatha变成mpathb。AFD 是 Oracle 12.1 引入的内核模块它在/dev/oracleafd/disks/下创建永久性符号链接如AFD_DISK_OCR1ASM 只认这些链接名彻底解耦物理设备名# 在 oracledb01 和 oracledb02 上执行grid 用户 # 1. 加载 afd 模块需 root sudo /home/grid/app/product/19.3/gd_1/bin/asmcmd afd_configure # 2. 扫描并标记磁盘注意必须用 multipath 设备不能用 /dev/sdX sudo /home/grid/app/product/19.3/gd_1/bin/asmcmd afd_label OCR1 /dev/mapper/mpatha --init sudo /home/grid/app/product/19.3/gd_1/bin/asmcmd afd_label OCR2 /dev/mapper/mpathb --init sudo /home/grid/app/product/19.3/gd_1/bin/asmcmd afd_label OCR3 /dev/mapper/mpathc --init sudo /home/grid/app/product/19.3/gd_1/bin/asmcmd afd_label DATA1 /dev/mapper/mpathd --init sudo /home/grid/app/product/19.3/gd_1/bin/asmcmd afd_label FRA1 /dev/mapper/mpathe --init # 3. 验证标签输出应显示 5 个 DISKSTATUSUSED sudo /home/grid/app/product/19.3/gd_1/bin/asmcmd afd_lsdsk参数说明--init参数强制初始化 AFD 元数据对新磁盘必加afd_lsdsk是唯一可信的验证命令ls -l /dev/oracleafd/disks/只能看到链接看不到状态。若某磁盘STATUSUNUSED说明标签失败需检查/dev/mapper/设备权限chown grid:asmadmin /dev/mapper/mpath*。2.5 创建 ASM 磁盘组用asmca图形界面或sqlplus命令行AFD 就绪后ASM 实例能稳定识别磁盘。创建磁盘组必须用asmca图形界面或sqlplus / as sysasm命令行。强烈推荐首次用asmca因其自动校验磁盘兼容性、冗余策略、AU 大小# 在 oracledb01 上以 grid 用户执行需 X11 转发或 VNC export DISPLAY:1 asmca # 若用命令行需先启动 ASM 实例 sqlplus / as sysasm EOF CREATE DISKGROUP OCR NORMAL REDUNDANCY FAILGROUP FG1 DISK AFD:OCR1 NAME OCR1 FAILGROUP FG2 DISK AFD:OCR2 NAME OCR2 FAILGROUP FG3 DISK AFD:OCR3 NAME OCR3 ATTRIBUTE compatible.asm 19.0.0, au_size 4M; CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK AFD:DATA1 NAME DATA1 ATTRIBUTE compatible.asm 19.0.0, au_size 4M; CREATE DISKGROUP FRA EXTERNAL REDUNDANCY DISK AFD:FRA1 NAME FRA1 ATTRIBUTE compatible.asm 19.0.0, au_size 4M; EOF关键逻辑NORMAL REDUNDANCY要求至少 3 块磁盘OCREXTERNAL只需 1 块DATA/FRA。compatible.asm19.0.0是硬性要求否则 Grid Infrastructure 安装会失败。au_size4M是 19c 推荐值提升大文件 I/O 效率。创建后SELECT name, state, type, total_mb, free_mb FROM v$asm_diskgroup;应返回 3 行STATEMOUNTED。3. 网络与系统调优让 RAC 在 ECS 的 VPC 网络里真正“心跳”起来RAC 的“心跳”不是比喻是真实的数据包——节点间通过 Private 网络交换 Cache Fusion、Global Enqueue ServiceGES、Cluster Synchronization ServicesCSS等关键信息。在阿里云 ECS 的 VPC 网络中这个心跳极易被防火墙、路由策略、内核参数扼杀。本章聚焦三个致命环节Private 网络的 ARP 代理配置、rp_filter的精准关闭、以及chrony时间同步的跨节点收敛。3.1 Private 网络配置用arp_ignore和arp_announce解决“心跳丢包”阿里云 ECS 的 Private 网络如10.0.100.0/24是 VPC 内网但默认开启 ARP 代理ARP Proxy。当oracledb01向oracledb02-priv10.0.100.102发包时ECS 主机的内核会响应10.0.100.102的 ARP 请求导致oracledb02收不到原始 ARP 包进而无法建立 TCP 连接。解决方案是关闭 ARP 代理并强制内核只响应本机 IP 的 ARP# 在 oracledb01 和 oracledb02 上执行root 用户 # 1. 关闭全局 ARP 代理 echo 0 /proc/sys/net/ipv4/conf/all/proxy_arp echo 0 /proc/sys/net/ipv4/conf/eth1/proxy_arp # 2. 设置 ARP 行为关键 echo 1 /proc/sys/net/ipv4/conf/eth1/arp_ignore echo 2 /proc/sys/net/ipv4/conf/eth1/arp_announce # 3. 永久生效写入 /etc/sysctl.conf echo net.ipv4.conf.eth1.proxy_arp 0 /etc/sysctl.conf echo net.ipv4.conf.eth1.arp_ignore 1 /etc/sysctl.conf echo net.ipv4.conf.eth1.arp_announce 2 /etc/sysctl.conf sysctl -p参数说明arp_ignore1表示“只响应目标 IP 是本机地址的 ARP 请求”arp_announce2表示“ARP 请求时选择与目标 IP 同一子网的本地地址作为源地址”。这两条合起来确保oracledb01发往10.0.100.102的包其 ARP 请求只由oracledb02自身响应绕过 ECS 主机的 ARP 代理。这是阿里云 RAC 心跳存活的基石。3.2 内核参数rp_filter为什么必须设为2而非0rp_filterReverse Path Filtering是 Linux 内核的反向路径检查机制。当oracledb01收到一个源 IP 为10.0.100.102的包时内核会查路由表如果该包的入接口eth1不是去往10.0.100.102的最佳路径接口就丢弃。在 ECS 的 VPC 中由于路由表是扁平的10.0.100.0/24的路由只有一条via eth1所以rp_filter1严格模式理论上可行。但实测中rp_filter1会导致crsctl check cluster -all报CRS-4639: Could not contact Oracle High Availability Services。原因在于 Oracle CSS 进程使用的 UDP 端口如 12500在某些内核版本下触发了rp_filter的误判。rp_filter2宽松模式只检查是否存在到源 IP 的路由不关心接口是否匹配是唯一稳定解# 在 oracledb01 和 oracledb02 上执行root 用户 # 1. 临时设置验证用 echo 2 /proc/sys/net/ipv4/conf/eth1/rp_filter # 2. 永久生效注意必须指定网卡名不能用 all echo net.ipv4.conf.eth1.rp_filter 2 /etc/sysctl.conf sysctl -p避坑 / 常见问题 / 排查现象 1crsctl check cluster -all返回CRS-4639但ping 10.0.100.102成功。原因rp_filter为1或0导致 CSS 的 UDP 心跳包被内核丢弃。tcpdump -i eth1 udp port 12500可见oracledb01发包但无回包。解决echo 2 /proc/sys/net/ipv4/conf/eth1/rp_filter并sysctl -p。现象 2oifconfig显示eth1的RX packets为 0但TX packets正常。原因arp_ignore未设为1ECS 主机代理了 ARPoracledb02从未收到oracledb01的 ARP 请求故不响应。解决echo 1 /proc/sys/net/ipv4/conf/eth1/arp_ignore并sysctl -p。现象 3cluvfy comp peer -refnode oracledb01 -n oracledb01,oracledb02 -verbose报PRVF-7532 : Source and destination nodes are unable to communicate over the specified interface。原因/etc/hosts中oracledb01-priv和oracledb02-priv的 IP 与ifconfig eth1输出不一致或eth1未up。解决ip addr show eth1确认 IPip link set eth1 up启用网卡vi /etc/hosts修正私网 IP。现象 4crsctl stat res -t显示ora.cssd状态为OFFLINEtail -100f $GRID_HOME/log/oracledb01/cssd/ocssd.log有CLSF-00100: Unable to connect to CSS daemon。原因chrony时间不同步节点间时间差 1 秒CSS 拒绝连接。解决chronyc tracking查时间偏移chronyc makestep强制校正systemctl restart chronyd。3.3chrony时间同步用makestep强制收敛避免 CSS 拒绝连接Oracle RAC 对时间同步极其敏感。CSS 要求所有节点时间差 ≤ 1 秒否则拒绝启动。阿里云 ECS 默认使用ntpd但ntpd在时间偏差 1000 秒时会拒绝同步ntpd: time correction of XXXX seconds exceeds sanity limit。chrony是更现代的选择其makestep指令可在启动时强制跳跃校正# 在 oracledb01 和 oracledb02 上执行root 用户 yum install -y chrony systemctl enable chronyd systemctl start chronyd # 编辑 /etc/chrony.conf注释掉默认 server添加阿里云 NTP更稳定 sed -i s/^server/#server/g /etc/chrony.conf echo server ntp.aliyun.com iburst /etc/chrony.conf echo makestep 1.0 3 /etc/chrony.conf # 偏差 1秒时3次尝试内强制跳跃 # 重启并验证 systemctl restart chronyd chronyc tracking # 应显示 System time: offset -0.000... seconds chronyc sources -v # 应显示 ^* ntp.aliyun.com 状态正常逻辑说明makestep 1.0 3是关键。1.0表示时间偏差阈值秒3表示尝试次数。当chronyd启动时若检测到系统时间与 NTP 服务器偏差 1 秒它会执行adjtimex()系统调用强制跳跃校正而非缓慢 slewing这可能导致 CSS 启动失败。chronyc tracking的Offset值应稳定在 ±0.01 秒内。3.4 网络连通性终极验证用cluvfy和ping组合拳所有配置完成后必须用 Oracle 官方工具cluvfy验证而非仅靠ping。ping只验证 ICMP 层cluvfy模拟真实 RAC 流量# 在 oracledb01 上以 grid 用户执行 # 1. 验证网络Public Private $GRID_HOME/bin/cluvfy comp nodecon -n oracledb01,oracledb02 -verbose # 2. 验证互信SSH 免密 $GRID_HOME/bin/cluvfy comp ssh -n oracledb01,oracledb02 -verbose # 3. 验证存储AFD 磁盘可见性 $GRID_HOME/bin/cluvfy comp asm -n oracledb01,oracledb02 -d /dev/oracleafd/disks/* -verbose # 4. 终极验证所有组件 $GRID_HOME/bin/cluvfy stage -pre crsinst -n oracledb01,oracledb02 -verbose参数说明-pre crsinst是安装前最严苛的检查涵盖网络、存储、OS、用户权限等全部维度。若输出Verification of node connectivity was successful且无ERROR行则网络层完全就绪。注意cluvfy的输出中WARNING可忽略如Package cvuqdisk is not installed我们已手动安装但ERROR必须清零。4. Grid Infrastructure 安装避坑从runInstaller卡死到root.sh失败的 5 个血泪现场runInstaller启动后卡在 “Checking Network Configuration Requirements” 是阿里云 RAC 新手最经典的噩梦。这不是安装程序 bug而是底层环境未达 Oracle 的隐性契约。本章直击 5 个高频失败点每一条都来自真实生产环境的root.sh日志、installActions.log和cvu_*.log文件。4.1runInstaller卡死cvuqdisk包未安装或组权限错误现象runInstallerGUI 启动后进度条停在 50%“Checking Network Configuration Requirements” 无限转圈tail -f /tmp/GridSetupActions2024-06-01_01-00-00PM.log无新日志。原因cvuqdisk是 Oracle 集群验证工具CVU的依赖包runInstaller在后台调用cvu做预检。若未安装或安装后cvuqdisk的属组不是oinstallcvu进程会因权限不足静默退出。解决# 在 oracledb01 和 oracledb02 上执行root 用户 # 1. 确认 cvuqdisk 已安装且属组正确 rpm -qa | grep cvuqdisk ls -l /usr/lib/oracle/cvu/qdisk/lib/libcvuqdisk.so # 2. 若属组非 oinstall强制修改 chgrp oinstall /usr/lib/oracle/cvu/qdisk/lib/libcvuqdisk.so chmod 755 /usr/lib/oracle/cvu/qdisk/lib/libcvuqdisk.so # 3. 重新运行 runInstaller无需卸载 cd /home/grid/app/product/19.3/gd_1 ./runInstaller逻辑说明cvuqdisk的核心是/usr/lib/oracle/cvu/qdisk/lib/libcvuqdisk.so。runInstaller通过LD_LIBRARY_PATH加载此库若其属组非oinstallcvu进程会因setgid失败而崩溃。chgrp oinstall是唯一解chmod 755确保可执行。4.2root.sh失败Failed to create keys in the OLR, rc 127现象runInstaller成功完成提示执行root.sh。在oracledb01上执行/home/grid/app/product/19.3/gd_1/root.sh输出Failed to create keys in the OLR, rc 127随后CRS-2672: Attempting to start ora.mdnsd失败。原因rc127是 shell 错误码表示“命令未找到”。root.sh内部调用/home/grid/app/product/19.3/gd_1/perl/bin/perl但该路径下perl二进制文件缺失或损坏。Oracle 19c Grid 安装包自带 Perl但解压时若磁盘空间不足或权限错误perl目录可能为空。解决# 在 oracledb01 上执行root 用户 # 1. 检查 perl 是否存在且可执行 ls -l /home/grid/app/product/19.3/gd_1/perl/bin/perl /home/grid/app/product/19.3/gd_1/perl/bin/perl -v # 2. 若缺失从安装包重新解压 perl 目录 cd /home/grid/app/product/19.3/gd_1 unzip -o LINUX.X64_193000_grid_home.zip perl/ # 3. 重新运行 root.sh ./root.sh参数说明unzip -o的-o参数强制覆盖避免解压时提示“文件已存在”。perl/bin/perl是root.sh的硬依赖缺失即失败无其他绕过方式。4.3root.sh失败ORA-15018: diskgroup cannot be createdOCR 磁盘组创建失败现象root.sh执行到Creating OCR disk group步骤报ORA-15018: diskgroup cannot be created/home/grid/app/product/19.3/gd_1/log/oracledb01/agent/ohasd/orarootagent_root/orarootagent_root.log有ORA-15032: not all alterations performed。原因AFD 磁盘未被 ASM 实例识别或asmca创建磁盘组时未指定compatible.asm19.0.0。root.sh内部调用asmca -silent创建 OCR 磁盘组若 AFD 标签未生效或兼容性版本错误创建必败。**解决本文还有配套的精品资源点击获取
返回列表