企业官网建设流程全解析

简介：本资源是一份面向DBA与Oracle高可用架构工程师的19c RAC生产级部署实战手册，聚焦Red Hat Enterprise Linux 7.6平台下的集群安装与深度配置。内容覆盖GNS环境搭建、SCAN配置、Flex ASM原理与演进（含12.2起Standalone Cluster与Domain Service Cluster双模式对比）、THP禁用与HugePages启用、内核参数调优（Preinstall RPM与手工配置双路径）、网络规划（固定IP与GNS混合方案）以及时钟同步等关键环节，并附有典型故障的定位逻辑与解决方法。资源为单文件Word文档（.docx），共1个文件，大小仅160KB，结构清晰、步骤详实，目录已细化至子章节（如2.1禁用透明大页面、5.2 GNS+固定配置等），便于快速查阅与实操对照。目前已有716人学习下载，适合具备Linux基础与Oracle单机经验、正迈向RAC高可用架构落地的中高级数据库运维人员系统掌握19c RAC部署全链路要点。

1. Oracle 19c RAC on Linux 7.6 安装手册：不是“照着点下一步”就能跑通的集群部署，而是对内核、网络、存储三重边界的硬核校准

你手里的这份.docx文件，表面看是份安装指南，实际是一张 Oracle 19c RAC 在 RHEL/OL 7.6 上的「系统级兼容性地图」。它不教你 SQL，也不讲 PL/SQL，但它决定你能不能在gridSetup.sh界面点完“Install”后，看到CRS-4123: Oracle High Availability Services has been started.而不是卡在PRVF-5431: Cannot verify the specified nodes或更糟的ORA-15032: not all alterations performed。这不是数据库安装，是操作系统与 Oracle Grid Infrastructure 的联合调试——RAM 不够 8G？/dev/shm权限不对？transparent_hugepage=never没写进 GRUB？哪怕只漏掉其中一项，runInstaller启动前就会被 Cluster Verification Utility（CVU）当场拦截。尤其当你用的是 Red Hat Enterprise Linux 7.6（非 Oracle Linux），preinstall RPM 不直接适配，所有内核参数、limits、udev 规则都得手工抠准字节级配置。这份手册的价值，正在于它把 Oracle 官方文档里分散在 20+ 个章节的隐性依赖，压缩成一份可逐项打钩的 checklist：从/proc/cmdline验证 THP 关闭状态，到named.rac.libai区域文件里IN A记录的顺序，再到gridSetup.sh中 SCAN 域名必须包含 GNS 子域的强制语法约束。适合谁？不是刚学sqlplus / as sysdba的新手，而是已能独立部署单机 19c、正要跨入 RAC 世界、且愿意为每个sysctl -p失败追查到/etc/sysctl.d/加载顺序的 DBA 或系统工程师。

2. OS 环境与内核调优：THP 关闭与 HugePages 分配的精确计算

Oracle RAC 对内存管理极度敏感。19c 要求关闭透明大页（THP），同时启用显式 HugePages —— 这不是二选一，而是必须并行完成的两步。很多翻车现场，都源于只做了前者，或后者分配值算错。下面拆解真实操作链路。

2.1 彻底禁用透明大页（THP）：不止改 GRUB，还要验证加载路径

THP 在 Linux 内核中默认启用，会干扰 Oracle SGA 的内存锁定。仅修改/etc/default/grub不够，必须确保新内核参数被 GRUB 正确读取并传递给 init 进程。

# 1. 检查当前 THP 状态（注意方括号标记的激活项） [root@node1 ~]# cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never # 2. 编辑 GRUB 配置，向内核命令行追加参数 [root@node1 ~]# vi /etc/default/grub # 在 GRUB_CMDLINE_LINUX 行末尾添加 transparent_hugepage=never GRUB_CMDLINE_LINUX="... rhgb quiet transparent_hugepage=never" # 3. 重建 GRUB 配置（BIOS 机器） [root@node1 ~]# grub2-mkconfig -o /boot/grub2/grub.cfg # 4. 重启后验证：参数必须出现在 /proc/cmdline 中 [root@node1 ~]# cat /proc/cmdline | grep transparent_hugepage rd.lvm.lv=rhel/root ... transparent_hugepage=never

注意：若cat /proc/cmdline未输出transparent_hugepage=never，说明 GRUB 重建失败或未生效。常见原因是grub2-mkconfig输出路径错误（UEFI 机器应为/boot/efi/EFI/redhat/grub.cfg），或/etc/default/grub修改后未保存。此时reboot无效，必须重新执行grub2-mkconfig并确认返回done。

2.2 HugePages 分配：不是拍脑袋填数字，而是按 SGA 总和 + GIMR（如启用）反推

HugePages 数量 =(SGA_TARGET 或 SGA_MAX_SIZE 总和) / 2MB（默认页大小）。若启用 GIMR（19c Standalone Cluster 可选），需额外预留约 1GB（即 512 个 2MB 页面）。假设两节点 SGA 各设 8GB，且启用 GIMR：

# 计算：(8GB + 8GB + 1GB) = 17GB → 17 * 1024 MB / 2 MB = 8704 # 注意：单位是页数，不是 MB！ [root@node1 ~]# echo "vm.nr_hugepages = 8704" >> /etc/sysctl.d/97-oracledatabase-sysctl.conf [root@node1 ~]# sysctl -p /etc/sysctl.d/97-oracledatabase-sysctl.conf # 验证分配结果（应显示 8704） [root@node1 ~]# cat /proc/sys/vm/nr_hugepages 8704 # 检查 HugePages 是否被 Oracle 进程锁定（关键！） [root@node1 ~]# grep -i huge /proc/meminfo HugePages_Total: 8704 HugePages_Free: 8704 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB

逻辑说明：HugePages_Free初始等于HugePages_Total，表示页面已分配但未被使用。当grid用户启动 ASM 实例后，HugePages_Free应下降，HugePages_Rsvd上升。若HugePages_Rsvd始终为 0，说明 Oracle 进程未成功锁定 HugePages —— 常见原因是oracle用户的memlock限制过低（见 6.7 节），或vm.nr_hugepages设置后未执行sysctl -p。

2.3 内核参数手工配置：为什么sysctl.d/优先级高于sysctl.conf

Oracle 官方推荐将参数写入/etc/sysctl.d/97-oracledatabase-sysctl.conf而非/etc/sysctl.conf，因为 systemd 的sysctl服务按文件名 ASCII 排序加载，97-*确保在其他配置之后生效，避免被覆盖。

# 创建专用配置文件（注意文件名以数字开头） [root@node1 ~]# cat > /etc/sysctl.d/97-oracledatabase-sysctl.conf << 'EOF' fs.aio-max-nr = 1048576 fs.file-max = 6815744 kernel.shmall = 2097152 kernel.shmmax = 4294967295 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 vm.nr_hugepages = 8704 EOF # 加载全部 sysctl.d 下的配置（比 sysctl -p 更彻底） [root@node1 ~]# sysctl --system # 验证关键参数是否生效 [root@node1 ~]# sysctl fs.file-max kernel.shmmax net.ipv4.ip_local_port_range fs.file-max = 6815744 kernel.shmmax = 4294967295 net.ipv4.ip_local_port_range = 9000 65500

参数说明：

• kernel.shmmax：单个共享内存段最大字节数，必须 ≥ 最大 SGA_TARGET（19c 默认 4GB 即4294967295字节）。
• net.ipv4.ip_local_port_range：Oracle 监听器和客户端连接使用的端口范围，9000 65500避免与常用服务冲突。
• fs.aio-max-nr：异步 I/O 请求队列深度，RAC 环境下必须 ≥1048576（1M），否则 ASM 启动报ORA-15064。

3. 软件包与用户环境：Preinstall RPM 的局限性与手工补漏清单

RHEL 7.6 自带的oracle-database-preinstall-19cRPM 是个好起点，但它无法覆盖所有 RAC 特有依赖，尤其当你的环境启用了 GNS 或 ACFS。必须手动校验并安装缺失包。

3.1 Preinstall RPM 的适用边界：Oracle Linux 优先，RHEL 需二次校验

Preinstall RPM 主要为 Oracle Linux 设计，在 RHEL 7.6 上安装后，仍需检查以下三项：

# 1. 检查 preinstall 是否创建了正确用户组（oinstall, dba, oper, asmadmin 等） [root@node1 ~]# id oracle uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),54322(dba),54323(oper),54324(asmadmin),54325(asmdba),54326(asmoper) # 2. 验证 limits.conf 是否生效（重点看 memlock） [root@node1 ~]# su - oracle -c 'ulimit -l' unlimited # 若显示数字（如 65536），说明 memlock 未正确设置 # 3. 检查关键包是否齐全（preinstall 不安装 nfs-utils, targetcli 等 RAC 特有包） [root@node1 ~]# rpm -q nfs-utils targetcli python-rtslib python-six nfs-utils-4.1.1-27.el7.x86_64 targetcli-2.1.fb46-5.el7.noarch python-rtslib-2.1.fb63-10.el7.noarch python-six-1.9.0-2.el7.noarch

为什么必须检查：nfs-utils是 Oracle ACFS（自动存储管理集群文件系统）的底层依赖；targetcli和python-rtslib支持 iSCSI Target 配置，用于测试共享存储；python-six是 Python 兼容性库，gridSetup.sh的 Python 脚本依赖它。缺少任一包，runInstaller可能在“Prerequisites”阶段报CVU-00021错误。

3.2 RHEL 7.6 必装 RAC 专属包：绕过 yum 仓库的离线方案

若生产环境无外网，需提前下载 RPM 包。以下是 RHEL 7.6 x86_64 环境下oracle-database-preinstall-19c未包含但 RAC 必需的包清单（含版本号）：

# 批量安装（假设 RPM 包已放在 /tmp/rpm/ 目录） [root@node1 ~]# cd /tmp/rpm/ [root@node1 rpm]# rpm -ivh nfs-utils-4.1.1-27.el7.x86_64.rpm \ targetcli-2.1.fb46-5.el7.noarch.rpm \ python-rtslib-2.1.fb63-10.el7.noarch.rpm \ python-six-1.9.0-2.el7.noarch.rpm \ smartmontools-6.5-1.el7.x86_64.rpm # 验证安装（无报错即成功） [root@node1 rpm]# rpm -q nfs-utils targetcli python-rtslib nfs-utils-4.1.1-27.el7.x86_64 targetcli-2.1.fb46-5.el7.noarch python-rtslib-2.1.fb63-10.el7.noarch

血泪经验：曾遇到targetcli安装后systemctl start target失败，日志显示ImportError: No module named rtslib_fb。根源是python-rtslib版本与targetcli不匹配。解决方案：严格按上表版本安装，或统一使用yum install targetcli（自动解决依赖）。

4. 网络配置：GNS 与固定 IP 的混合模式实战，SCAN 域名解析的致命陷阱

RAC 网络是安装中最易出错的环节。19c 允许 GNS（Grid Naming Service）动态分配 VIP/SCAN，但必须与 DNS 解析严格协同。/etc/hosts仅用于安装前临时解析，正式环境必须依赖 DNS —— 这是很多手册忽略的关键前提。

4.1 GNS + 固定 IP 混合配置：为什么/etc/hosts只是“安装脚手架”

/etc/hosts文件在gridSetup.sh运行时被读取，用于初始节点发现。但一旦集群启动，所有通信（包括 SCAN 解析）均走 DNS。若 DNS 未正确配置，crsctl check cluster会显示CRS-4534: Cannot communicate with Cluster Ready Services。

# /etc/hosts 示例（仅用于安装阶段，非生产） 192.168.204.11 pub19-node1.rac.libai 192.168.204.12 pub19-node2.rac.libai 40.40.40.41 priv19-node1.rac.libai 40.40.40.42 priv19-node2.rac.libai 192.168.204.21 vip19-node1.rac.libai 192.168.204.22 vip19-node2.rac.libai 192.168.204.10 gns19-vip.rac.libai # GNS 服务器 IP # SCAN VIP 注释掉！由 DNS 动态解析 # 192.168.204.33 scan19-vip.rac.libai

逻辑说明：gns19-vip.rac.libai是 GNS 服务的监听地址，gridSetup.sh中需指定此 IP。而 SCAN 域名scan19-vip.rac.libai必须在 DNS 中配置为CNAME 记录指向 GNS 管理的子域（见 4.2 节），而非直接 A 记录。这是 GNS 工作的核心机制。

4.2 DNS 正解与反解配置：SCAN 域名必须包含 GNS 子域的硬性语法

GNS 要求 SCAN 域名必须嵌套在 GNS 管理的子域内。例如，若 GNS 子域为vip.rac.libai，则 SCAN 域名必须是scan19.vip.rac.libai（而非scan19.rac.libai）。DNS 区域文件必须体现这一层级关系。

# /var/named/named.rac.libai（正向解析） $TTL 600 @ IN SOA rac.libai. admin.rac.libai. ( 10 ; serial 3H ; refresh 15M ; retry 1W ; expire 1D ) ; minimum @ IN NS master.rac.libai. master IN A 192.168.204.12 # GNS 子域声明（关键！） vip.rac.libai. IN NS gns.rac.libai. gns.rac.libai. IN A 192.168.204.10 # SCAN 域名必须属于 vip.rac.libai 子域 scan19.vip.rac.libai. IN A 192.168.204.162 scan19.vip.rac.libai. IN A 192.168.204.163 scan19.vip.rac.libai. IN A 192.168.204.164 # VIP 解析（GNS 管理，此处仅作示例） vip19-node1.rac.libai. IN A 192.168.204.21 vip19-node2.rac.libai. IN A 192.168.204.22

# /var/named/named.192.168.204（反向解析，对应 192.168.204.0/24） $TTL 600 @ IN SOA rac.libai. admin.rac.libai. ( 10 ; serial 3H ; refresh 15M ; retry 1W ; expire 1D ) ; minimum @ IN NS master.rac.libai. 12 IN PTR master.rac.libai. 162 IN PTR scan19.vip.rac.libai. 163 IN PTR scan19.vip.rac.libai. 164 IN PTR scan19.vip.rac.libai. 21 IN PTR vip19-node1.rac.libai. 22 IN PTR vip19-node2.rac.libai.

参数说明：vip.rac.libai. IN NS gns.rac.libai.行定义了 GNS 的权威 DNS 服务器；gns.rac.libai. IN A 192.168.204.10将其映射到实际 IP。scan19.vip.rac.libai.的 A 记录是 GNS 启动后动态分配的，安装时可先写死（如上），GNS 启动后会接管并轮询分发。

4.3 GNS 启动验证：srvctl命令确认服务状态

GNS 启动后，必须通过srvctl确认其运行状态及监听地址：

# 检查 GNS 服务状态 [root@node1 ~]# srvctl status gns GNS is running on node1 GNS is running on node2 # 查看 GNS 监听地址（应为 192.168.204.10） [root@node1 ~]# srvctl config gns GNS is enabled. GNS is individually enabled on nodes: node1,node2 GNS is individually disabled on nodes: GNS is configured at /u01/app/19.0.0/grid, port: 53, domain: vip.rac.libai, ip: 192.168.204.10 # 测试 DNS 解析（从任意节点执行） [root@node1 ~]# nslookup scan19.vip.rac.libai Server: 192.168.204.10 Address: 192.168.204.10#53 Name: scan19.vip.rac.libai Address: 192.168.204.162 Name: scan19.vip.rac.libai Address: 192.168.204.163 Name: scan19.vip.rac.libai Address: 192.168.204.164

提示：nslookup结果必须显示Server: 192.168.204.10（GNS IP），而非系统默认 DNS。若显示其他 IP，说明/etc/resolv.conf未指向 GNS。

5. 避坑：RAC 安装中 5 个高频翻车点与根因排查

RAC 安装不是线性流程，而是多节点、多服务、多配置的强耦合系统。以下 5 个问题占实际部署故障的 70% 以上，每条均按「现象 → 原因 → 解决」结构给出可立即执行的诊断命令。

5.1 现象：gridSetup.sh报PRVF-5431: Cannot verify the specified nodes

原因：节点间 SSH 免密登录未双向打通，或/etc/hosts中主机名解析不一致（如hostname返回node1，但/etc/hosts写node1.local）。
解决：

# 在 node1 上测试到 node2 的免密（必须 root 和 oracle 用户都通） [root@node1 ~]# ssh node2 date [root@node1 ~]# su - oracle -c "ssh node2 date" # 若失败，检查 ~/.ssh/authorized_keys 权限（600）及 /etc/hosts 一致性 # 确保所有节点 hostname -f 输出与 /etc/hosts 中的 FQDN 完全匹配

5.2 现象：runInstaller卡在 “Checking Network Configuration Requirements”

原因：/etc/resolv.conf中 nameserver 未指向 GNS IP（192.168.204.10），或 DNS 未启用 recursion（递归查询）。
解决：

# 检查 resolv.conf [root@node1 ~]# cat /etc/resolv.conf nameserver 192.168.204.10 # 必须是 GNS IP # 检查 named.conf 中 recursion yes [root@node1 ~]# grep recursion /etc/named.conf recursion yes; # 重启 named [root@node1 ~]# systemctl restart named

5.3 现象：ASM 实例启动失败，alert.log报ORA-15032: not all alterations performed+ORA-15017: diskgroup cannot be mounted

原因：UDEV 规则未正确绑定 ASM 磁盘，或oracleasm服务未启动（RHEL 7.6 默认不启用）。
解决：

# 检查 UDEV 规则（/etc/udev/rules.d/99-oracle-asm.rules） [root@node1 ~]# udevadm control --reload-rules [root@node1 ~]# udevadm trigger --subsystem-match=block --action=add # 启动 oracleasm（RHEL 7.6 需手动启用） [root@node1 ~]# systemctl enable oracleasm [root@node1 ~]# systemctl start oracleasm # 扫描磁盘 [root@node1 ~]# oracleasm scandisks

5.4 现象：crsctl check cluster显示CRS-4534: Cannot communicate with Cluster Ready Services

原因：/dev/shm挂载类型非tmpfs，或权限非1777。
解决：

# 检查挂载 [root@node1 ~]# mount | grep shm tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime,seclabel) # 检查权限 [root@node1 ~]# ls -ld /dev/shm drwxrwxrwt. 2 root root 40 Apr 10 10:00 /dev/shm # 若不正确，重新挂载 [root@node1 ~]# umount /dev/shm [root@node1 ~]# mount -t tmpfs shmfs -o size=2g /dev/shm [root@node1 ~]# chmod 1777 /dev/shm

5.5 现象：GNS 启动后nslookup scan19.vip.rac.libai返回NXDOMAIN

原因：DNS 区域文件中vip.rac.libai子域未正确定义为NS记录，或named服务未加载新区域。
解决：

# 检查 named 日志 [root@node1 ~]# tail -f /var/log/named/named.log # 确认区域加载成功（应有 "zone vip.rac.libai/IN: loaded serial ..."） # 重载 named [root@node1 ~]# rndc reload # 强制刷新 DNS 缓存 [root@node1 ~]# rndc flush

6. ASM 磁盘与存储配置：UDEV 规则编写与 Flex ASM 模式选择

RAC 的心脏是 ASM（Automatic Storage Management）。19c 引入 Flex ASM，允许 ASM 实例不与数据库实例同节点运行，但需明确配置。而磁盘识别，必须靠 UDEV 规则固化设备名，否则重启后/dev/sdb可能变成/dev/sdc，导致 ASM 无法挂载磁盘组。

6.1 UDEV 规则：用 WWID 替代/dev/sdX的稳定绑定

/dev/sdX名称在多路径或重启后不可靠。必须使用 SCSI 设备的 WWID（World Wide Identifier）生成持久化链接。

# 1. 获取磁盘 WWID（以 /dev/sdb 为例） [root@node1 ~]# scsi_id -g -u -d /dev/sdb 36000c291a2b3c4d5e6f7g8h9i0j1k2l3 # 2. 创建 UDEV 规则（/etc/udev/rules.d/99-oracle-asm.rules） [root@node1 ~]# cat > /etc/udev/rules.d/99-oracle-asm.rules << 'EOF' KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="36000c291a2b3c4d5e6f7g8h9i0j1k2l3", SYMLINK+="asm-disk1", OWNER="grid", GROUP="asmadmin", MODE="0660" KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="36000c292b3c4d5e6f7g8h9i0j1k2l3", SYMLINK+="asm-disk2", OWNER="grid", GROUP="asmadmin", MODE="0660" EOF # 3. 重载 UDEV 规则并触发 [root@node1 ~]# udevadm control --reload-rules [root@node1 ~]# udevadm trigger --subsystem-match=block --action=add # 4. 验证链接（重启后仍存在） [root@node1 ~]# ls -l /dev/asm* lrwxrwxrwx. 1 root root 3 Apr 10 10:00 /dev/asm-disk1 -> sdb lrwxrwxrwx. 1 root root 3 Apr 10 10:00 /dev/asm-disk2 -> sdc

逻辑说明：scsi_id命令提取磁盘唯一标识，SYMLINK+="asm-disk1"创建稳定链接名。OWNER="grid"确保 Grid Infrastructure 用户可访问，MODE="0660"保证权限安全。

6.2 Flex ASM 模式选择：Standalone Cluster 下的 ASM 实例部署策略

19c Standalone Cluster 支持两种 ASM 模式：

• Traditional ASM：每个节点运行一个 ASM 实例，数据库实例直连本地 ASM。
• Flex ASM：仅部分节点运行 ASM 实例（如 2 节点集群中仅 node1 运行），其他节点通过网络连接（ASM Proxy Instance）访问。

# 查看当前 ASM 模式（安装后） [root@node1 ~]# su - grid -c "asmcmd showclusterstate" Normal # 启用 Flex ASM（需在安装前通过 gridSetup.sh 选择，或安装后转换） # 转换命令（需停库） [root@node1 ~]# srvctl convert asm -flex # 验证 [root@node1 ~]# srvctl config asm ASM home: /u01/app/19.0.0/grid ASM listener: LISTENER ASM is enabled. ASM instance count: 1 # 若为 1，表示 Flex ASM 模式

选型建议：小型集群（≤4 节点）用 Traditional ASM，运维简单；大型集群（≥8 节点）用 Flex ASM，减少 ASM 实例数量，降低资源开销。但 Flex ASM 要求网络延迟 < 10ms，否则 I/O 性能下降明显。

6.3 NAS 存储附加配置：/etc/fstab与autofs的可靠性权衡

若使用 NFS NAS 作为 OCR/Voting Disk 存储，必须配置autofs而非直接mount，避免启动时 NFS 未就绪导致 CRS 启动失败。

# 1. 安装 autofs [root@node1 ~]# yum install -y autofs # 2. 配置 auto.master [root@node1 ~]# echo "/mnt/nas /etc/auto.nas --timeout=300" >> /etc/auto.master # 3. 创建 /etc/auto.nas [root@node1 ~]# cat > /etc/auto.nas << 'EOF' ocr_voting -fstype=nfs,rw,bg,hard,intr,timeo=600,retrans=2,tcp,rsize=32768,wsize=32768 192.168.204.100:/export/ocr_voting EOF # 4. 启动 autofs [root@node1 ~]# systemctl enable autofs [root@node1 ~]# systemctl start autofs # 5. 验证（首次访问时自动挂载） [root@node1 ~]# ls /mnt/nas/ocr_voting

参数说明：bg（后台重试）、hard（挂载失败时进程阻塞）、timeo=600（超时 10 分钟）、retrans=2（重试 2 次）确保 NFS 故障时 CRS 仍能启动。rsize/wsize=32768优化大块 I/O。

7. gridSetup.sh 执行与验证：从图形界面到静默安装的全流程控制

gridSetup.sh是 RAC 安装的临门一脚。它既支持图形界面（需配置 X11 Forward），也支持静默安装（-silent+responsefile）。生产环境强烈推荐静默安装，避免 GUI 依赖和人为误操作。

7.1 图形界面安装：X11 Forward 的正确打开方式

若必须用 GUI，切勿在ssh -X后直接su - grid，因为su -会重置DISPLAY环境变量。

# 正确步骤（在客户端执行） $ ssh -X oracle@node1 # 登录后，不要 su -，直接用 oracle 用户启动 gridSetup.sh [oracle@node1 ~]$ export DISPLAY=localhost:10.0 [oracle@node1 ~]$ ./gridSetup.sh # 若报错 "Cannot connect to display"，检查客户端 X server（如 Xming）是否运行

避坑：ssh -X后su - grid会导致DISPLAY变为空。解决方案：用sudo -u grid -i保持环境变量，或直接以oracle用户运行（grid用户通常由 preinstall 创建，密码与oracle相同）。

7.2 静默安装：responsefile 的关键字段与校验

静默安装依赖responsefile，其中oracle.install.asm.configureGIMR（GIMR 开关）、`oracle.install.asm.diskGroup.name

本文还有配套的精品资源，点击获取