生产环境Linux+Oracle 19c+ASM实战：从安装到运维

Oracle 19cASMLinux

于 2026-10-01 08:19:36 修改

·本内容遵循CC 4.0 BY-SA版权协议

生产环境里搞Oracle 19c + ASM，说难不难，说简单也真不简单。很多朋友在测试环境随手装一套能用就行，可一旦放到生产环境，各种细节问题就全冒出来了。这篇博文我就结合自己的实际经验，把Linux + Oracle 19c + ASM这套组合从环境规划、安装配置到项目实战的完整链路掰开揉碎讲清楚，包括每一步为什么要这么做、踩过哪些坑、怎么排查，希望对正在折腾生产库的朋友有实际帮助。

1. 从零开始：看懂生产环境下的技术选型逻辑

1.1 为什么生产环境偏爱 Linux + Oracle 19c + ASM

先说一个很现实的问题：生产环境为什么这么多人选 Linux、Oracle 19c 和 ASM 这个组合？其实说白了就是三个字：稳、快、省。

Linux 作为服务器操作系统，在稳定性、安全性和资源利用率上表现确实出色。相比 Windows Server，Linux 对硬件资源的消耗更低，而且极少需要重启，这对7×24小时运行的生产库来说是硬指标。Oracle 19c 作为 Oracle 数据库的长期支持版本，官方支持周期很长，修复bug和更新补丁都比较及时，是目前企业级生产环境里用得相当广泛的一个版本。

ASM（Automatic Storage Management）这个组件，说白了就是 Oracle 自己的一套“存储管理中间层”。它把多块磁盘统一管理成磁盘组，自动做条带化和镜像，好处是：你不用再依赖操作系统的 LVM 或者 RAID，直接让数据库和存储之间对话。生产库的数据文件、控制文件、日志文件全部放在 ASM 里，性能更好，管理也更简单。

这套组合的另一个优势在于高可用方案的配合。比如 Oracle RAC 集群环境下，ASM 是它的存储底座，Linux 是它最常见的宿主操作系统。即使你现在只装单机版，提前走 ASM 的路线，后续要扩展成 RAC，迁移成本会小很多。

1.2 生产与测试环境的本质区别

很多新手犯的典型错误是：拿测试环境的安装思路去搞生产库，最后搞出一堆隐患。我列个表说明区别：

对比项	测试环境	生产环境
系统资源配置	能跑就行	预留业务增长空间，内存/CPU/磁盘都有规划
存储方案	文件系统直接用	ASM / 裸设备，考虑性能与安全
备份策略	可有可无	必须规划RMAN备份+归档日志策略
变更流程	随意	有变更窗口、回滚方案、风险评审
监控告警	无	有完善的监控和告警机制
安全性	开个端口就行	最小权限、防火墙策略、审计开启

生产环境不是“能装起来”就行，而是“出了问题能兜住”。比如 ASM 磁盘组选 normal redundancy 还是 external redundancy，测试环境无所谓，生产环境你选错了，坏一块盘可能就是灾难。又比如数据库字符集，测试库选错了大不了重建，生产库字符集选错了，后面全是坑。

所以这篇文章我写的所有步骤、配置参数，都是以“生产环境可用”为标准来展开的，而不是那种“演示一下能跑起来”的教学模式。

2. 安装前的关键规划与参数计算

2.1 服务器硬件与操作系统版本规划

先说要准备什么。生产环境建议的最低配置是这样的：

CPU：不低于8核，主频2.0GHz以上，根据业务并发情况调整
内存：至少16GB，32GB或以上比较理想。Oracle 19c 在安装时会检查物理内存，小于1GB会直接挡下来不给装
磁盘：系统盘单独一块（/boot、/、swap分开是基本功），数据库盘另配，如果是 ASM 就用独立的物理盘或 LUN 给 ASM 用
网络：至少两块网卡，一块走业务，一块走管理，生产环境还建议冗余

操作系统版本上，Oracle 19c 官方支持的主流 Linux 发行版包括 RHEL 7.x、Oracle Linux 7.x/8.x、SUSE Linux Enterprise Server 12 SP3+ 等。如果用的是麒麟 V10 这种国产系统，Oracle 19c 安装也能跑，但需要额外注意几个问题，后面我会专门讲到。

我的建议是：如果是正规的生产项目，优先选官方认证的 RHEL/Oracle Linux 版本，别图新鲜用太冷门的发行版。很多问题不是 Oracle 本身的问题，而是操作系统兼容性带来的。

2.2 内存分配、内核参数与 swap 的规划方法

这是很多新手容易忽略的环节。Oracle 的安装前检查有一堆内核参数要求，你如果直接照抄网上的命令，十有八九是过了检查但后端运行隐患一堆。

先说内存。Linux 下 Oracle 19c 的 SGA + PGA 规划，业界常用的经验法则是：

若物理内存小于16GB，SGA 建议分配物理内存的 50% ~ 60%，PGA 分配 15% ~ 20%
若物理内存大于32GB，SGA 建议分配物理内存的 40% ~ 50%，PGA 分配 10% ~ 15%
两者相加不要超过物理内存的 75%，要留出 Linux 操作系统本身和 Page Cache 的余量

举个例子，一台64GB内存的服务器，SGA 给 32GB，PGA 给 8GB，剩下24GB留给 OS 和文件缓存，这个比例在生产环境里是比较稳妥的。

再看内核参数。关键几个我来解释一下为什么要这么设：

kernel.sem 的四个值分别代表信号量相关参数。Oracle 官方建议 kernel.sem = 4096 4096 4096 512，但生产环境大并发场景下建议适当调大，特别是第四个参数 SEMMNS，决定系统能同时持有的最大信号量数量
kernel.shmmni 是系统级共享内存段的最大数量，Oracle 建议设为 4096
kernel.shmall 表示共享内存页的总数，等于内存大小除以页大小。算一下就是：kernel.shmall = 物理内存大小 / 页大小，一般页面大小是4096字节
fs.aio-max-nr 是异步IO请求的最大数目，Oracle 19c 要求至少 1048576
fs.file-max 是文件句柄的上限，生产环境建议 6815744 或者更大

特别注意：Oracle 19c 会检查 kernel.sem 和 fs.aio-max-nr，不满足直接报错。而这些参数改完以后，需要 sysctl -p 重载，并且重启后依然生效需要写入 /etc/sysctl.conf。

swap 方面，Oracle 官方建议 swap 大小根据物理内存来定：2GB~16GB的物理内存，swap等于物理内存大小；16GB以上，swap可以设为16GB或物理内存的一半。但这个标准在云计算环境里很难满足，我的处理方式是：生产环境至少给8GB swap，宁可多给不可不给，避免内存压力触发 OOM。

3. Oracle 19c 与 ASM 的安装配置核心流程

3.1 Linux 系统侧的准备工作

这部分我用清单式的方式罗列，你照着做基本不会漏。

首先创建 Oracle 用户和用户组。生产环境建议这样建：

BASH

groupadd oinstall

groupadd dba

groupadd asmadmin

groupadd asmdba

groupadd asmoper

useradd -g oinstall -G dba,asmadmin,asmdba,asmoper oracle

注意：Oracle 用户的主组是 oinstall，附加组是 dba/asmadmin/asmdba/asmoper。如果你只建了 dba 组，后面装 ASM 时会发现权限不够，很麻烦。

然后建立目录：

BASH

mkdir -p /u01/app/oracle/product/19.0.0/dbhome_1

mkdir -p /u01/app/oracle/oradata

mkdir -p /u01/app/oraInventory

chown -R oracle:oinstall /u01/app

chmod -R 775 /u01/app

这些路径不是随便定的。/u01/app/oracle 是 ORACLE_BASE，/u01/app/oraInventory 存放安装清单，/u01/app/oracle/product/19.0.0/dbhome_1 是 ORACLE_HOME，路径统一有助于后期维护和升级。

接下来是安装依赖包。Oracle 19c 在 RHEL 7 上需要的包非常多，我建议直接用 yum 批量装：

BASH

yum install -y binutils compat-libcap1 compat-libstdc++-33 gcc gcc-c++ glibc glibc-devel ksh libaio libaio-devel libgcc libstdc++ libstdc++-devel libXext libXtst libX11 libXau libXi make sysstat unixODBC unixODBC-devel

如果你用的是麒麟 V10 或其他基于 CentOS/RHEL 的国产系统，rpm -qa 检查依赖时可能会报缺一些包，建议直接搜索 ISO 镜像源里的同名 RPM 包手动装上。这类系统里 compat-libstdc++-33 有时候源里没有，我是从老 CentOS 7 的源里下载编译安装的，可以正常用。

3.2 内核参数、资源限制与环境变量

前面讲了要配置哪些内核参数，这里给出一个完整可用的配置，你可以根据自己的物理内存调整：

INI

# 添加到 /etc/sysctl.conf

fs.aio-max-nr = 1048576

fs.file-max = 6815744

kernel.sem = 4096 4096 4096 512

kernel.shmall = 16777216

kernel.shmmni = 4096

net.core.rmem_default = 262144

net.core.rmem_max = 4194304

net.core.wmem_default = 262144

net.core.wmem_max = 1048576

net.ipv4.conf.all.rp_filter = 2

net.ipv4.conf.default.rp_filter = 2

net.ipv4.ip_local_port_range = 9000 65500

vm.swappiness = 10

注意 kernel.shmall 我写了 16777216，这个值适用于64GB内存的情况（64GB / 4096Bytes = 16777216）。你把 16777216 乘以 4096 再除以 1GB 就是 64GB，根据自己的物理内存去套这个公式。

sema 参数虽然官方推荐是 250 32000 100 128，但生产环境高并发下很容易不够用，所以调大会更稳。vm.swappiness = 10 是为了减少 swap 的使用，避免频繁换页影响数据库性能。

然后是资源限制，修改 /etc/security/limits.conf：

INI

oracle soft nproc 2047

oracle hard nproc 16384

oracle soft nofile 4096

oracle hard nofile 65536

oracle soft stack 10240

oracle hard stack 32768

oracle soft memlock 3145728

oracle hard memlock 3145728

memlock 这个很多人会漏掉。Oracle 19c 在开启 use_large_pages 时，如果 memlock 不够，数据库启动会报错或者性能不佳。我一般是把它设成 SGA 大小的上限（KB 为单位）。

Oracle 用户的环境变量配置 ~/.bash_profile：

BASH

export ORACLE_BASE=/u01/app/oracle

export ORACLE_HOME=$ORACLE_BASE/product/19.0.0/dbhome_1

export ORACLE_SID=ORCLCDB

export PATH=$PATH:$ORACLE_HOME/bin

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib

export TMP=/tmp

export TMPDIR=/tmp

这里特别提醒：ORACLE_SID 在安装前先不用设，或者设一个占位值。安装时会自动创建实例名。

3.3 ASM 实例与磁盘组的创建（核心难点）

ASM 这部分我单独拿出来讲，因为这是最容易翻车的地方。

先说说 ASM 是怎么工作的。简单理解：ASM 实例类似于一个“存储管家”，数据库实例通过它去读写存储在磁盘组里的数据文件。你在操作系统层面看到的裸盘，被 ASM 划归到磁盘组后，Oracle 以自己的方式管理这些空间。

创建 ASM 磁盘之前，在 VMware 或物理机上，你要先给虚拟机加几块磁盘，不要格式化，不要分区，直接原生态裸盘交给 Linux 系统识别。然后通过 lsblk 确认磁盘名称，比如 /dev/sdb、/dev/sdc。

为了让 ASM 能认出这些盘，需要用 oracle 用户身份执行 asmcmd 或者用 oracleasm 工具标记。不过更简单的方式是直接改 /etc/udev/rules.d/99-oracle-asm.rules 文件，设置磁盘的权限和属主：

TEXT

KERNEL=="sdb", OWNER="oracle", GROUP="asmadmin", MODE="0660"

KERNEL=="sdc", OWNER="oracle", GROUP="asmadmin", MODE="0660"

改完之后：

BASH

udevadm trigger

确认权限已生效后，用 oracle 用户连接 ASM 实例（此时 ASM 应该还没创建，稍后安装时一并创建）。

安装 Oracle 19c 的时候，有一个组件选择步骤可以选择“Install Grid Infrastructure”，用来安装 ASM 和集群软件。单机版生产环境不需要 Cluster，只装 ASM 即可。装完 Grid Infrastructure 之后，asmca 命令就能打开图形化界面来创建磁盘组。

磁盘组的三种冗余模式，生产环境怎么选，这里我给出我的建议：

external redundancy：数据只存一份，完全靠外部存储保障，比如用了 SAN 阵列的 RAID。生产环境如果存储层已有 RAID，可以选这个，省空间
normal redundancy：双份镜像，两块盘坏一块不影响。生产环境首选，如果你的 ASM 盘是本地 RAID 或者没有可靠存储保障，务必选这个
high redundancy：三份镜像，空间利用率只有 1/3，一般只有金融、核心交易系统才会用

创建磁盘组的界面里会要求填磁盘组名称、选择成员磁盘、设定冗余级别。起名建议用 DATA（放数据文件）、FRA（放闪回区和归档日志）。另外注意 AU（Allocation Unit）大小，默认 1MB 就行，除非你的是大规模 OLAP 场景，可以调大到 4MB。

3.4 数据库实例创建与初始化参数调优

数据库实例的创建有两种路径：DBCA 图形化工具，或者命令行静默创建。生产环境我建议使用 DBCA，因为它能顺便帮你建好监听器、配置好 EM 等。

在 DBCA 里关键的选择：

选“Create a database with default configuration”还是“Advanced Configuration”？生产建议走 Advanced，能细化很多参数
数据库类型：选“General Purpose or Transaction Processing”还是“Data Warehousing”？OLTP 选前者，分析型可选后者
Storage 选择：必须选 ASM，并指定磁盘组。选文件系统就是走老路，但既然你在生产环境用了 ASM，这里就没有理由选回文件系统
字符集：生产库建议 AL32UTF8，这个选择关乎后面乱不乱码。如果对接老系统，可能需要根据开发需求确认，但 AL32UTF8 是最通用的选择
内存参数：DBCA 会让你选“Automatic Shared Memory Management”还是“Manual”。我的建议是生产环境启用 ASMM（SGA_TARGET），但 PGA 要单独设 PGA_AGGREGATE_TARGET，别全自动

创建完成后，有一些初始化参数需要手工核对：

SQL

-- 查看关键参数

show parameter sga_target;

show parameter pga_aggregate_target;

show parameter db_recovery_file_dest;

show parameter compatible;

show parameter processes;

show parameter open_cursors;

show parameter db_files;

比较关键的是 compatible 参数。Oracle 19c 默认安装后 compatible 是 19.0.0，不要随便调低，因为调低之后某些新特性就用不了，而且调高容易调低难。

processes 默认是 300，生产环境至少要按并发会话数的两倍来设。我经历过一次生产系统因为 processes 不够，导致应用疯狂报 ORA-12520，排查半天才定位到这个问题。建议至少设 1000 或更高。

db_files 默认值是 200，如果你预期数据文件很多（比如分区表每个月一个新表空间），就把这个值调大，比如 500。不然文件数超过限制再扩容就要重启实例，非常麻烦。

4. 项目实战：从数据导入到生产切换的完整过程

4.1 项目背景与实战需求

光说不练假把式。我结合自己做过的一个真实项目来讲——某制造企业的 ERP 系统数据库升级，原库是 Oracle 11g，运行在 Windows Server 2008 R2 上，数据量约 1.2TB。项目要求升级到 19c，运行环境换成 Linux + ASM，业务中断时间窗口只有 4 个小时。

这种场景很有代表性，因为它不只是“装个新库”，还牵扯到数据迁移、兼容性测试、应用适配和切换方案。很多集成商到这一步都会翻车，所以我挑几个核心环节详细讲。

4.2 导出/导入还是跨版本升级

2019年以前的老方法往往是用 exp/imp，或者 Data Pump 来做逻辑迁移。但对 1.2TB 的库来说，逻辑迁移太慢，导出3小时、传输1小时、导入8小时，根本不可能在4小时内完成。

生产环境走跨版本迁移，我更推荐用物理方式：

方法一：用 RMAN 将 11g 的库恢复到一个中转环境，然后用 DBMS_REDEFINITION 或直接升级。缺点是耗时也长
方法二：如果两套库在不同服务器上，网络带宽足够，可以直接在旧库做好 Data Guard，切换时直接 role transition，增量时间极短，可以做到分钟级切换。但我做的这个项目，旧库是 Windows 单机，没开 DG 配置，重新配时间成本太高
方法三（本项目采用）：RMAN 备份恢复 + 增量应用。先用 RMAN 备份 11g 全库，在新环境上 restore 成为 19c 库，然后使用 RMAN CONVERT 或直接打开库后通过 utl_file 导入。实际生产上更推荐直接走 expdp/impdp 的并行方式和数据泵并行度来压缩耗时

我们这个项目最后的方案是折中的：先在线做全库备份，传输到新服务器，RMAN 恢复并升级数据字典到 19c，然后针对业务增量数据，用 expdp/impdp 单独做增量补录。整个过程耗时约 3.5 小时，包含了最后业务侧验证的时间，正正好好赶在窗口内完成。

所以，在实战环节我要强调的一个点：先测好你的迁移时间，再给领导承诺切换窗口。任何没经过演练的评估都是耍流氓，生产切换的紧张程度你真的想象不到。

4.3 实战中的 ASM 磁盘管理与空间预估

1.2TB 的数据量对 ASM 磁盘组规划提出了很高的要求。全库备份加归档日志，到新环境上我规划了两组磁盘：DATA 组 2TB，FRA 组 1.5TB。具体计算方式：

TEXT

DATA 组预估：

数据文件合计：约 1.2TB

同一时间增长余量：20%（基于业务月均增速计算）

镜像冗余开销：normal redundancy 乘以 2

合计：1.2TB * 1.2 * 2 = 2.88TB

但我实际只给了 DATA 组 2TB，因为我的 plan 是 nologging + 部分历史数据不迁移（旧系统已下线了两个历史模块，共约500GB）。这种取舍很关键，业务侧的确认比其他都重要。

FRA 组就是闪回恢复区，需要存放 RMAN 备份、归档日志、闪回日志。我按照“最近3天归档+1份全备+RMAN自动备份”来算：

TEXT

FRA 组预估：

归档日志：每天约 80GB，保留3天 = 240GB

RMAN 全备：压缩后约 700GB

control file / spfile 自动备份：约 2GB

冗余开销：normal redundancy 2倍

合计：(240 + 700 + 2) * 2 = 1884GB

最终给 FRA 组 1.5TB，实际使用约 1.1TB，剩余 400GB 用于后续增长。这个估算方式算是比较合理的。

4.4 数据库打开后的应用适配与性能验证

数据库这侧迁移完成，不代表项目交付了。接下来更麻烦的是应用适配和性能验证。

我们的应用系统中间层通过 JDBC 连接 Oracle，升级到 19c 后有一个很典型的问题：JDBC 驱动版本太旧。旧系统用的 ojdbc6 连 11g 没问题，连 19c 直接报 ORA-28040: No matching authentication protocol。解决方法是升级驱动到 ojdbc8，或者是把数据库的 SQLNET.ALLOWED_LOGON_VERSION_CLIENT 参数调低。

更稳妥的做法是在升级前检查一下应用的数据库驱动版本，结合 19c 的官方兼容性矩阵提前替换。

另一个实际遇到的问题：19c 默认开了 PDB（多租户架构），而旧系统是一个非容器数据库。这涉及到 CDB/PDB 的取舍。生产环境里有时候我们会选择用 PDB 来模拟原来的单库模式，应用连接配置改一点点就能用；但如果你不想上多租户，Oracle 19c 也支持 NON-CDB 模式（虽然官方对 non-CDB 的支持后续版本会弱化）。我个人的做法是：新环境能上 CDB/PDB 就坚决上，理由很简单——未来扩展和资源隔离都方便。

性能验证环节，我们不能只跑通 insert/select 就算完。至少要做这么几件事：

跑一遍核心业务全流程（下单、审核、入账、查询）
跑一版全表扫描类大报表，对比新库与旧库的响应时间
检查 AWR 报告，重点看 Top 5 Wait Events。生产环境 19c + ASM 下，我见过比较常见的等待事件是 cell single block physical read（这是Exadata上的）和 db file sequential read（传统存储），通过调整 db_file_multiblock_read_count 和存储并发策略来改善
观察 ASM 磁盘组的 I/O 吞吐量，确认没有单盘瓶颈

5. 真实环境里踩过的坑与排查经验

5.1 如何彻底卸载 Oracle 19c 并清理干净

这是一个经常被问到的问题，尤其是在 Windows 平台，卸载不干净导致重装失败的情况特别常见。虽然我们的标题是 Linux 环境，但搜这个热点的人非常多，我就一起说了。

Linux 下卸载 Oracle 才是正道。关键步骤是：先停库、再删文件、删用户、清理配置。很多新手只会 rm -rf /u01/app/oracle，这样根本卸不干净。

一套相对完整的卸载步骤：

BASH

# 1. 停止监听和数据库实例

lsnrctl stop

sqlplus / as sysdba

SQL> shutdown immediate;

SQL> exit

# 2. 停止 ASM 实例（如果有）

sqlplus / as sysasm

SQL> shutdown immediate;

SQL> exit

# 3. 使用 deinstall 工具

$ORACLE_HOME/deinstall/deinstall -checkonly

$ORACLE_HOME/deinstall/deinstall

# 4. 清理用户和目录

userdel -r oracle

groupdel oinstall

groupdel dba

rm -rf /u01/app /etc/oraInst.loc /etc/oratab

在注册表层面的问题主要出现在 Windows 平台。Windows 卸载 Oracle 时，光靠控制面板的卸载程序是不够的，还需要：

删除注册表 HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE 相关键值
删除 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services 下所有 Oracle 开头的服务项
删除环境变量里的 ORACLE_HOME、TNS_ADMIN 之类的条目
删除 C:\Program Files\Oracle 目录
删除 C:\Users\用户名\AppData\Local\Temp 下的 Oracle 临时文件

但我想说的是，你在生产 Linux 服务器上一般不会遇到这么脏的清理需求，反而很多装国产系统麒麟 V10 的机器上会遇到依赖问题。麒麟 V10 上装 Oracle 19c 时有几个典型的坑：

pdksh 包在麒麟源里没有，导致安装检查失败。解决办法是用 ksh 替代，创建符号链接 ln -s /usr/bin/ksh /bin/ksh，并安装 ksh 包
compat-libcap1 和 compat-libstdc++-33 在麒麟源里可能版本不匹配，可以手动下载 CentOS 7 的 RPM 强制安装（加 --nodeps --force，但要注意影响）
图形化安装界面中文乱码，一般是缺字体，设置环境变量 LANG=en_US.UTF-8 通常能解决

5.2 sysaux 表空间占用率过高的问题

另一个高频问题：Oracle 19c 的 SYSAUX 表空间占用率异常高。这问题通常不是单一原因，我遇到过的最常见的三类原因：

第一类是 AWR 快照保留时间过长、快照密度过高。默认 AWR 只保留8天，每60分钟采一次。有些同事图省事改了 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS，改成每15分钟一次还保留30天，SYSAUX 能不大吗？

排查语句：

SQL

SELECT occupant_name, space_usage_kbytes

FROM v$sysaux_occupants

ORDER BY space_usage_kbytes DESC;

看哪个组件占得多。如果是 SM/AWR 占大头，那就调整快照策略：

SQL

BEGIN

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(

retention => 43200, -- 保留5天（单位：分钟）

interval => 60, -- 每小时一个快照

topnsql => 50

);

END;

有时候光是调整策略还不够，你还需要手动清理老快照：

SQL

BEGIN

DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(

low_snap_id => 1,

high_snap_id => 500,

dbid => 1234567890

);

END;

第二类是审计日志（Audit Trail）爆了。19c 默认开启统一审计，如果审计记录大量写入 SYSAUX，增长速度非常快。我之前接手过一个库，跑了不到一个月，SYSAUX 直接干到 70GB。清理方法是：

SQL

-- 查看审计表大小

SELECT table_name, num_rows, blocks*8/1024 size_mb

FROM dba_tables

WHERE table_name LIKE 'AUD$%';

如果确认是审计日志占空间，可以关闭不必要的审计策略，或者把审计日志挪到独立表空间。有一条很实用的经验：生产库对外部登录失败的审计是必要的，但不要开对内部应用账号的详细 SQL 审计，不然空间和性能都在烧钱。

第三类是优化器统计信息历史表（WRI$_OPTSTAT_HISTORY）过大。Oracle 19c 默认会保存统计信息的历史记录，如果频繁跑 DBMS_STATS.GATHER_TABLE_STATS，历史累积也很大。清理方式：

SQL

BEGIN

DBMS_STATS.PURGE_STATS(sysdate - 30);

END;

我建议在你排查空间问题时，用这个终极 SQL 一次性列出各组件占用：

SQL

SELECT occupant_name, space_usage_kbytes/1024/1024 AS size_gb

FROM v$sysaux_occupants

ORDER BY space_usage_kbytes DESC;

对着结果逐个击破就好了。

5.3 从 ASM 中读取数据库及进入 ASM 实例的常用命令

进入 ASM 实例这个问题，问的人也不少。简单说一下：

BASH

# 以 oracle 用户登录

sqlplus / as sysasm

as sysasm 和 as sysdba 是有很大区别的。只有 sysasm 权限才能管理磁盘组、创建/删除 ASM 实例；sysdba 进 ASM 实例其实很多管理命令都不能执行。

进入后常用命令：

SQL

-- 查看磁盘组信息

SQL> set linesize 300

SQL> col name format a10

SQL> select group_number, name, type, total_mb, free_mb, state from v$asm_diskgroup;

-- 查看磁盘状态

SQL> select group_number, disk_number, name, path, total_mb, free_mb, mount_status, state from v$asm_disk;

-- 查看 ASM 实例的告警日志

SQL> show parameter background_dump_dest;

ASM 磁盘有时会遇到磁盘被 dismount 或者 offline 的情况，重新挂载磁盘组的命令：

SQL

SQL> alter diskgroup DATA mount;

另外用命令行控制 ASM 也更实用：

BASH

asmcmd

ASMCMD> ls /u01/app/oracle/oradata

ASMCMD> du -sh DATA

ASMCMD> lsdg

ASMCMD 中的 lsdg 查看磁盘组使用情况非常直观。

5.4 备份文件兼容性：19c 备份能否恢复到 11g

这个问题也特别多：19c 的备份文件能不能恢复到 11g 上？答案是明确的：不能。原因在于 Oracle 数据库的备份和恢复机制是“向下兼容，向上不兼容”的。简单说，11g 备份可以恢复到 19c，19c 备份不能恢复到 11g。

具体来说：

RMAN 备份集的格式和内容受数据库版本影响，高版本备份的低版本数据库无法识别
数据文件块版本不同，低版本数据库无法处理更高版本的数据文件头
控制文件的格式也不兼容

如果确实需要从 19c 回退到 11g（虽然这种事最好别发生），只能走逻辑导出：

BASH

expdp system/xxx@ORCLCDB schemas=xx directory=DATA_PUMP_DIR dumpfile=xx.dmp logfile=xx.log

在 11g 上执行：

BASH

impdp system/xxx@ORCL schemas=xx directory=DATA_PUMP_DIR dumpfile=xx.dmp logfile=xx.log

但要注意：如果 19c 里用了 11g 不支持的新特性（比如 12c+ 的多租户 PDB、新版本的数据类型），逻辑导入到 11g 也有风险。所以生产环境升级前，一定要把回退方案的细节提前验证清楚，别等到切换时才发现退不回去。我见过不止一次因为回退不了被迫熬夜做数据修复的惨痛案例。

5.5 进入 ASM 的权限与登录认证问题

还有一类很常见的问题是：明明装了 Grid Infrastructure，但 sqlplus / as sysasm 进去报 ORA-01031: insufficient privileges。这种情况排查思路是：

先确认操作系统用户所在的组是否正确：

BASH

id oracle

必须包含 asmadmin 组，因为拥有 sysasm 权限的前提是你属于 asmadmin 组。如果只属于 dba 组，你只能以 sysdba 登录，很多 ASM 管理命令执行不了。

其次确认 ORACLE_SID 是什么。ASM 实例的 SID 默认是 +ASM，如果没设置 ORACLE_SID，直接 sqlplus / as sysasm 有可能会去连数据库实例而不是 ASM 实例。所以进入 ASM 之前，建议执行：

BASH

export ORACLE_SID=+ASM

sqlplus / as sysasm

注意 +ASM 前面的加号不能丢，这是 ASM 实例的命名规范。把它写进 Grid Infrastructure 用户的 .bash_profile 里就不会搞混了。

6. 生产环境的日常运维与监控建议

最后我多说几句运维侧的东西。装好一套环境不是结束，而是开始。生产环境的数据库运维，我一般会做好这几件事：

每天检查的地方：

查 ASM 磁盘组使用率，低于20%空闲就要开始规划扩容了
查告警日志中是否有 ORA- 错误
查监听日志是否被爆破尝试（大量无效连接）
查看备份日志是否成功完成

每周检查的地方：

数据库 AWR 报告，重点关注 Top SQL、Top Wait Events
ASM 磁盘性能，查看 v$asm_disk_iostat
归档日志的产生量趋势，提前估算空间
数据库启动后的运行时长、进程数是否异常

监控工具方面，如果团队预算不足，最简单的方案就是用 Oracle 自带的 Enterprise Manager (EM Express)，从 12c 开始默认启用，端口 5500，浏览器直接访问就很方便。如果团队规模稍大，建议用 Zabbix + Orabbix 模板来监控数据库层的存活、表空间、备份状态等指标。

备份策略这块是最不该省的钱。生产环境强烈建议：

开启归档模式，并将 DB_RECOVERY_FILE_DEST_SIZE 设置到位
RMAN 每日增量备份（Level 0 每周一次，Level 1 每日一次）
控制文件和 spfile 自动备份必须开
备份完成后异地拷贝一份（从 ASM 拷贝到另一台存储服务器或对象存储）
每季度至少做一次恢复演练，别等出事了再测恢复流程行不行

我见过太多事故，不是没做备份，而是备份做了但从没恢复过，真要恢复了才发现备份数据损坏或路径对不上。做一次恢复演练一小时，出一次事故通宵一周，这笔账每个 DBA 都得算清楚。

7. 这套技术组合的扩展方向：从单机走向集群与云化

在生产环境跑熟了单机版 19c + ASM 之后，你会自然而然地思考一个问题：接下来怎么扩展？

一个很自然的演进路径是：单机 ASM → RAC 集群。由于你在单机阶段已经使用 ASM 存储，后续扩展 RAC 会顺畅很多，因为 ASM 本身就是共享存储架构。RAC 环境下，ASM 依然承担存储管理职责，而且集群件（GI）会提供节点间的心跳检测和故障转移能力。Linux + Oracle 19c RAC + ASM 是很多企业核心系统的标配，无论是在物理机还是虚拟化环境，这套组合都是经过验证的。

另一个方向是云化。Oracle 19c 现在可以跑到公有云（如阿里云、腾讯云的 Oracle RDS），也可以跑在 OCI（Oracle Cloud Infrastructure）的 Exadata 服务上。云化之后，很多运维细节（存储扩容、备份）会由云平台接管，但对 DBA 的技能要求变成“懂架构设计和成本核算”为主。不过即使上了云，ASM 这个底层逻辑也依然存在——云上的 Exadata 服务底层就是 ASM + 智能存储。

我给朋友的建议是：如果你想长期在数据库这个圈子里深耕，Linux + Oracle 19c + ASM 这个组合非常值得花时间学好。它既是传统企业级数据库的标杆组合，也是通向 RAC、Data Guard、Exadata 这些更高阶技术的基础。别怕麻烦，把安装文档做收敛、把每一类问题记录成自己的排查手册，这些东西在未来五年内都会是你的核心竞争力。

最后再分享一个我个人的习惯：每次在生产库做完变更，我都会把变更步骤、遇到的问题、排查过程、修复方法整理成一份带时间线的文档归档。这个习惯说不上多高大上，但真的能救命——半年后你接到一个类似的变更需求，打开这份文档就能省掉至少一半的踩坑时间。希望这篇关于 Linux + Oracle 19c + ASM 的经验分享也能成为你自己的“排雷手册”里的一页。