Oracle 19c + ASM生产环境部署与迁移实战：从文件系统到磁盘组

接到任务时的场景我还记得很清楚：生产库里有四百多万行订单数据躺在文件系统上，每天凌晨的备份窗口越来越不够用，I/O等待动不动就飙到顶端。领导给的方向很直接——新库直接上 Linux + Oracle 19c + ASM，顺便把历史数据都挪过去。数据库教程 FGMT03 这一篇，就是把我折腾了半个多月、改了五版实施方案之后沉淀下来的东西完整写清楚。

这篇内容适合正在规划生产环境部署、纠结 ASM 和文件系统怎么选、以及准备把旧库迁到 Oracle 19c 上的 DBA 和运维人员。我会把从存储选型、环境准备、Grid 安装、建库、到项目迁移踩坑的全过程拆开讲，命令和步骤都会给到可以直接抄的级别，而不是泛泛说“配置一下就行”。

1. 生产环境为什么用ASM承载Oracle 19c：存储架构选型复盘

这个决定直接影响后面所有安装和运维方式，所以我先聊清楚原因。很多人一听说 ASM 就觉得是 RAC 的附属品，其实单实例生产库同样适合用 ASM，关键在于你的存储环境长什么样。

1.1 从文件系统到ASM：我看到的性能差距

原来那套库用的是 Ext4 文件系统，底层是 RAID10 做的 LVM。表面上看起来没什么问题，但实际跑起来有几处硬伤：

• 数据文件分布在文件系统上，Oracle 的 DBWR 进程写脏块时，只能由操作系统去做块分配，多会话并发写入时会出现比较明显的等待事件，比如 log file sync 和 free buffer waits 受底层 I/O 波动影响很大。
• 加盘扩容要经过 LVM 的 pvcreate、vgextend、lvextend、resize2fs 一串操作，期间文件系统还得 remount 或者至少 XFS 在线扩容，数据库高峰时段根本不敢动。
• 备份时 RMAN 并发读数据文件，实际上还是在同一组 LVM 逻辑卷里转，带宽被锁死。

换成 ASM 之后，数据文件直接落在磁盘组里，ASM 在分配区（Allocation Unit）层面做了条带化，把读写均匀分布到组里的每一块物理盘上。我用 orion 做过一轮简单压测，同样 8 块 10K 盘，ASM 下的顺序读带宽比原来 Ext4 方案高出一截，最关键的是 db file sequential read 的平均等待时间从原来的 8 到 12 毫秒降到了 3 毫秒左右。

备份窗口缩短更明显。原来一个 600GB 的库做全备要 55 分钟，迁到 ASM 后，RMAN 可以同时读多个磁盘组成员，全备压进了 22 分钟左右。这不是玄学，是 ASM 把 I/O 打散之后带来的直接收益。

1.2 ASM的核心机制：要理解冗余和重平衡

ASM 不是简单的“把裸设备管理起来”的工具，它自己就是 Oracle 的卷管理器加文件系统。几个关键机制需要先搞清楚：

冗余策略

• EXTERNAL REDUNDANCY：冗余交给存储层来做，比如底层已经是 RAID10 或存储阵列做了镜像，磁盘组就不再做副本。坏盘后 ASM 直接降级，适合有硬阵列保护的环境。
• NORMAL REDUNDANCY：ASM 自己做双副本，数据分布在不同的故障组里，底层即使不做 RAID，也能扛住单盘丢失。代价是容量利用率减半。
• HIGH REDUNDANCY：三副本，一般很少用。

我在生产上用的是 NORMAL REDUNDANCY，因为存储本身是 RAID10，理论上用 EXTERNAL 就够了。但考虑到磁盘组里还装了归档日志和闪回区，最终选择了 NORMAL，把底层 RAID 换成 RAID0 条带化来补容量，相当于存储层加 ASM 层双重保护。

自动重平衡

给磁盘组加盘或者删盘时，ASM 会自动启动重平衡（Rebalance），把已有数据从使用率高的盘迁移到新盘上，不需要手动移动任何数据文件。重平衡强度由 ASM_POWER_LIMIT 控制，范围 0 到 11，数值越大迁移越快，但对业务 I/O 的影响也越大。我在线加盘时先设成 4，白天观察负载不高，再提到 6，整个过程没有锁表，业务完全无感知。

1.3 哪些场景其实不适合ASM

别把 ASM 想成万能药。下面这类场景我会明确建议继续用文件系统：

• 单块盘或者根本没有冗余可言的环境，上了 ASM 只会多一层故障点，NAS 或者云盘这种共享存储另说。
• 开发测试用的小库，IO 压力不大，DBA 对 ASM 命令不熟悉，维护起来反而麻烦。
• 公司有强力的集中存储团队，所有快照、复制、灾备都通过存储层做，且分配出来的 LUN 不能直接给 ASM 管理，这种情况下业务压力不大时没必要硬上。

我判断的基准其实就一条：如果这个库的 I/O 瓶颈已经（或即将）影响业务增长，而你又有底层多盘可用的环境，ASM 就值得上。

2. 环境准备阶段容易翻车的细节：内核参数、用户组与存储挂载

到了实施环节，第一件坑我的事居然是操作系统层面。Oracle 18c 起安装包就要求 Linux 的内核、glibc、依赖包都有明确版本要求，漏一个就可能在 runInstaller 阶段报错。环境准备做扎实，后面会顺利得多。

2.1 用户和用户组：grid和oracle为什么必须分离

这是很多新手最容易犯的错——图省事全部用 oracle 用户装完 Grid 再装 Database。短期能用，但后面做集群扩展或者补丁升级时会很痛苦。标准做法是建两个用户、三到四个用户组：

用户	必属用户组	用途
grid	oinstall, asmadmin, asmdba, asmoper	管理 ASM 实例和 Grid Infrastructure
oracle	oinstall, dba, oper, asmdba	管理数据库实例和监听

创建命令大致是：

这样的好处很明确：grid 用户只拥有 ASM 的管理权限，即使被攻破也动不了数据库数据文件；oracle 用户能读写磁盘组但不能改 ASM 磁盘组结构。生产环境最重要的是权限边界。

2.2 内核参数与资源限制：我验证过的可落地方案

/etc/sysctl.conf 里有一组参数是 Oracle 安装前置检查项，缺了对不上会卡在 prereq 校验。我用的这套是 19c 官方文档推荐值，并且在 CentOS 7.9 和 麒麟 V10 上都实测可过：

几个需要注意的点：

• kernel.shmmax 我设置的是物理内存的一半，不是越大越好，超出实际物理内存会导致某些 Linux 版本下 Oracle 分配共享内存失败。
• vm.swappiness = 10 是为了避免操作系统把空闲的 SGA 页交换到 swap，生产库上这个值一旦变成默认的 30 以上，遇到内存压力时性能会非常难看。
• kernel.sem 的第三个值 100 表示信号量最大值，128 是系统范围的最大信号量集数，这两个值低于 Oracle 要求时，数据库进程可能启动失败，日志里只报一个含糊的 semget 错误。

同时还要改 /etc/security/limits.conf：

改完之后别急着往下走，先 sysctl -p 并重新登录一次会话，确认 ulimit -n 和 ulimit -u 已经生效。很多安装失败案例里，问题就出在改完 limits 没重登，Shell 环境还是旧值。

2.3 磁盘分区与UDEV规则：给ASM稳定磁盘身份

ASM 识别磁盘不靠盘符，靠的是磁盘的 UUID 或者 /dev/asm-disk* 这种稳定路径。生产环境我用 UDEV 做绑定，不装 ASMLib。

做法是在 /etc/udev/rules.d/99-oracle-asm.rules 里写入类似下面的规则：

这里 ID_SERIAL 可以通过 udevadm info --query=all --name=/dev/sdb | grep ID_SERIAL 查到。为每块参与 ASM 的盘写一条规则，然后执行：

检查 /dev/asm-data01 是否存在且权限正确。规则里 OWNER 和 GROUP 一点都不能写错，如果写成了 oracle:dba，等 Grid 安装 root.sh 时就会报 ORA-15018 之类找不到磁盘组的错误。国产化系统如麒麟 V10 上同样走这套 UDEV 方案，兼容性没有问题。

3. Oracle 19c从Grid到Database的安装链路

环境准备好之后，正式安装分成两大步：先装 Grid Infrastructure，再装 Oracle Database 软件。这个顺序不能反，因为 Database 软件安装时可能会检查 ASM 环境，没有 Grid 实例在跑，建库步骤就没法选磁盘组。

3.1 安装介质：版本命名与文件校验

Oracle 19c 是企业版 19.3 起发布的，之后的补丁直接通过 OPatch 更新，不需要每年重新下载安装包。下载时认准官方渠道，千万别图方便去搜索“Oracle 19c 夸克网盘下载”之类来路不明的链接。

下载下来是两个 zip 包，解压时会合并成同一个目录，注意观察文件总数是否完整。然后做一次校验：

跟 Oracle 官方文档里列出的校验值比对一致再用。这一步很关键但经常被跳过，一旦介质损坏，安装到一半报 checksum mismatch，排查起来会浪费一整天。

3.2 Grid安装与ASM磁盘组创建：交互选项的含义

Grid 的安装入口是 ./gridSetup.sh，生产单实例环境我推荐的选项是：

• 选择“独立服务器（Standalone Server）”
• 语言保持默认英文即可
• 配置 ASM 磁盘组时创建两个，一个放数据文件（命名 DATA），一个放闪回区和归档（命名 ARCH），不要把两件事混在同一个磁盘组里，后面维护归档清理会麻烦很多。

磁盘组创建时，Oracle 19c 要求指定 AU_SIZE，默认 1MB 对 OLTP 场景合适，数据仓库类型可以设成 4MB。我在订单库上用的是 4MB，因为表比较大、扫描多。确定之前可以用 dbms_space 简单分析一下段大小，超过 1MB 的段占比高时，适当增大 AU 有助于减少跨盘读。

安装过程中会在最后一步要求执行两个 root 脚本：

root.sh 会在集群软件层面注册 CSS/CRS 服务，这个脚本执行失败是最常见的坎，九成原因在前面 UDEV 规则里权限配错或磁盘组里的盘没有全部识别到。如果报错，回到 /var/log/grid 里找 rootcrs_ 开头日志，里面会有可读的失败原因。

3.3 Database软件静默安装：适合生产环境的响应文件方式

图形界面的 runInstaller 虽然直观，但生产环境我更喜欢用静默安装响应文件，原因很简单：可以固化版本，配合后续的自动化审计。数据库软件的响应文件模板在安装介质解压后的 response/db_install.rsp，核心项如下：

然后执行：

结束后同样会提示用 root 执行 root.sh，照做即可。静默安装的优势在于我有完整的可复现记录，后续再上第二套环境时只需要改路径和主机名。

3.4 容器数据库与非容器数据库：19c的建库选择

19c 默认推荐的是 CDB/PDB 形态，也就是容器数据库加可插拔数据库。我把这个结构类比成公寓楼：CDB 是整栋楼的公共设施（参数文件、控制文件、undo），PDB 是里面的一户户住户（用户数据、表空间）。

这个架构带来的直接好处是管理密度提升：多个业务库可以共用一个实例，内存和后台进程共享，备份时还可以按 PDB 单独做。但从实际项目反馈来看，并不是所有业务都能接受这个模式：

• 老应用里写了 ALTER DATABASE 或者依赖某些实例级视图来管理对象，放 PDB 里可能不兼容。
• 开发团队如果习惯于每个环境一套独立监听、独立实例，CDB 模式会改变他们原有的排查习惯。

我们这个订单库最终采用的是 CDB + 单PDB 的结构。原因两条：一是数据库资源需要跟后续其他业务做隔离，PDB 方式登录切换比再起一个实例轻量；二是升级到 19c 后可以享受 PDB 级别的热拔插特性，将来拆分业务不用再迁移整个实例。

建库命令我用的是 DBCA 静默方式：

这里有几个细节：-storageType ASM 后面要跟的磁盘组必须是 Grid 已经建好的，-recoveryAreaDestination 指向 ARCH 磁盘组，否则 DBCA 会在校验阶段直接报错。-totalMemory 我给的是物理内存的 70%，剩下的留给操作系统和 Grid 组件。

4. ASM运维命令与项目落地实战

装完只是开始，真正考验功力的是后面日常操作和数据迁移。这一章我把 ASM 的常用命令和这个订单库实际迁移的过程串起来讲。

4.1 进入ASM环境的三种方式与常用命令

很多新 DBA 不知道 ASM 也有自己的实例，登录方式和普通数据库不太一样。常用方式有三种：

方式一：SQL*Plus 登录 ASM 实例

这种方式要求当前操作系统用户属于 asmadmin 组，通常是 grid 用户。进来后执行 show parameter instance_type 可以看到值是 ASM，跟数据库实例的 RDBMS 区分开。

方式二：ASMCMD 命令行工具

lsdg 查看磁盘组状态和使用率，du 查看目录空间占用，ls 列出 ASM 目录，可以像操作文件系统一样定位数据文件。需要强调一点：ASM 里是不能直接 vi 一个文件的，任何文件访问都必须通过数据库实例或 RMAN 来做。

方式三：ASMCA 图形管理

如果有图形终端，asmca 可以可视化地看磁盘组拓扑、加盘删盘。生产环境没有 X 服务时，顺手用方式一和方式二就够。

常用管理命令我再整理一个速查表：

目标	命令/视图	说明
查磁盘组空间	asmcmd lsdg	看到 USABLE_FILE_MB 才是真实可用空间
查实例状态	crsctl status resource -t	Grid 层面看所有资源在线状态
查数据库状态	srvctl status database -d ORCL	确认数据库是否托管在 CRS 下
加盘到磁盘组	ALTER DISKGROUP DATA ADD DISK ...	在线操作，触发自动重平衡
看重平衡进度	SELECT * FROM V$ASM_OPERATION;	观察 EST_MINUTES 字段
查磁盘故障	SELECT * FROM V$ASM_DISK WHERE HEADER_STATUS='FORMER';	异常盘排障

4.2 迁移项目实战：历史订单库从文件系统搬到ASM

这里说一个完整的迁移链路。源库是 Oracle 11g R2，Ext4 文件系统，目标库是 Oracle 19c ASM。外部环境要求尽量短停机，数据量大约 600GB。

我没有直接用 Data Pump，因为数据量太大，expdp/impdp 方式重建索引和统计信息的时间太长。最终用的是 RMAN 转换格式的方式：

1. 在 11g 源库上用 RMAN 做全备：

2. 把备份集拷贝到 19c 目标服务器。
3. 在 19c 目标库上执行 RMAN 的 RESTORE 和 RECOVER：

关键点：11g 的备份文件不能被 19c 直接读取吗？实际上可以，只要目标库版本更高，RMAN 是支持跨版本恢复的。反过来就不行——19c 备份不能恢复到 11g，这在文章第 5 章还会讲。

4. 恢复完成后，数据库打开时改成 OPEN，并修改临时表空间和数据文件位置。实际上因为目标库已经建好了 ASM 磁盘组，RESTORE 时 RMAN 会自动把数据文件放在设置的 DB_CREATE_FILE_DEST 指向的磁盘组里。

整个过程中有个明显的风险点：RESTORE 到一半如果 ASM 磁盘组空间不足，整个恢复会失败。所以迁移前我确认了 DATA 磁盘组至少有 900GB 可用空间——源库数据文件总大小的 1.5 倍，同时 ARCH 组留出归档日志的大小。

迁移完成后，我在业务低峰期做了一次全量校验：

然后开启应用，观察了一个小时，AWR 报告里物理读 1 秒 3000 次左右，比原来低了近一半，应用侧反馈查询响应明显变快。这里顺便说一句：迁移后性能提升有相当一部分来自版本升级和统计信息重新收集，不要把所有功劳都算在 ASM 头上，但 I/O 分散带来的稳定性和峰值吞吐改善是真实存在的。

4.3 从备份恢复到容灾库：ASM在恢复场景的另一个好处

项目后来又加了一个需求：在另一台服务器上搭一个只读容灾库，用于月底报表取数。数据同步我用的是数据库层面的日志应用，备库数据文件同样放在 ASM 上。

这个过程让我对 ASM 的“管理简单”有了更深的体会。备库数据文件多到几百个，如果放在文件系统上，每次添加数据文件、移动数据文件都要考虑路径、权限、空间。ASM 下只需要指定磁盘组名，文件命名和路径由 Oracle 自己管理，几乎零成本完成存储布局。

具体步骤简单提一下：在目标备库上启一个空实例，用 RMAN 的 DUPLICATE 方式从主库备份创建：

由于主备库数据文件都在 ASM，NOFILENAMECHECK 直接跳过路径检查，DG 的日志应用很快就追平了。这在文件系统时代要手动维护相同的目录结构，ASM 省掉了一大块工作。

5. 生产运维避坑：sysaux暴涨、卸载残留与空间耗尽

上线之后才是真正考验耐心的阶段。生产环境运行半年内我陆续遇到几个问题，每个都是典型的生产级“坑”，单独拿出来复盘。

5.1 sysaux表空间异常增长的定位与处理

第一次收到告警是某天早上：“SYSAUX 表空间使用率 99%”。登录进去一看，已经占用 320GB，而正常情况下 19c 的 SYSAUX 维持在三五十GB算是合理。

我排查的路径一步步说：

1. 先查各占用段的分布：

结果一眼看到 SM/OPTSTAT 和 AWR 两项排最前面，加起来占了 200 多 GB。SM/OPTSTAT 是优化器统计信息的存储，AWR 是快照历史。

2. 查 AWR 快照保留策略：

发现快照保留期被设成了 720 天，间隔 15 分钟。对这套业务来说，一年以上的历史快照基本没人查，纯属浪费空间。

3. 处理：把保留期调整为 30 天，并把未使用的 PDB 快照一并清掉：

4. 清理完再看，SYSAUX 降到 40GB 以内。顺手做了一条规定：以后任何生产变更中，涉及 AWR 保留期的改动必须先过变更评审。

这个问题的深层原因其实是之前测试人员不熟悉 19c 的默认设置，加上某段时间统计信息收集任务频繁失败重试，累积了大量历史。生产监控里对 SYSAUX 的使用率曲线要提前设置阈值，不要等它涨到 95% 才处理。

5.2 卸载Oracle 19c的血泪教训：注册表、目录残留与系统启动项

有次我要在一台测试服务器上把旧环境清掉重装，结果发现路径 /u01/app/oracle 存在大量残留文件，/etc/oratab 里还有旧实例信息，系统重启后 Grid 服务自动拉起了不存在磁盘组的实例，白白占内存。

在 Linux 上卸载 Oracle 虽然没有 Windows 的注册表一说，但下面这些地方不处理干净，重装必出幺蛾子：

• /etc/oratab：记录了实例名和 ORACLE_HOME，重装前要删除对应行。
• /etc/oraInst.loc：记录 inventory 位置，误删后 deinstall 工具就跑不起来了。
• /u01/app/oraInventory：安装清单目录，不删干净会导致新环境“检测到已有 Oracle 主目录”。
• /etc/systemd/system 或 /etc/init.d 里的 dbora、oracle 服务启动脚本。
• 环境变量文件中残留的 ORACLE_HOME、ORACLE_SID、LD_LIBRARY_PATH。

官方提供了 deinstall 工具，路径在 $ORACLE_HOME/deinstall/deinstall，执行后按提示选择本地实例即可。但光靠它还不够，比如 ASM 磁盘组头信息需要手动清理：

这个操作我之前犹豫了很久，因为零覆盖会直接毁掉磁盘上的 ASM 元数据。确认这盘已经不再使用后，执行起来倒也不复杂，关键是前期确认盘符对应关系，别把有用的盘清掉。

如果你问“Oracle 19c 的备份文件能在 Oracle 11g 上恢复出来吗”，答案很直接：不能。Oracle 的备份恢复规则是版本向后兼容，目标库版本必须不低于备份集版本，19c 的备份直接喂给 11g 恢复，RMAN 会明确报 RMAN-20242。存在 11g 环境的团队要注意，切升级前把归档和备份留好，一旦 19c 这边出了问题，至少还有回退路径。

5.3 ASM磁盘组空间耗尽的应急预案

另一个让我出冷汗的问题是归档日志写满磁盘组。某天上午 10 点，应用侧突然报“无法归档日志”，登录数据库一看，ARCH 磁盘组的使用率已经 99%，归档日志还在不断生成。

处理过程：

1. 先用 asmcmd lsdg 确认哪个磁盘组告急，看到 ARCH 组满。
2. 查询归档目录状态：

3. 确认归档日志可以被清理（已做完备份的前提下）：

4. 清理后空间降到 50% 左右，业务恢复。

这个过程中我意识到一个问题：ASM 的 USABLE_FILE_MB 计算里已经扣除了冗余镜像，但很多人看 lsdg 时只看 TOTAL_MB，不看 USABLE_FILE_MB，容易误判“空间还很富余”。从那以后我给自己定了规矩：生产环境磁盘组可用空间至少预留 30%，低于 25% 就要触发告警加盘或清数据。

6. 安全加固与日常巡检的经验清单

安装配置完成后还远没到可以撒手不管的程度。生产环境的安全基线和巡检机制同样重要，这一章我从实操角度谈几件见面就见效的事。

6.1 最小权限与口令策略

生产库最忌讳的就是图省事把账号权限一把梭。我在这个项目里做了几项加固：

• 业务访问账号只赋予 CONNECT 和 RESOURCE 角色，需要写数据的业务单独建账号，按表授予增删改查权限，绝不给 DBA。
• 关闭数据库的远程操作系统认证，REMOTE_OS_AUTHENT=FALSE。
• 启用口令复杂度函数，登录失败三次锁定账号，FAILED_LOGIN_ATTEMPTS=3，PASSWORD_LOCK_TIME=1。
• 定期打 Oracle Critical Patch Update，19c 的季度补丁是安全底线，不能在公网裸奔。

补丁升级要提醒一点：19c 打补丁前最好先跑一遍 opatch prereq CheckConflictAgainstOHWithDetail -ph BaseDir，确认补丁之间没有冲突，再执行 opatch apply。我见过有人在没做预检的情况下直接打 RU，打完监听状态异常，最后又回滚补丁，白白折腾一晚上。

6.2 每周巡检的核心命令组合

我把平日巡检内容整理成一个几十行的 Shell 脚本，每周一早上跑一遍，把输出重定向到文件里，然后快速扫一眼关键指标。

脚本内容大致是：

这套巡检看起来简单，但覆盖了系统负载、ASM 空间、数据库状态、归档量和告警日志几个最容易出问题的维度。每周花五分钟看输出，比出问题后再手忙脚乱强得多。

还有一件容易被忽略的事：控制文件、redo log、闪回区这些关键位置的备份也包含在每周计划里。最好每月做一次从备份恢复到临时环境的演练，我不觉得半年做一次就够，真正遇到灾难时你会发现，只有亲手恢复过，才敢说这套备份方案是靠谱的。

6.3 最后一点经验：每个参数改动都要有“为什么”

这套环境从文件系统迁到 Linux + Oracle 19c + ASM，再到稳定运行，回头看最值钱的不是命令本身，而是每次改动前的思考。生产库最怕“想当然”，改一个参数前问自己三个问题：为什么改、影响范围是什么、怎么回滚。

比如 ASM 重平衡的 ASM_POWER_LIMIT，我白天设 4，晚上设 6，是因为观察过白天的业务高峰和晚上的批处理窗口，不同场景下对 I/O 的容忍度完全不同。直接照搬别人“设成 10”的经验，在 IO 密集型的业务上只会加重负载。

再比如巡检脚本里的 FETCH FIRST 3 ROWS ONLY 这种写法，看起来只是查询语法，实际是在提醒自己：输出结果要小，才能坚持天天看。如果每次巡检输出几百行，人会很快麻木，真正的异常反而被淹没了。

数据库这行的成长路径就是这样：踩坑、复盘、改进巡检，循环往复。希望这篇文章里的思路和命令，能帮你在生产环境部署 Oracle 19c + ASM 时少走几步弯路。如果你在自己的项目里遇到不一样的坑，欢迎带着报错信息来聊，说不定你的经历正好是别人正在找的答案。