Oracle 19c+ASM生产环境部署实战：从Linux裸机到业务可用

之前有个学员私下问我：为什么别人装 Oracle 19c 那么快，我照着 PDF 一步步点，装完用起来却老觉得不踏实？这个问题其实特别典型。装一套能用的数据库和装一套“敢上生产”的数据库，中间差的不是鼠标点击的熟练度，而是对 Linux 环境、对存储层、对 Oracle 体系结构的理解深度。

我这篇 FGMT03 讲的不是“怎么点下一步”，而是你动手装 Linux + Oracle 19c + ASM 之前必须先想清楚的那些事，以及从裸机到能跑业务的完整链路。全程按生产环境的规格来，不会给你那种装完就完事的“玩具实例”。这套流程我前前后后在虚拟机上验证过不下十遍，也在测试环境中模拟过生产压力，里面的坑基本都是我实际踩过的。

1. 为什么生产环境的Oracle 19c跑在ASM上才靠谱

1.1 普通文件系统装Oracle的最大隐患

很多人第一次接触 Oracle，是在 Windows 或者没有 ASM 的 Linux 上，数据文件放在 ext4/xfs 文件系统里。这种部署方式在开发和测试环境完全可以用，但它有两个在生产环境里很要命的短板。

第一，文件系统对数据库文件的 IO 路径多了一层。数据库进程发起的 IO 要先经过文件系统、经过操作系统页缓存，中间还可能有各种锁。Oracle 在企业级场景里一直强调直接用裸设备或者 ASM，因为 ASM 本身就是一个为数据库 IO 设计的卷管理器 + 文件系统，它把数据文件切成一个个 Allocation Unit（默认 1MB，也可以设 4MB），通过指针把这些 AU 映射到底层磁盘上，IO 路径比普通文件系统更可控。

第二，也是最现实的：如果文件系统损坏，你恢复起来很痛苦。数据库文件的损坏检测、坏块自动修复能力（比如 ASM 的镜像和修复），在普通文件系统上完全发挥不出来。生产环境最怕的就是存储出问题，而 ASM 恰恰是 Oracle 在存储层加的那道保险。

1.2 ASM干了什么，以及它带来的部署变化

用一句话说，ASM 是 Oracle 自己做的“软件 RAID + 集群文件系统”组合体。你不需要再花钱买存储厂商的卷管理软件，也不用依赖 Linux 的 LVM，只需要给 ASM 指定几块“裸”磁盘，它自己会做条带化和镜像。

这就带来一个很明显的部署结构变化：以前数据库软件和数据库文件都在一块盘上，现在整个系统被拆成了三个层次：

层次	组件	作用
存储层	ASM 磁盘组	存放数据文件、控制文件、日志文件、备份
基础设施层	Grid Infrastructure（GI）	管理 ASM 实例、监听、集群资源
数据库层	Oracle Database 19c	提供业务访问

我见过不少人在虚拟机里硬装 ASM，结果因为共享磁盘、SCSI ID 之类的问题装到崩溃。其实单机环境完全不需要搞复杂的共享存储，ASM 在单机上照样能跑，只需要配置好磁盘的权限和名称，让 GI 能识别出来。虚拟机里做实验时，我给每个 ASM 磁盘单独划分一个 SCSI 控制器槽位，避免和多路径软件打架。

1.3 这台“生产环境”机器到底该怎么准备

既然标题里有“生产环境”四个字，很多人第一反应是去翻官方的最低配置：2GB 内存、10GB 磁盘。我只想说，最低配置装出来的实例根本没法做任何实战测试，连启动一套像样的 PDB 都费劲。我的建议是不要低于 8GB 内存、100GB 磁盘，建议配置如下：

• CPU：4 核以上，安装过程中那些检查脚本很吃 CPU。
• 内存：8GB 起步，16GB 更舒服。ASM 实例本身只占几百 MB，主要是留给数据库 SGA 和 PGA。
• 磁盘：系统盘 50GB，ASM 磁盘 3-5 块，每块 20GB 左右。

操作系统我推荐 Oracle Linux 7.9 或者 Rocky Linux 8.x。虽然 Oracle 19c 官方支持列表里主要是 Oracle Linux 和 RHEL，但只要你内核参数配置到位，基于 RHEL 的发行版都能跑。本文档里的命令在 Oracle Linux 7.9 上验证过，CentOS 7、Rocky 8 也适用。

2. 从零构建一台干净的Linux服务器

2.1 操作系统安装与网络规范

这一步看似简单，但踩过坑的人都知道，Linux 系统盘的 /boot 分区和根分区布局如果规划不当，后期会异常难受。我的建议是：

• /boot 分区给 1GB
• swap 给 4GB（如果物理内存 16GB 以上，swap 可以给 4GB 或干脆不要，因为 Oracle 对 swap 的建议是物理内存的 0.5 到 1 倍之间）
• 根分区 / 给完剩余全部空间，直接格式化为 xfs

网络方面，生产环境强烈建议配置固定的 IP 地址和主机名，不要依赖 DHCP。主机名不能用“oracle”或“db”这种过于简单和容易冲突的名字，我一般在规划文档里定义成 fgtm-db01 这种格式，并且在 /etc/hosts 里写清楚 IP 和主机名的对应关系。安装 GI 时有很多反向解析检查，hosts 文件里写不好会直接卡在检查阶段。

2.2 磁盘布局：留给ASM的盘子要干净

ASM 对磁盘的要求只有一个——它必须是未格式化的裸设备。这句话的坑在于“未格式化”三个字。很多人在虚拟机里加了一块新盘，安装操作系统时顺手给它建了分区，或者进系统后 mkfs 了一下，结果 ASM 识别时总是提示磁盘头有问题。

正确的做法是：给 ASM 预留的磁盘，从创建到使用都不要碰它。加盘之后用 fdisk -l 查看能看到三块 20GB 的盘，比如 /dev/sdb、/dev/sdc、/dev/sdd，但坚决不要对它们执行 fdisk 或 mkfs。ASM 在初始化磁盘时自己会写磁盘头，你提前写了任何文件系统，都可能导致后续 asmcmd 操作时报 “ORA-15018: diskgroup cannot be created” 这类错误。

2.3 安装依赖包：决定你后面顺不顺的唯一前置条件

Oracle 19c 的安装程序在安装前会执行一系列检查，其中一个让人烦躁的检查项就是缺少某些 RPM 包。如果你用的是 Oracle Linux 自带的 public yum 源，直接执行下面这一串命令：

注意 compat-libstdc++-33 这个包在 CentOS 8 及其后续版本里已经不在默认源中了，需要手动去 EPEL 或者用兼容包替换。如果你卡在这一步，可以直接使用 oracle-database-preinstall-19c 这个 rpm，它是 Oracle 官方提供的预安装包，执行完依赖全装好，用户和目录也会自动建好。不过在真实生产项目中，我更倾向于手动配置，因为预安装包有一些默认行为和我的环境规范不完全一致。

2.4 内核参数和Shell限制

这一步是最容易“照抄出错”的环节。很多博客直接丢一个 sysctl.conf 让你覆盖，也不告诉你每一项在干嘛。生产环境的系统上，内核参数是全局生效的，随便乱改可能影响同一台机器上的其他应用。

我按 Oracle 官方文档排序，把对 19c 最关键的几个参数说明一下：

参数	推荐值	意义
kernel.shmmax	物理内存的一半（字节）	单个共享内存段的最大尺寸
kernel.shmall	物理内存的页数	共享内存总页数上限
kernel.sem	250 32000 100 128	信号量参数，Oracle 并发访问依赖它
fs.file-max	6815744	系统级文件句柄上限
fs.aio-max-nr	1048576	异步 IO 请求数上限
net.ipv4.ip_local_port_range	9000 65500	预留端口范围，防止 Oracle 端口被临时端口占用
vm.swappiness	10	减少内存换页频率

怎么算物理内存对应的字节数？用 free -b 看 Mem 那行 total 值，shmmax 设成它的一半即可。shmall 则是把物理内存的总字节数除以页大小（通常是 4096 字节）。注意在真实生产环境里，如果机器还跑着别的业务进程，shmmax 不能随便吃满一半，否则其他应用可能起不来。

Shell 限制方面，编辑 /etc/security/limits.conf 加上：

这些设置的值不是随便写的，Oracle 官方安装文档里有对应的检查标准。测试环境中可以临时用 ulimit -n 调整，但生产环境一定要持久化配置，否则重启后失效。

3. 用户、目录与权限：数据库系统的地基

3.1 用户组规划

安装 Oracle 19c 的 Grid Infrastructure 和数据库软件，最少需要两个用户：grid 和 oracle。grid 负责管理 ASM 实例和集群资源，oracle 负责运行数据库。很多人图省事只用 oracle 一个用户装完所有组件，这在生产环境是非常不推荐的，因为 Oracle 官方支持的最低权限设计就是两者分离。

注意 oracle 用户不要加入 asmadmin 组，正常情况下它只需要访问 ASM 数据的权限（asmdba），而不应该有管理员级别的权限。如果加了，数据库和 ASM 的权限边界就模糊了，这在生产环境审计时是个问题。

3.2 目录结构设计

Oracle 的目录规划直接影响后续的升级、补丁和卸载。我用的是下面这套经典的结构，避免 Oracle Home 和 ORACLE_BASE 混在一起：

权限设置：

这里有一个很多人忽略的细节：/u01/app/oraInventory 的所有者第一次会由安装程序自动创建，但在安装之前指定好所有者能避免后续跑 root.sh 时因为权限错误出现 OUI-100 这种问题。

3.3 udev规则：让ASM找到磁盘的正确姿势

Linux 下磁盘设备名不固定，重启后 /dev/sdb 可能变成 /dev/sdc。生产环境绝对不能依赖这种不稳定的命名来让 ASM 识别磁盘，所以必须通过 udev 规则绑定磁盘的稳定标识。

常用的绑定方式有两种：一是按 UUID（通过 blkid 查看文件系统 UUID，不过裸盘没有文件系统），二是按 /dev/disk/by-id/ 下的 scsi id 或 wwn。对 ASM 这种裸盘场景，我习惯用 scsi_id 命令获取设备唯一标识，然后写 udev 规则。

拿到序列号后新建 /etc/udev/rules.d/99-oracle-asm.rules：

有三条规则就要写三行，分别指定三块盘。写完执行 udevadm control --reload-rules 和 udevadm trigger，再检查一下权限是否变成 grid:asmadmin。这一步做不好，后面启动 ASM 实例时会出现 ORA-15032: Not all alterations performed 这种让人摸不着头脑的报错。

4. Grid Infrastructure安装与ASM磁盘组规划

4.1 安装前检查与cvuqdisk

从 Oracle 19c 开始，安装介质自带一个 cvuqdisk 包，它在安装前检查 chk 包时需要用到。这个包在 stage 目录的 cvu/cv/rpm 下，需要先安装到系统里：

完整检查所有安装环境是否满足要求，用 runcluvfy.sh：

如果环境有什么问题，它会在输出里明确提示你该修什么。我当时在虚拟机上第一次跑这台命令，报了一个关于物理内存不足的警告（因为虚拟机默认 4GB），后来把内存调到 8GB 才彻底通过。这里提醒一下：chk 不通过不代表不能装，如果只是 warning 级别可以继续，但如果涉及 missing packages 或者 hard limit 不达标，最好停下来处理完再继续。

4.2 图形界面还是静默安装

生产环境我建议至少先学会静默安装，因为很多生产机器是内网环境，没有图形界面，也无法通过 X11 转发桌面。虽然图形界面交互起来直观一些，但在内网堡垒机环境下，静默安装文件才是你真正要维护的东西。

Grid Infrastructure 的静默安装响应文件用 gridSetup.sh -silent -responseFile 来调用。响应文件模板在安装介质的 response 目录下，其中 gridsetup.rsp 需要重点配置这几个参数：

参数	值	说明
oracle.install.option	CRS_CONFIG	安装集群就绪服务
ORACLE_BASE	/u01/app/grid	grid 用户基础目录
ORACLE_HOME	/u01/app/19.0.0/grid	GI 安装位置
oracle.install.asm.OSDBA	asmdba	指定 DBA 权限组
oracle.install.asm.OSOPER	asmoper	操作员权限组
oracle.install.asm.OSASM	asmadmin	ASM 管理员组
oracle.install.crs.config.scanType	LOCAL_NODE	单机环境用本地节点
oracle.install.asm.diskGroup.name	DATA	首个磁盘组名称
oracle.install.asm.diskGroup.redundancy	NORMAL	冗余模式
oracle.install.asm.diskGroup.disks	/dev/sdb,/dev/sdc,/dev/sdd	磁盘列表
oracle.install.asm.diskGroup.diskDiscoveryString	/dev/sd*	磁盘发现字符串

其中 redundancy 有 EXTERNAL、NORMAL、HIGH 三档，生产环境有硬件 RAID 的存量环境有时候会为了空间利用率选 EXTERNAL，这个见仁见智。但软件层面的冗余永远是低于底层硬件冗余的，硬件有 RAID 保护的情况下用 EXTERNAL 不是不能接受。一般来说，我建议虚拟机实验环境至少有 NORMAL，这样能理解 ASM 的镜像机制。

4.3 root.sh 和 ASMCA 磁盘组验证

安装 GI 的最后一步一定会让你在 root 用户下执行 /u01/app/19.0.0/grid/root.sh。这一步没跑好，后面各种 crsctl 命令都会罢工。常见的 root.sh 卡住原因有两个：一是 /etc/oratab 文件被之前的尝试污染，二是 ohasd 启动失败。

执行完 root.sh，用下面这些命令验证 ASM 集群状态：

crsctl stat res -t 的输出很长，只要看到 ora.asm 是 ONLINE 状态，就说明 GI 这一层基本没问题了。

接下来用 asmca 图形工具或 asmcmd msod 命令检查磁盘组的状态。如果没有图形环境，用 asmcmd 更直接：

lsdg 输出里要注意 State 一栏，正常显示 MOUNTED。每个磁盘组的 TOTAL_MB 和 FREE_MB 也要心里有数，这个直接对应你未来建表空间时可用容量。

5. 数据库软件的安装、监听和PDB规划

5.1 数据库软件的静默安装

GI 装好只是把地基打了，数据库软件本身还要单独装。数据库软件的静默安装响应文件是 db_install.rsp，关键参数如下：

启动安装：

这一步骤时间比较长，我等过二十多分钟的，期间屏幕上没有任何输出，不要急着中断。安装完要再跑一次 root 脚本：

5.2 监听配置与DBCA建库

先用 netca -silent 创建监听：

监听端口默认 1521，如果 1521 被占用，需要先调整 listener.ora 里的端口再启动。这个情况在企业内网挺常见，尤其是一台服务器上可能跑过其他数据库或中间件。

建库用 DBCA 静默模式：

注意 -createAsContainerDatabase true 意味着你建的是 CDB，这是 19c 的默认形态。如果你选 false，建的就是传统非容器数据库（非 CDB），这在 19c 上属于 deprecated 配置，官方已经不推荐但还支持。除非你有历史版本的升级兼容性需求，否则一律按 CDB 来。

5.3 生产库的PDB数量绝对不是越多越好

CDB 的好处是管理集中、资源隔离方便，很多人在一个 CDB 里塞十几个 PDB，表面上看节约了资源开销。但生产环境我提醒一句：PDB 数量一多，SYSAUX 表空间的膨胀速度会明显加快，AWR、统计信息、审计信息会为每个 PDB 各存一份。我自己就遇到过 SYSAUX 被 WRH$_ACTIVE_SESSION_HISTORY 相关段占满的例子，后面清理起来特别费劲。

一个 CDB 里放多少 PDB，取决于业务确权和运维人员的管理能力。如果每个业务线的 DBA 是同一批人，3 到 5 个 PDB 是合理的；如果 PDB 由不同团队自治，我强烈建议一个 CDB 少放几个，或者干脆每个业务一个独立 CDB，别为了省内存把运维复杂度拉满。

6. 项目实战：把一张订单表送进ASM

6.1 场景设计：一个小型订单系统的库表结构

这一节用一个简单的订单系统做例子，让大家感受数据到底是怎么进 ASM 的。场景：一个电商项目的订单库，数据量中等，每天产生约 10 万条订单记录，保留 12 个月。

首先在 PDB 内创建业务用户和表空间：

建订单表：

这里有个值得说的细节：你建表空间时如果没指定 datafile 的路径，Oracle 会在 DB_CREATE_FILE_DEST 指定的位置自动创建。而 DB_CREATE_FILE_DEST 在 DBCA 建库时会自动设置成 ASM 磁盘组路径。也就是说正常情况下，你根本不需要在 SQL 里写类似 +DATA/ORCL/DATAFILE 这种路径，Oracle 会自动帮你把数据文件放到 ASM 的 DATA 磁盘组里。

如果你想确认数据文件确实在 ASM 里，执行：

返回结果里 file_name 是 +DATA/ORCL/DATAFILE/tbs_order.272.123456789 这种格式，而不是 /u01/app/oracle/oradata/xxx.dbf。名字里的 .272. 是 ASM 内部的文件编号，掌握这个规律后，在 asmcmd 里定位文件就很容易。

6.2 ASM日常运维与监控命令

项目运行起来之后，日常需要关注的 ASM 操作主要是这几类。

查看磁盘组空间：

看到 USABLE_FILE_MB 小于 0 就说明磁盘组空间不足了。这个字段很特殊，它代表去掉冗余后还能安全使用的空间，NORMAL 冗余下实际可用空间是物理空间的一半。

看每个磁盘是否均衡，用：

重点看 READ_ERRS 和 WRITE_ERRS，如果某块盘频繁出现 IO 错误，ASM 会自动把它的数据重平衡到其他盘上，但你需要尽早发现并替换这块盘。

SQL 里也能查 ASM 状态：

建议在监控系统里加一个磁盘组空间使用率的指标，这种大表数据一涨起来，磁盘空间可能一两周就吃掉几十个 GB。

6.3 RMAN备份与恢复验证

生产库的备份策略不是可选配置。19c 默认安装完 ARCHIVELOG 是关闭的，所以建库后第一件事就是把数据库切成归档模式：

然后设置快速恢复区和归档日志路径，DBCA 如果指定了 -recoveryAreaDestination FRA 会自动配好，没有指定的话手动执行：

RMAN 全库备份命令：

RMAN 会把备份写到 db_recovery_file_dest 指定的 ASM 磁盘组。想验证备份可用，不一定要真的恢复，用 restore validate database; 可以检查备份集是否完好。真实生产环境建议在测试机定期做一次恢复演练，这个步骤最有价值，因为不出事你永远不知道备份脚本到底有没有遗漏。

7. 安装运行中那些折磨人的故障

7.1 安装阶段的经典报错

安装 GI 或 DB 软件时最经典的一个错误是 INS-06006，它通常出现在你安装完依赖包之后还需要额外安装某个 rpm 的场景。比如某个版本的 Oracle Linux 上缺少 libnsl.so.1，安装程序就会报找不到这个库。处理方法很简单：安装对应的兼容库，比如 yum install -y libnsl，报什么缺什么，装完重跑安装程序就行。

另一个高频错误是 ORA-15031: disk specification does not match any disks，这通常是磁盘发现字符串的问题。解决方法是确认 /etc/udev/rules.d/ 里的规则确实生效了，并且权限确实是 grid:asmadmin。执行 ls -l /dev/sdb 看看。

如果磁盘的属主不对，八成是 udev 规则没重载或者 RESULT 字符串写错了。/usr/lib/udev/scsi_id -g -u -d /dev/sdb 返回带有 /dev/ 前缀还是不带，不同系统版本会不一样，写 udev 规则时要特别注意。

7.2 运行阶段的空间问题：sysaux为什么会膨胀

运行阶段的故障基本围绕数据库打开速度和性能问题展开。我遇到过一个很典型的案例：数据库实例启动后，一条 AWR 报告要等几十分钟才能生成，后来发现 SYSAUX 表空间已经用满了 32GB。

主要原因有三个方向：AWR 基线数据过多、审计记录堆积、STATISTICS_LEVEL 设置过高等。清理方式可以参照下面这个顺序：

查出占用大头后，再针对具体组件处理。比如 AWR 快照保留时间过长，可以调短快照保留时间：

这些操作在生产环境都是可以动态执行的，不需要重启数据库，但也建议在变更窗口内操作，避免 AWR 数据大规模清理影响业务。

7.3 “卸载Oracle”在Linux上为什么不是删目录

很多从 Windows 转过来的朋友，看到教程里写着“清注册表”，一到 Linux 就懵了，因为 Linux 没有注册表。你这个标题下面的热搜词里都有“如何卸载oracle19c注册表”，足以说明这问题困扰过很多人。

Linux 上卸载 Oracle 的正确做法分三步：

• 停掉所有相关进程：crsctl stop crs
• 用图形工具或者静默方式调用卸载脚本：$ORACLE_HOME/deinstall/deinstall
• 清理残留目录和系统文件：/etc/oratab、/etc/oraInst.loc、/u01/app 下相关 HOME 目录，以及 /etc/udev/rules.d/ 里的 ASM 磁盘规则

没有“注册表”不等于没有残留。/etc/oratab、/etc/oraInst.loc 和 oracle 用户的环境变量里都留有痕迹，不清理干净，等下一次安装的检查阶段就会异常，甚至把新安装的实例和旧的监听混在一起。

8. 上线前必须补完的收尾工作

8.1 归档、闪回与备份策略的联动

很多人装完数据库，导完数据，觉得“能用就行”，结果几个月后硬盘满了才发现归档日志已经把空间吃光。ASM 磁盘组里 FRA 的空间规划和磁盘组本身的容量规划同样重要。

推荐的生产参数组合是：

归档日志保留时间建议拉到 7 天以上，闪回保留 1 天左右。具体的值取决于业务容忍的停机时间和你对数据丢失的容忍度。备份策略上，我目前实际使用频率最高的是每周日 0 点全备，每天增量备份，归档日志实时备份到异机。RMAN 里可以这样配增量备份：

8.2 打开数据库级别的调优

19c 默认安装后，有一些参数和真实生产负载匹配得不好。比如 processes 默认只有 300，很多业务一上线就报 ORA-00020: maximum number of processes exceeded。根据你的最大并发连接数，提前调高：

内存管理如果是手动模式，建议检查 sga_target 和 pga_aggregate_target，使用 memory_target 自动管理虽然省事，但在内存申请和实例稳定性之间需要平衡。我的个人建议是生产库使用 sga_target + pga_aggregate_target 的手动管理方式，这样实例内存使用更可控，OOM 风险更小。

8.3 监控、告警和变更记录

说实话，这一节是我最想跟大家强调的“非技术”环节。我也见过太多项目，数据库装得漂亮，参数调得也专业，但没接监控，出故障时靠人肉登录。

生产库至少要监控这几个指标：

• ASM 磁盘组空间使用率，超过 70% 预警，超过 85% 告警
• 告警日志中的 ORA-600 和 ORA-7445 错误
• 数据库会话数和活跃会话数
• 归档日志生成速率和磁盘增长趋势

变更记录我建议使用简单的数据库变更清单，每次操作都记下时间、操作人、变更内容、验证结果。这个习惯在排查性能问题时价值巨大，你能快速知道是不是某次参数调整导致的性能回退。

最后再分享一个我的个人习惯：在每台数据库服务器的 ~/.bash_profile 里加上环境变量别名，把 sqlplus / as sysdba 和 asmcmd 这两个最短命令写成 alias，减少生产环境误操作的概率。装完这套环境，建议把从操作系统安装到 DBCA 建库的全过程在文档里重新走一遍，不只是记命令，而是把每一步背后的意图写下来。你亲自验证过一遍之后，再遇到任何安装问题，都会比直接搜“xxxx教程”可靠得多。