Linux生产环境Oracle 19c+ASM部署全流程指南

Oracle 19cLinuxASM

于 2026-10-01 07:58:48 修改

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

我不是第一次在 Linux 上装 Oracle 数据库了，但每次拿到一套新的生产环境需求，从“要不要用 ASM”“磁盘怎么规划”“容器数据库还是非容器”一路磨到最终上线，还是有很多值得复盘的地方。这篇文章所对应的这套环境，就是我最近完成的一套生产级部署——Linux 上装 Oracle 19c，存储层走 Oracle 自家的 ASM（自动存储管理），从系统参数调整、Grid Infrastructure 安装、ASM 磁盘组创建，到数据库实例搭建、项目库表设计，再到备份恢复和日常运维，完整跑了一遍。标题里的 FGMT03 是我们内部项目命名，不重要，重要的是这条链路里踩过的坑、验证过的方案，值得系统性拆出来给同样在做数据库实施的同学参考。

网上关于 Oracle 19c 安装的教程并不少，但大多数停留在“图形界面点下一步”的演示层面，真正到了生产环境，要面对的往往是静默安装、磁盘权限、跨平台兼容、版本选择这类硬问题。所以这篇文章不会只讲“怎么点”，而是把每一步背后的为什么讲透，把你可能踩到的坑提前摆出来。适合的人群大概是：正在准备 Linux 环境下部署 Oracle 的 DBA、运维工程师，以及做数据库课程设计或项目实战的学生——尤其是那种“课设题目写着生产环境部署，但还没搞明白生产环境到底和测试环境差在哪”的同学。

1. 生产部署前的方案选型与环境规划

1.1 为什么选 Linux + Oracle 19c + ASM 这套组合

先说选型。生产环境选数据库技术栈，第一原则不是“最新”，而是“足够稳定、足够成熟、有人验证过”。Oracle 19c 属于 12.2 体系之后的长期支持版本，补丁支持周期长，功能上也稳定，是目前企业级环境里性价比很高的一代。相比起 18c 这种过渡版本，19c 更“抗造”，这算是我在实际项目中比较深的一个体会。

操作系统的选择上，Linux 在数据库承载场景里已经是绝对主流，无论 RHEL、CentOS 还是国产的麒麟等系统，内核层面都能满足 Oracle 的部署要求。相比 Windows 环境，Linux 在稳定性、资源利用率和远程运维方面优势明显，这也是生产环境大多选 Linux 的根本原因。

然后是 ASM。很多刚接触的人会问：现在 Linux 本身就有 LVM、有 ext4、xfs，为什么还要单独搞一个 ASM？我的理解是这样的：ASM 是 Oracle 自己的卷管理器和文件系统二合一方案，它把多块物理磁盘聚合成磁盘组，数据文件、控制文件、日志文件都由 ASM 来管理，等于把存储层完全收归数据库统一调度。它的核心价值在于三点：一是条带化与负载均衡，二是镜像冗余，三是扩展和管理方便。如果你用文件系统直接放数据文件，那么“文件系统满了”“跨主机迁移磁盘挂载乱了”“单块盘性能成了瓶颈”这些事就得自己一项一项去处理，而在 ASM 模式下，这些事都被收拢到数据库自治体系内。

我之前也做过用 ext4+ASM 组合的环境，起点只是“ASM 磁盘组放 OCR 和投票文件，数据文件放普通文件系统”，生产上后来发现跨主机迁移、备份恢复都特别别扭，因为文件系统层面的路径和 ASM 内部路径两套逻辑同时存在，管理成本直接翻倍。所以这轮部署我直接确定了一个原则：数据文件、控制文件、联机日志、归档日志、闪回日志全部放进 ASM，操作系统层面只保留软件安装目录和网络配置。

1.2 主机与磁盘分组规划

生产环境的规划阶段，最怕拍脑袋。我一般会先画一张“环境拓扑表”，把主机角色、OS 版本、内存、磁盘用途、IP 规划全部列清楚。下面是我这次部署用的一个简化模板，你可以直接套用：

项目	配置说明
主机角色	数据库单节点，运行 Grid Infrastructure + Oracle 19c
操作系统	RHEL 系 Linux（内核 3.10+），生产建议 7.x 或兼容版本；国产环境可用麒麟 V10
内存	至少 16 GB，建议 32 GB；生产按业务峰值评估
CPU	8 核以上
系统盘	120 GB SSD（/，/u01 分开挂载）
ASM 数据盘	数据盘 2 块（如 500G 每块）
ASM 恢复盘	恢复盘 1 块或 2 块（如 500G 每块）
网络	业务网、心跳网分离；生产建议多网卡绑定

磁盘组的规划是整个 ASM 设计的核心。Oracle 官方推荐的组合一般是这样：

磁盘组	用途	冗余策略	说明
OCR_VOTE	存储 Clusterware 的 OCR 和投票文件	Normal 冗余（至少 3 个盘）	单节点也建议建，避免单点故障
DATA	数据文件、控制文件、联机日志	Normal 冗余或 External	看你对数据冗余的要求
FRA	快速恢复区、归档日志、闪回日志	External 或 Normal	容量建议为数据库整体大小的 1.5 倍以上

不同人的规划习惯会有差异，但有几个原则是通用的：OCR/VOTE 所在的磁盘组不要和数据磁盘组混在一起，原因很直接——如果混在一个磁盘组，数据文件把空间占满了，OCR 的写入也会受影响，严重时可能导致集群资源异常；另外，同一磁盘组内的物理磁盘尽量保持同型号、同容量、同转速，不然 ASM 做条带化时性能会以最低的那块盘为短板。

1.3 系统分区与目录设计

目录规划说得直白一点就是“别让所有东西挤在一个分区”。Oracle 安装软件、Grid 安装软件、oracle 用户家目录、数据库文件（如果走文件系统调试）、共享存储挂载点，这些都应该尽量独立。我这次的环境是把 / 分区和 /u01 单独分开了，/u01 用来放 Oracle 软件和 Grid 软件，数据类文件全部交给 ASM。

推荐目录结构如下：

路径	用途
/u01/app/grid	Grid Infrastructure 软件的 ORACLE_BASE
/u01/app/19.0.0/grid	Grid 软件的 ORACLE_HOME
/u01/app/oracle	Oracle 数据库软件的 ORACLE_BASE
/u01/app/product/19.0.0/dbhome_1	Oracle 数据库软件的 ORACLE_HOME
/u01/app/oraInventory	Oracle 统一安装清单目录

为什么 ORACLE_BASE 和 ORACLE_HOME 要分开？因为这样做的最大好处是便于版本升级和回滚。如果未来要升级数据库软件，可以新装一个 ORACLE_HOME，切换环境变量即可，旧版本的原封不动留在原目录里。这一点在实际运维中非常重要，尤其是生产环境做小版本升级时，回滚方案往往就靠这个目录隔离来兜底。

2. Linux 基础环境与安装前检查

2.1 内核版本与依赖包检查

不管你是装 Grid 还是装 Oracle Database，安装前第一步永远是检查系统环境。Oracle 的安装程序（OUI）有预检查机制，但你绝不能等它检查才发现缺了几十个包。“先手动确认基础环境一次过”是省时间的关键。

系统版本检查，直接来看：

BASH

cat /etc/os-release

uname -r

如果你用的是 RHEL 7 或 CentOS 7 这类系统，Oracle 19c 官方要求的内核是 3.10.0 以上。国产化环境（如麒麟 V10）也是基于主流 Linux 内核做的，一般都能满足，但要注意架构是 x86_64 还是 ARM，Oracle 19c 对 ARM 架构的支持情况和 x86 不同，这一点提前确认清楚。

接下来是依赖包。Oracle 19c 的依赖包清单比 11g 时代精简了不少，但有几个包还是老面孔：binutils、gcc、gcc-c++、glibc、glibc-devel、ksh、libaio、libaio-devel、libX11、libXau、libXi、libXtst、libXrender、make、net-tools、sysstat。这些包一条命令装齐：

BASH

yum install -y bc binutils compat-libcap1 compat-libstdc++-33 gcc gcc-c++ \

glibc glibc-devel ksh libaio libaio-devel libX11 libXau libXi libXtst \

libXrender libXrender-devel make net-tools sysstat smartmontools

有些老教程会提到 compat-libstdc++-33，19c 下不一定强制，但装了也不会有副作用。国产系统如果自带的软件源里缺这个包，可以从系统安装镜像的 packages 目录里找对应的 rpm 用 rpm -ivh 装上。我自己遇到过几次“卡在预检查缺包”的情况，基本都是这些老包版本名不一致导致的，解决办法就是在官方文档的对应系统版本章节找到精确包名，然后逐一安装。

2.2 用户、组与目录权限设计

Oracle 的权限模型很严格，Grid 和 Oracle Database 要分别用不同的操作系统用户来运行。最少需要两组用户：

用户名	所属组	用途
grid	oinstall, asmadmin, asmdba, asmoper	运行 ASM 实例和 Clusterware
oracle	oinstall, dba, oper, asmdba	运行数据库实例

这里有一个很多新手容易绕晕的点：为什么 oracle 用户也要加入 asmdba 组？因为数据库实例需要访问 ASM 磁盘组里的数据文件，而 ASM 实例对磁盘的访问权限是通过 asmdba 组来控制的。oracle 用户不在 asmdba 组里，数据库启动时就可能报 ORA-15077 或权限相关的错误。

创建用户和组的命令并不复杂：

BASH

groupadd oinstall

groupadd dba

groupadd oper

groupadd asmadmin

groupadd asmdba

groupadd asmoper

useradd -g oinstall -G asmadmin,asmdba,asmoper grid

useradd -g oinstall -G dba,oper,asmdba oracle

目录权限方面，/u01 要求属主是 grid:oinstall，权限 755，然后 /u01/app/oraInventory 属主 grid:oinstall。安装软件时如果权限不对，OUI 会直接报“Inventory 目录不可写”之类的错误。生产环境建议安装前就建好目录并赋权：

BASH

mkdir -p /u01/app/grid

mkdir -p /u01/app/19.0.0/grid

mkdir -p /u01/app/oracle

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

mkdir -p /u01/app/oraInventory

chown -R grid:oinstall /u01

chmod -R 775 /u01

2.3 内核参数与资源限制调优

Linux 内核参数直接关系 Oracle 能不能正常启动、能跑多稳。调优不是越多越好，关键参数到位即可。下面是我这次环境里的 /etc/sysctl.conf 核心配置：

BASH

fs.aio-max-nr = 1048576

fs.file-max = 6815744

kernel.sem = 250 32000 100 128

kernel.shmmni = 4096

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

vm.swappiness = 10

vm.dirty_background_ratio = 3

vm.dirty_ratio = 15

这些参数里最值得解释的是 kernel.sem 和 vm.swappiness。kernel.sem 的四个数字分别表示信号量集最大值、系统范围内信号量最大值、每个信号量集的信号量个数、系统范围内信号量的组数。Oracle 的进程间通信大量依赖信号量，这个值设小了，实例启动时可能报 ORA-27154 之类的问题。vm.swappiness 表示系统使用交换分区的“意愿”，数据库服务器建议调低到 10 以下，别让操作系统动不动就把进程换到 swap 里。

修改后记得执行：

BASH

sysctl -p

资源限制方面，/etc/security/limits.conf 里需要追加：

BASH

grid soft nproc 2047

grid hard nproc 16384

grid soft nofile 1024

grid hard nofile 65536

grid soft stack 10240

grid hard stack 32768

oracle soft nproc 2047

oracle hard nproc 16384

oracle soft nofile 1024

oracle hard nofile 65536

oracle soft stack 10240

oracle hard stack 32768

nofile 是文件描述符上限，nproc 是进程数上限。数据库在高峰期会同时打开大量数据文件和日志文件，文件描述符不够会产生“ORA-01116/ORA-01110”这种报错，排查起来会很烧脑。设置完成后，用 ulimit -n 和 ulimit -u 检查是否生效。

2.4 /dev/shm 与 tmpfs 的调整

/dev/shm 是 Linux 上的共享内存临时文件系统，Oracle 内存管理会用到。很多 Linux 默认的 /dev/shm 只有物理内存的一半，生产环境可能偏小。我在正式安装前会检查一下：

BASH

df -h /dev/shm

如果偏小，可以在 /etc/fstab 里修改 tmpfs 的大小，比如机器物理内存 32GB，给 /dev/shm 分配 16GB：

BASH

tmpfs /dev/shm tmpfs defaults,size=16G 0 0

这里提醒一下，如果数据库启用的是 AMM（Automatic Memory Management），并且 MEMORY_TARGET 设置得比较大，而 /dev/shm 不够大，实例启动时可能报 ORA-00845: MEMORY_TARGET not supported on this system。生产环境我更推荐使用 ASMM（Automatic Shared Memory Management），即只设置 SGA_TARGET 和 PGA_AGGREGATE_TARGET，让数据库在内部自动调 SGA 组件大小，而不是依赖操作系统共享内存文件系统来分配全部内存。这样在重启动、数据库迁移和内核参数调整时都更省心。

3. Grid Infrastructure 与 ASM 实例搭建

3.1 静默方式安装 Grid Infrastructure

拿到 Oracle 19c 的 Grid 安装包（一般是 linuxx64_19c_grid_home.zip），先解压到 /u01/app/19.0.0/grid 目录。Grid 的安装分两种典型路径：一种是用图形界面跑 gridSetup.sh，另一种是静默方式。生产环境我强烈推荐静默方式，原因很简单：图形界面在远程服务器上要么需要折腾 X11 转发，要么会因为缺图形库直接罢工。

静默安装需要准备一个响应文件，关键片段如下：

BASH

oracle.install.responseFileVersion=/oracle/install/rspfmt_crsinstall_response_schema_v19.0.0

oracle.install.option=CRS_CONFIG

ORACLE_BASE=/u01/app/grid

ORACLE_HOME=/u01/app/19.0.0/grid

oracle.install.asm.OSDBA=asmdba

oracle.install.asm.OSOPER=asmoper

oracle.install.asm.OSASM=asmadmin

oracle.install.crs.config.scanName=

oracle.install.crs.config.gpnp.scanName=

oracle.install.crs.config.ClusterConfiguration=STANDALONE

oracle.install.crs.config.clusterName=

oracle.install.crs.config.clusterNodes=

oracle.install.crs.config.networkInterfaceList=

oracle.install.asm.SYSASMPassword=你的密码

oracle.install.asm.diskGroup.name=DATA

oracle.install.asm.diskGroup.redundancy=NORMAL

oracle.install.asm.diskGroup.AUSize=4

oracle.install.asm.diskGroup.disks=/dev/asm-disk1,/dev/asm-disk2

oracle.install.asm.diskGroup.diskDiscoveryString=/dev/asm-*

需要说明的是，单节点部署时，ClusterConfiguration 选择 STANDALONE 即可，不需要配置 SCAN 和心跳网络。响应文件里的密码只是部署生成时用，生产环境后续应通过 orapwd 单独维护。

执行安装：

BASH

cd /u01/app/19.0.0/grid

./gridSetup.sh -silent -responseFile /home/grid/grid_install.rsp

安装过程中会有 root 脚本需要以 root 身份执行。这个脚本什么时候运行一般会有提示，常见的是在安装进度到 53% 左右会提示“执行 /u01/app/19.0.0/grid/root.sh”。用 root 执行：

BASH

cd /u01/app/19.0.0/grid

./root.sh

root.sh 执行时会创建 /etc/oracle 目录、配置 OCR 等关键资源，如果这一步漏了或者提前执行，后续 ASM 实例会起不来。

安装完成后，检查 Grid 服务状态：

BASH

crsctl check crs

crs_stat -t

如果输出显示 crsd、cssd、evmd 进程都处于 online 状态，说明集群资源这一层是健康的。

3.2 ASM 磁盘组创建与初始化

Grid 装完，并不意味着磁盘组已经建好了。这一步要决定 ASM 能“看到”哪些物理磁盘。两种常见的磁盘绑定方式是 asmlib 和 udev 规则。Linux 环境下 asmlib 需要额外安装 oracleasmlib 和 kmod-oracleasm 包，而 udev 是系统自带机制，更通用。我这次用的是 udev 方式。

udev 规则绑定磁盘的示例，放在 /etc/udev/rules.d/99-oracle-asm.rules 里：

BASH

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

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

注意把盘符替换成你自己的实际设备名。绑定后重载规则并检查：

BASH

udevadm control --reload-rules

udevadm trigger

ls -l /dev/sdb /dev/sdc

随后用 asmca 或 sqlplus 的方式创建磁盘组。命令行下创建磁盘组也很方便：

SQL

CREATE DISKGROUP DATA NORMAL REDUNDANCY

DISK '/dev/sdb' NAME DATA01,

'/dev/sdc' NAME DATA02

ATTRIBUTE 'compatible.asm'='19.0', 'compatible.rdbms'='19.0';

创建时有两个兼容性参数很关键：compatible.asm 表示这个磁盘组能支持的最低 ASM 版本，compatible.rdbms 表示允许访问该磁盘组的数据库版本。如果这两个参数设得过高，低版本的数据库实例就无法使用这个磁盘组。同一个 ASM 实例下可以同时有不同兼容级别的磁盘组，这为混合版本环境提供了灵活性。

创建完成后，用 asmcmd lsdg 验证：

BASH

asmcmd lsdg

正常输出会列出磁盘组名称、冗余级别、总大小、空闲大小等。看到状态是 MOUNTED，再继续下一部分。

3.3 常用 ASM 运维命令速查

生产环境里你不可能总是打开 asmca 图形界面去看磁盘组状态，命令行才是常态。很多刚接触 ASM 的人一头雾水，不知道“怎么进 ASM 实例”。实际上进入 ASM 实例非常简单：

BASH

su - grid

. oraenv

# 提示输入 ORACLE_SID 时，输入 +ASM

sqlplus / as sysasm

注意，管理 ASM 实例要用 sysasm 权限，不是 sysdba。sysasm 权限级别高于 sysdba，是专门为 ASM 管理设置的。

asmcmd 命令行的常用操作：

BASH

asmcmd lsdg # 查看磁盘组信息

asmcmd lsdsk # 查看磁盘信息

asmcmd lspw # 查看密码文件信息

asmcmd lsct # 查看磁盘组客户端

asmcmd cp # 在 ASM 磁盘组与文件系统之间复制文件

asmcmd du # 统计目录空间使用

平时做巡检，我最常用的组合就是先 asmcmd lsdg 看空间使用率，再 asmcmd lsct 看哪些实例挂载了磁盘组，期间如果发现有磁盘组状态异常，再用 crsctl status res -t 去查集群资源的运行情况。ASM 实例的 alert 日志也值得日常多看一眼，路径一般在 $ORACLE_BASE/diag/asm/+asm/+ASM/trace/alert_+ASM.log。

3.4 监听器配置与检查

Oracle 的监听器是客户端连接数据库的第一道门。Grid 安装后一般会自动创建监听器，但有些环境会因为网卡名、主机名解析问题导致监听器异常。生产环境建议用 netca 的静默模式重新配置一下：

BASH

netca -silent -responsefile /home/grid/netca.rsp

配置完成后，检查监听状态：

BASH

lsnrctl status

如果监听正常，你会看到类似“Service RUNNING”的信息，并且至少有一个“DEDICATED”服务名。这里提醒一点：生产环境的监听日志默认是无限增长的，长时间不清会导致 /u01 或者对应日志目录被写满。建议在监听配置项里加上诊断日志轮转参数，或者定时任务定期按日期切割监听日志，这个细节很多环境都容易忽略。

4. Oracle 19c 数据库实例创建与项目库结构设计

4.1 安装 Oracle Database 19c 软件

Grid 环境健康运行后，第二步就是安装数据库软件本体。这步同样建议用静默方式。先将数据库安装包解压到目标目录，然后准备 db_install.rsp 响应文件：

BASH

oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v19.0.0

oracle.install.option=INSTALL_DB_SWONLY

ORACLE_BASE=/u01/app/oracle

ORACLE_HOME=/u01/app/product/19.0.0/dbhome_1

oracle.install.db.InstallEdition=EE

oracle.install.db.OSDBA_GROUP=dba

oracle.install.db.OSOPER_GROUP=oper

oracle.install.db.OSBACKUPDBA_GROUP=dba

oracle.install.db.OSDGDBA_GROUP=dba

oracle.install.db.OSKMDBA_GROUP=dba

oracle.install.db.OSRACDBA_GROUP=dba

执行安装：

BASH

cd /u01/app/product/19.0.0/dbhome_1

./runInstaller -silent -responseFile /home/oracle/db_install.rsp

同样，会有一次 root 脚本需要执行：

BASH

cd /u01/app/product/19.0.0/dbhome_1

./root.sh

装完软件后，oracle 用户的环境变量要配置好。编辑 ~/.bash_profile：

BASH

export ORACLE_BASE=/u01/app/oracle

export ORACLE_HOME=/u01/app/product/19.0.0/dbhome_1

export ORACLE_SID=PROD

export PATH=$ORACLE_HOME/bin:$PATH

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

这里 ORACLE_SID 的值取决于你要建的库名，通常和生产项目名对应。配置后 . ~/.bash_profile 让环境变量立即生效，然后验证：

BASH

sqlplus / as sysdba

如果出现 SQL*Plus 的提示符，说明软件安装成功，oracle 用户的环境是通的。

4.2 容器数据库还是非容器数据库的抉择

Oracle 19c 默认推荐的是 CDB/PDB 容器架构，但生产环境到底用不用 CDB，这真是个值得掰扯的问题。我的观点是：按业务场景来，别盲从。

对比项	容器架构（CDB/PDB）	非容器架构（传统）
管理粒度	多个 PDB 共享一个 CDB，补丁、备份可统一管理	一个实例一个数据库，管理独立
资源隔离	PDB 之间需要额外配置资源管理	天然隔离，互不影响
运维复杂度	需要理解 PDB 概念，部分运维脚本要适配容器	传统运维经验直接可用
适合场景	多套业务系统合并部署、云环境多租户	单业务系统强隔离、项目级独立库

这次项目里的业务就是一套相对独立的业务系统，没有多租户需求，我直接选择了非容器架构。创建命令参考：

BASH

dbca -silent -createDatabase \

-templateName General_Purpose.dbc \

-gdbname PROD \

-sid PROD \

-sysPassword '你的强密码' \

-systemPassword '你的强密码' \

-datafileDestination '+DATA' \

-recoveryAreaDestination '+FRA' \

-totalMemory 16384 \

-emConfiguration NONE \

-storageType ASM \

-characterSet AL32UTF8 \

-createAsContainerDatabase false

有个实践心得：dbca 的 -totalMemory 参数是总内存值，内部会自动分配 SGA 和 PGA。如果你对内存策略有更细致的诉求（比如 SGA 给多大、PGA 给多大），我建议 dbca 创建时先用一个初始值，建完库后再用 ALTER SYSTEM 调整，这样更精准。

4.3 关键初始化参数与内存策略配置

库建完之后，第一步就是检查核心初始化参数。用下面这条命令看当前值：

SQL

SELECT name, value, isdefault FROM v$parameter WHERE name LIKE '%memory%' OR name LIKE '%sga%' OR name LIKE '%pga%';

生产环境我一般这样设：SGA_TARGET 设为物理内存的 50% 左右，PGA_AGGREGATE_TARGET 设为物理内存的 15%～20%。例如 32GB 物理内存，SGA 给 16GB，PGA 给 6GB 左右。在这个基础上再往下调。

SQL

ALTER SYSTEM SET sga_target=16G SCOPE=SPFILE;

ALTER SYSTEM SET pga_aggregate_target=6G SCOPE=SPFILE;

然后是归档模式。生产库必须开归档，这句话说了无数遍，但仍有环境因为图省事没开，结果数据出问题只能恢复到备份点。开启归档的方式：

SQL

-- 数据库需要先到 mount 状态

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

归档日志的位置我建议放在 +FRA 磁盘组，并设置合理的恢复区大小。默认 8GB 常常不够，尤其业务量大、归档产生快的时候。我先改大：

SQL

ALTER SYSTEM SET db_recovery_file_dest_size=500G;

另外，记得修改数据库兼容性参数。检查当前值：

SQL

SHOW PARAMETER compatible;

19c 的默认 compatible 就是 19.0，这没问题。但如果是跨版本升级上来的库，要确认它别停留在 11g/12c 的低版本，否则 Oracle 19c 的一些新特性用不了。

4.4 项目库表空间与用户设计

生产环境的业务库不能直接用 SYSTEM 表空间承载用户数据，这是原则问题。把业务表、索引、临时数据分开存放，既方便性能调优，也方便备份恢复时的粒度控制。

根据这次项目的业务模型，我设计了这样一组表空间：

表空间	用途	初始大小	自动扩展
PROD_DATA	业务表数据	10GB	8GB 每次，上限 100GB
PROD_INDEX	索引数据	5GB	4GB 每次，上限 50GB
PROD_UNDOTBS	事务回滚段（非系统）	4GB	2GB 每次，上限 20GB
PROD_TEMP	排序与临时段	2GB	不自动扩展，用临时表空间组管理

为什么索引和数据要分开？本质上是为了灵活控制 IO 和备份恢复粒度。如果你的存储层做了冷热数据分层，或者要针对大表做表空间级迁移，分开会方便很多。

创建表空间和业务用户的过程很简单，但密码策略和权限分配要留心。业务项目账号不应该一上来就 grant dba to 业务用户，按照最小权限原则，只 grant connect、resource 和业务需要的特定权限。创建用户的示例：

SQL

CREATE TABLESPACE prod_data DATAFILE '+DATA' SIZE 10G AUTOEXTEND ON NEXT 8G MAXSIZE 100G;

CREATE TABLESPACE prod_index DATAFILE '+DATA' SIZE 5G AUTOEXTEND ON NEXT 4G MAXSIZE 50G;

CREATE USER app_prod IDENTIFIED BY "强密码"

DEFAULT TABLESPACE prod_data

QUOTA UNLIMITED ON prod_data;

GRANT CONNECT, RESOURCE TO app_prod;

5. 项目实战：从部署到日常运维的完整链路

5.1 部署后验证与项目数据初始化装载

数据库建完，不是跑一句 select 1 from dual 觉得没问题就大功告成了。生产环境要做的验证清单远不止这些：

监听器服务是否注册成功：lsnrctl status
ASM 磁盘组空间是否充足：asmcmd lsdg
数据库 alert 日志有无异常报错：查看 $ORACLE_BASE/diag/rdbms/prod/PROD/trace/alert_PROD.log
定时任务（cron/dbms_scheduler）是否正常
备份任务是否已经配置并成功执行过

如果项目里有历史数据需要导入，通常会用到 Data Pump。生产环境导入时，我习惯加上并行和预估参数。比如从 dump 文件导入业务用户数据：

BASH

impdp directory=DATA_PUMP_DIR dumpfile=proj_data.dmp \

logfile=impdp_proj.log schemas=app_prod parallel=4 \

transform=segment_attributes:n

这里 transform=segment_attributes:n 是为了导入时不沿用导出端的表空间属性，而是落到当前环境默认表空间里，避免出现“目标表空间不存在”之类的错误。

数据导入完成后，别忘了收集统计信息：

SQL

EXEC DBMS_STATS.GATHER_SCHEMA_STATS(ownname => 'APP_PROD', cascade => TRUE, degree => 8);

统计信息老旧会导致优化器产生错误执行计划，表现为“数据量不大但 SQL 跑得极慢”，这类问题在导入后尤其常见。

5.2 备份恢复策略在 ASM 环境下的落地

ASM 环境下的备份方式和文件系统环境最大的区别是路径概念不同。文件系统下你写 /u01/oradata/PROD/datafile01.dbf，ASM 环境下你写 +DATA/PROD/DATAFILE/system.257.1175123456。RMAN 天生支持 ASM，操作上并没有增加难度，但要求你必须适应“文件号加创建号”这种路径表达。

基础备份脚本模板如下：

BASH

rman target / <<EOF

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '+FRA/%F';

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+FRA/backup/%U';

BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;

DELETE NOPROMPT OBSOLETE;

EOF

DELETE INPUT 表示归档日志备份完成后删除原归档，避免恢复区被历史归档占满。DELETE OBSOLETE 则是按保留策略清理过期备份。

备份策略里还有一个容易被忽视的步骤：备份完成后做一次 crosscheck，确认备份片和 catalog 记录一致。如果你用的是控制文件作为 RMAN catalog，务必定时备份控制文件，或者至少确认自动备份控制文件已经打开。

恢复流程也要提前演练。不要等生产环境真的出了故障，才第一次去执行 restore 命令。我经历过一次因为不理解 ASM 磁盘组路径而手工指定错误恢复路径导致恢复失败的案例，教训就是：恢复操作一定要先在测试环境完整演练过，路径、恢复顺序、归档应用这些环节都要白纸黑字写进应急预案。

5.3 常见故障与报警处理

生产环境跑起来之后，日常巡检会发现若干“新手看不到但老手秒懂”的坑。这里挑几个最常见的展开讲。

第一类是 SYSAUX 表空间占用率异常升高。Oracle 19c 的 SYSAUX 里存放 AWR 快照、优化器统计信息历史、审计日志等。如果 AWR 快照保留时间过长，或者某张分析表的历史数据积累过多，SYSAUX 会膨胀到令人意外。排查方法：

SQL

SELECT owner, segment_name, segment_type, sum(bytes)/1024/1024 AS SIZE_MB

FROM dba_segments

WHERE tablespace_name = 'SYSAUX'

GROUP BY owner, segment_name, segment_type

ORDER BY SIZE_MB DESC;

找到占用高的段后，针对 AWR 可以调整快照保留策略：

SQL

BEGIN

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(

retention => 21600,

interval => 30

);

END;

第二类是监听日志无限增长。这个前面提过，处理办法是定期切割归档日志文件。可以用 logrotate，也可以写一个按天归档的脚本放到 crontab 里。切完日志后重启监听器或者用 lsnrctl set log_status off/on 让它重新打开一个新日志文件，这一步很多脚本都没写对，导致旧日志没有被有效归档。

第三类是 ASM 磁盘组空间不足。业务增长导致 +DATA 或 +FRA 使用率到达 85% 以上时，ASM 会自动告警。早日发现磁盘组空间趋势，需要建立每日巡检脚本，把 asmcmd lsdg 的输出结果定期记录下来做趋势分析。遇到空间不足，优先清理过期归档和废弃备份，其次再考虑扩容物理磁盘并加入磁盘组。

第四类是归档日志写满恢复区。如果开归档后没有设置备份清理策略，恢复区很快会被写满。故障表现通常是数据库不能打开，应用连接直接报错。解决思路是：备份归档 + 删除已备归档，同时扩大 db_recovery_file_dest_size 作为缓冲。

5.4 安全加固与基线配置

生产库的安全加固是部署交付时的一项硬指标，不能只有数据库跑通了就算完。我给自己定了一个基线清单，每次新环境部署后逐项落实：

修改所有默认密码，包括 SYS、SYSTEM、DBSNMP 等。
设置密码策略：登录失败锁定次数、密码有效期、密码复杂度。例如：

SQL

ALTER PROFILE DEFAULT LIMIT

FAILED_LOGIN_ATTEMPTS 5

PASSWORD_LOCK_TIME 1

PASSWORD_LIFE_TIME 90

PASSWORD_VERIFY_FUNCTION verify_function_11G;

关闭非必要的数据库服务，比如 XDB 的 FTP/HTTP 端口监听。
限制远端登录 IP，配置 sqlnet.ora 里的 TCP.VALIDNODE_CHECKING 白名单机制。这个参数曾被称为“明灯保护”，但现在它的意义是过滤恶意来源连接，仍然值得配置。
定期检查 dba_users 里账户状态为 OPEN 的用户，确认无异常新增。

安全配置不是一次性的，每次发版、每次新增账号之后，都应该重新过一遍。我曾经见到一套数据库环境里残留了十几个没人知道的账号，其中还有 DBA 权限的空口令账号，这种问题比数据库本身的安全漏洞更致命。

6. 常见问题排查与经验总结

6.1 高频踩坑清单速查

现象	可能原因	快速处理
Grid 安装时找不到磁盘	udev 规则未生效或磁盘权限不对	检查 /dev/sd* 属主是否为 grid:asmadmin，重载 udev 规则
asmca 建组时报磁盘不可用	磁盘已被其它文件系统占用	确认磁盘未格式化、无分区表残留
实例启动报 ORA-00845	/dev/shm 不足	扩大 tmpfs 大小或改用 SGA_TARGET
监听正常但连接报 ORA-12514	tnsnames 或 service_name 不匹配	确认 SERVICE_NAME，检查监听注册信息
数据库打开后 SYSAUX 高	AWR 快照过多或统计信息过期	清理 AWR，重建相关表
RMAN 备份报 ORA-19809	恢复区空间不足	清理归档，增大 db_recovery_file_dest_size
ASM 磁盘组 DEGRADED	个别磁盘离线或故障	检查磁盘链路，替换故障盘

这张表是真实环境问题的浓缩版。很多时候生产环境的故障并不会有特别复杂的根因，往往是基础配置没做到位。比如“asmca 发现不了磁盘”这类问题，80% 都是权限和设备路径没弄对，排查时先往这些基础方向走，效率最高。

6.2 19c 备份文件能不能恢复到 11g

这个问题在社区里很常见，也很有代表性。“Oracle 19c 的备份文件能在 Oracle 11g 上恢复出来吗？”答案是：RMAN 物理备份不行，逻辑备份在一定条件下可以。

原因要去数据库文件格式层面理解。RMAN 备份的是数据文件、控制文件等物理结构，这些文件内部格式是跟数据库版本强相关的，高版本产生的数据文件，低版本连识别都做不到，更不要说恢复了。但如果你用的是 Data Pump（expdp/impdp）做的逻辑备份，那它是 SQL 层的数据导出，只要导出时使用了兼容版本参数，就可以导入到低版本数据库。

实操上，从 19c 导出再导入 11g 时，要加上版本参数：

BASH

expdp directory=DATA_PUMP_DIR schemas=app_prod dumpfile=exp_prod.dmp logfile=exp_prod.log version=11.2.0.4

然后再把 dump 文件拷贝到 11g 环境执行 impdp 导入。这个过程中还可能遇到字符集、类型映射等兼容问题，需要逐个调，但至少路径是通的。

所以，如果有人问“生产库升级前要不要保留 11g 能恢复的备份”，答案很清楚：物理层面不要指望跨大版本恢复，逻辑层面用 expdp 配上 version 参数定期导出一份，才是真正可用的降级预案。

6.3 Linux 环境下卸载与重装注意点

虽然文章主题是安装配置，但实际维护中你几乎一定会遇到“装坏了要重来”的场景，所以卸载这件事值得写清楚。

Linux 下卸载 Oracle 19c 和 Grid，不需要像 Windows 那样清理注册表，但也有一套标准顺序。第一步停掉数据库实例和监听，然后停掉集群资源，最后删目录和用户。停库和停集群的命令：

BASH

sqlplus / as sysdba <<EOF

SHUTDOWN IMMEDIATE;

EXIT;

EOF

lsnrctl stop

crsctl stop crs

然后删除软件目录和用户组：

BASH

rm -rf /u01/app/oracle /u01/app/grid /u01/app/product /u01/app/oraInventory

userdel -r oracle

userdel -r grid

groupdel oinstall

groupdel dba

Windows 环境卸载 Oracle 19c 的流程则完全不同，它强调“停止服务 → 卸载产品 → 删除目录 → 清理注册表”，注册表路径主要在 HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE 以及 HKLM\SYSTEM\CurrentControlSet\Services 下的 Oracle 服务键。如果你在 Windows 上装过再卸，务必确认注册表清理干净，否则重装时经常会出现莫名的冲突。这一点虽然和本篇文章的 Linux 主题不同，但在跨平台项目里很常见，顺手提一下。

6.4 我的实操心得与建议

这一路部署下来，有几个体会想重点分享。

第一，静默安装是生产环境的唯一正道。图形界面给了新手安全感，但它也隐藏了太多细节。用静默安装，你被迫去理解每一个参数的含义，遇到问题也要从日志和响应文件里找答案，这个过程虽然难受，但成长速度最快。而且生产环境往往不允许随便开图形界面，习惯静默模式越早越好。

第二，磁盘规划前务必想清楚业务增长趋势。我见过不少环境是上线时磁盘空间看着充裕，半年后报警，追根究底是规划时没有考虑归档保留周期和备份文件体积。ASM 字段设计之初，把 FRA 的空间按“数据量 × 1.5 + 归档日志保留量“去估，至少预留一年的冗余空间。

第三，备份恢复不要只看备份成功日志。备份成功的 Job 不代表你的数据一定能恢复。定期做一次“破坏性恢复演练”，在一个不影响生产的测试环境上，把最近的一次备份完整地 restore 一遍。这个动作虽然耗时，但真的是生产环境最终极的底牌。

第四，运维手册和部署文档要边做边写。部署过程中的命令、响应文件、参数调整记录，都是后续排查问题时的宝贵资料。不要依赖记忆，也不要依赖聊天记录里的只言片语，把这些沉淀成一份完整的项目文档，是交付项目时最有价值的内容之一。

最后再分享一个小习惯：每次执行完一条关键 DDL 或者改掉一个数据库参数后，习惯性记录到一个变更清单里。生产环境出问题时，这份变更清单往往是第一个被翻出来核对的。它救过我很多次。