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

简介：Linux与Oracle 11g R2 RAC的结合是企业级高可用数据库系统的典型方案。本教程全面讲解在Linux环境下搭建Oracle Real Application Clusters的完整流程，涵盖系统准备、Grid Infrastructure安装、数据库软件部署、RAC数据库创建、OCR与Voting Disks配置、集群验证、备份恢复及性能监控等关键环节。通过图文并茂的方式，帮助IT技术人员掌握RAC环境的部署、运维与故障处理技能，提升企业数据库系统的可靠性与可扩展性。

1. Linux集群环境准备与网络配置

操作系统选型与最小化安装

部署Oracle 11g R2 RAC前，需选择Oracle官方认证的Linux发行版，如Oracle Linux 5.8或Red Hat Enterprise Linux 5.8（64位）。建议采用最小化安装模式，仅保留基础系统组件，避免无关服务干扰集群运行。安装完成后，及时更新内核及关键系统库，并关闭不需要的开机自启服务（如 iptables 、 avahi-daemon 等），以减少安全风险和资源占用。

内核参数调优与用户组管理

根据Oracle官方文档要求，修改 /etc/sysctl.conf 文件，调整信号量、共享内存（ shmmax 、 shmall ）、文件句柄数等内核参数，确保满足RAC进程通信与SGA大内存段需求。执行 sysctl -p 使配置生效。同时创建专用用户 oracle 和组 oinstall 、 dba 、 asmadmin 等，统一UID/GID跨节点一致，保障权限兼容性。

网络规划与SSH互信配置

合理规划Public IP与Private IP网段，分别用于客户端访问和心跳通信（如eth0为public，eth1为private）。配置静态IP、主机名解析（ /etc/hosts ），并禁用NetworkManager。通过 ssh-keygen 与 ssh-copy-id 实现 oracle 用户在各节点间的无密码SSH互信，确保CRS进程正常启动与集群节点间命令远程执行能力。

# 示例：配置SSH互信（在任一节点执行）
ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub oracle@node2

防火墙与SELinux策略调整

关闭防火墙服务：

service iptables stop
chkconfig iptables off

设置SELinux为permissive模式，在 /etc/selinux/config 中修改：

SELINUX=permissive

临时生效命令： setenforce 0 。此举防止SELinux拦截Oracle进程对共享存储或网络端口的访问。

时间同步服务（NTP）部署

RAC节点间时间偏差不得超过500ms，否则导致CSS异常。配置NTP客户端自动同步时间：

# /etc/ntp.conf 示例配置
server ntp.example.com iburst
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

启动并设为开机自启：

service ntpd start
chkconfig ntpd on

使用 ntpq -p 验证同步状态，确保所有节点时间高度一致。

提示 ：上述配置是Grid Infrastructure安装的前提条件，任何遗漏都可能导致 cluvfy 校验失败或后续OCR初始化异常。

2. 共享存储配置与节点一致性设置

在Oracle 11g R2 RAC架构中，所有数据库实例必须能够并发访问同一组数据文件，这就要求底层存储具备真正的“共享”能力。不同于单机系统中的本地磁盘，RAC环境下的存储必须满足多节点同时读写、高可用性、低延迟以及严格的一致性控制等核心需求。因此，共享存储不仅是RAC的基石，更是决定其性能上限和故障恢复能力的关键因素之一。与此同时，多个集群节点作为独立操作系统运行时，若系统层面存在用户权限不一致、设备命名漂移或环境变量差异等问题，则极易导致Grid Infrastructure启动失败、ASM磁盘组无法挂载甚至OCR损坏等严重后果。为此，在进入Grid Infrastructure安装之前，必须完成两个关键任务：一是构建稳定可靠的共享存储平台，并确保各节点对存储资源具有完全一致的识别方式；二是通过标准化机制实现跨节点的操作系统级一致性维护。

本章将深入探讨基于NFS和iSCSI两种典型共享存储技术的部署方案，分析ASM兼容性设计原则，并从udev规则、SCSI预留到多路径管理等多个维度讲解如何实现持久化设备绑定与集群锁机制支持。此外，还将详细阐述如何统一规划UID/GID、标准化umask与bash profile同步策略，并结合 iperf 、 ping 等工具进行私网通信质量验证，为后续Clusterware的顺利部署打下坚实基础。

2.1 共享存储技术选型与实现方式

选择合适的共享存储技术是构建Oracle RAC系统的首要决策点。不同的存储方案在性能表现、成本投入、运维复杂度及可扩展性方面各有优劣。当前主流的技术路径主要包括网络文件系统（NFS）、基于iSCSI的目标端模拟裸设备、以及直接使用SAN提供的块设备。其中，对于测试或开发环境而言，利用Linux自带服务搭建基于NFS或iSCSI的共享存储是一种经济高效的替代方案；而在生产环境中，则更倾向于采用光纤通道SAN配合ASM（Automatic Storage Management）来实现最佳性能与可靠性平衡。

值得注意的是，无论采用哪种底层技术，最终呈现给Oracle Clusterware和ASM的都应是原始块设备（raw device）或ASMLib兼容设备，而非普通文件系统。这是因为OCR（Oracle Cluster Registry）和Voting Disk等关键组件需要独占式访问，避免文件系统层带来的缓存干扰和元数据竞争问题。以下将分别介绍NFS与iSCSI两种常见实现方式的具体配置流程及其适用场景。

2.1.1 基于NFS的共享存储配置

尽管Oracle官方推荐使用裸设备或ASM专用磁盘组来存放OCR和Voting Disk，但从Oracle 11g R2开始，已正式支持将这些关键组件放置于NFS挂载点上，前提是该NFS服务器符合特定的安全性和性能要求——例如关闭atime更新、启用no_root_squash选项以保留root权限映射，并建议使用TCP协议以提高稳定性。

假设我们有一台IP地址为 192.168.10.100 的NFS服务器，需为两个RAC节点（rac1、rac2）提供共享目录 /u02/share ，用于存放OCR备份文件及测试用途的Voting Disk镜像。

首先在NFS服务端执行如下操作：

# 创建共享目录
mkdir -p /u02/share

# 设置权限
chmod 755 /u02/share
chown oracle:oinstall /u02/share

# 编辑 exports 配置文件
echo "/u02/share 192.168.10.0/24(rw,sync,no_root_squash,no_subtree_check)" >> /etc/exports

# 启动 NFS 服务
systemctl enable nfs-server
systemctl start nfs-server
exportfs -a

代码逻辑逐行解读 ：

• mkdir -p /u02/share ：创建目标共享目录， -p 参数确保父目录自动创建。
• chmod 755 ：赋予所有者读写执行权限，组和其他用户仅读和执行，防止非授权修改。
• chown oracle:oinstall ：所有权设为Oracle安装用户和OSDBA组，保证后续RAC进程能正常访问。
• /etc/exports 中的配置项说明：
• rw ：允许读写；
• sync ：强制同步写入磁盘后再响应客户端请求，保障数据一致性；
• no_root_squash ：禁止将远程root映射为nobody，否则可能导致权限错误；
• no_subtree_check ：提升性能，跳过子树检查。
• exportfs -a ：重新加载所有导出项，使新配置立即生效。

随后在每个RAC节点上挂载该NFS共享：

# 安装必要的NFS客户端包
yum install -y nfs-utils

# 创建本地挂载点
mkdir -p /mnt/nfs_share

# 临时挂载测试
mount -t nfs 192.168.10.100:/u02/share /mnt/nfs_share

# 永久挂载写入 fstab
echo "192.168.10.100:/u02/share /mnt/nfs_share nfs rw,bg,hard,intr,tcp,timeo=600,retrans=2,_netdev 0 0" >> /etc/fstab

参数说明 ：

• bg ：后台重试，避免系统启动时因网络未就绪而卡住；
• hard ：硬挂载模式，I/O失败时持续重试，防止数据损坏；
• intr ：允许被中断信号终止挂起的操作；
• tcp ：使用TCP传输协议，比UDP更可靠；
• timeo=600 ：超时时间为600 deciseconds（即60秒），单位为十分之一秒；
• retrans=2 ：最多重试2次后报错；
• _netdev ：标明此设备依赖网络，确保在网络服务启动后才尝试挂载。

虽然NFS便于部署且无需额外硬件，但其主要局限在于缺乏原生的并发写控制机制，不适合作为主OCR/Voting Disk载体。通常仅用于归档日志、备份目录或非关键测试环境。

NFS vs iSCSI 对比表格

特性	NFS	iSCSI
协议层级	文件级（应用层）	块级（传输层）
性能	中等，受文件系统开销影响	高，接近本地磁盘
并发访问支持	弱，依赖锁机制	强，可通过SCSI-3 PR实现
配置复杂度	简单，标准Linux服务	较复杂，需Target/Initiator配置
是否支持OCR/Voting Disk	Oracle支持但有限制	完全支持，推荐方式
适用场景	开发/测试、归档存储	生产级RAC共享存储

如上表所示，iSCSI因其块级语义和更强的并发控制能力，成为更理想的RAC共享存储解决方案。

2.1.2 使用iSCSI模拟裸设备实现共享磁盘

为了在无SAN设备的环境下模拟真实共享存储，可以使用Linux的 targetcli 工具创建iSCSI Target，并将其后端指向物理磁盘或大容量文件。以下是具体实施步骤。

在存储服务器上配置iSCSI Target

# 安装 targetcli 工具
yum install -y targetcli

# 启动服务并设置开机自启
systemctl enable target
systemctl start target

# 进入交互式配置界面
targetcli << EOF
/backstores/block create name=disk1 dev=/dev/sdb
/iscsi create iqn.2025-04.com.example:storage.target1
/iscsi/iqn.2025-04.com.example:storage.target1/tpg1/acls create iqn.2025-04.com.example:rac1
/iscsi/iqn.2025-04.com.example:storage.target1/tpg1/acls create iqn.2025-04.com.example:rac2
/iscsi/iqn.2025-04.com.example:storage.target1/tpg1/luns create /backstores/block/disk1
/iscsi/iqn.2025-04.com.example:storage.target1/tpg1/portals create 192.168.10.100
saveconfig
EOF

逻辑分析 ：

• /backstores/block create ：定义一个基于块设备 /dev/sdb 的后端存储对象；
• /iscsi create ：创建一个全局唯一的IQN标识符（iSCSI Qualified Name）；
• acls create ：为每个RAC节点添加访问控制列表，确保只有指定initiator可连接；
• luns create ：将block设备映射为LUN（逻辑单元号），暴露给客户端；
• portals create ：绑定监听IP地址；
• saveconfig ：保存配置至 /etc/target/saveconfig.json ，重启不失效。

在RAC节点上连接iSCSI Initiator

# 安装 iscsi-initiator-utils
yum install -y iscsi-initiator-utils

# 修改 initiator 名称（需与ACL一致）
echo "InitiatorName=iqn.2025-04.com.example:rac1" > /etc/iscsi/initiatorname.iscsi

# 发现目标
iscsiadm -m discovery -t st -p 192.168.10.100

# 登录目标
iscsiadm -m node -L automatic

# 查看新出现的设备
lsblk | grep sd

成功登录后，系统会识别出一个新的SCSI设备（如 /dev/sdc ），该设备即为共享磁盘，可用于创建ASM磁盘或存放OCR/Voting Disk。

graph TD
    A[NFS Server] -->|Export /u02/share| B(RAC Node 1)
    A -->|Mount via NFS| C(RAC Node 2)
    D[iSCSI Target<br>(/dev/sdb)] -->|LUN over IP| E[RAC Node 1<br>via /dev/sdc]
    D -->|Multi-path Access| F[RAC Node 2<br>via /dev/sdc]

    style A fill:#f9f,stroke:#333
    style D fill:#bbf,stroke:#333
    style B fill:#cff,stroke:#333
    style C fill:#cff,stroke:#333
    style E fill:#cfc,stroke:#333
    style F fill:#cfc,stroke:#333

    subgraph "共享存储拓扑示意图"
        A; B; C; D; E; F
    end

该流程图展示了NFS与iSCSI两种共享方式的数据流向：NFS以文件形式共享，而iSCSI则提供块级裸设备访问能力，更适合Oracle RAC对低延迟和强一致性的要求。

2.1.3 ASM兼容性存储结构设计原则

ASM（Automatic Storage Management）是Oracle专为数据库设计的高性能卷管理器和文件系统，它直接操作裸设备或ASMLib标记的磁盘，绕过操作系统文件系统层，从而减少I/O栈深度并优化条带化与镜像策略。

在规划ASM磁盘组时，应遵循以下设计原则：

1. 分离不同类型的文件 ：建议将OCR/Voting Disk、数据文件、归档日志、快速恢复区分别置于不同的磁盘组中，便于管理和性能调优。
2. 冗余级别选择 ：
   - External Redundancy ：无内部冗余，依赖外部RAID或存储阵列；
   - Normal Redundancy ：双副本，容忍一个故障组失效；
   - High Redundancy ：三副本，容忍两个故障组失效。
3. AU（Allocation Unit）大小设定 ：默认为1MB，适用于大多数OLTP系统；对于大数据量批量处理场景，可调整为4MB以提升连续I/O效率。
4. 故障组划分 ：若使用多路径或多控制器，应将属于不同路径的磁盘划入不同故障组，增强容错能力。

例如，创建一个名为 CRS 的磁盘组用于存放OCR和Voting Disk，采用Normal冗余：

-- 在ASMCA或SQL*Plus中执行
CREATE DISKGROUP CRS NORMAL REDUNDANCY
  FAILGROUP fg1 DISK '/dev/oracle/crs1' NAME CRSA,
             '/dev/oracle/crs2' NAME CRSB
  FAILGROUP fg2 DISK '/dev/oracle/crs3' NAME CRSC,
             '/dev/oracle/crs4' NAME CRSD;

此配置中，每个FAILGROUP代表一个独立的物理路径或控制器域，确保即使某条路径中断，另一组仍可维持运行。

2.2 多节点间的系统一致性维护

在RAC集群中，所有节点虽为独立主机，但在操作系统层面必须保持高度一致性，否则会导致Clusterware无法识别成员身份、资源分配冲突或权限校验失败等问题。尤其当涉及到文件所有权、进程运行身份、shell环境变量等细节时，任何细微偏差都可能引发连锁反应。因此，必须建立一套完整的标准化体系，涵盖用户/组ID统一、权限模型规范以及环境变量同步机制。

2.2.1 用户与组ID在各节点上的统一规划

Oracle RAC要求所有节点上的 oracle 用户和相关OS组（如 oinstall 、 dba 、 asmadmin 等）具有相同的UID和GID，否则在执行 cluvfy 校验或运行 runInstaller 时会提示“User equivalence check failed”。

应在所有节点上执行以下命令以确保一致性：

# 创建所需组（GID 必须相同）
groupadd -g 500 oinstall
groupadd -g 501 dba
groupadd -g 502 asmadmin
groupadd -g 503 asmdba

# 创建 oracle 用户（UID 必须相同）
useradd -u 500 -g oinstall -G dba,asmdba,asmadmin oracle
passwd oracle  # 设置密码

参数说明 ：

• -g ：指定主组；
• -G ：附加组，决定用户的数据库角色权限；
• UID/GID 推荐使用500以上数值段，避开系统账户范围；
• 所有节点必须使用完全相同的数字ID，不能依赖自动分配。

可通过以下脚本批量验证：

for group in oinstall dba asmadmin asmdba; do
    gid=$(getent group $group | cut -d: -f3)
    echo "Group $group: GID=$gid"
done

id oracle

输出结果应在所有节点间完全一致。

2.2.2 文件系统权限与umask设置标准化

为防止因权限不当导致安装失败，必须统一设置 /tmp 、 /u01/app 等关键目录的权限，并配置合理的 umask 值。

推荐在所有节点的 /etc/profile.d/oracle.sh 中加入：

# 设置安全的默认掩码
if [ \$USER = "oracle" ]; then
  umask 022
else
  umask 027
fi

解释 ：

• umask 022 ：新建文件权限为644，目录为755，适合Oracle用户；
• 027 ：其他用户无读权限，增强安全性；
• 使用profile.d方式确保所有shell环境均生效。

同时检查关键目录权限：

mkdir -p /u01/app/grid
mkdir -p /u01/app/oracle/product/11.2.0/dbhome_1
chown -R grid:oinstall /u01/app/grid
chown -R oracle:oinstall /u01/app/oracle
chmod -R 775 /u01/app

2.2.3 环境变量与bash profile同步机制

Oracle软件运行依赖一系列环境变量，如 ORACLE_HOME 、 GRID_HOME 、 PATH 等。若各节点设置不一，将导致 srvctl 命令行为异常或监听器注册失败。

建议采用集中分发方式维护 .bash_profile ，例如使用 rsync 或配置管理工具（Ansible/Puppet）同步模板：

# 示例 .bash_profile 内容
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=\$ORACLE_BASE/product/11.2.0/dbhome_1
export GRID_HOME=/u01/app/grid/11.2.0
export PATH=\$ORACLE_HOME/bin:\$GRID_HOME/bin:/usr/local/bin:\$PATH
export LD_LIBRARY_PATH=\$ORACLE_HOME/lib:\$GRID_HOME/lib:\$LD_LIBRARY_PATH

并通过脚本定期校验一致性：

diff <(ssh rac1 cat ~/.bash_profile) <(ssh rac2 cat ~/.bash_profile)

任何差异都应及时修正，确保整个集群处于统一的运行上下文中。

flowchart LR
    A[Central Config Repo] --> B[Deploy bash_profile]
    B --> C[rac1]
    B --> D[rac2]
    B --> E[rac3]
    F[UID/GID Plan] --> G[Create Users]
    G --> C
    G --> D
    G --> E

    H[Permission Policy] --> I[Set umask & chmod]
    I --> C
    I --> D
    I --> E

    style A fill:#f96,stroke:#333
    style F fill:#69f,stroke:#333
    style H fill:#6f9,stroke:#333

该流程图展示了系统一致性配置的自动化推进路径，强调了集中管理的重要性。

3. Oracle Grid Infrastructure安装与Clusterware部署

Oracle Grid Infrastructure（GI）是构建Real Application Clusters（RAC）架构的基石，其核心组件Clusterware为数据库集群提供高可用性、资源调度和节点协调能力。在完成底层操作系统环境准备与共享存储配置后，Grid Infrastructure 的正确部署成为决定整个 RAC 系统稳定性与可维护性的关键步骤。本章将深入剖析 GI 安装前的系统预检机制、核心进程工作原理、OCR 与 Voting Disk 的初始化策略，以及 GPnP 架构如何实现动态节点发现与自动化集群管理。

Grid Infrastructure 不仅包含 Clusterware，还集成了 Automatic Storage Management（ASM），即便在后续章节中单独讨论 ASM 实例的详细配置，也必须认识到其与 Clusterware 在启动顺序和依赖关系上的紧密耦合。例如，OHASD（Oracle High Availability Services Daemon）作为最底层守护进程，负责启动 CSSD、CRSD 和 ASMD 等关键服务。因此，在安装过程中理解各组件之间的依赖层级，对于故障排查和静默安装参数定制具有重要意义。

此外，随着企业对弹性扩展与自动化运维需求的增长，Grid Plug and Play（GPnP）和 Grid Naming Service（GNS）等高级特性逐渐从“可选”变为“必备”。特别是在大规模私有云或虚拟化环境中，通过 GNS 实现基于 DHCP 的动态节点加入，极大简化了新节点的部署流程。而 OCR（Oracle Cluster Registry）与 Voting Disks 的冗余设计，则直接决定了集群在部分节点或磁盘故障时能否维持仲裁并避免脑裂（Split-Brain）现象。

本章内容不仅涵盖图形化安装向导的操作细节，还将重点解析响应文件（response file）的结构定义与参数调优技巧，使读者掌握适用于生产环境的大规模批量部署能力。同时，通过实际命令行操作示例、udev 绑定验证、CVU 检查输出分析等内容，帮助从业者建立完整的端到端部署视角。

3.1 Grid Infrastructure安装前的预检查与依赖处理

在正式执行 runInstaller 启动 Oracle Grid Infrastructure 安装之前，必须进行全面的系统合规性验证，以确保所有软硬件条件满足 Oracle 11g R2 RAC 的官方要求。这一阶段的核心工具是 Cluster Verification Utility（CVU） ，它能够自动检测网络连通性、时间同步状态、用户权限、内核参数、共享存储可见性等多个维度的关键指标。若跳过此步骤或忽略警告信息，可能导致安装失败、集群无法启动甚至运行时性能异常。

CVU 的优势在于其非侵入式检测机制——它不需要修改任何系统配置即可完成评估，并生成结构化的报告输出。该工具既可以由安装程序内部调用，也可独立运行于命令行模式，便于在复杂环境中进行分步调试。

3.1.1 运行Cluster Verification Utility（CVU）进行系统合规性验证

CVU 支持多种检查类型，包括节点间通信、存储设备访问、操作系统设置等。以下是典型的 CVU 使用场景及命令格式：

$GRID_HOME/cv/bin/cluvfy comp nodecon -n all -verbose
$GRID_HOME/cv/bin/cluvfy comp sys -n all -verbose
$GRID_HOME/cv/bin/cluvfy stage -pre crsinst -n racnode1,racnode2 -verbose

上述三条命令分别用于：
- nodecon ：验证所有节点间的 SSH 互信、网络延迟与带宽；
- sys ：检查系统级配置，如内核参数、包依赖、用户组设置；
- stage -pre crsinst ：模拟 CRS 安装前的整体环境检查。

执行结果将以等级形式呈现： SUCCESS、WARNING、FAILURE 。对于 WARNING 类提示，应结合具体上下文判断是否需要干预；而 FAILURE 则必须解决才能继续安装。

以下是一个典型 CVU 输出片段示例：

Component	Status	Target Nodes	Details
Node Connectivity	SUCCESS	racnode1, racnode2	TCP ping succeeded
Time Synchronization	WARNING	racnode1, racnode2	NTP drift > 1s
Package Check	FAILURE	racnode1	binutils missing
Shared Storage	SUCCESS	/dev/oraocr, /dev/votedisk	All nodes see same devices

⚠️ 注意：即使多数项目通过，只要存在 FAILURE，OUI 安装界面仍会阻止下一步操作。

Mermaid 流程图：CVU 检查执行逻辑流程

graph TD
    A[开始 CVU 预检查] --> B{是否指定节点列表?}
    B -->|是| C[解析节点名称]
    B -->|否| D[使用本地节点]
    C --> E[建立 SSH 连接至目标节点]
    E --> F[并行执行各项子检查]
    F --> G[收集各节点返回数据]
    G --> H[汇总比对一致性]
    H --> I{是否存在 FAILURE?}
    I -->|是| J[终止并输出错误码]
    I -->|否| K{是否存在 WARNING?}
    K -->|是| L[输出建议但允许继续]
    K -->|否| M[返回 SUCCESS]

该流程图清晰展示了 CVU 如何跨节点协同工作，体现了其分布式验证的设计思想。

3.1.2 解决rpm包缺失、内核参数不达标等问题

当 CVU 报告 package check failure 时，常见缺失的 RPM 包包括：

• binutils
• compat-libcap1
• compat-libstdc++-33
• libgcc , libstdc++ , ksh
• make , glibc , glibc-devel

可通过 YUM 自动补全：

yum install -y binutils compat-libcap1 compat-libstdc++-33 \
               libgcc libstdc++ ksh make glibc glibc-devel

参数说明：
- -y ：自动确认安装；
- 列出多个包名一次性安装，减少重复扫描开销；
- 若无互联网源，需挂载 Oracle Linux ISO 手动安装。

针对内核参数问题，CVU 常报错如下：

FAIL: Kernel parameter "sem" does not meet minimum requirement [current: 250 32000 32 32]

此时应编辑 /etc/sysctl.conf 添加或修正：

kernel.sem = 250 32000 100 128
kernel.shmall = 2097152
kernel.shmmax = 4294967295
kernel.shmmni = 4096
fs.file-max = 6815744
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304

逐行解释：
- kernel.sem ：信号量设置，四个值分别对应 SEMMSL、SEMMNS、SEMOPM、SEMMNI；
- shmmax ：单个共享内存段最大字节，建议设为主机物理内存的 90%；
- file-max ：系统级别最大打开文件数；
- ip_local_port_range ：避免端口耗尽，特别影响大量连接的应用。

应用更改：

/sbin/sysctl -p

此命令重新加载内核参数，无需重启即可生效。

3.1.3 安装介质校验与解压规范流程

Oracle 提供的 GI 安装介质通常为 .zip 或 .tar.gz 格式压缩包。为防止因传输损坏导致安装中断，应在解压前进行完整性校验。

假设下载文件为 p10404530_112030_Linux-x86-64_1of2.zip ，首先获取其 MD5 值：

md5sum p10404530_112030_Linux-x86-64_1of2.zip

对比 Oracle Support 文档中的官方哈希值。若一致，则创建专用目录解压：

mkdir /stage/grid
unzip p10404530_112030_Linux-x86-64_1of2.zip -d /stage/grid
unzip p10404530_112030_Linux-x86-64_2of2.zip -d /stage/grid

关键点：
- 解压路径避免空格或中文；
- 使用绝对路径提高脚本兼容性；
- 解压后保留原始 zip 文件以备审计。

最终目录结构应类似：

/stage/grid/
├── grid/
│   ├── install/
│   ├── response/
│   └── runInstaller
└── readme.html

此时可切换至 grid 用户并启动安装：

su - grid
cd /stage/grid/grid
./runInstaller

至此，已完成安装前的所有准备工作，进入下一阶段的图形化或静默安装流程。

3.2 Oracle Clusterware组件详解与安装流程

Oracle Clusterware 是 GI 的核心高可用框架，负责管理集群成员资格、资源生命周期、故障检测与恢复。其架构采用分层守护进程模型，每个组件承担特定职责且具备明确的启动顺序依赖。

3.2.1 OHASD、CRSD、CSSD、EVMD等核心进程作用解析

Clusterware 启动始于 OHASD（Oracle High Availability Services Daemon） ，它是唯一由 init 或 systemd 直接启动的 Oracle 进程，位于 /etc/init.d/ohasd 或通过 oracle-ohasd.service 管理。

一旦 OHASD 启动，便会按序拉起其他关键服务：

进程名称	全称	功能描述	是否跨节点通信
OHASD	Oracle HA Services Daemon	初始化 HA 框架，加载本地服务	否（本地）
CSSD	Cluster Synchronization Services Daemon	节点心跳、成员资格管理、Voting Disk 访问	是
CRSD	Cluster Ready Services Daemon	资源管理器，控制数据库、监听器、VIP 等资源	是
EVMD	Event Volume Manager Daemon	发布集群事件通知，支持外部脚本触发	是
EVMLET	EVM Listener Thread	接收来自客户端的事件订阅请求	是

其中， CSSD 是实现“脑裂保护”的核心。它通过定期读写 Voting Disk 来确认节点存活状态。若某节点连续若干次未能更新其投票记录（默认 1.5 秒一次），则被标记为离线，其余节点形成多数派继续服务。

CRSD 则依赖 OCR 存储集群资源配置信息（如数据库实例位置、服务启停策略）。任何资源变更（如 srvctl start database）都会写入 OCR，并由 CRSD 监听变化后执行动作。

这些进程的状态可通过以下命令查看：

crsctl check cluster
crsctl check crs
ps -ef | grep cssd

输出示例：

CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

表明三类核心服务均正常运行。

3.2.2 图形化OUI安装向导操作步骤分解

运行 ./runInstaller 后进入 Oracle Universal Installer（OUI）界面，主要步骤如下：

1. 选择安装选项
   → “Install and Configure Grid Infrastructure for a Cluster”

2. 选择集群类型
   → “Standard Cluster”（非域管理模式）

3. 添加集群节点
   输入所有节点的 public hostname、virtual hostname、SSH 用户凭证

4. 指定 GI HOME 路径
   如 /u01/app/11.2.0/grid ，确保该路径在所有节点上一致

5. 配置 SCAN（Single Client Access Name）
   输入一个域名（如 scan.example.com），DNS 必须解析到三个 IP 地址（循环 A 记录），用于负载均衡客户端连接

6. 选择存储方式
   → 使用 ASM 存储 OCR 和 Voting Disk
   → 指定已通过 udev 绑定的裸设备（如 /dev/asm-ocr ）

7. 设置密码
   统一设置 ASM 实例 SYS 密码

8. 先决条件检查
   OUI 自动调用 CVU，若有 FAILURE 需修复后点击“Retry”

9. 安装概览与执行 root.sh
   安装完成后提示在各节点依次执行 root.sh

root.sh 脚本的作用包括：
- 创建 OCR/Voting Disk 元数据；
- 注册 OHASD 到系统服务；
- 启动初始 Clusterware 进程；
- 时间敏感，建议在所有节点关闭防火墙后再集中执行。

3.2.3 静默安装模式下的response file定制技巧

对于大规模部署或自动化场景，推荐使用静默安装（Silent Mode），依赖 responseFile 完成无人值守安装。

模板位于 $GRID_HOME/response/grid_install.rsp ，关键参数示例如下：

oracle.install.responseFileVersion=/software/oracle/install/rspfmt_crsinstall_response_schema_v11_2_0
ORACLE_HOSTNAME=racnode1
INVENTORY_LOCATION=/u01/app/oraInventory
SELECTED_LANGUAGES=en,zh
oracle.install.grid.install.config.option=CLUSTER_INSTALL
oracle.install.grid.cluster.nodes=racnode1:racnode1-vip,racnode2:racnode2-vip
oracle.install.grid.asm.SYSASMPassword=welcome1
oracle.install.grid.asm.diskGroup.name=OCR_VOTE
oracle.install.grid.asm.diskGroup.redundancy=EXTERNAL
oracle.install.grid.asm.diskGroup.disks=/dev/asm-ocr
oracle.install.grid.asm.diskGroup.diskDiscoveryString=/dev/asm*
oracle.install.grid.crs.config.gpnp.scanName=scan.example.com
oracle.install.grid.crs.config.gpnp.scanPort=1521

参数说明：
- redundancy=EXTERNAL 表示依赖外部 RAID 或存储阵列做冗余；
- diskDiscoveryString 帮助 ASM 自动识别候选磁盘；
- SCAN 名称必须提前在 DNS 中注册；
- 所有节点需能解析彼此主机名及 VIP。

执行命令：

./runInstaller -silent -responseFile /stage/grid.rsp -ignorePrereq

-ignorePrereq 可跳过某些非致命警告，但在生产环境慎用。

安装完成后仍需手动执行 root.sh ，顺序为：先第一个节点，再其余节点。

3.3 OCR与Voting Disks的初始化配置

OCR（Oracle Cluster Registry）和 Voting Disks 是 Clusterware 正常运行的两大元数据支柱。OCR 存储集群资源配置信息，Voting Disks 用于节点仲裁决策。二者都必须具备高可用性和持久性保障。

3.3.1 基于ASM或裸设备的OCR存储位置选择

从 Oracle 11g R2 开始，强烈推荐将 OCR 和 Voting Disks 存放于 ASM 磁盘组中，原因如下：

• 自动镜像与再平衡；
• 易于扩展与迁移；
• 与数据库存储统一管理。

但若未启用 ASM，则只能使用裸设备（raw device）或块设备（block device）。

创建 ASM 磁盘组用于 OCR/Voting Disk 的典型 SQL：

CREATE DISKGROUP OCR_VOTE
  EXTERNAL REDUNDANCY
  DISK '/dev/asm-ocr' SIZE 2G;

EXTERNAL REDUNDANCY ：表示不依赖 ASM 冗余，信任底层存储（如 SAN RAID1）；
若使用本地磁盘，应选择 NORMAL REDUNDANCY 并至少提供三块磁盘。

OCR 最多支持两个副本，Voting Disk 最多支持 15 个文件（11.2+ 版本支持 Flex ASM 下更多）。

查看当前 OCR 状态：

ocrcheck

输出示例：

Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 2448
Available space (kbytes) : 259672
ID : 123456789
Device/File Name : +OCR_VOTE

3.3.2 Voting Disk冗余策略与多副本部署实践

增加 Voting Disk 副本提升容灾能力：

crsctl replace votedisk +OCR_VOTE

该命令会自动删除旧位置并在新磁盘组中创建三份副本（NORMAL REDUNDANCY 下）。

也可手动增删：

crsctl add votedisk /dev/asm-vote1
crsctl delete votedisk /dev/old_vote

注意：删除前必须确保剩余数量为奇数（≥1），否则集群将宕机。

查询当前 Voting Disk 分布：

crsctl query css votedisk

输出：

## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1 ONLINE 7e4b2a3d7f... /dev/asm-vote1 [OCR_VOTE]
2 ONLINE 8f5c3b4e8g... /dev/asm-vote2 [OCR_VOTE]
3 ONLINE 9a6d4c5f9h... /dev/asm-vote3 [OCR_VOTE]
Located 3 voting disk(s).

3.3.3 初始阶段的备份与恢复预案建立

OCR 支持自动和手动备份：

ocrconfig -showbackup

列出最近的自动备份文件：

ocrconfig -autobackup enabled
Location: /u01/app/11.2.0/grid/cdata/rac-cluster/backup00.ocr

手动备份：

ocrconfig -export /backup/ocr_exp.dmp

-export ：逻辑导出，可用于异机恢复；
-manualbackup ：生成物理快照式备份。

恢复流程（假设全部 OCR 损坏）：

# 停止 CRS
crsctl stop crs

# 以独占模式启动
crsctl start crs -excl

# 恢复
ocrconfig -import /backup/ocr_exp.dmp

# 退出独占模式
crsctl stop crs
crsctl start crs

⚠️ 恢复期间集群不可用，务必提前演练。

3.4 GPnP（Grid Plug and Play）架构工作机制

GPnP 是 Oracle 11g 引入的重要创新，旨在实现集群节点的即插即用（Plug-and-Play），大幅降低扩展复杂度。

3.4.1 配置文件gpnp-profile.xml的作用与结构

每个节点的 $GRID_HOME/gpnp/<hostname>/profiles/peer/profile.xml 文件保存了全局集群视图，内容示例如下：

<gpnp:profile version="1.0">
  <gpnp:wls>
    <gpnp:masteredlist>
      <gpnp:entry cn="racnode1" addr="192.168.1.101"/>
      <gpnp:entry cn="racnode2" addr="192.168.1.102"/>
    </gpnp:masteredlist>
  </gpnp:wls>
  <gpnp:ols>
    <gpnp:scan name="scan.example.com" port="1521"/>
  </gpnp:ols>
</gpnp:profile>

该文件通过 GNS 或手工传播至所有节点，确保新加入节点能立即获知集群拓扑。

3.4.2 节点加入/退出集群的自动化发现过程

当新增节点执行 addNode.sh 时，流程如下：

./addNode.sh -silent "CLUSTER_NEW_NODES={racnode3}" \
                  "CLUSTER_NEW_VIRTUAL_HOSTNAMES={racnode3-vip}"

内部机制：
1. 新节点联系现有任意节点获取 profile.xml ；
2. 根据 SCAN 和 GNS 获取分配 IP；
3. 自动同步 OCR、启动 OHASD；
4. 加入集群并注册资源。

3.4.3 GNS（Grid Naming Service）在动态扩展中的应用

启用 GNS 需配置 DHCP + DNS 转发器，允许动态分配 .cluster 域名下的 VIP 和 GNS VIP。

优点：
- 无需预先规划所有节点 IP；
- 支持数百节点自动发现；
- 与云计算平台集成友好。

命令启用：

gnsctl start
srvctl add gns -vip gns-vip.example.com

综上所述，GPnP 与 GNS 共同构成了现代 Oracle RAC 的自适应网络基础，显著提升了运维效率与弹性能力。

4. Automatic Storage Management (ASM) 配置与管理

Oracle Automatic Storage Management（ASM）是专为Oracle数据库设计的高性能、高可用性的存储管理解决方案。它屏蔽了底层物理存储的复杂性，通过将多个磁盘组合成逻辑磁盘组（Disk Group），实现数据条带化、镜像冗余和自动重平衡，极大简化了RAC环境中共享存储的管理负担。在Oracle 11g R2 RAC架构中，ASM不仅是推荐的存储方式，更是Grid Infrastructure组件（如OCR和Voting Disk）默认依赖的核心服务之一。本章深入剖析ASM的体系结构原理、实例创建流程、日常运维机制以及关键迁移实践，帮助高级DBA构建稳健、可扩展的存储基础。

4.1 ASM体系结构原理与核心概念

ASM并非传统意义上的文件系统或卷管理器，而是介于两者之间的“智能中间层”，其设计理念在于最大化I/O性能与容错能力的同时，保持对数据库透明的存储访问接口。理解ASM内部各层级对象之间的关系，是高效规划和管理ASM环境的前提。

4.1.1 ASM实例、磁盘组、AU、Extent之间的逻辑关系

ASM的基本工作单元由四个层次构成：ASM实例 → 磁盘组（Disk Group） → 分配单元（Allocation Unit, AU） → Extent。每一层都承担特定功能，并形成清晰的上下级映射关系。

• ASM实例 ：每个节点上运行一个独立的ASM实例（+ASM1、+ASM2等），负责管理本地连接的磁盘设备并与其他节点协同完成集群级别的存储操作。该实例不存放用户数据，仅维护元数据信息（metadata），类似于Oracle数据库实例中的控制文件角色。

• 磁盘组（Disk Group） ：一组物理磁盘的逻辑集合，用于统一管理存储资源。所有数据库文件（数据文件、控制文件、日志文件等）均存放在某个磁盘组内，路径格式为 +DATA/dbname/datafile/users.256.1 。磁盘组支持Normal（两副本）、High（三副本）和External（无镜像）三种冗余模式。

• 分配单元（AU） ：ASM进行I/O操作的最小单位，默认大小为1MB（可通过 _asm_ausize 参数调整）。当向磁盘写入数据时，ASM以AU为粒度进行条带化分布，确保负载均衡。

• Extent ：数据库文件层面的数据块集合。一个Extent包含一个或多个连续的AU。例如，在非ASM环境下，一个数据文件可能被划分为多个Extent来容纳表段；而在ASM中，这些Extent实际分布在不同磁盘上的AU中，实现了跨磁盘的自动条带化。

这四者的关系可以用如下mermaid流程图表示：

graph TD
    A[ASM Instance] --> B[Disk Group]
    B --> C[Failure Group 1]
    B --> D[Failure Group 2]
    C --> E[AU Size: 1MB]
    D --> F[AU Size: 1MB]
    E --> G[Extent Mapping]
    F --> H[Extent Mapping]
    G --> I[Database File]
    H --> I

说明 ：该图展示了从ASM实例向下到具体数据库文件的数据组织路径。磁盘组下划分故障组（Failure Group）以支持冗余策略；AU作为I/O基本单位参与条带化；最终Extent将多个AU关联至数据库对象。

以下表格进一步对比各层级的技术特征：

层级	名称	功能描述	可配置项	示例值
L1	ASM Instance	每节点运行的后台进程集合	实例名（+ASMx）、内存参数（SGA_TARGET）	+ASM1
L2	Disk Group	物理磁盘的逻辑容器	冗余级别（NORMAL/HIGH/EXTERNAL）、兼容性参数	DATA, FRA
L3	Allocation Unit (AU)	数据读写的最小单位	_asm_ausize （隐藏参数）	1MB
L4	Extent	数据库文件的数据块集合	初始/下一Extent大小（由DB决定）	包含1~N个AU

这种分层模型使得ASM既能提供接近裸设备的性能，又具备现代文件系统的灵活性与容灾能力。

4.1.2 Normal、High冗余模式的数据保护机制对比

ASM通过内置镜像机制实现数据冗余，避免单点故障导致数据丢失。主要支持两种保护级别：

• Normal Redundancy ：每个数据块保存两个副本，分别位于不同的Failure Group中。适用于大多数企业场景，在成本与安全性之间取得良好平衡。
• High Redundancy ：每个数据块保存三个副本，分布在至少三个Failure Group中。适用于对数据可用性要求极高的核心系统，如金融交易系统。
• External Redundancy ：不启用ASM级镜像，完全依赖外部存储阵列（如RAID 5/6）提供冗余保障。通常用于已具备硬件级保护的SAN环境。

为了更直观地比较差异，下表列出关键指标：

冗余模式	副本数	最少磁盘数	故障容忍度	存储开销	典型应用场景
External	1	1	依赖外部RAID	0%	已部署高端存储阵列
Normal	2	2	单Failure Group失效	50%	一般OLTP系统
High	3	3	任意两个Failure Group同时失效仍可用	200%	核心业务系统

⚠️ 注意：Failure Group应代表独立的故障域，如不同机柜、不同控制器或不同电源回路下的磁盘。若所有磁盘属于同一Failure Group，则即使配置High冗余也无法抵御机架断电风险。

假设某客户使用Normal冗余模式创建名为 DATA 的磁盘组，包含两块各1TB的磁盘：

CREATE DISKGROUP DATA NORMAL REDUNDANCY
  FAILGROUP fg1 DISK '/dev/oracleasm/disks/DATA1'
  FAILGROUP fg2 DISK '/dev/oracleasm/disks/DATA2';

执行后，ASM会自动将每个AU的内容同步写入fg1和fg2中的对应位置。若其中一块磁盘损坏，另一块仍能提供完整数据服务，且ASM会在新加入磁盘后自动触发重建过程。

4.1.3 权衡性能与容错能力的磁盘组设计策略

合理设计磁盘组结构是发挥ASM优势的关键。需综合考虑I/O性能、容灾需求、扩展性和维护便利性。

分离关键组件至独立磁盘组

建议将不同类型的数据分离到不同磁盘组中，实现职责隔离与性能优化：
- DATA ：存放用户数据文件
- FRA （Fast Recovery Area）：归档日志、备份集、闪回日志
- OCR_VOTE ：承载OCR和Voting Disk元数据

这样做的好处包括：
- 减少I/O争抢：归档日志的大批量写入不会影响在线事务处理性能；
- 提高恢复效率：FRA专用磁盘组可配置更高吞吐能力；
- 便于容量规划与监控：各组件使用率可单独统计。

合理设置AU大小

虽然默认AU为1MB，但在某些场景下调整此值可显著提升性能：
- 大型数据仓库（DW）系统：大量顺序扫描，增大AU至4MB可减少元数据开销；
- OLTP密集小IO系统：保持1MB以提高随机读写效率。

修改方法需在创建磁盘组前设定隐藏参数：

-- 在asmcmd中临时设置（重启失效）
ASMCMD> setattr -G DATA _asm_ausize 4194304

❗注意：该参数只能在磁盘组创建前生效，且需所有节点一致配置。

使用模板（Template）精细化控制文件属性

ASM允许为每类文件定义默认行为，如镜像级别、条带化类型（fine/coarse）。例如：

ALTER DISKGROUP DATA ADD TEMPLATE online_redo ATTRIBUTES (MIRROR COARSE);

上述命令设置重做日志文件采用粗粒度条带化（coarse striping），即每个AU连续写入同一磁盘，适合大块顺序写入场景。

综上所述，ASM的设计不仅仅是“把磁盘放进去”，而是需要结合业务负载、硬件条件和SLA要求进行系统性规划，才能真正释放其潜力。

4.2 ASM实例创建与磁盘组初始化

ASM实例的启动与磁盘组的初始化是Grid Infrastructure安装后的首要任务。无论是通过图形化工具ASMCA还是手动命令行方式，都需要严格遵循Oracle官方的最佳实践，确保集群级一致性。

4.2.1 使用ASMCA图形工具创建磁盘组全过程

ASMCA（ASM Configuration Assistant）是Oracle提供的GUI工具，集成于Grid Infrastructure安装包中，极大简化了磁盘组创建流程。

操作步骤详解：

1. 登录任一节点，切换至grid用户：
   bash su - grid

2. 启动ASMCA：
   bash asmca

3. 在主界面点击“Create”按钮进入创建向导。

4. 输入磁盘组名称（如 DATA ），选择冗余类型（Normal）。

5. 点击“Select All”选中所有可用候选磁盘（状态为“Candidate”）。

6. 系统自动识别udev绑定的设备路径（如 /dev/oracleasm/disks/DISK1 ），确认无误后点击OK。

7. ASMCA自动校验磁盘头信息并初始化磁盘组。

8. 创建完成后可在界面查看磁盘组状态、总容量及空闲空间。

整个过程中，ASMCA会调用底层SQL命令执行实际操作，等效于以下语句：

CREATE DISKGROUP DATA NORMAL REDUNDANCY
  DISK '/dev/oracleasm/disks/DISK1',
       '/dev/oracleasm/disks/DISK2'
  ATTRIBUTE 'compatible.asm' = '11.2.0.0.0',
           'compatible.rdbms' = '11.2.0.0.0';

参数说明 ：
- 'compatible.asm' ：指定ASM软件版本兼容性，影响可用特性；
- 'compatible.rdbms' ：定义可挂载该磁盘组的数据库版本下限。

成功创建后，可通过 v$asm_diskgroup 视图验证：

SELECT name, state, total_mb, free_mb FROM v$asm_diskgroup;

输出示例：

NAME     STATE     TOTAL_MB FREE_MB
-------- --------- -------- -------
DATA     MOUNTED      20480    8900

表明磁盘组已成功加载且可用。

4.2.2 手动启动ASM实例及参数文件管理

尽管OUI安装过程通常自动启动ASM实例，但在故障恢复或调试场景中，掌握手动启停流程至关重要。

启动ASM实例步骤：

1. 切换至grid用户并设置ORACLE_SID：
   bash export ORACLE_SID=+ASM1

2. 使用SQL*Plus连接ASM实例：
   bash sqlplus / as sysdba

3. 启动实例：
   sql STARTUP;

首次启动时，ASM会查找SPFILE（服务器参数文件），默认路径为 +GRID/<hostname>/asmparameterfile/registrar.263.1 。若SPFILE不存在，则尝试使用PFILE。

参数文件管理最佳实践：

推荐始终使用SPFILE以支持动态修改和跨节点同步：

-- 查看当前使用的参数文件类型
SHOW PARAMETER spfile;

-- 若返回为空，说明使用PFILE，应转换为SPFILE
CREATE SPFILE='+GRID' FROM PFILE;

逻辑分析 ： CREATE SPFILE='+GRID' 表示将SPFILE创建在ASM磁盘组 GRID 中，实现集中管理和高可用。所有节点均可通过GPnP机制获取同一份参数文件，避免配置漂移。

此外，关键参数需特别关注：

参数	推荐值	作用
asm_power_limit	10	控制重平衡速度，值越高越快但消耗更多I/O
large_pool_size	≥ 1GB	为ASM提供足够的内存缓冲区
diagnostic_dest	/u01/app/grid	日志和trace文件输出目录

4.2.3 添加新磁盘至现有磁盘组的操作规范

随着业务增长，常需扩展磁盘组容量。ASM支持在线添加磁盘，无需中断数据库服务。

添加磁盘的标准流程：

1. 确认新磁盘已被操作系统识别并完成udev绑定；
2. 使用 asmcmd lsdsk 检查是否可见；
3. 执行 ALTER DISKGROUP ... ADD DISK 命令。

示例：

ALTER DISKGROUP DATA ADD DISK '/dev/oracleasm/disks/DISK3' NAME DATA3;

执行后，ASM会自动开始 重平衡（Rebalance） 过程，将部分已有数据迁移到新磁盘以维持条带化均衡。

可通过以下查询监控进度：

SELECT group_number, operation, est_minutes FROM v$asm_operation;

输出：

GROUP_NUMBER OPERATION EST_MINUTES
------------ --------- -----------
1            REBAL      15

表示预计还需15分钟完成。

注意事项 ：
- 添加磁盘应在低峰期进行，避免影响生产性能；
- 若 asm_power_limit=0 ，则重平衡不会自动启动，需手动开启；
- 建议命名磁盘（如 NAME DATA3 ），便于后期识别与维护。

4.3 ASM存储空间监控与日常运维

持续监控ASM健康状态是预防性维护的重要组成部分。有效的监控不仅能及时发现潜在问题，还能为容量规划提供依据。

4.3.1 查询磁盘组使用率、故障组状态与重建进度

定期检查磁盘组使用率可防止因空间耗尽导致数据库宕机。

常用SQL语句：

COL name FOR A20
COL "Used %" FOR 999.99
SELECT 
  name,
  total_mb,
  free_mb,
  (1 - free_mb/total_mb)*100 AS "Used %",
  state
FROM v$asm_diskgroup;

输出示例：

name                 total_mb    free_mb   Used % state
-------------------- -------- ---------- ------- --------
DATA                      20480       3000   85.37 MOUNTED
FRA                       10240       1200   88.28 MOUNTED

建议设定阈值告警：
- 超过80%：发出警告；
- 超过90%：立即扩容；
- 超过95%：禁止新建大型对象。

同时，检查故障组状态以确认冗余完整性：

SELECT dg.name dg_name, d.failgroup, d.mount_status, d.header_status
FROM v$asm_disk d JOIN v$asm_diskgroup dg ON d.group_number = dg.group_number
WHERE dg.name = 'DATA';

正常状态下应显示所有磁盘 mount_status=OPENED , header_status=MEMBER 。

4.3.2 在线重平衡操作的触发条件与性能影响控制

重平衡是ASM的核心机制，发生在以下情况：
- 添加/删除磁盘；
- 磁盘故障后替换；
- 手动执行 REBALANCE POWER HIGH 。

其本质是重新分布Extent以实现均匀I/O负载。

性能调优技巧：

通过调节 asm_power_limit 参数控制重平衡强度：

-- 查看当前值
SHOW PARAMETER asm_power_limit;

-- 设置为较低值以减少I/O压力
ALTER SYSTEM SET asm_power_limit = 5;

取值范围为0~11，含义如下：

Power Level	描述
0	禁用自动重平衡
1~5	低强度，适合生产高峰期
6~10	中高强度，适合夜间维护窗口
11	极速模式，仅用于紧急恢复

建议策略：
- 平时设为5；
- 维护时段临时提升至10；
- 完成后恢复原值。

4.3.3 故障磁盘隔离与自动再平衡机制分析

当某块磁盘出现I/O错误时，ASM具备自我修复能力。

故障检测流程：

1. ASM定期探测磁盘健康状况；
2. 若连续多次失败，则标记为“DROPPING”；
3. 触发自动重平衡，利用冗余副本重建数据；
4. 待重建完成后，磁盘自动移除。

可通过以下命令模拟强制删除（测试用途）：

ALTER DISKGROUP DATA DROP DISK DATA1;

⚠️ 实际生产中不应手动删除，除非确认物理更换已完成。

自动化程度取决于 disk_repair_time 参数（默认3.6小时），在此期间内若磁盘恢复连接，则自动取消删除操作，称为“可修复磁盘”功能。

-- 修改保留时间为24小时
ALTER DISKGROUP DATA SET ATTRIBUTE 'disk_repair_time' = '24H';

此机制有效降低了误拔线缆或短暂链路中断引发的数据丢失风险。

4.4 OCR/Voting Disk迁移至ASM的最佳实践

早期RAC部署可能将OCR和Voting Disk置于裸设备或NFS上。随着ASM成熟，将其迁移至ASM成为标准做法，以统一管理并提升可靠性。

4.4.1 利用relocate命令完成元数据在线迁移

Oracle提供 ocrcheck , ocrconfig , 和 crsctl replace votedisk 等工具支持在线迁移。

OCR迁移步骤：

1. 确认当前OCR位置：
   bash ocrcheck

2. 添加新的OCR副本到ASM磁盘组：
   bash ocrconfig -add +DATA

3. 删除旧OCR设备：
   bash ocrconfig -delete /dev/raw/raw1

4. 验证最终配置：
   bash ocrcheck

输出应显示所有副本均位于ASM中。

Voting Disk迁移步骤：

1. 查看当前Voting Disk：
   bash crsctl query css votedisk

2. 替换至ASM磁盘组：
   bash crsctl replace votedisk +DATA

该命令会自动完成复制、切换与清理，全程不影响Clusterware运行。

4.4.2 迁移前后的一致性验证与回滚方案

任何元数据变更都必须经过充分验证。

验证清单：

• OCR完整性： ocrcheck -details
• Voting Disk状态： crsctl query css votedisk
• CRS日志无报错： tail $ORACLE_HOME/log/<host>/cssd/ocssd.log
• 节点重启测试：逐个重启节点验证自启动能力

回滚预案：

若迁移失败，应立即恢复原配置：

# OCR回滚
ocrconfig -replace +DATA -replacement /dev/raw/raw1

# Voting Disk回滚
crsctl replace votedisk /dev/raw/raw1

💡 建议在变更前备份OCR：
bash ocrconfig -manualbackup

通过严谨的操作流程与完善的应急预案，可确保关键元数据安全迁移，为后续RAC稳定运行奠定坚实基础。

5. Oracle Database 11g R2软件安装与RAC数据库创建

5.1 Oracle Database软件安装流程与注意事项

在完成Grid Infrastructure和ASM的部署后，下一步是安装Oracle Database 11g R2软件并创建RAC（Real Application Clusters）数据库。该过程需严格遵循节点间一致性原则，并确保所有先决条件已满足。

5.1.1 运行runInstaller前的环境确认清单

在执行 runInstaller 之前，必须完成以下关键检查项：

检查项	验证命令/方法	说明
节点连通性	ssh node1 , ssh node2	确保双向SSH无密码访问
共享存储可见性	ls /dev/oracleasm/disks/	所有节点应看到相同ASM磁盘
CRS状态	crsctl check cluster -all	所有节点Clusterware运行正常
时间同步	ntpq -p	各节点时间偏差<1秒
内核参数	sysctl -a \| grep sem	对照官方文档校验
用户环境变量	env \| grep ORACLE	.bash_profile 中正确设置

此外，还需确认 /etc/oraInst.loc 文件内容统一，指向相同的inventory路径：

inventory_loc=/u01/app/oraInventory
inst_group=oinstall

5.1.2 选择“Install database software only”模式的配置要点

使用OUI（Oracle Universal Installer）时，在安装选项中选择 “Install database software only” ，为后续通过DBCA创建数据库做准备。关键配置如下：

• 数据库版本 ：Enterprise Edition
• 安装类型 ：Real Application Clusters Database
• 节点选择 ：勾选所有参与集群的节点（如node1, node2）
• ORACLE_HOME路径 ： /u01/app/oracle/product/11.2.0/db_1
• 操作系统组 ：
• Database Administrator (OSDBA) Group: dba
• Database Operator (OSOPER) Group: oper （可选）
• Database Backup and Recovery Operator (OSBACKUPDBA): backupdba

安装过程中会自动复制软件到其他节点并进行权限设置。

5.1.3 所有节点上执行root.sh脚本的顺序与依赖关系

安装程序提示在每个节点以root身份运行 root.sh 脚本， 必须按顺序执行 ：

# 在第一个节点执行
/u01/app/oracle/product/11.2.0/db_1/root.sh

# 输出示例：
Performing root user operation for Oracle 11g 

The following environment scripts need to be run as root:
        /u01/app/oracle/product/11.2.0/db_1/root.sh

Check the log file "/u01/app/oracle/product/11.2.0/db_1/install/root_node1.xxx.com_2025-04-05_10-23-45.log" for root script output.

# 等待脚本完全结束后再登录第二个节点执行
ssh node2
/u01/app/oracle/product/11.2.0/db_1/root.sh

⚠️ 注意： root.sh 会注册OHAS资源、创建初始化参数链接、更新库存信息。若并发执行可能导致锁冲突或注册失败。

5.2 使用DBCA创建RAC数据库实例

5.2.1 启用归档模式、启用ASM存储模板的选择依据

启动DBCA（Database Configuration Assistant）图形化工具：

export DISPLAY=:0.0
dbca

在向导中选择 “Oracle Real Application Clusters database” → “Create a Database”。

关键决策点包括：

• 模板选择 ：
• Custom Database（推荐用于生产环境）

• General Purpose + Data Warehousing（适合多数OLTP场景）

• 归档模式（Archive Log Mode） ：

• 必须启用，否则无法实现高可用备份恢复

• 可通过RMAN进行增量备份与时间点恢复

• ASM作为默认存储机制 ：

• 数据文件、控制文件、在线日志均置于ASM磁盘组（如+DATA）
• 使用OMF（Oracle Managed Files）简化管理

5.2.2 设置SPFILE、CONTROL FILES、REDO LOGS的ASM路径

在“Storage Options”页面指定：

• Database Storage Type : Automatic Storage Management (ASM)
• Recovery Area Location : +FRA （快速恢复区，建议独立磁盘组）
• Control Files : 存储于 +DATA ，由ASM自动镜像
• Redo Log Groups ：
• 每个实例至少两组
• 大小建议 ≥ 512MB（减少日志切换频率）
• 分布在不同故障组以提高可靠性

可通过SQL验证日志分布：

SELECT GROUP#, THREAD#, BYTES/1024/1024 AS MB, STATUS 
FROM gv$log ORDER BY THREAD#, GROUP#;

输出示例：

GROUP#    THREAD#        MB STATUS
-------- ---------- -------- ----------------
     1          1      512 CURRENT
     2          1      512 INACTIVE
     3          2      512 CURRENT
     4          2      512 INACTIVE

5.2.3 实例命名规则与服务分离策略设计

实例名称自动生成为 orcl1 , orcl2 （基于SID前缀+节点名）。建议采用清晰的命名规范，例如：

节点	实例名	用途
node1	orcl1	主处理实例
node2	orcl2	故障转移备用

同时配置TAF（Transparent Application Failover）服务：

srvctl add service -d orcl -s reporting -r "orcl1" -a "orcl2" -P BASIC -e SELECT -m BASIC -z 180 -w 5

参数说明：
- -r : 首选实例
- -a : 次选实例（故障转移目标）
- -P : TAF策略类型
- -e : 失败重试策略
- -w : 重试次数
- -z : 超时时间（秒）

5.3 RAC数据库初始配置与健康检查

5.3.1 验证所有实例是否正常注册至监听器

查询本地监听器状态：

lsnrctl status LISTENER

查看远程注册情况：

SELECT INSTANCE_NAME, HOST_NAME, REGISTRAR FROM GV$INSTANCE_REGISTER;

预期输出：

INSTANCE_NAME  HOST_NAME     REGISTRAR
-------------  ------------  ----------
orcl1          node1         LMON
orcl2          node2         LMON

5.3.2 检查VIP、SCAN Listener运行状态与故障转移功能

使用 crsctl 检查资源状态：

crsctl status resource -t

典型输出片段：

NAME           TARGET  STATE        SERVER       STATE_DETAILS                   
Local Resources
ora.LISTENER.lsnr
               ONLINE  ONLINE       node1                                        
               ONLINE  ONLINE       node2                                        

Cluster Resources
ora.scan1.vip
      1        ONLINE  ONLINE       node1                                        
ora.orcl.db
      1        ONLINE  ONLINE       node1            Open,HOME=/u01/app/oracle...
      2        ONLINE  ONLINE       node2            Open,HOME=/u01/app/oracle...

测试SCAN连接可用性：

sqlplus sys/oracle@scan-cluster:1521/orcl.us.example.com as sysdba

5.3.3 使用srvctl命令管理数据库、实例和服务资源

常用 srvctl 命令汇总：

功能	命令
启动整个数据库	srvctl start database -d orcl
停止某个实例	srvctl stop instance -d orcl -i orcl1
查看数据库配置	srvctl config database -d orcl
添加新服务	srvctl add service ...
故障转移测试	srvctl relocate service -d orcl -s reporting -i orcl1 -t orcl2

5.4 全流程总结与典型问题应对策略

5.4.1 安装过程中常见错误代码解析与解决方案汇总

错误代码	现象描述	解决方案
ORA-00600: kccpb_sanity_check	控制文件损坏或不一致	使用 alter database backup controlfile to trace; 重建
ORA-15077	ASM实例未启动	检查 cssd 进程状态，重启CRS
ORA-12545	连接不到SCAN IP	ping scan-ip, 检查DNS解析
ORA-01034: ORACLE not available	实例未启动	检查alert日志，确认spfile位置
ORA-1110	数据文件无法访问	检查udev绑定、ASM磁盘组挂载状态

示例：当出现 ORA-15077 时，排查流程图如下：

graph TD
    A[报错ORA-15077] --> B{CSS服务是否运行?}
    B -->|否| C[crsctl check css]
    C --> D[crsctl start res ora.cssd -init]
    B -->|是| E[检查ASM告警日志]
    E --> F[确认磁盘路径权限]
    F --> G[尝试手动启动ASM实例]
    G --> H[sqlplus / as sysasm; startup]

5.4.2 构建标准化RAC部署文档模板的方法论

建议文档结构包含以下章节：

1. 网络规划表（Public/VIP/Scan/Private IP）
2. 存储映射表（LUN -> udev name -> ASM disk）
3. 用户与目录权限清单
4. CRS资源启动顺序记录
5. DBCA响应文件备份（可用于静默建库）
6. 初始参数设置快照（pfile/spfile extract）

5.4.3 向生产环境推广前的最终验收测试项清单

测试类别	测试项	工具/方法
高可用性	VIP漂移测试	ifdown eth0; 观察failover
存储容灾	拔出一块ASM磁盘	ALTER DISKGROUP DATA DROP DISK ...
性能基准	OLTP压力测试	SwingBench, HammerDB
备份恢复	RMAN全备+异机恢复演练	backup as compressed backupset database;
监控集成	OEM或Zabbix监控接入	配置Metric Collection
安全审计	登录失败告警、权限最小化验证	DBA_USERS, AUDIT POLICY

执行如下脚本可批量采集基础健康指标：

#!/bin/bash
echo "=== RAC Health Check ==="
echo "Date: $(date)"
srvctl status database -d orcl
echo "--- ASM Diskgroups ---"
sqlplus -S / as sysasm <<EOF
select NAME, STATE, TOTAL_MB, FREE_MB from V\$ASM_DISKGROUP;
exit;
EOF

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

简介：Linux与Oracle 11g R2 RAC的结合是企业级高可用数据库系统的典型方案。本教程全面讲解在Linux环境下搭建Oracle Real Application Clusters的完整流程，涵盖系统准备、Grid Infrastructure安装、数据库软件部署、RAC数据库创建、OCR与Voting Disks配置、集群验证、备份恢复及性能监控等关键环节。通过图文并茂的方式，帮助IT技术人员掌握RAC环境的部署、运维与故障处理技能，提升企业数据库系统的可靠性与可扩展性。

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