Linux下Oracle 19c生产环境部署与调优实战

刚帮一个业务团队交付完数据库底座，整个过程从评估、规划到装机、调优、上线，前后踩了不少坑，也沉淀了一些思路。这台环境是典型的Linux服务器配Oracle 19c，属于生产级别，不是拿来练手的虚拟机。我把它整理成这个系列的第二篇，也就是FGMT02，给后面要做的同类项目当参考。这篇不会只丢给你一堆命令，而是把生产环境安装配置背后的取舍、参数怎么定、项目实战中会遇到什么问题，尽量讲透。如果你正在准备Linux环境下Oracle 19c的生产部署，或者刚接到一个从零搭建业务数据库的需求，这篇文章应该能帮你省下不少试错时间。

1. 生产环境方案选型：先想清楚再动手

1.1 为什么生产环境我坚持选Linux+Oracle19c

先回答一个很多人纠结的问题：现在MySQL、PostgreSQL都这么火，为什么还要在Linux上装Oracle 19c？

业务存量决定技术选型。很多企业的核心系统，尤其是金融、制造、政务类项目，底层早就跑在Oracle上，牵一发动全身。Oracle 19c是目前的长期支持版本，这意味着它有很长的官方维护周期，对于追求稳定压倒一切的生产环境来说，比那些一两年就停更的版本靠谱得多。

Linux这边也没什么悬念。x86服务器上Linux是绝对主流，运维工具链、监控体系、自动化脚本基本都是围绕Linux来的。Oracle 19c对Linux内核和glibc的适配已经非常成熟，安装包解压之后直接能跑，不需要像某些数据库那样反复折腾系统组件。

另外，现在国产化环境的呼声很高，有人在麒麟操作系统V10上装Oracle 19c单机也能成功。我身边确实有同事这么干过，整体流程和标准Linux发行版差不多，关键是要提前确认内核版本和依赖包是否满足Oracle的官方要求。所以这篇讲的流程，不管你用的是RHEL系、Oracle Linux还是部分国产系统，思路都是通用的。

1.2 生产环境和非生产环境，差的不只是一台机器

我见过太多人在虚拟机里装Oracle很熟练，一到生产环境就懵。差别到底在哪？

虚拟机练手时，你root权限随手用，图形界面点Next就装完了，数据文件也随便放。生产环境不一样，这玩意儿是要跑真实业务数据的，一旦出问题就是事故。生产环境至少要考虑这几件事：

• 数据文件、归档日志、备份文件要分目录甚至是分磁盘放，不能跟系统盘挤在一起。
• 安装方式要可追溯、可自动化，不能靠鼠标点来点去。
• 参数配置要有依据，不能拿默认值直接上。
• 出了问题要有排查路径和备份恢复方案。

所以这篇我全程用静默安装的方式，全部操作通过命令行和响应文件完成。这不是装酷，而是生产运维的基本要求——你在哪台机器上装了什么参数，都能通过脚本和文件复现，出问题也好回溯。

1.3 这次实战的部署场景怎么假设

为了让内容更贴近实际，我设定一个典型的业务系统场景来展开：

• 数据库版本：Oracle Database 19c Enterprise Edition
• 操作系统：兼容Linux发行版，内核3.10以上
• 服务器配置：16核CPU、64G内存、数据盘用RAID或SSD
• 业务形态：订单、客户、商品这类常见OLTP业务
• 安装方式：静默安装

这样的场景在中小型项目里非常常见。后面所有目录规划、参数设置、建库建表，我都是基于这个假设来的。你实际环境如果内存更大或业务并发更高，我可以一步步告诉你参数该往哪个方向调。

2. 安装前的系统规划与参数准备

2.1 目录规划与硬件基础

很多新手装Oracle最容易忽略的就是目录规划，觉得反正装完能连上就行。等你跑了一段生产业务，发现数据目录跟系统盘共享空间，或者归档日志把磁盘塞满的时候，再想改结构就非常痛苦了。

我建议的生产环境目录大概是这样的：

目录	用途	建议磁盘
/u01/app/oracle	ORACLE_BASE，软件和实例的根目录	系统盘或独立数据盘
/u01/app/oracle/product/19.0.0/dbhome_1	ORACLE_HOME，数据库软件目录	系统盘或独立数据盘
/u01/app/oracle/oradata	数据文件目录	独立数据盘，最好SSD
/u01/app/oracle/fast_recovery_area	快速恢复区，归档和闪回	独立磁盘，容量要大
/data/backup	RMAN备份目录	独立磁盘，甚至可以是远程挂载

一句话总结：数据库软件和系统放一起没关系，但数据文件、归档、备份这三个位置一定要分开规划，最好分别挂在不同的磁盘或存储卷上。我遇到不止一次归档日志把整个根目录写满导致数据库卡死的事故，根源就是目录规划时没想清楚。

硬件方面，生产环境内存至少32G起步，64G会舒服很多。Oracle是个内存大户，SGA和PGA都要从内存里划。CPU核数越多越好，尤其是并发业务。磁盘强烈建议SSD，机械盘跑Oracle 19c的并发写入会明显吃力。

2.2 内核参数到底动了哪些，为什么

先直接给出一份我常用的内核参数模板，放在 /etc/sysctl.conf 里：

这里面每一个参数都不是随便填的：

• kernel.sem：控制信号量。Oracle进程之间要频繁通信，信号量太小会导致“semget失败”之类的报错。四个数字分别对应信号量组数、每组最大信号量等，直接按官方建议填就行。
• fs.file-max：整个系统能打开的文件句柄总数。Oracle一个进程可能要开几百个文件，库一大、并发一高，默认值根本不够用。
• kernel.shmmax 和 kernel.shmall：共享内存的最大值和总页数。虽然19c更倾向于用/dev/shm来管理共享内存，但把这两个参数配好，可以避免某些场景下进程起不来的问题。
• net.core.rmem_max 和 wmem_max：网络收发缓冲区。客户端连接多的时候，TCP缓冲区太小会导致读写超时。
• fs.aio-max-nr：异步IO请求上限。Oracle的IO操作大量依赖AIO，这个值不够会直接报IO错误。
• net.ipv4.ip_local_port_range：本地可用端口范围。生产环境会有大量数据库连接，端口范围太小很容易耗尽。

配置完执行 sysctl -p 让它生效。我的习惯是配完后重启一次服务器，确保内核参数在干净环境下没问题。

2.3 用户、权限与系统资源限制

在Linux上跑Oracle，我不会建议你用root去启动数据库。生产规范里，Oracle进程必须用一个普通用户来运行，通常是oracle用户。

创建用户和组：

然后确认oracle用户有权限读写 /u01 和 /data 这些目录。权限不对是安装失败的常见原因，我一般直接给目录赋权：

接下来是操作系统的资源限制，在 /etc/security/limits.conf 里加上：

nproc是进程数上限，nofile是文件描述符上限，stack是栈大小。生产环境的数据库进程数动不动就上千，不提前放宽的话，后面创建会话时报ORA-27102之类的错误你找半天都找不到原因。

2.4 依赖包与环境变量

Oracle 19c安装前需要一堆系统依赖包。如果你用的是Oracle Linux或者Red Hat系，官方封装了一个省事的东西叫 oracle-database-preinstall-19c，一条命令就能装好所有依赖：

不是Oracle Linux的话就得手动装了，大致包括这些：binutils、gcc、gcc-c++、glibc、glibc-devel、libaio、libaio-devel、libX11、libstdc++、libstdc++-devel、make、sysstat、unixODBC。具体列表以官方安装文档为准，不同小版本会有差异。

环境变量也很关键。编辑 /home/oracle/.bash_profile：

ORACLE_SID一定要在第一次建库之前确认好，装完再改很麻烦。SID就是数据库实例名，相当于你在服务器上的数据库身份证，后面监听、连接全都要靠它。

3. 静默安装Oracle19c的完整流程

3.1 为什么生产环境不推荐图形化安装

Oracle的图形化安装界面做了很多年，但放到生产环境就很不合适。原因很简单：

• 生产服务器一般不装桌面环境，你用X11转发把图形界面拉到自己电脑上，网络一抖就断，装到一半卡住很尴尬。
• 图形化安装的每一步都是手动点的，没有脚本记录，你很难说清楚当时到底点了什么。
• 排查问题时，图形化安装的日志散得到处都是，不如响应文件一个文件就能看全所有选项。

所以生产环境几乎都是静默安装。所谓静默安装，就是先把安装选项写进一个文本响应文件，然后让 runInstaller 对着这个文件去装，全程不需要人工干预。好处是所有配置项明确可见，换一台机器改几个参数就能复用，非常符合生产变更管理的习惯。

3.2 响应文件配置与核心字段解释

Oracle安装包解压后，在 database/response 目录下会有响应文件模板。我通常复制一份出来修改：

核心配置如下：

注意这里 INSTALL_DB_SWONLY 意思是只装数据库软件，不建库。我极力推荐这样做，因为安装软件和建库是两个大环节，分开做可以避免出错时不知道问题到底出在哪。

INVENTORY_LOCATION 是Oracle的清单目录，记录软件安装信息，后面卸载和补丁都要用到。

3.3 执行安装与root脚本处理

配置好响应文件后，切换到oracle用户执行安装：

安装命令运行后会有一段时间没有输出，不要以为卡住了，去 $ORACLE_BASE/oraInventory/logs 看安装日志就行。安装完成会提示你用root去执行两个脚本：

这一步非常容易漏。不执行root.sh的话，后面 dbca 建库时权限和目录都会出问题。root.sh运行时会问你本地监听要不要配置，选是。

3.4 静默建库：从dbca到一张空库

软件装好，接下来就是建库了。我用dbca的静默模式：

这里有几个参数值得展开说：

• createAsContainerDatabase false：Oracle 19c默认建的是CDB，就是容器数据库。如果你有PDB的需求可以保留默认并指定 -pdbName，多租户架构对资源隔离有好处。但很多传统项目还是习惯用普通库，后面接应用的时候不用写PDB的服务名，省事。
• characterSet AL32UTF8：字符集必须建库前定死，建完再改字符集是出了名的大坑，数据容易乱码。
• memoryPercentage 40：数据库能使用的内存占服务器总内存的40%。64G内存的机器分25G左右给数据库，留一部分给操作系统和未来连接池，是保守但合理的做法。
• redoLogFileSize 1024：redo日志文件大小设为1G。默认值太小，生产环境事务频繁切换日志会很影响性能。

建库完成后，用 sqlplus / as sysdba 登录，查询一下实例状态：

看到 OPEN 就说明库已经起来了。再执行 lsnrctl status 确认监听正常，数据库已经注册到监听里。

4. 初始化配置与生产级参数调优

4.1 内存、进程、会话参数怎么定

很多人建完库就直接跑业务了，结果没过两天就出问题。默认参数只是让你“能跑”，离“跑得稳”还有距离。生产环境我至少要调这几个参数：

sga_target 是数据库共享内存区，主要缓存数据块和SQL执行计划；pga_aggregate_target 是各个会话私有内存区的总上限。OLTP业务一般SGA:PGA按3:1到4:1分配。前面 memoryPercentage 已经给数据库分配了25G左右，这里SGA给24G、PGA给8G，总量会超出一点，但SGA实际有动态调整机制，整体可控。

processes 和 sessions 是并发连接相关。sessions一般按 processes × 1.5 + 20 来估算。比如processes设1000，sessions就是1520左右。并发一旦超过processes就会报ORA-00020，这种错误在业务高峰期出现会很被动，所以宁可按未来一年业务增长量来预留，也别卡得太紧。

改完这些参数需要重启数据库实例才能生效：

4.2 归档模式、redo与备份策略

生产库不开归档模式，就等于裸奔。归档模式允许你在数据库打开状态下备份数据文件，也是Data Guard这类同步方案的基础。

建库时如果指定了 recoveryAreaDestination，快速恢复区已经配好，但还要手动开启归档：

验证一下：

看到 Archive mode 是 enabled 就行。同时检查redo日志大小：

如果redo还是默认的几百M级别，可以考虑增加一组大日志或者重建redo。生产OLTP建议redo单组1G左右，太大会让崩溃恢复变慢，太小会频繁切换日志导致磁盘IO压力。

备份方面，RMAN是Oracle自带的备份工具。我给一个最小可用的备份策略：

生产环境一般还会搭建灾备或同步方案，比如Data Guard做备库，或者用数据库同步工具做数据分发，这个内容量太大，后面可以单独写一篇。

4.3 表空间、业务用户与字符集

表空间规划很影响数据库后续的维护成本。我习惯按业务域拆表空间，而不是所有表都塞到SYSTEM或SYSAUX里。

给业务系统单独建表空间和用户：

注意几个细节：

• 我不建议直接给业务用户赋 dba 权限。connect 和 resource 两个角色足够跑业务，最危险的权限给了，安全审计那关都过不去。
• 表空间类型用 permanent，数据文件和临时表空间分开。
• 字符集建库时选 AL32UTF8 是为了多语言存储，如果你的业务只存中文和英文，这个选择也是通用的。

5. 项目实战：从空库到业务可用

5.1 设计一个业务库：订单、客户、商品

光把库装好不算完，我们得真正跑一遍业务。我用最常见的订单模型来演示，这种结构你去看北风数据库或者大部分课程设计题目，都能看到影子。

设计这几张表：

索引方面，过滤条件和关联字段一定要建索引：

主键会自动建唯一索引，外键字段的普通索引需要手动加。生产环境很多慢查询就是外键字段没索引导致的，这个坑我见得太多了。

5.2 数据导入与连接验证

表建好后，往里面插入一条模拟数据：

批量导入大批量数据时，SQL*Loader或外部表是更好的选择。一条条insert在生产环境跑上百万行，不仅慢还会撑爆redo日志。

验证连接是必须的。业务应用一般不会通过服务器本地sqlplus来连，而是通过网络。用业务用户远程登录测试：

JDBC连接串对应的是：

注意这里 orcl 在19c非容器库模式下是服务名，如果是CDB模式就要写PDB的服务名。很多应用连不上就是因为分不清SID和Service Name。

5.3 锁与并发：一次真实的生产事故复现

项目实战里最常遇到的就是锁问题。我模拟一个场景：两个会话同时更新同一行数据。

会话A执行更新但不提交：

会话B执行同一条更新，就会一直卡住：

这是因为Oracle的行级锁机制：未提交的更新会持有该行的锁，其他会话只能等待。生产中很多“数据库卡死”的事故，查到最后都是某个会话没提交或者程序里忘了commit。

定位阻塞源的SQL：

如果有大量锁等待，在确认业务可以中断的情况下，可以由DBA杀掉阻塞会话：

这个案例告诉我们：一是业务代码里事务一定要短平快，别在一个事务里磨蹭太久；二是给关键表的关联字段建全索引，避免更新时行锁升级成更大范围的锁。

6. 常见问题排查速查表与避坑心得

6.1 高频问题排查速查表

生产环境出问题不可怕，可怕的是没有排查思路。我整理了一张高频问题表，都是我实际遇到过的：

现象	可能原因	排查方法	处理建议
安装时prereq检查失败	依赖包缺失、内核参数不对	查看安装日志中具体失败项	按提示安装对应依赖包，用官方preinstall包最省事
监听启动失败	端口占用、hosts配置错误	lsnrctl status，查看listener.log	确认1521端口没被占用，/etc/hosts配好主机名
ORA-12505/12514	SID或服务名写错	lsnrctl services 查看已注册的服务	区分SID和Service Name，非容器库用orcl，容器库写PDB服务名
数据库启动卡住	空间不足、undo无法扩展	查看alert日志	检查磁盘空间，扩undo表空间
归档日志目录满	归档没定期清理、快速恢复区太小	archive log list，查看vg大小	扩展快速恢复区，配置RMAN定期删除过期归档
ORA-28001密码过期	默认密码有效期180天	查看dba_users中的expiry_date	生产库制定密码策略，结合应用改造统一处理
ORA-00020进程数超限	processes参数太小或连接泄漏	show parameter processes，查v$session	调大processes，重点排查应用连接池释放问题

6.2 sysaux占用率异常的排查路径

最近搜这个词的人特别多，确实是个高频问题。SYSAUX表空间是Oracle的系统辅助表空间，正常应该保持稳定，如果持续膨胀，最常见原因有这几个：

先查一下到底是什么占了空间：

在我处理过的案例里，TOP3基本是：

• AWR快照保留时间过长。默认保留8天，如果业务库压力大，AWR每小时一张快照，占空间很容易失控。可以缩短保留时间：

• 审计记录太多。如果开启了细粒度审计，AUD$表会疯狂增长。确认审计策略后可以清理历史记录，并评估是否要降低审计级别。

• 优化器统计信息历史过多。统计信息每次自动采集都会保留历史版本，可以手动清理过旧的历史。

处理完别忘记收缩SYSAUX表空间释放磁盘空间，只删数据不收缩文件的话，磁盘还是满的。

6.3 卸载与整体回滚预案

生产环境变更，随时要有回滚的觉悟。虽然正常情况下你不会想去卸载一台生产库，但万一安装配置的过程中搞出无法修复的问题，至少要知道怎么干净地退回去。

Oracle 19c自带卸载工具，在ORACLE_HOME的deinstall目录下：

按照提示确认实例SID和目录信息，工具会自动停止实例、清理监听配置和目录。Linux系统下没有Windows那种“注册表”概念，Oracle在Linux上的安装信息主要存在于 /etc/oratab、/u01/app/oraInventory、/u01/app/oracle 这几个位置，卸载后手动清理残留目录：

当然，真正生产环境的底线不是“会卸载”，而是“有备份”。安装前做好系统快照或整机备份，比学会了再强的卸载命令都管用。

6.4 给新手的几条实战心得

最后说几句实在的，都是我从一次次故障和加班里总结出来的：

第一，安装阶段就把日志看明白。无论是 runInstaller 还是 dbca，输出的每一行都不要急着跳过。很多问题在日志里其实写得很明白，只是很多人不习惯去看。

第二，所有配置记录在案。SID、目录、密码、参数文件、监听端口，每个环境建一个文档。生产环境不止你一个DBA，交接和排障时这个文档能救人一命。

第三，参数不是越大越好。有人觉得内存大就all in给数据库，结果操作系统都没内存可用，数据库反而更慢。给内存留20%到30%给OS和文件缓存，这是底线。

第四，没事多看看 alert 日志。Oracle会把重大错误和信息写在这里，定期扫一眼，很多隐患能提前发现。这也是区分资深DBA和“会装Oracle的人”的一个标志。

这套流程走下来，你已经不是“能把Oracle装出来”的水平了，而是能站在生产角度去思考怎么装、为什么这么装、出了问题怎么办。后面如果再聊聊Data Guard同步、AWR报告分析、数据库备份策略这些生产环境绕不开的课题，那就是下一篇FGMT03的事了。