上个月接手了一套 Oracle 11g 老系统的升级客户提的需求很直接数据库换到 Oracle 19c。我原以为这就是一次常规的“装新版、导数据”操作真正做下来才发现19c 和 11g 的差距比想象中大不少尤其是 CDB/PDB 多租户架构几乎影响了从建库到连接的所有操作习惯。这篇文章就是整套实操笔记包含我从下载 Oracle 19c 安装包、搞定“没有 Oracle 账户也能下载”的问题到 DBCA 创建单机 CDB、处理监听服务无法启动、排查 ORA-28547、配置 DBeaver/Navicat再到日常 SQL 写法和 DataGuard 主备切换的完整过程。准备上 19c 的运维、正在做版本评估的 DBA以及被 Oracle 各种连接报错折磨的开发同学都可以直接参考。1. 为什么选 19c从选型到升级思路1.1 19c 到底改了什么Oracle 19c 虽然叫 19c但本质上属于 12c 产品线是 Oracle 12.2 的延续版本只不过后来 Oracle 改用年份命名。它最特殊的地方在于它是 12c/18c 这个系列里明确给出的长期支持版本补丁维护周期比其他版本长很多所以现在很多新项目直接把它当成默认选项。比起 11g19c 最核心的变化是多租户架构。11g 时代“一个实例就是一个数据库”到了 19c一个实例里可以装一个 CDB容器数据库CDB 下面再挂多个 PDB可插拔数据库。除此之外19c 在自动化上也推进了不少比如自动索引、内存列存储、更细粒度的资源管理以及 PDB 级别的在线克隆和刷新。对一线 DBA 来说最直观的感受就是show pdbs这个命令变得高频了登录之后第一件事不再是select name from v$database而是先看自己在哪个容器里。从实际运维角度看19c 相比 11g 的稳定性更好坏块检测、统计信息收集、SQL 计划管理这些基础能力都有加强。如果你还在 11g 上扛着与其等到支持到期被催着迁移不如找一台测试机先把 19c 的节奏踩一遍后续真正搬迁时会从容很多。1.2 CDB/PDB 架构怎么理解很多第一次接触 19c 的人会被 CDB、PDB 这两个缩写绕晕。我的理解方式是CDB 相当于整栋公寓楼PDB 就是楼里的一套套独立房间。每套房都有自己独立的家具、水电表从外面看是一栋楼但每户人家关起门来完全是自己的空间。对应到数据库上一个 CDB 实例承载多个 PDB每个 PDB 对外部用户来说就像是一个独立数据库有自己的数据文件、表空间、用户、权限。管理员登录 CDB 根容器之后可以统一管理所有 PDB业务用户则往往只看到自己所在的 PDB。这个架构带来的第一个坑就是连接方式。很多人沿用 11g 的习惯tnsnames 里只写一个 SID结果连上之后发现业务用户不在当前容器里或者直接报 ORA-12514。正确做法是连 PDB 时用 PDB 的 service_name比如//host:1521/orclpdb1而不是用 CDB 的实例名。这个后面我会专门展开。1.3 哪些场景不建议直接上 19c虽说 19c 是长期支持版但它不是万能药有几个场景我建议谨慎评估。第一老库用了大量 11g 时代的内部包或非常规写法比如依赖sys.x$表做监控、大量使用触发器改数据、用了不规范的并行 DML这些逻辑在迁移到 PDB 之后很可能会出现权限或隔离层面的问题。第二第三方商业软件如果没有官方 19c 认证哪怕数据库本身能装上去应用层也可能在某个隐蔽功能上报错。第三如果公司只有两三个几十 GB 的小库又完全没有整合需求那从 11g 直接升 19c 的意义不大反而要承担应用改造的成本。我这次迁移采取的方案是先在另外一套环境装好 19c再用 expdp/impdp 做逻辑迁移。虽然大数据量下速度不如 DataGuard 物理迁移但更容易提前暴露出对象兼容性和字符集问题。如果你想要停机时间更短可以考虑 DataGuard 的方式前提是两套环境 Endian 一致、数据库版本都在支持的升级路径上。2. 安装部署全流程笔记2.1 下载安装包与账号问题先解决很多新手卡住的第一关没有 Oracle 账户怎么下载 19c。Oracle 官方下载确实需要登录但注册本身只需要一个能收邮件的邮箱不需要付费。打开 Oracle Software Downloads 页面选 Database再选 Oracle Database 19c for Linux x86-64会看到两个 zip 分卷加起来大约 2.8 GB。下载完一定要先校验不要直接解压安装。校验命令很简单sha256sum LINUX.X64_193000_db_home.zip*把输出的哈希值和官网页面上的 SHA-256 值比对一下一致再继续。这一步很多人忽略其实挺重要因为安装包在公网传输过程中一旦损坏安装时可能报各种莫名其妙的错误比如unzip: cannot find zipfile directory或者安装过程中file dol not found这类奇怪问题排查起来非常浪费时间。我个人的建议是尽量别用第三方网盘下载。Oracle 安装包动辄几个 GB第三方来源的安全性和完整性都没法保证万一里面被塞了点东西装到一个内网核心系统上后果不是省那点时间能补偿的。2.2 Linux 前置条件依赖、内核参数与目录规划安装 Oracle 19c 之前系统层面的准备比想象中琐碎。如果你用的是 Oracle Linux官方提供了预安装包一条命令就能把依赖和内核参数都配好yum install -y oracle-database-preinstall-19c但如果你的环境是用 RHEL 或者 CentOS建议还是手动把依赖包装齐全。关键包大约有这些binutils、glibc、glibc-devel、libaio、libaio-devel、libXext、libXtst、libXrender、ksh、sysstat、compat-libcap1等。缺哪个装哪个不用一上来就指望某个包能解决所有问题。内核参数是另一个重点。如果预安装包没帮你配我会按下面这套常用值手动加到/etc/sysctl.conf然后执行sysctl -p让它生效参数推荐值fs.file-max6815744fs.aio-max-nr1048576kernel.semmsl32000kernel.semmns1536000kernel.semopm6000kernel.semmni142net.ipv4.ip_local_port_range9000 65500vm.swappiness10这些参数不是越多越好而是要让系统能支撑 Oracle 的文件句柄、信号量和网络连接需求。比如kernel.sem的第一个值 32000表示每个信号量集的信号量数上限数据库并发进程一多这个值太小会直接影响后台进程创建。接下来是创建安装用户和目录。19c 不允许直接用 root 安装必须创建一个专门的oracle用户groupadd oinstall groupadd dba useradd -g oinstall -G dba -m oracle mkdir -p /u01/app/oracle chown -R oracle:oinstall /u01/app/oracle我个人习惯把ORACLE_BASE放在/u01/app/oracle软件路径放/u01/app/oracle/product/19.3.0/dbhome_1。不推荐所有东西都塞在根目录下后面补丁和日志一多根分区很容易被撑爆。最后别忘了处理 SELinux 和防火墙。内网测试环境可以直接把 SELinux 设为 permissive防火墙放行 1521 端口否则后面监听服务很容易“起来但连不上”。2.3 实测安装与环境变量配置准备就绪后把两个 zip 分卷解压到同一个目录然后用oracle用户进入安装目录直接运行./runInstaller。如果服务器没有图形界面可以用 X 转发或者用响应文件静默安装。我更推荐先“只装软件”再“DBCA 建库”两步走这样安装和建库可以分开排查出问题的时候定位更清楚。安装过程中有一步会提示你执行root.sh千万别跳过。很多新手装完软件后直接用结果权限没提上来后面建库报错或者监听启动失败基本都是漏了这步。执行方式是在 root 下跑cd /u01/app/oracle/product/19.3.0/dbhome_1 ./root.sh装完软件后记得给 oracle 用户配置环境变量。我一般放在/home/oracle/.bash_profile里export ORACLE_BASE/u01/app/oracle export ORACLE_HOME/u01/app/oracle/product/19.3.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib:/lib:/usr/lib export ORACLE_SIDorclORACLE_SID这个名字会和后面 DBCA 建库时的 SID 对应别随手填一个之后自己都忘了。配置完执行source ~/.bash_profile再用sqlplus / as sysdba试一下如果能进去说明软件环境基本正常。3. DBCA 创建单机 CDB 的实操记录3.1 图形界面 DBCA 关键选项软件装好之后创建数据库我习惯用 DBCA。直接跑dbca会弹图形向导。第一次用 19c 的人容易踩的一个点是选数据库模板时默认会帮你勾选“Create as Container Database”很多人没注意就直接下一步最后发现建出来的是 CDB里面还带了一个默认 PDB。我建议选 Advanced configuration虽然比标准模式多几步但能自己控制 PDB 数量、内存、字符集、存储位置和归档方式后续省事很多。模板选 General Purpose数据库名称可以叫 orclSID 也设 orcl重点在下一步勾选“Create as Container Database”后在 Pluggable Database Name 里填一个 PDB 的名字比如 orclpdb1。字符集这里要特别强调新系统直接用 AL32UTF8 基本没毛病但如果老库是 ZHS16GBK且有大量历史数据需要迁移不要拍脑袋选字符集先在测试环境做一个小规模导入测试看中文数据有没有乱码再定。字符集建库之后想改非常痛苦甚至可能只能重建库所以这一步多花点时间绝对值得。内存方面如果是开发测试机我用 Automatic Memory Management 让 Oracle 自己管理省心如果是生产库我更倾向手动设置 SGA 和 PGA比如 SGA4G、PGA2G避免数据库把服务器内存吃满导致操作系统 swap 频繁。3.2 静默方式建库命令有些服务器没有图形环境DBCA 也可以完全静默执行。下面是我实际用过的命令逻辑上和图形向导是一样的dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname orcl \ -sid orcl \ -createAsContainerDatabase true \ -numberOfPDBs 1 \ -pdbName orclpdb1 \ -pdbAdminPassword Oracle123456 \ -sysPassword Oracle123456 \ -systemPassword Oracle123456 \ -characterSet AL32UTF8 \ -totalMemory 6000 \ -emConfiguration NONE注意密码强度Oracle 19c 的默认密码策略比较严格如果用了太短的密码DBCA 会在最后报 ORA-28003 之类的错误。上面示例里的密码已经包含大小写和数字实际使用可以根据公司规范调整。如果嫌密码策略太麻烦也可以在建库后修改 profile但我不建议直接关掉密码复杂度安全评估的时候会很难看。静默建库过程中日志会输出到/u01/app/oracle/cfgtoollogs/dbca/目录。如果建库卡住或者失败不要只看终端最后一行去那个目录下翻日志才能看到真正的原因。3.3 创建后的基础验证建完库后我习惯先做一轮基础验证确认 CDB、PDB、监听都正常再交付给开发。第一步用sqlplus / as sysdba登录执行show pdbs;正常情况下会看到PDB$SEED和你建的ORCLPDB1。如果你的业务数据要放在 PDB 里下一步是打开 PDB 并保存状态alter pluggable database orclpdb1 open; alter pluggable database orclpdb1 save state;save state的作用是让 PDB 在数据库实例重启后自动保持打开状态。没有这一步你重启 CDB 之后PDB 可能还是 MOUNTED 状态应用一连接就被拒。这个坑在 11g 时代不存在所以很多老 DBA 刚转 19c 时会忽略。然后验证监听和服务注册lsnrctl status如果看到orclpdb1以 service 形式注册在监听里说明网络侧基本没问题。最后再用 easy connect 方式连一次 PDBsqlplus sys/Oracle123456//localhost:1521/orclpdb1 as sysdba能进入说明一套单机 CDB/PDB 环境算是建好了。4. 监听、连接与常见工具排障4.1 监听服务无法启动的检查清单监听服务无法启动算是我遇到最多的求助问题。很多人一看到 TNS-12541 就急着改listener.ora其实大部分原因都是主机名解析、环境变量或端口占用。我一般按下面这个顺序排查先看进程和状态ps -ef | grep tnslsnr lsnrctl status如果lsnrctl status报 no listener说明进程根本没起来再看日志/u01/app/oracle/product/19.3.0/dbhome_1/network/log/listener.log。接下来检查/etc/hosts和主机名hostname cat /etc/hosts一个很常见的坑是/etc/hosts里把主机名解析到 IPv6 的::1上了导致监听器绑定到 IPv6 地址客户端用 IPv4 地址连不上表现就是连接超时或 TNS-12170。我这次就遇到这个问题改成127.0.0.1 主机名之后重启 listener 就好了。然后检查端口冲突netstat -tlnp | grep 1521如果 1521 被别的进程占了要么杀掉占用进程要么改监听端口。最后确认防火墙状态systemctl status firewalld开发环境直接systemctl stop firewalld省心但生产环境还是建议放行端口而不是关防火墙。4.2 tnsnames.ora 和 sqlnet.ora 的常用坑连接出错时tnsnames.ora是最容易被甩锅的文件。其实它本身很简单就是给数据库服务起一个别名。真正的问题往往出在别名背后的SERVICE_NAME写没写对。19c 环境下如果业务在 PDB 里tnsnames 的SERVICE_NAME必须是 PDB 的服务名而不是 CDB 的名字。比如ORCLPDB1 (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.10)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME orclpdb1)))如果你写成SID orcl很容易连到 CDB然后发现业务用户不存在或者 PDB 没打开时直接报 ORA-01033。排查这种问题最快的方式是绕过 tnsnames用 easy connect 直接连一次sqlplus system/Oracle123456192.168.1.10:1521/orclpdb1这条命令能连上说明监听和 PDB 都没问题那就是 tnsnames 配置的事。另外sqlnet.ora里如果写了SQLNET.AUTHENTICATION_SERVICES(NONE)本机用sqlplus / as sysdba可能会报 ORA-01031因为禁用了系统认证。19c 上我一般保留默认或者用(ALL)除非有特殊安全需求。4.3 Navicat 闪退、DBeaver 驱动和 ORA-28547客户端工具这一块我实测下来最典型的有三个问题而且都是新手高频踩坑。第一个是 Navicat 12 一打开 Oracle 数据库就闪退。这个大概率是本机没有安装 Oracle Client或者 OCI 库版本和 Navicat 的位数不匹配。解决办法是下载对应位数的 Oracle Instant Client比如 Windows x64 就下instantclient-basic-windows.x64-19.x解压后打开 Navicat 的“工具 - 选项 - 环境”把 OCI 指向解压目录里的oci.dll。如果 Navicat 本身是 32 位那必须用 32 位的 Instant Client否则打开连接一样会崩。第二个是 DBeaver 连 19c 报驱动找不到或版本太旧。新版 DBeaver 虽然自带 Oracle 驱动但经常连不上 19c原因无非是驱动太老。解决办法是手动下载ojdbc8.jar或ojdbc11.jar在 DBeaver 的“数据库 - 驱动管理器 - Oracle”里把旧 jar 删掉添加你下载的 jar然后 URL 写成jdbc:oracle:thin://192.168.1.10:1521/orclpdb1第三个就是热词里反复出现的 ORA-28547connection to server failed, probable Oracle Net admin error。这个报错常见于用 OCI 方式连接时比如 Navicat、PL/SQL Developer 等工具多数原因是本机 Instant Client 和服务器端 Oracle Net 版本不一致或者TNS_ADMIN环境变量指向了一个不存在的目录。检查一下本机的TNS_ADMIN是否指向tnsnames.ora所在目录以及 Instant Client 版本是否和数据库大版本接近基本能解决。还有一个老生常谈的问题Windows 上装过 11g 或 12c再装 19c 时提示“已存在 Oracle 环境”其实是卸载不干净。注册表里HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE还有残留服务也没有删干净。可以先把服务停掉再用sc delete OracleServiceXXX删掉残留服务最后清理注册表和安装目录。这个动作风险比较大操作前一定要先备份相关注册表项。5. SQL 开发侧高频笔记5.1 分页、存储过程与 trunc(sysdate)如果是从 MySQL 转过来写 Oracle分页可能是第一个不适应的点。MySQL 用LIMIT offset, rowsOracle 11g 时代只能用ROWNUM而且稍不注意就写错。到了 19c终于可以直接用FETCH FIRST语法了SELECT * FROM employees ORDER BY employee_id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;这句话的意思是跳过 20 行取接下来 10 行等价于 MySQL 的LIMIT 20, 10。但有个细节要注意ORDER BY的字段最好能唯一确定排序否则分页结果可能重复或丢失。比如按employee_id排就比按hire_date排更稳因为 hire_date 可能有大量同一天数据排序不稳定。存储过程的基本写法和 11g 时代差别不大但新手经常忘记一件事在 SQL*Plus 里看不到dbms_output的输出是因为默认没开。要先执行set serveroutput on。一个最简单的示例CREATE OR REPLACE PROCEDURE p_hello IS BEGIN dbms_output.put_line(hello 19c); END; /日期处理方面TRUNC(SYSDATE)是报表里最常用的函数之一。它会把系统当前时间截断到当天的零点。配合不同参数还能截断到其他粒度-- 当天零点 select trunc(sysdate) from dual; -- 当月第一天 select trunc(sysdate, MM) from dual; -- 当年第一天 select trunc(sysdate, YYYY) from dual; -- 本周一 select trunc(sysdate, IW) from dual;这个函数特别适合用来做“今天、本周、本月”的统计条件比如查当天订单直接在 where 里写order_date trunc(sysdate) and order_date trunc(sysdate) 1比用to_char比较字符串高效得多而且能正确利用索引。5.2 dual、拆分列与“重复则不插入”dual这个表在 Oracle 里非常特殊它只有一个字段DUMMY和一行数据主要用来执行那些不需要从业务表查询的 SQL比如取序列、算日期、拼字符串select seq_test.nextval from dual; select 1 1 from dual;有朋友问 dual 最多能存多大、能存多少数据这个问题的本质是dual 是一张系统内部表业务数据就不应该往里面放。如果你真的往 dual 里插入多行之后再用select 1 from dual这种写法返回的行数可能变成多行应用层逻辑直接出问题。所以记住一句话dual 不是业务表也不要做容量规划它天生就该是单行单列。按逗号拆分列为多行这也是开发里经常遇到的需求。比如一张表里有个字段存了a,b,c你想拆成三行。19c 下用regexp_substr配合connect by很方便SELECT trim(regexp_substr(a,b,c, [^,], 1, level)) FROM dual CONNECT BY level regexp_count(a,b,c, ,) 1;这个语句的原理是根据逗号个数算出要拆成几行然后逐层把第 1 个、第 2 个、第 3 个逗号分隔的子串取出来。实际使用时要注意如果每个值之间可能有空格记得加trim如果分隔符不止逗号一个字符regexp_substr的模式串也要同步调整。“插入数据重复则不插入”这个需求也很常见。最简单的方式是not existsINSERT INTO t_user(id, name) SELECT 1, 张三 FROM dual WHERE NOT EXISTS (SELECT 1 FROM t_user WHERE id 1);更正规的做法是用MERGE尤其当你要同时处理“存在则更新、不存在则插入”时MERGE比两条 SQL 优雅得多。但要注意MERGE在并发场景下仍然需要唯一约束兜底否则两个会话同时执行还是可能插入重复数据。5.3 身份证科学计数法与 MySQL 语法的差异“Oracle 数据库 SQL 导出的身份证信息是科学计数法”这个热搜词其实问题不在 Oracle而在导出工具和 Excel。18 位身份证号在 Excel 里默认被当成数字超过 15 位后第 16 位起变成 0再超过一定长度就自动显示成科学计数法。我之前遇到这种问题最简单的解决办法是在 SQL 查询里拼接一个制表符或引号让 Excel 把它当文本处理SELECT \t || id_card FROM t_user;或者SELECT || id_card || FROM t_user;导出到 CSV 后Excel 打开时身份证就能完整显示。更规范的做法是在 Excel 导入向导里把该列指定为“文本”格式或者先用记事本打开 CSV再通过“数据 - 自文本导入”按向导导入并且把这一列设置为文本。最后简单说说 MySQL 和 Oracle 的主要语法差异。分页一个用LIMIT一个用FETCH FIRST或ROWNUM字符串拼接 MySQL 用CONCAT()或||Oracle 用||空值排序 MySQL 默认 NULL 排最前Oracle 默认 NULL 排最后自增列 MySQL 用AUTO_INCREMENTOracle 用序列或 12c 之后新增的 Identity 列。这些差异在团队切换数据库时最容易引发低级 bug建议统一整理一份对照表。6. DataGuard、ASM 与等保运维速查6.1 DataGuard 主备切换与 gap 处理如果业务对可用性要求高19c 环境下我一般会搭 DataGuard。主备切换的命令本身不算复杂但真正麻烦的是切换前后出现日志断层也就是热词里提到的 “resolvable gap”。先说切换的基本语法。主库转为备库ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;备库转为主库ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;切换之前必须先确认两边的角色和状态都符合预期否则很可能半路卡死。我的习惯是在主库查SELECT database_role, open_mode FROM v$database;备库需要处于MOUNTED并已经启动 MRP 日志应用。切换时如果出现 gap通常的表现是备库的v$archive_gap视图有记录SELECT * FROM v$archive_gap;看到结果里显示的 thread 号和缺失的低位、高位日志序号就需要从主库找到对应区间内的归档日志复制到备库然后在备库执行ALTER DATABASE REGISTER PHYSICAL LOGFILE /u01/arch/1_100_123456.arc;注册完再启动日志应用RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;如果 gap 的根源是备库闪回区或归档目录满了就算你手动补了日志过一阵还会有新的 gap。所以实际排障时要先看磁盘空间再补日志不要一上来就埋头复制归档。6.2 ASM 基础命令与进入方式19c 里头 ASM 通常用在 RAC 或企业级单机环境。如果只是普通文件系统安装根本不需要 ASM。但一旦用上了很多人卡在“不知道从哪里看 ASM 的状态”。ASM 实例和普通数据库实例不一样日常管理要用grid用户不是oracle用户。进入 ASM 有两种方式。一种是用 ASM 命令行工具su - grid asmcmd进入后可以先看磁盘组lsdg这个命令会显示磁盘组的名称、状态、冗余级别、可用空间等。再看具体文件目录ls DATA/ORCL/DATAFILE另一种是在 SQL*Plus 里以 sysasm 身份登录sqlplus / as sysasm然后查磁盘组状态SELECT name, state, type FROM v$asm_diskgroup;管理 ASM 时要小心权限不要用sysdba去连接 ASM 实例很多操作会直接报 insufficient privileges。6.3 等保测评常用检查命令数据库过等保时经常需要提供给测评方一些基础信息和配置项。这里把我常用的几条命令整理一下。版本信息SELECT banner FROM v$version;补丁信息$ORACLE_HOME/OPatch/opatch lspatches密码策略SHOW PARAMETER password_life_time; SHOW PARAMETER failed_login_attempts; SHOW PARAMETER idle_time;审计配置SHOW PARAMETER audit_trail;用户状态SELECT username, account_status, lock_date, expiry_date FROM dba_users;这些命令不复杂但测评前一定要提前跑一遍确认结果不是默认的空值或 0。比如audit_trail如果是NONE审计就相当于没开password_life_time如果是UNLIMITED密码过期策略就不合规。等保整改时重点也是把这些参数调到符合公司安全基线。7. 我踩过的坑和最后建议7.1 几个值得记住的经验这次 19c 迁移踩过最大的坑是/etc/hosts把主机名解析到 IPv6导致lsnrctl status显示监听正常但客户端怎么都连不上。这种问题最恶心因为服务器本地tnsping可能是通的应用侧却超时。所以装 19c 之前一定要先确认主机名和/etc/hosts是清晰、一致的不要等建完库再来查网络。另一个让我印象深刻的点是连接方式要从 SID 思维切换到 SERVICE_NAME 思维。19c 默认是容器数据库连接 PDB 必须用 service name如果业务代码里面还写着老式的SIDorcl连接大概率会出问题。特别是 Java 应用里的 JDBC URL一定要确认用的是 service name 而不是 SID。最后一个建议是升级前无论如何先做一次 expdp 全库导出。这不仅是为了备份更是为了提前看到哪些对象可能不兼容、哪些索引会有异常、哪些类型转换在目标库会失败。相比上线后才发现问题导出过程暴露问题已经算很温柔了。7.2 给新手的路线建议如果你以前只玩过 11g准备上手 19c我的建议是先别急着管 RAC、DataGuard、ASM 这些高级话题先把单机 CDB/PDB 的安装建库流程完整走一遍。重点理解几个命令和场景show pdbs、DBCA 创建 PDB、alter pluggable database ... open、连接 PDB 的 service_name、监听日志排查。这些都通了再看自动索引、PDB 热克隆、DataGuard 的维护会顺利很多。我个人在实际操作中的体会是19c 与其说是一个新数据库版本不如说是一套更强调整合和自动化的运维理念。如果你一直用 11g 的习惯去操作 19c那确实会觉得处处别扭但一旦接受了 CDB/PDB 的模型再看数据整合、资源隔离、在线克隆这些能力就会明白 Oracle 把方向押在多租户上是有道理的值得花时间把基础打牢。
上个月接手了一套 Oracle 11g 老系统的升级客户提的需求很直接数据库换到 Oracle 19c。我原以为这就是一次常规的“装新版、导数据”操作真正做下来才发现19c 和 11g 的差距比想象中大不少尤其是 CDB/PDB 多租户架构几乎影响了从建库到连接的所有操作习惯。这篇文章就是整套实操笔记包含我从下载 Oracle 19c 安装包、搞定“没有 Oracle 账户也能下载”的问题到 DBCA 创建单机 CDB、处理监听服务无法启动、排查 ORA-28547、配置 DBeaver/Navicat再到日常 SQL 写法和 DataGuard 主备切换的完整过程。准备上 19c 的运维、正在做版本评估的 DBA以及被 Oracle 各种连接报错折磨的开发同学都可以直接参考。1. 为什么选 19c从选型到升级思路1.1 19c 到底改了什么Oracle 19c 虽然叫 19c但本质上属于 12c 产品线是 Oracle 12.2 的延续版本只不过后来 Oracle 改用年份命名。它最特殊的地方在于它是 12c/18c 这个系列里明确给出的长期支持版本补丁维护周期比其他版本长很多所以现在很多新项目直接把它当成默认选项。比起 11g19c 最核心的变化是多租户架构。11g 时代“一个实例就是一个数据库”到了 19c一个实例里可以装一个 CDB容器数据库CDB 下面再挂多个 PDB可插拔数据库。除此之外19c 在自动化上也推进了不少比如自动索引、内存列存储、更细粒度的资源管理以及 PDB 级别的在线克隆和刷新。对一线 DBA 来说最直观的感受就是show pdbs这个命令变得高频了登录之后第一件事不再是select name from v$database而是先看自己在哪个容器里。从实际运维角度看19c 相比 11g 的稳定性更好坏块检测、统计信息收集、SQL 计划管理这些基础能力都有加强。如果你还在 11g 上扛着与其等到支持到期被催着迁移不如找一台测试机先把 19c 的节奏踩一遍后续真正搬迁时会从容很多。1.2 CDB/PDB 架构怎么理解很多第一次接触 19c 的人会被 CDB、PDB 这两个缩写绕晕。我的理解方式是CDB 相当于整栋公寓楼PDB 就是楼里的一套套独立房间。每套房都有自己独立的家具、水电表从外面看是一栋楼但每户人家关起门来完全是自己的空间。对应到数据库上一个 CDB 实例承载多个 PDB每个 PDB 对外部用户来说就像是一个独立数据库有自己的数据文件、表空间、用户、权限。管理员登录 CDB 根容器之后可以统一管理所有 PDB业务用户则往往只看到自己所在的 PDB。这个架构带来的第一个坑就是连接方式。很多人沿用 11g 的习惯tnsnames 里只写一个 SID结果连上之后发现业务用户不在当前容器里或者直接报 ORA-12514。正确做法是连 PDB 时用 PDB 的 service_name比如//host:1521/orclpdb1而不是用 CDB 的实例名。这个后面我会专门展开。1.3 哪些场景不建议直接上 19c虽说 19c 是长期支持版但它不是万能药有几个场景我建议谨慎评估。第一老库用了大量 11g 时代的内部包或非常规写法比如依赖sys.x$表做监控、大量使用触发器改数据、用了不规范的并行 DML这些逻辑在迁移到 PDB 之后很可能会出现权限或隔离层面的问题。第二第三方商业软件如果没有官方 19c 认证哪怕数据库本身能装上去应用层也可能在某个隐蔽功能上报错。第三如果公司只有两三个几十 GB 的小库又完全没有整合需求那从 11g 直接升 19c 的意义不大反而要承担应用改造的成本。我这次迁移采取的方案是先在另外一套环境装好 19c再用 expdp/impdp 做逻辑迁移。虽然大数据量下速度不如 DataGuard 物理迁移但更容易提前暴露出对象兼容性和字符集问题。如果你想要停机时间更短可以考虑 DataGuard 的方式前提是两套环境 Endian 一致、数据库版本都在支持的升级路径上。2. 安装部署全流程笔记2.1 下载安装包与账号问题先解决很多新手卡住的第一关没有 Oracle 账户怎么下载 19c。Oracle 官方下载确实需要登录但注册本身只需要一个能收邮件的邮箱不需要付费。打开 Oracle Software Downloads 页面选 Database再选 Oracle Database 19c for Linux x86-64会看到两个 zip 分卷加起来大约 2.8 GB。下载完一定要先校验不要直接解压安装。校验命令很简单sha256sum LINUX.X64_193000_db_home.zip*把输出的哈希值和官网页面上的 SHA-256 值比对一下一致再继续。这一步很多人忽略其实挺重要因为安装包在公网传输过程中一旦损坏安装时可能报各种莫名其妙的错误比如unzip: cannot find zipfile directory或者安装过程中file dol not found这类奇怪问题排查起来非常浪费时间。我个人的建议是尽量别用第三方网盘下载。Oracle 安装包动辄几个 GB第三方来源的安全性和完整性都没法保证万一里面被塞了点东西装到一个内网核心系统上后果不是省那点时间能补偿的。2.2 Linux 前置条件依赖、内核参数与目录规划安装 Oracle 19c 之前系统层面的准备比想象中琐碎。如果你用的是 Oracle Linux官方提供了预安装包一条命令就能把依赖和内核参数都配好yum install -y oracle-database-preinstall-19c但如果你的环境是用 RHEL 或者 CentOS建议还是手动把依赖包装齐全。关键包大约有这些binutils、glibc、glibc-devel、libaio、libaio-devel、libXext、libXtst、libXrender、ksh、sysstat、compat-libcap1等。缺哪个装哪个不用一上来就指望某个包能解决所有问题。内核参数是另一个重点。如果预安装包没帮你配我会按下面这套常用值手动加到/etc/sysctl.conf然后执行sysctl -p让它生效参数推荐值fs.file-max6815744fs.aio-max-nr1048576kernel.semmsl32000kernel.semmns1536000kernel.semopm6000kernel.semmni142net.ipv4.ip_local_port_range9000 65500vm.swappiness10这些参数不是越多越好而是要让系统能支撑 Oracle 的文件句柄、信号量和网络连接需求。比如kernel.sem的第一个值 32000表示每个信号量集的信号量数上限数据库并发进程一多这个值太小会直接影响后台进程创建。接下来是创建安装用户和目录。19c 不允许直接用 root 安装必须创建一个专门的oracle用户groupadd oinstall groupadd dba useradd -g oinstall -G dba -m oracle mkdir -p /u01/app/oracle chown -R oracle:oinstall /u01/app/oracle我个人习惯把ORACLE_BASE放在/u01/app/oracle软件路径放/u01/app/oracle/product/19.3.0/dbhome_1。不推荐所有东西都塞在根目录下后面补丁和日志一多根分区很容易被撑爆。最后别忘了处理 SELinux 和防火墙。内网测试环境可以直接把 SELinux 设为 permissive防火墙放行 1521 端口否则后面监听服务很容易“起来但连不上”。2.3 实测安装与环境变量配置准备就绪后把两个 zip 分卷解压到同一个目录然后用oracle用户进入安装目录直接运行./runInstaller。如果服务器没有图形界面可以用 X 转发或者用响应文件静默安装。我更推荐先“只装软件”再“DBCA 建库”两步走这样安装和建库可以分开排查出问题的时候定位更清楚。安装过程中有一步会提示你执行root.sh千万别跳过。很多新手装完软件后直接用结果权限没提上来后面建库报错或者监听启动失败基本都是漏了这步。执行方式是在 root 下跑cd /u01/app/oracle/product/19.3.0/dbhome_1 ./root.sh装完软件后记得给 oracle 用户配置环境变量。我一般放在/home/oracle/.bash_profile里export ORACLE_BASE/u01/app/oracle export ORACLE_HOME/u01/app/oracle/product/19.3.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib:/lib:/usr/lib export ORACLE_SIDorclORACLE_SID这个名字会和后面 DBCA 建库时的 SID 对应别随手填一个之后自己都忘了。配置完执行source ~/.bash_profile再用sqlplus / as sysdba试一下如果能进去说明软件环境基本正常。3. DBCA 创建单机 CDB 的实操记录3.1 图形界面 DBCA 关键选项软件装好之后创建数据库我习惯用 DBCA。直接跑dbca会弹图形向导。第一次用 19c 的人容易踩的一个点是选数据库模板时默认会帮你勾选“Create as Container Database”很多人没注意就直接下一步最后发现建出来的是 CDB里面还带了一个默认 PDB。我建议选 Advanced configuration虽然比标准模式多几步但能自己控制 PDB 数量、内存、字符集、存储位置和归档方式后续省事很多。模板选 General Purpose数据库名称可以叫 orclSID 也设 orcl重点在下一步勾选“Create as Container Database”后在 Pluggable Database Name 里填一个 PDB 的名字比如 orclpdb1。字符集这里要特别强调新系统直接用 AL32UTF8 基本没毛病但如果老库是 ZHS16GBK且有大量历史数据需要迁移不要拍脑袋选字符集先在测试环境做一个小规模导入测试看中文数据有没有乱码再定。字符集建库之后想改非常痛苦甚至可能只能重建库所以这一步多花点时间绝对值得。内存方面如果是开发测试机我用 Automatic Memory Management 让 Oracle 自己管理省心如果是生产库我更倾向手动设置 SGA 和 PGA比如 SGA4G、PGA2G避免数据库把服务器内存吃满导致操作系统 swap 频繁。3.2 静默方式建库命令有些服务器没有图形环境DBCA 也可以完全静默执行。下面是我实际用过的命令逻辑上和图形向导是一样的dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname orcl \ -sid orcl \ -createAsContainerDatabase true \ -numberOfPDBs 1 \ -pdbName orclpdb1 \ -pdbAdminPassword Oracle123456 \ -sysPassword Oracle123456 \ -systemPassword Oracle123456 \ -characterSet AL32UTF8 \ -totalMemory 6000 \ -emConfiguration NONE注意密码强度Oracle 19c 的默认密码策略比较严格如果用了太短的密码DBCA 会在最后报 ORA-28003 之类的错误。上面示例里的密码已经包含大小写和数字实际使用可以根据公司规范调整。如果嫌密码策略太麻烦也可以在建库后修改 profile但我不建议直接关掉密码复杂度安全评估的时候会很难看。静默建库过程中日志会输出到/u01/app/oracle/cfgtoollogs/dbca/目录。如果建库卡住或者失败不要只看终端最后一行去那个目录下翻日志才能看到真正的原因。3.3 创建后的基础验证建完库后我习惯先做一轮基础验证确认 CDB、PDB、监听都正常再交付给开发。第一步用sqlplus / as sysdba登录执行show pdbs;正常情况下会看到PDB$SEED和你建的ORCLPDB1。如果你的业务数据要放在 PDB 里下一步是打开 PDB 并保存状态alter pluggable database orclpdb1 open; alter pluggable database orclpdb1 save state;save state的作用是让 PDB 在数据库实例重启后自动保持打开状态。没有这一步你重启 CDB 之后PDB 可能还是 MOUNTED 状态应用一连接就被拒。这个坑在 11g 时代不存在所以很多老 DBA 刚转 19c 时会忽略。然后验证监听和服务注册lsnrctl status如果看到orclpdb1以 service 形式注册在监听里说明网络侧基本没问题。最后再用 easy connect 方式连一次 PDBsqlplus sys/Oracle123456//localhost:1521/orclpdb1 as sysdba能进入说明一套单机 CDB/PDB 环境算是建好了。4. 监听、连接与常见工具排障4.1 监听服务无法启动的检查清单监听服务无法启动算是我遇到最多的求助问题。很多人一看到 TNS-12541 就急着改listener.ora其实大部分原因都是主机名解析、环境变量或端口占用。我一般按下面这个顺序排查先看进程和状态ps -ef | grep tnslsnr lsnrctl status如果lsnrctl status报 no listener说明进程根本没起来再看日志/u01/app/oracle/product/19.3.0/dbhome_1/network/log/listener.log。接下来检查/etc/hosts和主机名hostname cat /etc/hosts一个很常见的坑是/etc/hosts里把主机名解析到 IPv6 的::1上了导致监听器绑定到 IPv6 地址客户端用 IPv4 地址连不上表现就是连接超时或 TNS-12170。我这次就遇到这个问题改成127.0.0.1 主机名之后重启 listener 就好了。然后检查端口冲突netstat -tlnp | grep 1521如果 1521 被别的进程占了要么杀掉占用进程要么改监听端口。最后确认防火墙状态systemctl status firewalld开发环境直接systemctl stop firewalld省心但生产环境还是建议放行端口而不是关防火墙。4.2 tnsnames.ora 和 sqlnet.ora 的常用坑连接出错时tnsnames.ora是最容易被甩锅的文件。其实它本身很简单就是给数据库服务起一个别名。真正的问题往往出在别名背后的SERVICE_NAME写没写对。19c 环境下如果业务在 PDB 里tnsnames 的SERVICE_NAME必须是 PDB 的服务名而不是 CDB 的名字。比如ORCLPDB1 (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.10)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME orclpdb1)))如果你写成SID orcl很容易连到 CDB然后发现业务用户不存在或者 PDB 没打开时直接报 ORA-01033。排查这种问题最快的方式是绕过 tnsnames用 easy connect 直接连一次sqlplus system/Oracle123456192.168.1.10:1521/orclpdb1这条命令能连上说明监听和 PDB 都没问题那就是 tnsnames 配置的事。另外sqlnet.ora里如果写了SQLNET.AUTHENTICATION_SERVICES(NONE)本机用sqlplus / as sysdba可能会报 ORA-01031因为禁用了系统认证。19c 上我一般保留默认或者用(ALL)除非有特殊安全需求。4.3 Navicat 闪退、DBeaver 驱动和 ORA-28547客户端工具这一块我实测下来最典型的有三个问题而且都是新手高频踩坑。第一个是 Navicat 12 一打开 Oracle 数据库就闪退。这个大概率是本机没有安装 Oracle Client或者 OCI 库版本和 Navicat 的位数不匹配。解决办法是下载对应位数的 Oracle Instant Client比如 Windows x64 就下instantclient-basic-windows.x64-19.x解压后打开 Navicat 的“工具 - 选项 - 环境”把 OCI 指向解压目录里的oci.dll。如果 Navicat 本身是 32 位那必须用 32 位的 Instant Client否则打开连接一样会崩。第二个是 DBeaver 连 19c 报驱动找不到或版本太旧。新版 DBeaver 虽然自带 Oracle 驱动但经常连不上 19c原因无非是驱动太老。解决办法是手动下载ojdbc8.jar或ojdbc11.jar在 DBeaver 的“数据库 - 驱动管理器 - Oracle”里把旧 jar 删掉添加你下载的 jar然后 URL 写成jdbc:oracle:thin://192.168.1.10:1521/orclpdb1第三个就是热词里反复出现的 ORA-28547connection to server failed, probable Oracle Net admin error。这个报错常见于用 OCI 方式连接时比如 Navicat、PL/SQL Developer 等工具多数原因是本机 Instant Client 和服务器端 Oracle Net 版本不一致或者TNS_ADMIN环境变量指向了一个不存在的目录。检查一下本机的TNS_ADMIN是否指向tnsnames.ora所在目录以及 Instant Client 版本是否和数据库大版本接近基本能解决。还有一个老生常谈的问题Windows 上装过 11g 或 12c再装 19c 时提示“已存在 Oracle 环境”其实是卸载不干净。注册表里HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE还有残留服务也没有删干净。可以先把服务停掉再用sc delete OracleServiceXXX删掉残留服务最后清理注册表和安装目录。这个动作风险比较大操作前一定要先备份相关注册表项。5. SQL 开发侧高频笔记5.1 分页、存储过程与 trunc(sysdate)如果是从 MySQL 转过来写 Oracle分页可能是第一个不适应的点。MySQL 用LIMIT offset, rowsOracle 11g 时代只能用ROWNUM而且稍不注意就写错。到了 19c终于可以直接用FETCH FIRST语法了SELECT * FROM employees ORDER BY employee_id OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;这句话的意思是跳过 20 行取接下来 10 行等价于 MySQL 的LIMIT 20, 10。但有个细节要注意ORDER BY的字段最好能唯一确定排序否则分页结果可能重复或丢失。比如按employee_id排就比按hire_date排更稳因为 hire_date 可能有大量同一天数据排序不稳定。存储过程的基本写法和 11g 时代差别不大但新手经常忘记一件事在 SQL*Plus 里看不到dbms_output的输出是因为默认没开。要先执行set serveroutput on。一个最简单的示例CREATE OR REPLACE PROCEDURE p_hello IS BEGIN dbms_output.put_line(hello 19c); END; /日期处理方面TRUNC(SYSDATE)是报表里最常用的函数之一。它会把系统当前时间截断到当天的零点。配合不同参数还能截断到其他粒度-- 当天零点 select trunc(sysdate) from dual; -- 当月第一天 select trunc(sysdate, MM) from dual; -- 当年第一天 select trunc(sysdate, YYYY) from dual; -- 本周一 select trunc(sysdate, IW) from dual;这个函数特别适合用来做“今天、本周、本月”的统计条件比如查当天订单直接在 where 里写order_date trunc(sysdate) and order_date trunc(sysdate) 1比用to_char比较字符串高效得多而且能正确利用索引。5.2 dual、拆分列与“重复则不插入”dual这个表在 Oracle 里非常特殊它只有一个字段DUMMY和一行数据主要用来执行那些不需要从业务表查询的 SQL比如取序列、算日期、拼字符串select seq_test.nextval from dual; select 1 1 from dual;有朋友问 dual 最多能存多大、能存多少数据这个问题的本质是dual 是一张系统内部表业务数据就不应该往里面放。如果你真的往 dual 里插入多行之后再用select 1 from dual这种写法返回的行数可能变成多行应用层逻辑直接出问题。所以记住一句话dual 不是业务表也不要做容量规划它天生就该是单行单列。按逗号拆分列为多行这也是开发里经常遇到的需求。比如一张表里有个字段存了a,b,c你想拆成三行。19c 下用regexp_substr配合connect by很方便SELECT trim(regexp_substr(a,b,c, [^,], 1, level)) FROM dual CONNECT BY level regexp_count(a,b,c, ,) 1;这个语句的原理是根据逗号个数算出要拆成几行然后逐层把第 1 个、第 2 个、第 3 个逗号分隔的子串取出来。实际使用时要注意如果每个值之间可能有空格记得加trim如果分隔符不止逗号一个字符regexp_substr的模式串也要同步调整。“插入数据重复则不插入”这个需求也很常见。最简单的方式是not existsINSERT INTO t_user(id, name) SELECT 1, 张三 FROM dual WHERE NOT EXISTS (SELECT 1 FROM t_user WHERE id 1);更正规的做法是用MERGE尤其当你要同时处理“存在则更新、不存在则插入”时MERGE比两条 SQL 优雅得多。但要注意MERGE在并发场景下仍然需要唯一约束兜底否则两个会话同时执行还是可能插入重复数据。5.3 身份证科学计数法与 MySQL 语法的差异“Oracle 数据库 SQL 导出的身份证信息是科学计数法”这个热搜词其实问题不在 Oracle而在导出工具和 Excel。18 位身份证号在 Excel 里默认被当成数字超过 15 位后第 16 位起变成 0再超过一定长度就自动显示成科学计数法。我之前遇到这种问题最简单的解决办法是在 SQL 查询里拼接一个制表符或引号让 Excel 把它当文本处理SELECT \t || id_card FROM t_user;或者SELECT || id_card || FROM t_user;导出到 CSV 后Excel 打开时身份证就能完整显示。更规范的做法是在 Excel 导入向导里把该列指定为“文本”格式或者先用记事本打开 CSV再通过“数据 - 自文本导入”按向导导入并且把这一列设置为文本。最后简单说说 MySQL 和 Oracle 的主要语法差异。分页一个用LIMIT一个用FETCH FIRST或ROWNUM字符串拼接 MySQL 用CONCAT()或||Oracle 用||空值排序 MySQL 默认 NULL 排最前Oracle 默认 NULL 排最后自增列 MySQL 用AUTO_INCREMENTOracle 用序列或 12c 之后新增的 Identity 列。这些差异在团队切换数据库时最容易引发低级 bug建议统一整理一份对照表。6. DataGuard、ASM 与等保运维速查6.1 DataGuard 主备切换与 gap 处理如果业务对可用性要求高19c 环境下我一般会搭 DataGuard。主备切换的命令本身不算复杂但真正麻烦的是切换前后出现日志断层也就是热词里提到的 “resolvable gap”。先说切换的基本语法。主库转为备库ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;备库转为主库ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;切换之前必须先确认两边的角色和状态都符合预期否则很可能半路卡死。我的习惯是在主库查SELECT database_role, open_mode FROM v$database;备库需要处于MOUNTED并已经启动 MRP 日志应用。切换时如果出现 gap通常的表现是备库的v$archive_gap视图有记录SELECT * FROM v$archive_gap;看到结果里显示的 thread 号和缺失的低位、高位日志序号就需要从主库找到对应区间内的归档日志复制到备库然后在备库执行ALTER DATABASE REGISTER PHYSICAL LOGFILE /u01/arch/1_100_123456.arc;注册完再启动日志应用RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;如果 gap 的根源是备库闪回区或归档目录满了就算你手动补了日志过一阵还会有新的 gap。所以实际排障时要先看磁盘空间再补日志不要一上来就埋头复制归档。6.2 ASM 基础命令与进入方式19c 里头 ASM 通常用在 RAC 或企业级单机环境。如果只是普通文件系统安装根本不需要 ASM。但一旦用上了很多人卡在“不知道从哪里看 ASM 的状态”。ASM 实例和普通数据库实例不一样日常管理要用grid用户不是oracle用户。进入 ASM 有两种方式。一种是用 ASM 命令行工具su - grid asmcmd进入后可以先看磁盘组lsdg这个命令会显示磁盘组的名称、状态、冗余级别、可用空间等。再看具体文件目录ls DATA/ORCL/DATAFILE另一种是在 SQL*Plus 里以 sysasm 身份登录sqlplus / as sysasm然后查磁盘组状态SELECT name, state, type FROM v$asm_diskgroup;管理 ASM 时要小心权限不要用sysdba去连接 ASM 实例很多操作会直接报 insufficient privileges。6.3 等保测评常用检查命令数据库过等保时经常需要提供给测评方一些基础信息和配置项。这里把我常用的几条命令整理一下。版本信息SELECT banner FROM v$version;补丁信息$ORACLE_HOME/OPatch/opatch lspatches密码策略SHOW PARAMETER password_life_time; SHOW PARAMETER failed_login_attempts; SHOW PARAMETER idle_time;审计配置SHOW PARAMETER audit_trail;用户状态SELECT username, account_status, lock_date, expiry_date FROM dba_users;这些命令不复杂但测评前一定要提前跑一遍确认结果不是默认的空值或 0。比如audit_trail如果是NONE审计就相当于没开password_life_time如果是UNLIMITED密码过期策略就不合规。等保整改时重点也是把这些参数调到符合公司安全基线。7. 我踩过的坑和最后建议7.1 几个值得记住的经验这次 19c 迁移踩过最大的坑是/etc/hosts把主机名解析到 IPv6导致lsnrctl status显示监听正常但客户端怎么都连不上。这种问题最恶心因为服务器本地tnsping可能是通的应用侧却超时。所以装 19c 之前一定要先确认主机名和/etc/hosts是清晰、一致的不要等建完库再来查网络。另一个让我印象深刻的点是连接方式要从 SID 思维切换到 SERVICE_NAME 思维。19c 默认是容器数据库连接 PDB 必须用 service name如果业务代码里面还写着老式的SIDorcl连接大概率会出问题。特别是 Java 应用里的 JDBC URL一定要确认用的是 service name 而不是 SID。最后一个建议是升级前无论如何先做一次 expdp 全库导出。这不仅是为了备份更是为了提前看到哪些对象可能不兼容、哪些索引会有异常、哪些类型转换在目标库会失败。相比上线后才发现问题导出过程暴露问题已经算很温柔了。7.2 给新手的路线建议如果你以前只玩过 11g准备上手 19c我的建议是先别急着管 RAC、DataGuard、ASM 这些高级话题先把单机 CDB/PDB 的安装建库流程完整走一遍。重点理解几个命令和场景show pdbs、DBCA 创建 PDB、alter pluggable database ... open、连接 PDB 的 service_name、监听日志排查。这些都通了再看自动索引、PDB 热克隆、DataGuard 的维护会顺利很多。我个人在实际操作中的体会是19c 与其说是一个新数据库版本不如说是一套更强调整合和自动化的运维理念。如果你一直用 11g 的习惯去操作 19c那确实会觉得处处别扭但一旦接受了 CDB/PDB 的模型再看数据整合、资源隔离、在线克隆这些能力就会明白 Oracle 把方向押在多租户上是有道理的值得花时间把基础打牢。
