1. 为什么在CentOS 7.8上装RAC 21c?版本适配与适用场景先过一遍
1.1 RAC 21c在版本谱系里的位置
先说个可能让人困惑的点:Oracle 21c并没有像19c那样频繁出现在生产部署的话题里,因为它属于“Innovation Release”,也就是创新版本,生命周期和长期支持版本不太一样。它的Grid Infrastructure版本固定为21.3.0,不存在21.1、21.2这种中间小版本,安装时反而少了很多“该下哪个补丁包”的纠结。
很多团队之所以要在这个组合上折腾,是因为手头还有一大片CentOS 7.8的存量服务器。数据库要升级到21c,但操作系统不可能一夜之间全部重装,尤其是有业务约束、有存量集群的环境,运维最怕的就是“为了升数据库把OS也一起大动干戈”。CentOS 7.8和RHEL 7.8在二进制层面基本一致,Oracle官方对RHEL 7.8有明确支持,CentOS在社区实践中也能正常跑起来,所以这个搭配并不是异想天开,而是有实际落地案例的。
1.2 什么场景适合这套组合
我见过两类场景最容易用上这套方案:
一是测试环境要模拟生产。公司生产还在用老版本的RAC,但新项目要求评估21c的新特性,比如区块链表、属性图、自动内存管理等,手头刚好只有CentOS 7.8的虚机模板,于是直接在模板上搭一套RAC 21c做功能验证。
二是存量CentOS 7.8机房做技术预研。DBA团队想看看现有硬件资源能不能撑起下一代数据库集群,先装一套跑跑负载测试,确认瓶颈在哪、要加多少内存和IO带宽,再决定后续采购计划。
这两类场景的核心诉求都不是“追求最新”,而是“在既有资源约束下把新版本跑起来”。所以这篇内容更适合手里已经有一批CentOS 7.8机器、但还没实际动过RAC 21c的DBA、运维工程师,以及准备做数据库选型评估的技术负责人。
1.3 整套安装路径的全局预览
在我实际动手之前,先把整体流程在脑子里过了一遍,这样可以避免装到一半才发现前面某步漏了:
- 预安装检查:OS版本、内核、CPU架构、内存/交换分区、/tmp空间。
- 基础环境配置:依赖包、内核参数、用户/组、目录结构、SELinux和防火墙。
- 存储与网络准备:ASM磁盘绑定、公有/私有IP、/etc/hosts。
- SSH互信配置:grid用户和oracle用户都要能免密登录所有节点。
- 安装Grid Infrastructure:这一步是RAC的骨架,负责集群软件、ASM、监听、SCAN、VIP等资源。
- 安装数据库软件:用oracle用户执行runInstaller,选择RAC安装类型。
- 创建数据库实例:用dbca创建集群数据库,可以选图形界面或静默方式。
- 验证与调优:检查集群资源状态、数据库状态、监听日志。
图形安装和静默安装在这条路径上的区别主要在第5步和第7步,前置的系统和存储配置完全一样。所以我建议无论你打算用哪种方式装,前面的基础配置都老老实实按同一套标准来,这样万一图形界面不可用,切到静默安装也不至于从头再折腾一遍。
2. 环境准备:硬件、操作系统、依赖包与内核参数核查
2.1 节点规划与资源配额
RAC至少需要两个节点才能体现集群意义。我这次用的规划是两个节点,各自配置如下:
| 项目 | 要求 | 说明 |
|---|---|---|
| CPU | 4核以上 | 两个节点合计至少8线程 |
| 内存 | 16GB起步 | 建议32GB,GI+ASM+两个实例比较吃内存 |
| 交换分区 | 至少4GB | Oracle不建议在大内存机器上关闭swap |
| /tmp空间 | 不少于4GB | 安装包解压和oui临时文件用 |
| root目录空间 | 不少于30GB | 软件安装基础空间 |
| 共享存储 | 至少3块盘 | 用于ASM磁盘组,建议再加一块装FRA |
节点名称我用的是rac1和rac2。集群名称叫rac-cluster,SCAN名称叫scan-cluster。这种情况下,业务通过SCAN来连接数据库,不依赖具体节点IP,节点故障自动转移。
2.2 OS版本与内核确认
登录每一台机器先确认基础信息:
cat /etc/redhat-release uname -rCentOS 7.8的内核一般是3.10.0-1127,这个内核版本在Oracle 21c的支持范围内。如果发现系统有特殊加固或定制内核,建议先退回标准内核,不然后面装GI的时候很容易出现不兼容的报错。
2.3 依赖包安装:少了哪个都可能卡在预检查
Oracle在CentOS 7.8上运行RAC 21c需要一批基础库,有些是编译用的,有些是运行时的。我在两台节点上都执行了同样的yum命令:
yum install -y bc binutils compat-libcap1 compat-libstdc++-33 \ elfutils-libelf elfutils-libelf-devel fontconfig-devel \ glibc glibc-devel ksh libaio libaio-devel \ libX11 libX11-devel libXau libXau-devel libXi libXi-devel \ libXtst libXtst-devel libXrender libXrender-devel \ libXpm libXpm-devel libgcc libstdc++ libstdc++-devel \ libxcb libxcb-devel make smartmontools sysstat ncurses \ ncurses-devel net-tools unixODBC unixODBC-devel \ nfs-utils python3这里面有个容易被忽略的点:compat-libstdc++-33在CentOS 7默认源里可能没有,需要先从EPEL源装好EPEL release,或者在Oracle的安装介质里找到对应的rpm包。我一开始没装这个包,结果GI的预检查阶段直接报了缺失,后来补上才通过。还有一个是libnsl,21c在某些环境下会用到libnsl.so.1,没有的话数据库启动阶段会报错。保险起见一起装:
yum install -y libnsl libnsl22.4 内核参数:直接决定ASM实例能否启动
Oracle官方给RHEL 7的大多数数据库版本规定了内核参数建议值。我这次用的是一套经过验证的参数组合:
cat >> /etc/sysctl.conf <<'EOF' kernel.sem = 250 32000 100 128 kernel.shmall = 1073741824 kernel.shmmax = 4398046511104 fs.aio-max-nr = 1048576 fs.file-max = 6815744 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 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 EOF sysctl -pkernel.shmmax这里我设置了4TB,这不是说要真的用4TB共享内存,而是避免数据库SGA或ASM实例因为共享内存段太小而无法分配。fs.aio-max-nr在高IO负载下尤其重要,ASM和数据库都重度依赖异步IO,这个值如果太小,运行中可能报aio资源不足。
2.5 用户、组与目录结构
RAC 21c需要两个操作系统用户:grid用户负责Grid Infrastructure,oracle用户负责数据库软件。它们各自有不同属组:
groupadd oinstall groupadd dba groupadd oper groupadd backupdba groupadd dgdba groupadd kmdba groupadd asmdba groupadd asmoper groupadd asmadmin groupadd racdba useradd -g oinstall -G dba,oper,backupdba,dgdba,kmdba,racdba oracle useradd -g oinstall -G asmadmin,asmdba,asmoper,racdba,dba grid注意grid用户也要加入dba组,否则后续dbca建库时,grid用户无法正常操作ASM磁盘组。这个细节我在第一次装的时候漏了,导致dbca创建数据库时报了磁盘组权限不足的错误。
目录规划沿用Oracle的标准结构:
mkdir -p /u01/app/oraInventory mkdir -p /u01/app/grid mkdir -p /u01/app/oracle/product/21.3.0/dbhome_1 chown -R grid:oinstall /u01 chown -R oracle:oinstall /u01/app/oracle chmod -R 775 /u012.6 资源限制与SELinux/防火墙
/etc/security/limits.conf里需要设置两个用户的资源上限,尤其memlock如果不设,GI的ASM实例可能无法锁定内存:
cat >> /etc/security/limits.conf <<'EOF' grid soft nproc 2047 grid hard nproc 16384 grid soft nofile 1024 grid hard nofile 65536 grid soft stack 10240 grid hard stack 32768 grid soft memlock 3145728 grid hard memlock 3145728 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768 oracle soft memlock 3145728 oracle hard memlock 3145728 EOFSELinux建议直接设为disabled。虽然Oracle在特定配置下支持SELinux enforcing,但实际操作中,SELinux导致的问题(尤其是网络绑定和ASM磁盘访问)排查起来很耗时间,测试环境没必要在这个上面较劲:
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config setenforce 0防火墙在测试环境可以直接关掉,生产环境如果有安全要求,需要放行1521、5500、5900等端口,以及GRID的组播端口。RAC节点间还需要放行很多内部通信端口,最省心的做法是节点间互相完全信任,用iptables白名单限定来源IP。
3. 存储绑定、网络规划与SSH互信:集群的底层骨架
3.1 ASM共享磁盘与udev规则
RAC的数据文件必须放在所有节点都能访问的共享存储上,ASM是Oracle官方推荐的存储管理方式。我这边是虚拟机环境,模拟了三块共享磁盘:sdb、sdc、sdd,每块30GB,规划给DATA磁盘组;另外两块10GB的盘放FRA恢复区。
磁盘绑定用udev规则最可靠。CentOS 7环境下,只要scsi_id能识别出唯一ID,就可以在udev里把磁盘固定成因ASM需要的名称:
/usr/lib/udev/scsi_id -g -u -d /dev/sdb用这个命令查出每块盘的唯一标识后,在/etc/udev/rules.d/99-oracle-asm.rules里写规则:
KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$name", RESULT=="36000c29e8d0d5f1e1234abcd1234abcd", SYMLINK+="asm-data1", OWNER="grid", GROUP="asmadmin", MODE="0660" KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$name", RESULT=="36000c29e8d0d5f1e1234abcd1234abce", SYMLINK+="asm-data2", OWNER="grid", GROUP="asmadmin", MODE="0660" KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$name", RESULT=="36000c29e8d0d5f1e1234abcd1234abcf", SYMLINK+="asm-data3", OWNER="grid", GROUP="asmadmin", MODE="0660"写完规则后在两个节点同时执行:
udevadm control --reload-rules udevadm trigger ls -l /dev/asm-*如果看到/dev/asm-data1等链接存在且属主是grid:asmadmin,说明绑定成功。这里有个坑:如果只在一台节点做了udev规则,另一台节点照样访问不了共享磁盘的ASM设备,所以规则文件要在所有节点上保持一致。
3.2 网络ip与/etc/hosts配置
RAC需要三类IP,每类IP都有明确的职责:
| IP类型 | 用途 | 节点1 | 节点2 |
|---|---|---|---|
| Public IP | 业务IP、SCAN解析 | 192.168.56.101 | 192.168.56.102 |
| Private IP | 节点间心跳、Cache Fusion传输 | 10.0.0.101 | 10.0.0.102 |
| VIP | 虚拟IP,漂移保护 | 192.168.56.111 | 192.168.56.112 |
| SCAN IP | 集群统一入口 | 192.168.56.120 | - |
/etc/hosts的配置需要把主机名、公有IP、VIP、SCAN全部对应起来。注意私有IP不要放进hosts文件里解析,而是靠GI的私有网络配置来识别,这样更稳:
192.168.56.101 rac1 192.168.56.102 rac2 192.168.56.111 rac1-vip 192.168.56.112 rac2-vip 192.168.56.120 scan-cluster3.3 SSH互信配置:GI安装的第一道关卡
Grid Infrastructure安装时需要在节点间传输文件并执行远程命令,所以grid用户和oracle用户的SSH互信必须在安装前配好。我用的是标准的三步法:
mkdir -p ~/.ssh chmod 700 ~/.ssh在rac1上生成密钥并分发到两台节点:
ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa ssh-copy-id rac1 ssh-copy-id rac2然后用ssh rac1 hostname && ssh rac2 hostname测试,确保免密登录正常。如果配置过程中遇到权限问题,多半是.ssh目录或者authorized_keys文件权限不对,SSH对权限检查很严格。
4. 图形界面安装Grid Infrastructure 21.3.0
4.1 准备图形显示环境
图形安装的第一步是让图形界面能弹出来。最实用的方式是准备一台有桌面环境的跳板机,或者用X11转发。我这里用的是Xmanager直接连CentOS桌面的方式。
在安装节点上设置DISPLAY环境变量:
export DISPLAY=192.168.56.1:0.0 xhost +设置完后,先跑一条命令测试图形通道是否通:
xclock如果跳板机上能弹出时钟窗口,说明DISPLAY配置没问题。如果弹不出来,检查xhost授权和防火墙是否拦截了X11端口。
4.2 gridSetup.sh启动安装
Grid解压后,找到gridSetup.sh脚本。以grid用户执行:
cd /u01/app/grid ./gridSetup.sh启动后图形界面会按以下顺序引导:
- 选择“Set Up Grid Infrastructure for a New Cluster”,也就是配置一个新集群。
- 配置集群名称和SCAN名称。SCAN名称输入
scan-cluster,端口1521。 - 添加节点信息,把rac2加进来,填好对应的VIP地址。
- SSH互信配置界面,填入grid用户的系统密码,OUI会自动配置互信。如果前面已经手动配好,这一步直接点Test也能通过。
- 选择网络类型。这里会把两个网卡都识别出来,你需要正确指定哪个是公有网络、哪个是私有网络。选错会导致节点间通信异常。
界面操作不复杂,但每一步都值得停下来确认,尤其是网络绑定和SCAN解析。如果SCAN没有DNS解析,OUI会提示“SCAN无法解析”,这时有两条路:在DNS里加SCAN的A记录,或者选择“Use GNS”让GI管理SCAN。GNS需要额外的DHCP环境,所以在我的环境里直接配了DNS。
4.3 ASM磁盘组配置
接下来是ASM配置。选择磁盘发现路径/dev/asm-*,OUI会自动列表识别出来的磁盘。把前面准备好的三块30GB磁盘归到DATA磁盘组,冗余策略我选的是External(外部冗余),因为虚拟机环境的存储本身有RAID保护,ASM再冗余一层意义不大还浪费空间。
为了保险起见,我额外建了一个FRA磁盘组,把两块小盘放进去,数据库闪回和归档日志都有地方去了。
ASM SYS密码一定要记好,后期维护ASM实例、扩展磁盘组都要用到。这里有个细节:ASM密码不能是纯数字,包含大小写字母和数字的组合更稳妥,否则校验那步过不去。
4.4 执行root.sh脚本:整个安装最容易出问题的环节
GUI走到最后一步会提示以root用户执行脚本。先执行rac1的,再执行rac2的:
/u01/app/oraInventory/orainstRoot.sh /u01/app/grid/root.shroot.sh执行过程中会启动OHASD服务并注册集群资源。如果这一步卡住,说明前面的预检查或网络配置有隐藏问题。常见报错包括集群无法跨节点通信、网络接口名不一致等。两个节点的root.sh都执行成功后,回到GUI界面点OK,GI安装就算完成了。
4.5 图形安装后的验证
GI装完不要急着建库,先用命令确认集群状态:
crsctl check cluster -all crsctl status resource -t正常会看到ora.cssd、ora.diskmon、ora.evmd这些资源处于ONLINE状态。crsctl check cluster -all返回“CRS-4537: Cluster Ready Services is online”之类的结果,就说明集群层是健康的。
5. 静默安装Grid Infrastructure:响应文件与无界面场景
5.1 为什么要准备静默安装
很多机房根本没有图形环境,也不能随便开放X11端口。这时候就需要响应文件配合静默模式。静默安装还有个好处:响应文件本身是一份“配置即文档”,下次再搭一套环境,直接改改参数就能复用,不用在GUI里一步步点过去。
5.2 准备Grid响应文件
响应文件的模板可以在解压后的grid目录里找到:
ls /u01/app/grid/response/里面会有gridsetup.rsp之类的模板。复制一份出来改:
cp /u01/app/grid/response/gridsetup.rsp /home/grid/grid21c.rsp chown grid:oinstall /home/grid/grid21c.rsp关键配置项如下:
oracle.install.responseFileVersion=/oracle/install/rspfmt_crsinstall_response_schema_v21.0 oracle.install.option=CRS_CONFIG INVENTORY_LOCATION=/u01/app/oraInventory oracle.install.asm.OSDBA=asmdba oracle.install.asm.OSOPER=asmoper oracle.install.asm.OSASM=asmadmin oracle.install.crs.config.scanType=SCAN oracle.install.crs.config.gpnp.scanName=scan-cluster oracle.install.crs.config.gpnp.scanPort=1521 oracle.install.crs.config.ClusterConfiguration=STANDALONE oracle.install.crs.config.configureAsExtendedCluster=false oracle.install.crs.config.clusterName=rac-cluster oracle.install.crs.config.gpnp.configureGNS=false oracle.install.crs.config.autoConfigureClusterNodeVIP=false oracle.install.crs.config.storageOption=ASM_STORAGE oracle.install.asm.SYSASMPassword=YourStrongPassw0rd oracle.install.asm.diskGroup.name=DATA oracle.install.asm.diskGroup.redundancy=EXTERNAL oracle.install.asm.diskGroup.AUSize=4 oracle.install.asm.diskGroup.disks=/dev/asm-data1,/dev/asm-data2,/dev/asm-data3 oracle.install.asm.diskGroup.diskDiscoveryString=/dev/asm-*注意:
oracle.install.asm.SYSASMPassword这里明文写密码,响应文件的权限要收紧,建议chmod 600,防止被其他用户看到。敏感环境里也可以用${env:ASM_PASS}这样的环境变量引用方式。
5.3 执行静默安装与日志监控
所有配置都写好后,以grid用户执行:
cd /u01/app/grid ./gridSetup.sh -silent -responseFile /home/grid/grid21c.rsp -ignorePrereq这里我加了-ignorePrereq,是因为有些非关键预检查项在CentOS环境上会提示警告,但不加这个参数直接阻断安装。当然,警告不是全部都能忽略,如果是缺包、缺内核参数导致的检查失败,还是要回到第2节把配置补上再继续。
安装过程比较长,不要干等着。实时查看日志:
tail -f /u01/app/oraInventory/logs/GridInstallActions*.log看到“Configuration complete”或者类似的提示后,说明GI层已经装好。和图形安装一样,还要以root身份执行节点上的root脚本:
/u01/app/oraInventory/orainstRoot.sh /u01/app/grid/root.shroot.sh执行完,静默安装的GI部分就完成了。
5.4 图形安装与静默安装的实际差异
两种方式我都用过,简单说说取舍:
| 对比项 | 图形安装 | 静默安装 |
|---|---|---|
| 配置反馈 | 界面直观,每步都能看到选项 | 只能靠日志和响应文件 |
| 出错定位 | 界面上能直接看到红叉 | 日志级别高,需要梳理 |
| 可复用性 | 每次都要重新点 | 修改响应文件即可复用 |
| 环境要求 | 需要X11或桌面 | 纯命令行即可 |
如果有图形环境,建议第一次装用图形,便于理解每一步到底在做什么;后面在相同环境批量部署时,直接用静默方式效率高得多。
6. 数据库软件与RAC实例创建(图形+静默两套)
6.1 数据库软件安装:runInstaller的图形与静默
GI装好后,开始装数据库软件。数据库软件的安装介质里也有响应文件模板。图形安装时以oracle用户执行:
cd /u01/app/oracle/product/21.3.0/dbhome_1 ./runInstaller选择“Set Up Software Only”,然后选择“Oracle Real Application Clusters”和数据库版本,把两个节点都加进去。这一步不创建数据库,只把软件分发到所有节点。
静默安装数据库软件同样用响应文件:
./runInstaller -silent -responseFile /home/oracle/db21c_install.rsp -ignorePrereq响应文件里几个关键项:
oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v21.0 oracle.install.option=INSTALL_DB_SWONLY UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=/u01/app/oraInventory ORACLE_HOME=/u01/app/oracle/product/21.3.0/dbhome_1 ORACLE_BASE=/u01/app/oracle oracle.install.db.InstallEdition=EE oracle.install.db.OSDBA_GROUP=dba oracle.install.db.OSOPER_GROUP=oper oracle.install.db.OSBACKUPDBA_GROUP=backupdba oracle.install.db.OSDGDBA_GROUP=dgdba oracle.install.db.OSKMDBA_GROUP=kmdba oracle.install.db.OSRACDBA_GROUP=racdba oracle.install.db.rac.configuration=true oracle.install.db.rac.nodeList=rac1,rac2数据库软件装完,同样要执行root脚本,这里就不再重复解释root脚本的作用了。
6.2 图形方式创建RAC数据库:details
数据库实例的创建用dbca工具。以oracle用户执行:
dbca选择“Oracle Real Application Clusters database”,再选“Create a database”。之后会进入熟悉的建库流程:输入全局数据库名称(如RACDB.example.com)、选择容器数据库模式、设置SYS和SYSTEM密码、选择存储类型为ASM并指定DATA磁盘组、选择字符集。
从21c开始,默认推荐使用多租户架构创建数据库,就是说会创建CDB和PDB。如果业务还没准备好上多租户,可以选“Create as Container Database”的时候只保留一个初始PDB,这样既享受了架构升级的好处,也不会对现有应用产生太大影响。
建库过程会持续十几分钟,主要取决于硬件性能。期间dbca会通过ASM自动创建数据文件、控制文件、重做日志,不用手动指定路径。
6.3 静默方式创建RAC数据库:dbca命令行
无图形环境下用命令构造数据库:
dbca -silent -createDatabase \ -gdbName RACDB.example.com \ -sid RACDB \ -templateName General_Purpose.dbc \ -storageType ASM \ -datafileDestination +DATA \ -recoveryAreaDestination +DATA \ -sysPassword YourSysPwd123 \ -systemPassword YourSystemPwd123 \ -characterSet AL32UTF8 \ -nationalCharacterSet AL16UTF16 \ -memoryPercentage 40 \ -nodeinfo rac1,rac2这里解释一下几个容易搞混的参数:
-sid是数据库实例名前缀。RAC会自动加上节点序号,比如rac1上的实例名是RACDB1,rac2上是RACDB2。-storageType ASM告诉dbca用ASM来管理数据文件,而不是文件系统。-nodeinfo rac1,rac2指定数据库实例要部署在哪些节点上。如果漏了这个参数,dbca默认只在执行命令的当前节点建实例,那就变成单实例而不是RAC了。-memoryPercentage 40表示给数据库分配总物理内存的40%,具体值要根据服务器实际内存调整。
静默建库过程中,dbca会在控制台输出进度,同时写日志到$ORACLE_BASE/cfgtoollogs/dbca/目录。如果卡住不动,去这里翻日志比盯着控制台更有用。
7. 安装过程中踩过的坑与排查过程
7.1 libaio和compat-libstdc++缺失导致的预检查失败
第一次装GI,预检查阶段两个包没通过:compat-libstdc++-33和libaio-devel。服务器是内网环境,yum源里没有这两个包,我一开始没当回事,想跳过预检查直接装。结果GI装到后面弹了个编译链接错误,ASM实例根本起不来。
排查链路也很典型:先查crsctl status resource -t发现ora.asm是OFFLINE,再查$GRID_HOME/cfgtoollogs/crsconfig/下的日志,看到了libaio.so.1: cannot open shared object file的报错。补上libaio和libaio-devel之后,重新执行ASM的资源配置才恢复。
所以提醒一句:预检查里报的缺失项,不要盲目跳过。缺包这类问题虽然不会立刻让安装失败,但会在后面的某个环节突然冒出来,而且越到后面排查成本越高。
7.2 SSH互信在OUI里一直配置失败
我在一台机器上提前配好了SSH互信,但OUI引导时输入密码后还是报错。排查发现是~/.ssh/authorized_keys里的条目有问题:我之前手动合过公钥,格式粘错了,导致从rac1到rac2能登录,从rac2到rac1却不行。
处理办法是删掉.ssh目录重新生成密钥和互信:
rm -rf ~/.ssh ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa ssh-copy-id rac1 ssh-copy-id rac2 ssh rac1 hostname ssh rac2 hostname确认两边都能免密后,再回到OUI测试就能通过了。经验就是:SSH互信要双向验证,只测单向很容易出现“以为配好了,结果来回报错”的尴尬。
7.3 ASM磁盘权限不对,GI识别不到磁盘
udev规则配置完,我在rac1上能看到/dev/asm-data1,但GI预检查识别当前可用磁盘时一个都没找到。查了ls -l /dev/asm-*发现链接指向正常,但权限变成了root:root。
原因是我在rac1上先写了udev规则并reload,但rac2上还没同步。共享存储是虚拟机共享盘,但udev规则是按节点生效的,rac2上没写规则,重启后那块多路径设备就以默认权限出现了。
两个节点都补上规则、reload、trigger之后,GI就能正常看到磁盘了。在中大型环境里,还有一个可能性是磁盘有厂商多路径软件,设备名不是sd开头,比如dm-*,那udev规则要改成匹配dm-*的方式。
7.4 VIP资源启动失败:SCAN的DNS解析问题
GI安装后检查集群状态,发现ora.rac1.vip是OFFLINE。排查过程比较曲折:
先看crsctl status resource ora.rac1.vip -p确认资源依赖,再看/var/log/messages和GI的alert日志,终于看到一行Failed to determine if virtual IP address is already assigned之类的报错。
一分析,原来是我在/etc/hosts里写了SCAN的解析,但虚拟机网络里的网关和DNS没有真正为SCAN提供服务。GI的VIP检查会尝试反向解析VIP地址,反向解析失败就认为IP已被占用或网络不可达。
解决办法是在DNS服务器上给SCAN和VIP都加上正向和反向解析记录,或者至少在本地DNS配置里保证这些IP的反向解析能通。如果你只是在测试环境,图省事可以把validate参数调整,但正规部署还是要走DNS。
7.5 静默安装时响应文件路径或权限报错
用响应文件静默安装GI时,报过Unable to create the directory的错误。原因是响应文件里的INVENTORY_LOCATION指向的路径父目录不存在,而grid用户对/u01没有写权限。
这种问题很简单,但也很容易忽略:先mkdir -p把路径建好,再检查ls -ld /u01确认grid用户有写权限。不要只改响应文件不检查底层目录权限。
8. 安装完成后的集群验证与基础调优
8.1 集群资源全面检查
安装完成后,尽快做一轮完整的健康检查,把下面这几条命令的结果都过一遍:
crsctl check cluster -all crsctl status resource -t srvctl status database -d RACDB srvctl status scan srvctl status listener正常时,crsctl status resource -t里ora.asm、ora.cssd、ora.diskmon、ora.evmd、ora.rac1.vip、ora.rac2.vip、ora.scan1.vip以及listener都应该处于ONLINE状态。数据库实例方面,RACDB1和RACDB2都应该标着OPEN。
8.2 数据库层面验证
用oracle用户登录数据库做基本验证:
sqlplus / as sysdba select inst_id, instance_name, status from gv$instance; select name, open_mode from v$database;gv$instance能查到两个实例,说明RAC跨节点查询正常。再用cluvfy做一次环境体检:
cluvfy comp cluster -n rac1,rac2 -verbose如果有警告项,确认是文档类警告还是硬性错误。硬性错误必须处理,比如网络包丢失率过高、ASM磁盘组空间不足这些。
8.3 我在实际部署中建议补充的几件事
集群跑起来只是第一步,更关键的是后续运维配置。结合我在多个项目里的经验,有几件事建议在交付前就做掉:
一是调整数据库的归档模式和闪回设置。21c默认可能是非归档模式,但生产环境必须开归档。把快速恢复区指定到FRA磁盘组,开启闪回,这样误操作时多一条恢复路径。
二是重做日志组大小要提前规划。RAC每个实例都有独立的redo log,使用默认配置往往会出现小日志频繁切换的问题,导致数据库成为性能瓶颈。建议每个实例至少4组日志,每组大小512MB起步,具体根据业务压力再放大。
三是定期查看DIAG和alert日志。RAC日志分散在各节点,最好配置一个集中式日志收集方案,或者定期用脚本汇总$ORACLE_BASE/diag目录下的告警信息。
8.4 再说一句静默与图形怎么选
装完这套RAC之后,我对双模式安装的一个体会是:图形安装适合第一次学习和排错,静默安装适合批量交付和自动化运维。如果你只是自己搭一套测试环境,图形安装更省心,每步都看得到;如果你之后要在十几台机器上重复同样的事情,响应文件反而是最值钱的资产——改改IP和主机名就能复用。
CentOS 7.8上装RAC 21c这套组合,在社区里的参考文档不算特别多,尤其是静默安装部分,很多时候要靠日志一点点摸索。但只要你把系统层的基础配置做扎实,存储和网络规划到位,图形和静默两条路都能走通。我自己更习惯把响应文件当成配置模板管理起来,每次部署前先更新参数,再执行静默安装,效率和稳定性都比反复操作图形界面好很多,也少了很多误点击的风险。