2026/9/18 4:47:04
FEATURED · 精选文章 
上个月我帮一家制造企业把跑了好几年的 11.2.0.4 单机库升到了 Oracle 19c真正敲升级命令只花了一个多小时但前前后后的环境核查、补丁确认、回退演练占了两天半。很多朋友以为升级就是把新版本装上、跑一遍脚本实际根本不是这么回事——真正的坑全在版本认知、监听环境、历史残留这些看起来不重要的地方。这篇文章就围绕 19c 升级路径和后续高频 QA 来写内容包括不同老版本到底能不能直接升、季度补丁版本号怎么看、DBUA/DBCA/DataGuard 三条路线怎么选、升级后连接故障怎么排查、开发侧从 MySQL 转 Oracle 最常踩的语法差异以及 EBS、Primavera P6、JDK 选型这些周边问题。适合正在规划升级的 DBA也适合刚从其他数据库切过来的开发者。1. 升级前的版本盘点19c 在 Oracle 版本序列里的准确位置1.1 19c 不是“新版本”而是 12.2 体系的长期支持版很多人一听说 19c下意识觉得它跟 18c、21c 一样是“又一个大版本”。这个认知得先纠正过来。Oracle 19c 的完整版本号其实是 12.2.0.3它是 12.2 系列下的长期支持版本。Oracle 发布策略里12.2、18c 都是创新版本生命周期短而 19c 是官方指定的长期支持版本支持周期明显更长这也是为什么很多企业跳过 18c 直接上 19c。看版本演进会更清楚10g → 11g → 12c → 18c → 19c → 21c → 23ai。其中 18c 和 19c 发布时间很近但 18c 更像是 19c 的“前哨版”普及率一直不高。现在网上还有不少人在搜“oracle 11g 下载资源”和“oracle 11g 安装教程”我只能说如果生产环境还在用 11g 且没有特殊兼容性约束尽快规划到 19c 是当前性价比最高的选择。19c 的另一个特点是它完整支持 CDB/PDB 多租户架构。从 12c 开始的容器数据库概念到 19c 已经非常成熟。单机场景下用 DBCA 建一个 CDB里面放 PDB日常管理和资源隔离都比老版本的非容器库舒服很多。1.2 不同老版本到 19c 的升级路线表决定升级之前第一件事是要搞清楚自己的源版本能不能“一步到位”。Oracle 官方对直接升级路径有严格限制不是所有版本都能直接跳到 19c。我按常见源版本整理了一张路线表源版本是否能直接升到 19c建议路径11.2.0.4可以直接使用 DBUA 或手工升级脚本12.1.0.2可以直接升级注意时区和兼容性参数12.2.0.1可以直接升级路径很短18c可以直接升级本质是小版本跨越11.2.0.1 / 11.2.0.2 / 11.2.0.3不可以先升级到 11.2.0.4再升 19c10.2.0.5不可以先升到 11.2.0.4 或 12.1.0.2再升 19c9i 及更早不可以需要多步升级建议直接逻辑迁移这张表的核心信息是11.2.0.4 是通往 19c 的关键跳板。如果你手上的库还停留在 10g 或者 11g 第一个小版本不要硬来老老实实分两步走。很多升级失败案例问题都出在试图跨过“不允许跨越的版本”。另外就算是“可以直接升级”也不代表源版本补丁无所谓。Oracle 官方的升级兼容矩阵里对源版本的补丁水平有最低要求。我的建议是升级前先把源库的 PSU/RU 补丁打到一个相对新的水平减少升级过程中遇到已知 bug 的概率。升级前备份永远是第一位的RMAN 全备加归档缺一不可。2. 动手前必须确认的三个环境问题2.1 版本号与季度补丁19.25.0.0.241015 该怎么读热词里有“oracle 19c 最新版”和“oracle 19c 的版本号 19.25.0.0.241015”说明很多人在下载安装包时被版本号搞晕了。这个必须解释清楚。Oracle 从 2019 年开始把补丁策略改成了季度更新Release Update简称 RU每三个月发布一个。RU 里既包含安全补丁也包含 bug 修复。版本串 19.25.0.0.241015 是这么拆的19主版本代表 19c25第 25 个季度 RU241015补丁发布日期是 2024 年 10 月 15 日所以你看到 19.25意味着这是 19c 的第 25 个季度补丁版本。还有一个概念叫 RURRelease Update Revision是 RU 发布后发现紧急问题后的修订版本。下载安装包时优先选最新的 RU/RUR装完之后再用opatch lsinventory确认当前补丁水平。查看当前数据库版本最常用的 SQL 是SELECT banner_full FROM v$version;19c 的输出会类似Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production。补丁版本则要看dba_registry_sqlpatchSELECT patch_id, action, status, description FROM dba_registry_sqlpatch ORDER BY patch_id;升级前核对好这两条命令的输出能避免很多环境错乱的尴尬。2.2 监听服务起不来、ORA-28547 这类 Net 问题监听问题在升级过程中太常见了热搜里“oracle 监听服务无法启动”和“ora-28547: connection to server failed, probable oracle net admin error”都是典型场景。监听起不来的排查链路我按出现概率排序主机名解析问题/etc/hosts里主机名被解析到 127.0.0.1或者主机名跟hostname命令输出不一致。19c 安装时对主机名解析很敏感listener.ora 里的 HOST 参数一旦写错lsnrctl start就会报 TNS-12545 之类的错。端口被占用1521 被其他进程占了用netstat -tunlp | grep 1521查。防火墙拦截Linux 上firewalld或者iptables没放开 1521/5500 端口。listener.ora 配置损坏手动编辑格式写错了或者从老环境复制过来 HOST 没改。排查时先看日志$ORACLE_HOME/network/log/listener.log里面会有最直接的原因。还有一个技巧是前台启动监听错误信息比后台日志更直观lsnrctl startORA-28547 的问题稍有不同。这个错字面意思是“连接服务器失败可能是 Oracle Net 管理错误”本质是客户端连接到数据库时Net 服务配置有问题。常见原因包括tnsnames.ora 里服务名写错或者主机端口不匹配sqlnet.ora 的NAMES.DIRECTORY_PATH配置有问题客户端版本太旧连不上 19c 的新特性排查顺序是先tnsping看通不通再看 tnsnames.ora 描述符最后确认客户端版本。很多人用 Navicat 连 19c 时碰到 ORA-28547换一个较新的 Oracle Instant Client 往往直接解决问题。2.3 12c 删除不干净与虚拟机环境残留热词里有“12c 删除不干净 oracle”这个问题在 Windows 上尤其常见。很多人在本机装过 12c后来又卸载结果再装 19c 时报各种环境错误。Windows 上卸载 Oracle 不能只删安装目录标准流程是用deinstall工具卸载数据库软件删除服务sc delete或 regedit 清理 Oracle 相关服务清理注册表HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE删除环境变量里的 ORACLE_HOME、ORACLE_SID、PATH 里的 Oracle 路径删除残留目录和C:\Program Files\Oracle如果之前装过 12c 没删干净最典型的表现是新装 19c 时DBCA 里能看到旧的监听器配置或者环境变量把命令指到了旧目录。我的建议是装之前先把环境变量全部列出来看一遍确认没有指向旧 Oracle 的路径。还有人用 VirtualBox 装虚拟机跑 19c热词里“oracle 虚拟机上网”也是高频。这里提醒一句虚拟机里装 19c网络模式建议用 NAT 加端口转发或者 Host-only 方式注意网关和 DNS 配置。如果虚拟机启动后监听只监听在 127.0.0.1外面连不上多半是主机名解析被改成了 localhost。3. 三条主流升级路线DBUA、DBCA 重建、DataGuard 切换3.1 DBUA 升级与 DBCA 建单机 CDB 的实操要点升级老库最直接的方式是 DBUADatabase Upgrade Assistant。图形界面虽然是点击式操作但有几个点必须提前处理好源库必须处于 OPEN 状态升级前做好 RMAN 全备系统表空间和临时表空间要有足够的剩余空间升级过程中不要有活动会话最好停掉业务DBUA 跑完后第一件事不是验收业务而是重新编译失效对象。跨版本升级后部分 PL/SQL 包和视图会变成 INVALID需要跑$ORACLE_HOME/rdbms/admin/utlrp.sql这个脚本要用 SYS 用户执行建议加SET SERVEROUTPUT ON看输出。跑完后查一下SELECT count(*) FROM dba_objects WHERE status INVALID;数量应该归零或极少。如果你没有老库要升级而是从零部署一套 19c那就是 DBCA 建单机 CDB 的过程。热词“oracle 19c 单机 cdb dbca 安装过程”说的就是这个。图形界面里注意几个地方选择“Create a container database”PDB 的数量和名称提前规划字符集强烈建议 AL32UTF8避免以后乱码内存参数按机器实际内存配置别选默认自动管理后在内存小的机器上启动失败DBCA 也支持静默命令dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl -sid orcl \ -createAsContainerDatabase true \ -numberOfPDBs 1 -pdbName orclpdb \ -characterSet AL32UTF8静默安装适合批量部署省掉图形界面点来点去的时间。单机 CDB 建好后日常操作就是show pdbs、alter session set container这些了。3.2 expdp/impdp 逻辑迁移适合哪些场景不是所有升级场景都适合 DBUA。如果源库太老、环境太乱、或者跨平台迁移逻辑迁移反而更干净。我用 expdp/impdp 做过几次从 11g 到 19c 的迁移最大的好处是对源库影响小可以在目标环境先建好库然后只迁移数据。基本的思路源库 expdp 导出全库或指定 schema目标 19c 建好 CDB/PDB创建好表空间和用户impdp 导入导入后重新编译存储过程收集统计信息导出时最常踩的坑是字符集不一致源库如果还是 ZHS16GBK目标库建成了 AL32UTF8中文数据导入后可能出现乱码。迁移前用SELECT userenv(language) FROM dual;确认两边的字符集不一致的先在目标库处理好。另外expdp 导出的 dump 文件不像文件拷贝不会自动带索引和约束的全部状态导入后建议重新校验外键约束跑一遍DBMS_STATS.GATHER_SCHEMA_STATS。3.3 DataGuard 物理备库滚动升级与主备切换的 gap 处理对于有 DataGuard 的环境19c 支持“物理备库先升级再 switchover”的滚动升级方式可以显著减少停机窗口。基本流程是把物理备库升到 19c在备库上执行切换让原备库成为新主库原主库再升级到 19c重新配置 DataGuard 关系这个方案的好处是业务只需要停一次很短的时间但前提是保护模式和归档日志都正常。热词里“oracle 主备切换 resolvable gap”和“两套 dg 库”也是 DG 运维的高频问题。所谓 resolvable gap指的是备库缺少的日志还在主库的归档目录里可以通过 fetch archived logFAL机制自动补齐。判断方法用SELECT * FROM v$archive_gap;如果这个查询有结果说明存在 gap。能通过归档解决的 gap 属于可解析 gap等 FAL 进程把日志拉过来就能追平如果对应归档日志已经被删了或者从未产生过那就是 unresolvable gap这种只能重建备库。主备切换前建议先做一次完整日志校验SELECT thread#, sequence#, applied FROM v$archived_log WHERE applied NO;有未应用日志时先手动 apply再执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY。切换后记得启动备用库的日志应用很多切换完成后库起不来的问题都出在这一步。4. 升级后的高频运维问答ASM、等保、日常检查4.1 进入 ASM 的正确姿势asmcmd 和 sysasm升级到 19c 后如果是 RAC 或者用了 ASM 存储很多人会困惑“oracle 进入 asm 命令”到底怎么敲。这里要明确ASM 实例不是用普通 oracle 用户登录的而是用 grid 用户。进入 ASM 命令行的方式有两种。第一种是用 asmcmd[griddb1 ~]$ asmcmd ASMCMD ls -lasmcmd是 ASM 文件系统管理工具可以查看磁盘组、目录、文件。常用命令包括ls -l列出文件、lsdg查看磁盘组状态和可用空间、du查看目录占用。第二种方式是用 SQL*Plus 连 ASM 实例[griddb1 ~]$ sqlplus / as sysasm注意是sysasm不是sysdba。很多 DBA 习惯性用as sysdba连会发现看到的不是 ASM 实例的信息。连上后可以查show parameter instance_name、select name, state from v$asm_diskgroup;这些。一个容易忽视的点是如果主机上有多个 ORACLE_HOMEgrid 用户的ORACLE_HOME环境变量和 oracle 用户是不一样的。进 asmcmd 之前先echo $ORACLE_HOME确认路径不然经常命令找不到。4.2 等保测评里常被问到的安全配置升级到 19c 后不少单位会做等保测评DBA 免不了要配合检查数据库的安全配置。我整理几个经常被问到的点仅作为操作记录参考审计是否开启SHOW PARAMETER audit_trail;等保要求审计功能是开启状态audit_trail应为DB或XML如果值是NONE就要打开并重启数据库。密码策略SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name IN (FAILED_LOGIN_ATTEMPTS, PASSWORD_LOCK_TIME, PASSWORD_LIFE_TIME);检查登录失败锁定次数、密码有效期这些参数有没有配置。账号状态和权限SELECT username, account_status FROM dba_users; SELECT grantee, granted_role FROM dba_role_privs WHERE granted_role DBA;重点关注默认账号有没有被锁DBA 权限的授予是否合理。这些命令本身不难难的是测评前要把结果提前整理出来别等检查的时候才现场敲。4.3 日常巡检中最常做的几条 SQL升级后日常巡检我必做的几条 SQL 都跟资源和使用状态有关。查 PDB 状态SELECT name, open_mode FROM v$pdbs;查表空间使用率SELECT tablespace_name, used_percent FROM dba_tablespace_usage_metrics;查系统等待事件看有没有明显异常SELECT event, total_waits, time_waited FROM v$system_event WHERE wait_class Idle ORDER BY time_waited DESC;这几条 SQL 信息密度高写进巡检脚本里每天跑一遍比盯着 OEM 界面效率高得多。5. 开发侧高频问答从 MySQL 转 Oracle 最常踩的语法差异5.1 分页、TRUNC、CASE WHEN、dual 的常见用法开发同学从 MySQL 转 Oracle第一反应往往是“为什么我的 SQL 报错”。最大的差异集中在几个地方。分页。MySQL 用LIMITOracle 用ROWNUM或者 19c 的OFFSET FETCH。新版语法更简单SELECT * FROM employees ORDER BY employee_id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;老版本只能套 ROWNUMSELECT * FROM ( SELECT a.*, ROWNUM rn FROM (SELECT * FROM employees ORDER BY employee_id) a WHERE ROWNUM 30 ) WHERE rn 20;TRUNC(SYSDATE) 是高频函数返回当天零点SELECT TRUNC(SYSDATE) FROM dual; SELECT TRUNC(SYSDATE, MM) FROM dual; -- 当月第一天CASE WHEN 的用法跟 MySQL 基本一致但要注意 Oracle 的 CASE 表达式里不能省略 ELSE 时取 NULL 的行为SELECT CASE WHEN salary 10000 THEN 高 WHEN salary 5000 THEN 中 ELSE 低 END AS salary_level FROM employees;dual 表也是个经典困惑点。它是 Oracle 内置的哑表只有一列一行用来支撑SELECT SYSDATE FROM dual这种没有真实表名却必须带 FROM 的语法。有人问“dual 最多存多大”这个问题的前提就是错的——dual 不是用来存业务数据的别往里面写东西。存储过程方面热词里“oracle 存储过程”也是高频搜索。升级后最常见的现象是存储过程变成 INVALID原因通常是依赖对象版本变化。处理方式就是前面讲过的utlrp.sql重编译。5.2 逗号拆分、重复插入、禁用索引“oracle 按逗号拆分列为多行”是我见过最多的提问之一。业务表里经常有A,B,C这种逗号拼接的字段要拆成多行最通用的写法是配合正则和层级查询SELECT REGEXP_SUBSTR(A,B,C, [^,], 1, LEVEL) AS value FROM dual CONNECT BY REGEXP_SUBSTR(A,B,C, [^,], 1, LEVEL) IS NOT NULL;这个语句的机制是REGEXP_SUBSTR从字符串里按逗号分隔取第 N 段CONNECT BY负责把 N 从 1 一直递增到没有更多段落为止。实际业务中把字符串字段名替换进去即可。“oracle 插入数据重复则不插入”这个需求最直接的方案是MERGEMERGE INTO employees tgt USING (SELECT 1001 AS id, 张三 AS name FROM dual) src ON (tgt.id src.id) WHEN NOT MATCHED THEN INSERT (id, name) VALUES (src.id, src.name);比先 SELECT 再 INSERT 的写法少一次往返也更能保证原子性。“oracle 禁用索引”在 19c 里比老版本多了一个选择。传统方式是ALTER INDEX idx_name UNUSABLE;索引变成不可用状态查询不再走它但 DML 期间需要维护成本。19c 还支持INVISIBLE索引让优化器暂时看不见它但索引本身还在维护适合临时对比效果ALTER INDEX idx_name INVISIBLE; ALTER INDEX idx_name VISIBLE;5.3 身份证号导出变科学计数法“oracle 数据库 sql 导出的身份证信息是科学计数法怎么正确显示身份信息”这个问题本质不是 Oracle 的问题而是 Excel 打开 CSV 时把超过 15 位的数字自动转成了科学计数法。身份证号是 18 位放在 Excel 里必然被转。解决方案有几个层面。第一SQL 导出时可以把身份证号码用双引号包起来或者用TO_CHAR加上制表符前缀破坏 Excel 的自动识别。第二导出后用 Excel 打开时先把整列格式设为“文本”再导入数据。第三用 PL/SQL Developer 或者 Navicat 导出时尽量选文本格式或者直接用复制粘贴到文本编辑器再处理。我在实际项目里发现最省事的做法是用sqlplus的set markup csv on加一个技巧把身份证字段用双引号斩断 Excel 的格式识别。实在搞不定就用 Python 的 pandas 处理后导出不要用手工复制粘贴。6. 应用题EBS、Primavera P6、JDK 选型这些周边问题6.1 EBS 数据库升级到 19c 的搭配Oracle EBS 用户升级 19c 是一条绕不开的路。EBS 的应用版本和数据库版本有严格绑定关系不是数据库单独升级就完事的。EBS 12.1.3 和 12.2 系列对 19c 的支持程度不一样升级前必须查对应版本的支持矩阵。实际操作中EBS 升级 19c 的典型顺序是先给 EBS 应用层打对应的兼容性补丁再升级数据库层最后做功能和性能回归。我见过不少只升库不动应用的案例结果应用启动后报一堆驱动和兼容性错误。另外 EBS 对数据库的字符集、时区文件版本都有要求升级前检查SELECT * FROM v$timezone_file;确认时区版本是否在 EBS 的要求范围内。热词里“oracle ebs”搜索量一直很高。如果你是 EBS 环境我的建议是不要自己硬来先找 Oracle Support 上对应版本的升级路径文档把前置条件一个个打勾再动手。6.2 Primavera P6 与 JRE 7 的依赖关系以及 JDK 选型热词里“oracle primavera p6 软件破解”和“oracle jre 7 更新 51”放在一起看多半是 P6 用户的问题。P6 EPPM 的客户端确实对 Java 版本有严格依赖尤其是老版本 P6官方明确要求 Oracle JRE 7 的某个更新版本。装到新机器上系统自动装了 JRE 8 或更高版本P6 启动直接报错。遇到这种问题正确做法是先查你手里的 P6 版本对应的官方 Java 兼容矩阵找到准确的 JRE 版本然后只从可信渠道下载旧版 JRE安装后把JAVA_HOME和 PATH 指过去。如果有多个 Java 环境注意别让系统自动更新把版本顶掉。另外热词里“dragonwell 对比 oracle”也值得提一句。Dragonwell 是阿里开源的 JDK 发行版主要面向 Java 应用服务场景性能优化做得很不错。但如果你跑的是 Oracle 官方应用比如 P6、EBS、WebLogic我个人的建议是优先用 Oracle 官方 JDK避免应用的兼容性检查和厂商支持出问题。生产环境里“好用”比“看起来新”重要得多。6.3 Fusion 与周边中间件版本匹配热词里还有“oracle fusion”。如果指的是 Oracle Fusion Middleware 或者 Fusion Applications 这类套件核心逻辑跟 EBS 一样中间件版本和数据库版本必须匹配。升级数据库到 19c 前确认中间件的补丁版本、JDBC 驱动版本都要跟上。这类套件升级通常会牵一发动全身建议先在测试环境完整演练一遍确认所有组件兼容之后再排生产升级窗口。我自己实际操作的体会是升级 19c 这件事数据库本身只是一个半小时的事真正消耗时间的是环境核查、周边组件联动和回退方案。如果你的生产环境还跑着 EBS 或者 P6 这类重型套件一定把它们的版本绑定关系放在升级计划的第一步。最后再分享一个小技巧升级前把 SPFILE、Listener、Tnsnames、sqlnet 这些配置文件全部做一份带日期的副本放到升级目录之外——别小看这一步出了问题回退时它比任何恢复工具都管用。
Oracle 19c升级实战：从版本盘点到高频问题全解析
上个月我帮一家制造企业把跑了好几年的 11.2.0.4 单机库升到了 Oracle 19c真正敲升级命令只花了一个多小时但前前后后的环境核查、补丁确认、回退演练占了两天半。很多朋友以为升级就是把新版本装上、跑一遍脚本实际根本不是这么回事——真正的坑全在版本认知、监听环境、历史残留这些看起来不重要的地方。这篇文章就围绕 19c 升级路径和后续高频 QA 来写内容包括不同老版本到底能不能直接升、季度补丁版本号怎么看、DBUA/DBCA/DataGuard 三条路线怎么选、升级后连接故障怎么排查、开发侧从 MySQL 转 Oracle 最常踩的语法差异以及 EBS、Primavera P6、JDK 选型这些周边问题。适合正在规划升级的 DBA也适合刚从其他数据库切过来的开发者。1. 升级前的版本盘点19c 在 Oracle 版本序列里的准确位置1.1 19c 不是“新版本”而是 12.2 体系的长期支持版很多人一听说 19c下意识觉得它跟 18c、21c 一样是“又一个大版本”。这个认知得先纠正过来。Oracle 19c 的完整版本号其实是 12.2.0.3它是 12.2 系列下的长期支持版本。Oracle 发布策略里12.2、18c 都是创新版本生命周期短而 19c 是官方指定的长期支持版本支持周期明显更长这也是为什么很多企业跳过 18c 直接上 19c。看版本演进会更清楚10g → 11g → 12c → 18c → 19c → 21c → 23ai。其中 18c 和 19c 发布时间很近但 18c 更像是 19c 的“前哨版”普及率一直不高。现在网上还有不少人在搜“oracle 11g 下载资源”和“oracle 11g 安装教程”我只能说如果生产环境还在用 11g 且没有特殊兼容性约束尽快规划到 19c 是当前性价比最高的选择。19c 的另一个特点是它完整支持 CDB/PDB 多租户架构。从 12c 开始的容器数据库概念到 19c 已经非常成熟。单机场景下用 DBCA 建一个 CDB里面放 PDB日常管理和资源隔离都比老版本的非容器库舒服很多。1.2 不同老版本到 19c 的升级路线表决定升级之前第一件事是要搞清楚自己的源版本能不能“一步到位”。Oracle 官方对直接升级路径有严格限制不是所有版本都能直接跳到 19c。我按常见源版本整理了一张路线表源版本是否能直接升到 19c建议路径11.2.0.4可以直接使用 DBUA 或手工升级脚本12.1.0.2可以直接升级注意时区和兼容性参数12.2.0.1可以直接升级路径很短18c可以直接升级本质是小版本跨越11.2.0.1 / 11.2.0.2 / 11.2.0.3不可以先升级到 11.2.0.4再升 19c10.2.0.5不可以先升到 11.2.0.4 或 12.1.0.2再升 19c9i 及更早不可以需要多步升级建议直接逻辑迁移这张表的核心信息是11.2.0.4 是通往 19c 的关键跳板。如果你手上的库还停留在 10g 或者 11g 第一个小版本不要硬来老老实实分两步走。很多升级失败案例问题都出在试图跨过“不允许跨越的版本”。另外就算是“可以直接升级”也不代表源版本补丁无所谓。Oracle 官方的升级兼容矩阵里对源版本的补丁水平有最低要求。我的建议是升级前先把源库的 PSU/RU 补丁打到一个相对新的水平减少升级过程中遇到已知 bug 的概率。升级前备份永远是第一位的RMAN 全备加归档缺一不可。2. 动手前必须确认的三个环境问题2.1 版本号与季度补丁19.25.0.0.241015 该怎么读热词里有“oracle 19c 最新版”和“oracle 19c 的版本号 19.25.0.0.241015”说明很多人在下载安装包时被版本号搞晕了。这个必须解释清楚。Oracle 从 2019 年开始把补丁策略改成了季度更新Release Update简称 RU每三个月发布一个。RU 里既包含安全补丁也包含 bug 修复。版本串 19.25.0.0.241015 是这么拆的19主版本代表 19c25第 25 个季度 RU241015补丁发布日期是 2024 年 10 月 15 日所以你看到 19.25意味着这是 19c 的第 25 个季度补丁版本。还有一个概念叫 RURRelease Update Revision是 RU 发布后发现紧急问题后的修订版本。下载安装包时优先选最新的 RU/RUR装完之后再用opatch lsinventory确认当前补丁水平。查看当前数据库版本最常用的 SQL 是SELECT banner_full FROM v$version;19c 的输出会类似Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production。补丁版本则要看dba_registry_sqlpatchSELECT patch_id, action, status, description FROM dba_registry_sqlpatch ORDER BY patch_id;升级前核对好这两条命令的输出能避免很多环境错乱的尴尬。2.2 监听服务起不来、ORA-28547 这类 Net 问题监听问题在升级过程中太常见了热搜里“oracle 监听服务无法启动”和“ora-28547: connection to server failed, probable oracle net admin error”都是典型场景。监听起不来的排查链路我按出现概率排序主机名解析问题/etc/hosts里主机名被解析到 127.0.0.1或者主机名跟hostname命令输出不一致。19c 安装时对主机名解析很敏感listener.ora 里的 HOST 参数一旦写错lsnrctl start就会报 TNS-12545 之类的错。端口被占用1521 被其他进程占了用netstat -tunlp | grep 1521查。防火墙拦截Linux 上firewalld或者iptables没放开 1521/5500 端口。listener.ora 配置损坏手动编辑格式写错了或者从老环境复制过来 HOST 没改。排查时先看日志$ORACLE_HOME/network/log/listener.log里面会有最直接的原因。还有一个技巧是前台启动监听错误信息比后台日志更直观lsnrctl startORA-28547 的问题稍有不同。这个错字面意思是“连接服务器失败可能是 Oracle Net 管理错误”本质是客户端连接到数据库时Net 服务配置有问题。常见原因包括tnsnames.ora 里服务名写错或者主机端口不匹配sqlnet.ora 的NAMES.DIRECTORY_PATH配置有问题客户端版本太旧连不上 19c 的新特性排查顺序是先tnsping看通不通再看 tnsnames.ora 描述符最后确认客户端版本。很多人用 Navicat 连 19c 时碰到 ORA-28547换一个较新的 Oracle Instant Client 往往直接解决问题。2.3 12c 删除不干净与虚拟机环境残留热词里有“12c 删除不干净 oracle”这个问题在 Windows 上尤其常见。很多人在本机装过 12c后来又卸载结果再装 19c 时报各种环境错误。Windows 上卸载 Oracle 不能只删安装目录标准流程是用deinstall工具卸载数据库软件删除服务sc delete或 regedit 清理 Oracle 相关服务清理注册表HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE删除环境变量里的 ORACLE_HOME、ORACLE_SID、PATH 里的 Oracle 路径删除残留目录和C:\Program Files\Oracle如果之前装过 12c 没删干净最典型的表现是新装 19c 时DBCA 里能看到旧的监听器配置或者环境变量把命令指到了旧目录。我的建议是装之前先把环境变量全部列出来看一遍确认没有指向旧 Oracle 的路径。还有人用 VirtualBox 装虚拟机跑 19c热词里“oracle 虚拟机上网”也是高频。这里提醒一句虚拟机里装 19c网络模式建议用 NAT 加端口转发或者 Host-only 方式注意网关和 DNS 配置。如果虚拟机启动后监听只监听在 127.0.0.1外面连不上多半是主机名解析被改成了 localhost。3. 三条主流升级路线DBUA、DBCA 重建、DataGuard 切换3.1 DBUA 升级与 DBCA 建单机 CDB 的实操要点升级老库最直接的方式是 DBUADatabase Upgrade Assistant。图形界面虽然是点击式操作但有几个点必须提前处理好源库必须处于 OPEN 状态升级前做好 RMAN 全备系统表空间和临时表空间要有足够的剩余空间升级过程中不要有活动会话最好停掉业务DBUA 跑完后第一件事不是验收业务而是重新编译失效对象。跨版本升级后部分 PL/SQL 包和视图会变成 INVALID需要跑$ORACLE_HOME/rdbms/admin/utlrp.sql这个脚本要用 SYS 用户执行建议加SET SERVEROUTPUT ON看输出。跑完后查一下SELECT count(*) FROM dba_objects WHERE status INVALID;数量应该归零或极少。如果你没有老库要升级而是从零部署一套 19c那就是 DBCA 建单机 CDB 的过程。热词“oracle 19c 单机 cdb dbca 安装过程”说的就是这个。图形界面里注意几个地方选择“Create a container database”PDB 的数量和名称提前规划字符集强烈建议 AL32UTF8避免以后乱码内存参数按机器实际内存配置别选默认自动管理后在内存小的机器上启动失败DBCA 也支持静默命令dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl -sid orcl \ -createAsContainerDatabase true \ -numberOfPDBs 1 -pdbName orclpdb \ -characterSet AL32UTF8静默安装适合批量部署省掉图形界面点来点去的时间。单机 CDB 建好后日常操作就是show pdbs、alter session set container这些了。3.2 expdp/impdp 逻辑迁移适合哪些场景不是所有升级场景都适合 DBUA。如果源库太老、环境太乱、或者跨平台迁移逻辑迁移反而更干净。我用 expdp/impdp 做过几次从 11g 到 19c 的迁移最大的好处是对源库影响小可以在目标环境先建好库然后只迁移数据。基本的思路源库 expdp 导出全库或指定 schema目标 19c 建好 CDB/PDB创建好表空间和用户impdp 导入导入后重新编译存储过程收集统计信息导出时最常踩的坑是字符集不一致源库如果还是 ZHS16GBK目标库建成了 AL32UTF8中文数据导入后可能出现乱码。迁移前用SELECT userenv(language) FROM dual;确认两边的字符集不一致的先在目标库处理好。另外expdp 导出的 dump 文件不像文件拷贝不会自动带索引和约束的全部状态导入后建议重新校验外键约束跑一遍DBMS_STATS.GATHER_SCHEMA_STATS。3.3 DataGuard 物理备库滚动升级与主备切换的 gap 处理对于有 DataGuard 的环境19c 支持“物理备库先升级再 switchover”的滚动升级方式可以显著减少停机窗口。基本流程是把物理备库升到 19c在备库上执行切换让原备库成为新主库原主库再升级到 19c重新配置 DataGuard 关系这个方案的好处是业务只需要停一次很短的时间但前提是保护模式和归档日志都正常。热词里“oracle 主备切换 resolvable gap”和“两套 dg 库”也是 DG 运维的高频问题。所谓 resolvable gap指的是备库缺少的日志还在主库的归档目录里可以通过 fetch archived logFAL机制自动补齐。判断方法用SELECT * FROM v$archive_gap;如果这个查询有结果说明存在 gap。能通过归档解决的 gap 属于可解析 gap等 FAL 进程把日志拉过来就能追平如果对应归档日志已经被删了或者从未产生过那就是 unresolvable gap这种只能重建备库。主备切换前建议先做一次完整日志校验SELECT thread#, sequence#, applied FROM v$archived_log WHERE applied NO;有未应用日志时先手动 apply再执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY。切换后记得启动备用库的日志应用很多切换完成后库起不来的问题都出在这一步。4. 升级后的高频运维问答ASM、等保、日常检查4.1 进入 ASM 的正确姿势asmcmd 和 sysasm升级到 19c 后如果是 RAC 或者用了 ASM 存储很多人会困惑“oracle 进入 asm 命令”到底怎么敲。这里要明确ASM 实例不是用普通 oracle 用户登录的而是用 grid 用户。进入 ASM 命令行的方式有两种。第一种是用 asmcmd[griddb1 ~]$ asmcmd ASMCMD ls -lasmcmd是 ASM 文件系统管理工具可以查看磁盘组、目录、文件。常用命令包括ls -l列出文件、lsdg查看磁盘组状态和可用空间、du查看目录占用。第二种方式是用 SQL*Plus 连 ASM 实例[griddb1 ~]$ sqlplus / as sysasm注意是sysasm不是sysdba。很多 DBA 习惯性用as sysdba连会发现看到的不是 ASM 实例的信息。连上后可以查show parameter instance_name、select name, state from v$asm_diskgroup;这些。一个容易忽视的点是如果主机上有多个 ORACLE_HOMEgrid 用户的ORACLE_HOME环境变量和 oracle 用户是不一样的。进 asmcmd 之前先echo $ORACLE_HOME确认路径不然经常命令找不到。4.2 等保测评里常被问到的安全配置升级到 19c 后不少单位会做等保测评DBA 免不了要配合检查数据库的安全配置。我整理几个经常被问到的点仅作为操作记录参考审计是否开启SHOW PARAMETER audit_trail;等保要求审计功能是开启状态audit_trail应为DB或XML如果值是NONE就要打开并重启数据库。密码策略SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name IN (FAILED_LOGIN_ATTEMPTS, PASSWORD_LOCK_TIME, PASSWORD_LIFE_TIME);检查登录失败锁定次数、密码有效期这些参数有没有配置。账号状态和权限SELECT username, account_status FROM dba_users; SELECT grantee, granted_role FROM dba_role_privs WHERE granted_role DBA;重点关注默认账号有没有被锁DBA 权限的授予是否合理。这些命令本身不难难的是测评前要把结果提前整理出来别等检查的时候才现场敲。4.3 日常巡检中最常做的几条 SQL升级后日常巡检我必做的几条 SQL 都跟资源和使用状态有关。查 PDB 状态SELECT name, open_mode FROM v$pdbs;查表空间使用率SELECT tablespace_name, used_percent FROM dba_tablespace_usage_metrics;查系统等待事件看有没有明显异常SELECT event, total_waits, time_waited FROM v$system_event WHERE wait_class Idle ORDER BY time_waited DESC;这几条 SQL 信息密度高写进巡检脚本里每天跑一遍比盯着 OEM 界面效率高得多。5. 开发侧高频问答从 MySQL 转 Oracle 最常踩的语法差异5.1 分页、TRUNC、CASE WHEN、dual 的常见用法开发同学从 MySQL 转 Oracle第一反应往往是“为什么我的 SQL 报错”。最大的差异集中在几个地方。分页。MySQL 用LIMITOracle 用ROWNUM或者 19c 的OFFSET FETCH。新版语法更简单SELECT * FROM employees ORDER BY employee_id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;老版本只能套 ROWNUMSELECT * FROM ( SELECT a.*, ROWNUM rn FROM (SELECT * FROM employees ORDER BY employee_id) a WHERE ROWNUM 30 ) WHERE rn 20;TRUNC(SYSDATE) 是高频函数返回当天零点SELECT TRUNC(SYSDATE) FROM dual; SELECT TRUNC(SYSDATE, MM) FROM dual; -- 当月第一天CASE WHEN 的用法跟 MySQL 基本一致但要注意 Oracle 的 CASE 表达式里不能省略 ELSE 时取 NULL 的行为SELECT CASE WHEN salary 10000 THEN 高 WHEN salary 5000 THEN 中 ELSE 低 END AS salary_level FROM employees;dual 表也是个经典困惑点。它是 Oracle 内置的哑表只有一列一行用来支撑SELECT SYSDATE FROM dual这种没有真实表名却必须带 FROM 的语法。有人问“dual 最多存多大”这个问题的前提就是错的——dual 不是用来存业务数据的别往里面写东西。存储过程方面热词里“oracle 存储过程”也是高频搜索。升级后最常见的现象是存储过程变成 INVALID原因通常是依赖对象版本变化。处理方式就是前面讲过的utlrp.sql重编译。5.2 逗号拆分、重复插入、禁用索引“oracle 按逗号拆分列为多行”是我见过最多的提问之一。业务表里经常有A,B,C这种逗号拼接的字段要拆成多行最通用的写法是配合正则和层级查询SELECT REGEXP_SUBSTR(A,B,C, [^,], 1, LEVEL) AS value FROM dual CONNECT BY REGEXP_SUBSTR(A,B,C, [^,], 1, LEVEL) IS NOT NULL;这个语句的机制是REGEXP_SUBSTR从字符串里按逗号分隔取第 N 段CONNECT BY负责把 N 从 1 一直递增到没有更多段落为止。实际业务中把字符串字段名替换进去即可。“oracle 插入数据重复则不插入”这个需求最直接的方案是MERGEMERGE INTO employees tgt USING (SELECT 1001 AS id, 张三 AS name FROM dual) src ON (tgt.id src.id) WHEN NOT MATCHED THEN INSERT (id, name) VALUES (src.id, src.name);比先 SELECT 再 INSERT 的写法少一次往返也更能保证原子性。“oracle 禁用索引”在 19c 里比老版本多了一个选择。传统方式是ALTER INDEX idx_name UNUSABLE;索引变成不可用状态查询不再走它但 DML 期间需要维护成本。19c 还支持INVISIBLE索引让优化器暂时看不见它但索引本身还在维护适合临时对比效果ALTER INDEX idx_name INVISIBLE; ALTER INDEX idx_name VISIBLE;5.3 身份证号导出变科学计数法“oracle 数据库 sql 导出的身份证信息是科学计数法怎么正确显示身份信息”这个问题本质不是 Oracle 的问题而是 Excel 打开 CSV 时把超过 15 位的数字自动转成了科学计数法。身份证号是 18 位放在 Excel 里必然被转。解决方案有几个层面。第一SQL 导出时可以把身份证号码用双引号包起来或者用TO_CHAR加上制表符前缀破坏 Excel 的自动识别。第二导出后用 Excel 打开时先把整列格式设为“文本”再导入数据。第三用 PL/SQL Developer 或者 Navicat 导出时尽量选文本格式或者直接用复制粘贴到文本编辑器再处理。我在实际项目里发现最省事的做法是用sqlplus的set markup csv on加一个技巧把身份证字段用双引号斩断 Excel 的格式识别。实在搞不定就用 Python 的 pandas 处理后导出不要用手工复制粘贴。6. 应用题EBS、Primavera P6、JDK 选型这些周边问题6.1 EBS 数据库升级到 19c 的搭配Oracle EBS 用户升级 19c 是一条绕不开的路。EBS 的应用版本和数据库版本有严格绑定关系不是数据库单独升级就完事的。EBS 12.1.3 和 12.2 系列对 19c 的支持程度不一样升级前必须查对应版本的支持矩阵。实际操作中EBS 升级 19c 的典型顺序是先给 EBS 应用层打对应的兼容性补丁再升级数据库层最后做功能和性能回归。我见过不少只升库不动应用的案例结果应用启动后报一堆驱动和兼容性错误。另外 EBS 对数据库的字符集、时区文件版本都有要求升级前检查SELECT * FROM v$timezone_file;确认时区版本是否在 EBS 的要求范围内。热词里“oracle ebs”搜索量一直很高。如果你是 EBS 环境我的建议是不要自己硬来先找 Oracle Support 上对应版本的升级路径文档把前置条件一个个打勾再动手。6.2 Primavera P6 与 JRE 7 的依赖关系以及 JDK 选型热词里“oracle primavera p6 软件破解”和“oracle jre 7 更新 51”放在一起看多半是 P6 用户的问题。P6 EPPM 的客户端确实对 Java 版本有严格依赖尤其是老版本 P6官方明确要求 Oracle JRE 7 的某个更新版本。装到新机器上系统自动装了 JRE 8 或更高版本P6 启动直接报错。遇到这种问题正确做法是先查你手里的 P6 版本对应的官方 Java 兼容矩阵找到准确的 JRE 版本然后只从可信渠道下载旧版 JRE安装后把JAVA_HOME和 PATH 指过去。如果有多个 Java 环境注意别让系统自动更新把版本顶掉。另外热词里“dragonwell 对比 oracle”也值得提一句。Dragonwell 是阿里开源的 JDK 发行版主要面向 Java 应用服务场景性能优化做得很不错。但如果你跑的是 Oracle 官方应用比如 P6、EBS、WebLogic我个人的建议是优先用 Oracle 官方 JDK避免应用的兼容性检查和厂商支持出问题。生产环境里“好用”比“看起来新”重要得多。6.3 Fusion 与周边中间件版本匹配热词里还有“oracle fusion”。如果指的是 Oracle Fusion Middleware 或者 Fusion Applications 这类套件核心逻辑跟 EBS 一样中间件版本和数据库版本必须匹配。升级数据库到 19c 前确认中间件的补丁版本、JDBC 驱动版本都要跟上。这类套件升级通常会牵一发动全身建议先在测试环境完整演练一遍确认所有组件兼容之后再排生产升级窗口。我自己实际操作的体会是升级 19c 这件事数据库本身只是一个半小时的事真正消耗时间的是环境核查、周边组件联动和回退方案。如果你的生产环境还跑着 EBS 或者 P6 这类重型套件一定把它们的版本绑定关系放在升级计划的第一步。最后再分享一个小技巧升级前把 SPFILE、Listener、Tnsnames、sqlnet 这些配置文件全部做一份带日期的副本放到升级目录之外——别小看这一步出了问题回退时它比任何恢复工具都管用。 
