1. 项目概述从11g到19c一次跨越十年的数据库升级之旅最近在社区里看到不少朋友还在为Oracle 11g的维护和性能问题头疼尤其是当业务系统发展到一定规模老版本的数据库在性能、安全性和新功能支持上开始显得力不从心。我手头刚完成一个核心业务系统从Oracle 11g到19c的迁移项目整个过程历时近一个月涉及数据量超过10TB算是把迁移路上的坑都踩了一遍。今天就把这次实战经验整理出来希望能给正在或计划进行类似升级的朋友们一个清晰的路线图。这次迁移不仅仅是换个版本号那么简单它涉及到兼容性评估、数据迁移策略选择、性能调优以及迁移后的验证每一个环节都需要谨慎对待。如果你正面临老旧系统升级、等保合规要求或是单纯想拥抱Oracle 19c带来的新特性比如多租户架构、自动索引、实时统计信息那么这篇从实战中总结出来的指南应该能帮到你。2. 迁移前的核心评估与准备工作在真正动手迁移数据之前充分的评估和准备是决定项目成败的关键。盲目开始操作很可能导致迁移失败、业务中断甚至数据丢失。这一阶段的工作其重要性不亚于迁移执行本身。2.1 深度兼容性分析与影响评估首先我们必须清醒地认识到从11g特别是11.2.0.4直接跳到19c中间跨越了12c和18c两个大版本这不仅仅是版本的升级更是架构和理念的演进。最核心的变化莫过于12c引入的多租户架构CDB/PDB。在11g时代我们面对的是一个个独立的数据库实例而在19c最佳实践是创建一个容器数据库CDB然后将我们的业务数据库作为可插拔数据库PDB放入其中。这意味着我们的迁移目标不是一个传统的“非CDB”数据库而是一个PDB。因此兼容性分析的第一要务就是使用Oracle官方提供的工具——Database Upgrade Assistant (DBUA)的命令行版本或者更专业的Oracle Pre-Upgrade Information Tool。具体来说你需要从19c的ORACLE_HOME/rdbms/admin目录下找到preupgrd.sql脚本在11g的源库上执行它。这个脚本会生成一份详尽的报告列出所有的不兼容项、过时的参数、失效对象以及废弃的组件。根据我的经验需要特别关注以下几点过时的初始化参数比如*_deprecated_parameters。11g中一些参数在19c可能已被废弃或更名报告会明确指出你需要提前在19c的参数文件中做好映射。失效的PL/SQL对象和视图由于数据字典结构的改变尤其是引入CDB相关视图后一些自定义的PL/SQL程序或视图可能会引用到不再存在的表或列。报告会列出这些对象必须在迁移前进行修改和重新编译。字符集与语言环境确保19c数据库的字符集如AL32UTF8是11g源库字符集的超集否则在迁移过程中会出现字符转换错误。如果源库是ZHS16GBK目标库是AL32UTF8这通常是安全的。废弃组件检查是否使用了如Oracle Streams, Advanced Queuing的旧版本等可能在19c中不再默认安装或完全废弃的组件并规划替代方案。注意千万不要在测试环境缺失的情况下直接在生产环境运行预升级脚本。虽然它主要是查询操作但某些检查可能会在系统表上创建临时对象存在极低的理论风险。务必先在克隆出的测试库上执行。2.2 迁移路径与策略选择确定了兼容性问题后下一步是选择迁移路径。从11g到19c主要有以下几种主流方式每种都有其适用场景和优缺点。1. 使用Oracle Data Pump (expdp/impdp)这是最常用、最灵活的方式。它逻辑导出/导入数据不依赖于底层存储结构。优点跨平台比如从AIX迁移到Linux可以在迁移同时进行数据重组如表空间、用户重定义选择性迁移仅迁移部分表或数据并且能很好地处理版本差异。缺点对于超大型数据库10TB以上导出/导入时间较长期间需要业务停机和维护窗口。并且需要足够的磁盘空间存放Dump文件。操作意图适用于有较长停机窗口、需要改变存储结构或进行数据清洗的迁移场景。我这次迁移就采用了这种方式因为我们需要将数据从旧的文件系统迁移到新的ASM磁盘组并整合部分用户。2. 使用可传输表空间Transportable Tablespaces, TTS这种方式物理移动数据文件配合元数据的导出/导入速度极快。优点迁移速度最快因为大部分数据是物理复制。适合数据量巨大、停机时间要求极短的场景。缺点限制较多。要求源库和目标库的字节序Endianness一致同平台迁移通常没问题数据库字符集必须相同且不能有跨表空间的引用如某个表的LOB列存放在其他表空间。迁移前需要将表空间设为只读。操作意图适用于同平台、大容量、极短停机窗口的迁移且数据结构符合TTS要求。3. 使用GoldenGate等逻辑复制工具这是一种“在线迁移”或“滚动升级”方案通过实时捕获和复制数据变化实现最小化停机。优点几乎可以实现零停机迁移。在迁移过程中源库保持读写通过GoldenGate将增量数据持续同步到19c目标库最后进行短暂切换。缺点配置和管理复杂成本高昂需要GoldenGate许可且对源库有一定性能影响。并非所有数据类型和DDL操作都支持。操作意图适用于7x24小时运行、无法容忍长时间停机的高可用核心系统。4. 使用Recovery Manager (RMAN) 进行备份恢复通过RMAN将11g的备份恢复到19c环境然后使用DBMS_UPGRADE_INTERNAL包在目标端进行升级。优点可以充分利用现有的备份恢复体系。对于使用相同存储架构如ASM的环境流程相对直接。缺点同样要求平台兼容且升级过程在目标端进行需要仔细处理控制文件、重做日志的兼容性问题。步骤比Data Pump繁琐。操作意图适用于已建立成熟RMAN备份策略且希望迁移与备份恢复流程结合的环境。对于大多数从11g到19c的迁移Oracle Data Pump因其灵活性和可靠性成为首选。我的项目也基于此后续的实操详解将围绕Data Pump展开。2.3 环境与资源准备清单兵马未动粮草先行。在技术方案确定后需要准备以下资源目标服务器安装好Oracle Database 19c软件。确保操作系统版本、内核参数、依赖包等符合19c的安装要求。内存、CPU、存储I/O能力应至少不低于源库并建议有所提升以发挥19c的性能优势。存储规划根据Data Pump估算的Dump文件大小可通过查询DBA_SEGMENTS估算表空间大小再乘以一个压缩系数如0.7准备足够的临时存储空间。同时规划好19c目标库的最终存储例如ASM磁盘组。网络带宽如果源和目标不在同一机房需要评估网络传输速度。传输10TB数据即使通过1Gbps网络理论时间也需要超过24小时这还不包括处理时间。必要时需使用物理介质快递或高速专线。测试环境必须搭建使用生产库的备份或脱敏后的副本搭建一套从11g到19c的完整测试环境。在这个环境上完整演练迁移全过程包括预检查、导出、传输、导入、后升级脚本、应用连接测试、性能基准测试。这是发现和解决问题的最佳场所。备份与回滚方案在正式迁移开始前务必对11g源库进行一次全量备份包括数据文件、控制文件、归档日志。明确如果迁移失败如何快速回退到11g环境并恢复业务。回滚方案和时间必须得到业务部门的确认。3. 基于Data Pump的迁移核心实操详解假设我们已经完成了所有评估并决定采用Data Pump进行迁移。以下是我在实际操作中总结的标准化步骤和核心命令其中包含了许多参数选择的背后逻辑。3.1 源库11g导出阶段导出阶段的目标是生成一个完整、一致的数据快照。我们使用expdp数据泵导出工具。# 1. 创建目录对象如果不存在。目录对象是Oracle中指向操作系统路径的逻辑指针。 sqlplus / as sysdba SQL CREATE OR REPLACE DIRECTORY dpump_dir AS /u01/app/oracle/dpump; SQL GRANT READ, WRITE ON DIRECTORY dpump_dir TO system; # 2. 执行全库导出。这里有几个关键参数需要解释 # fully: 导出全库。 # compressionall: 启用压缩能显著减少Dump文件大小对于文本型的SQL文件效果极佳。 # parallel4: 启用并行加快导出速度。该值通常设置为CPU核心数的2倍左右但需观察I/O瓶颈。 # dumpfileexpdp_full_%U.dmp: %U是通配符会生成expdp_full_01.dmp, 02.dmp等文件配合parallel参数实现并行导出到多个文件。 # logfileexpdp_full.log: 记录导出过程的日志。 # excludestatistics: **强烈建议排除统计信息**。因为11g的统计信息在19c上可能不准确或存在兼容性问题我们应在导入后在19c上重新收集。 # flashback_timesystimestamp: 确保导出数据的一致性。指定一个SCN或时间点Data Pump会使用Flashback Query来获取该时间点的一致数据避免在导出过程中数据变化导致的不一致。 # 注意使用flashback_time需要源库启用归档模式和补充日志且UNDO表空间足够大。 expdp system/passwordsource11g \ directorydpump_dir \ fully \ compressionall \ parallel4 \ dumpfileexpdp_full_%U.dmp \ logfileexpdp_full.log \ excludestatistics \ flashback_timesystimestamp实操心得与避坑点关于并行度不要盲目设置过高。先通过iostat等工具监控磁盘I/O。如果磁盘已经是100%繁忙增加并行度只会加剧竞争降低效率。我一般从CPU核心数开始设置然后根据expdpworker进程的等待事件如“db file sequential read”来调整。关于压缩compressionall在导出时增加一些CPU开销但能减少约30%-70%的磁盘占用和网络传输时间对于网络迁移场景性价比极高。确保服务器CPU有足够余量。排除统计信息这是关键。我曾尝试包含统计信息导入结果导致19c的CBO基于成本的优化器选择了极差的执行计划。在19c的空库上重新收集统计信息能让优化器基于新的系统统计信息如I/O速度、CPU速度做出更优判断。空间预估导出前使用SELECT SUM(bytes)/1024/1024/1024 AS size_gb FROM dba_segments;粗略估算数据库大小。为Dump文件预留至少1.5倍的估算空间以防万一。3.2 文件传输与目标库19c前期准备导出完成后将Dump文件和日志文件传输到19c目标服务器。可以使用scp,rsync等工具。如果文件巨大考虑使用nc(netcat) 或专业的高速传输工具。在目标库19c上需要做一些准备工作# 1. 同样创建目录对象 sqlplus / as sysdba SQL CREATE OR REPLACE DIRECTORY dpump_dir AS /u01/app/oracle/dpump; SQL GRANT READ, WRITE ON DIRECTORY dpump_dir TO system; # 2. 创建必要的表空间。虽然Data Pump导入时会创建表空间但如果路径不同例如从文件系统到ASM最好预先创建。 # 例如源库的USERS表空间在文件系统我们希望它在19c的ASM上 SQL CREATE TABLESPACE users DATAFILE DATA SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED; # 3. 检查并设置关键初始化参数。19c有些参数默认值变了需要根据新硬件和业务特点调整。 # 例如memory_target, processes, sessions, open_cursors等。 # 特别要注意与PDB相关的参数如max_pdbs。3.3 目标库19c导入与升级阶段这是最核心的步骤使用impdp数据泵导入工具。我们的目标是将11g的数据导入到一个新建的PDB中。# 1. 首先在19c的CDB中创建一个空的PDB作为我们迁移的目标容器。 sqlplus / as sysdba SQL CREATE PLUGGABLE DATABASE myapppdb ADMIN USER pdbadmin IDENTIFIED BY password; SQL ALTER PLUGGABLE DATABASE myapppdb OPEN; SQL ALTER SESSION SET CONTAINERmyapppdb; # 2. 在PDB中创建目录对象注意PDB中的目录对象是独立的需要单独创建和授权 SQL CREATE OR REPLACE DIRECTORY dpump_dir AS /u01/app/oracle/dpump; SQL GRANT READ, WRITE ON DIRECTORY dpump_dir TO system; # 3. 执行导入。关键参数解析 # fully: 导入全库dump文件。 # remap_tablespace: **至关重要**将源库的表空间映射到目标PDB中已存在的表空间。如果路径或存储类型变了必须用此参数。 # remap_schema: 如果需要改变用户模式名在此指定。 # transformoid:n: 禁用对象OID的转换除非你使用高级复制或Oracle目录服务否则建议禁用以避免潜在问题。 # parallel4: 与导出时保持一致或根据目标端资源调整。 # excludeuser:“IN (‘OUTLN’,‘APEX_030200’)”排除一些Oracle自带的、可能在两个版本间存在差异的非必要用户。 # skip_unusable_indexesy: 跳过那些因依赖对象未导入而暂时不可用的索引导入后再处理。 # logfileimpdp_full.log # 注意我们连接到目标PDBmyapppdb进行导入。 impdp system/passwordlocalhost:1521/myapppdb \ directorydpump_dir \ fully \ remap_tablespaceUSERS:USERS, EXAMPLE:EXAMPLE \ parallel4 \ transformoid:n \ excludeuser:“IN (‘OUTLN’,‘APEX_030200’)” \ skip_unusable_indexesy \ dumpfileexpdp_full_%U.dmp \ logfileimpdp_full.log导入过程中的关键监控与问题处理监控进度不要干等。可以另开一个会话查询DBA_DATAPUMP_JOBS和DBA_DATAPUMP_SESSIONS视图来监控作业状态和并行worker进度。处理错误导入日志 (impdp_full.log) 中会记录ORA-错误。常见的错误包括ORA-39083: 对象类型 OBJECT_TYPE 创建失败, 错误为: error_number。这通常是对象定义在19c中不兼容。需要根据错误信息手动编辑相关DDL例如修改过时的语法然后使用impdp的sqlfile参数生成SQL文件修改后再通过impdp的sqlfile导入或手动执行。ORA-00959: 表空间 ‘XXX’ 不存在。检查remap_tablespace参数是否正确或者目标PDB中是否预先创建了该表空间。对于非关键对象的错误如某些失效的视图有时可以先忽略待导入完成后单独处理。可以使用impdp ... excludeobject_type[:name_clause]在后续导入中排除它。3.4 后升级操作与系统优化数据导入成功并不意味着迁移结束。以下后处理步骤直接关系到新系统的稳定性和性能。运行后升级脚本在目标PDB中以SYS用户身份运行19c的升级后修复脚本。这些脚本位于$ORACLE_HOME/rdbms/admin目录下。通常需要按顺序运行catupgrd.sql(如果是从低版本直接升级但我们是导入情况不同) 和utlrp.sql重新编译所有无效对象。sqlplus / as sysdba SQL ALTER SESSION SET CONTAINERmyapppdb; SQL ?/rdbms/admin/utlrp.sql运行utlrp.sql可能会花费较长时间它会对所有状态为INVALID的PL/SQL包、视图、触发器等进行重新编译。务必检查编译后是否还有无效对象SELECT COUNT(*) FROM dba_objects WHERE status ‘INVALID’;重新收集统计信息如前所述导入的数据没有统计信息或统计信息是旧的。必须在19c上重新收集。-- 以SYSDBA或拥有DBA权限的用户在PDB中执行 EXEC DBMS_STATS.GATHER_DATABASE_STATS(estimate_percent DBMS_STATS.AUTO_SAMPLE_SIZE, cascade TRUE, degree 8);estimate_percent: 设置为AUTO_SAMPLE_SIZE让Oracle自动决定采样比例通常效果最好。cascade: 收集表统计信息的同时也收集索引统计信息。degree: 并行度根据服务器CPU资源设置。更新数据库参数与配置检查并设置PDB级别的参数如SGA_TARGET,PGA_AGGREGATE_TARGET。配置19c的新特性例如自动索引AUTO_INDEX可以根据情况开启测试模式。设置归档模式、配置备份策略RMAN。应用连接测试修改应用程序的连接字符串指向新的19c PDB服务名。进行全面的功能测试、性能测试和压力测试。对比迁移前后的关键业务事务响应时间。4. 迁移全流程中的常见问题与排查实录即使准备再充分实战中也会遇到各种“惊喜”。下面是我在这次及以往迁移中遇到的典型问题及解决方法。4.1 导出/导入性能瓶颈分析与优化问题现象expdp或impdp进程运行缓慢监控发现wait event中大量出现“db file scattered read”或“db file sequential read”或者CPU利用率很低但I/O等待很高。排查与解决I/O瓶颈这是最常见的原因。使用iostat -x 2查看磁盘利用率%util和响应时间await。如果利用率持续接近100%说明磁盘是瓶颈。优化降低parallel参数值减少并发I/O压力。将Dump文件目录指向更快的存储如SSD或高速SAN。确保导出/导入的临时表空间用于排序等操作也在高速磁盘上。网络瓶颈远程导出/导入如果使用网络链接模式network_link网络带宽可能成为瓶颈。优化改为先导出到本地文件再通过物理介质或高速网络传输文件最后在目标端导入。或者使用压缩 (compressionall) 减少传输量。CPU瓶颈如果启用了压缩且CPU核心数较少压缩可能成为瓶颈。优化监控top或vmstat如果CPUsys或us利用率持续很高可以尝试降低压缩级别或关闭压缩如果网络和磁盘不是问题。单表过大单个超大表的导出/导入可能无法有效并行。优化对于已知的超大表可以在导出时使用includetable:“in (‘BIG_TABLE1’ ‘BIG_TABLE2’)”单独处理并为这些表指定更高的并行度。在导入时也可以使用table_exists_actionappend和partition_optionsmerge等参数进行优化。4.2 对象编译失效与版本兼容性错误问题现象导入后运行utlrp.sql仍有大量对象编译失败或在应用测试中报错提示包、视图或触发器无效。排查与解决查看具体错误查询DBA_ERRORS视图找到具体的编译错误信息。SELECT owner, name, type, line, position, text FROM dba_errors WHERE owner ‘YOUR_SCHEMA’ ORDER BY name, type, line;常见原因及处理引用不存在的基表或列19c的数据字典视图可能发生了变化。例如11g中某个自定义视图直接查询了tab$这样的底层表而该表在19c中结构已变。需要根据19c的官方文档修改视图定义改为查询公开的字典视图如DBA_TABLES。使用废弃的PL/SQL特性检查错误中是否提示使用了废弃的语法或程序包。需要查阅19c的《PL/SQL语言参考》更新代码。权限问题在PDB中某些系统权限的授予方式可能与非CDB时代不同。确保用户拥有必要的权限特别是涉及跨PDB操作时。手动编译对于少数顽固对象尝试手动编译ALTER PACKAGE scott.my_pkg COMPILE BODY; ALTER VIEW scott.my_view COMPILE;4.3 迁移后性能不升反降问题现象迁移完成后应用响应时间变慢数据库监控显示等待事件异常如“enq: TX - allocate ITL entry”或“buffer busy waits”。排查与解决检查统计信息首先确认是否已重新收集统计信息。使用DBMS_STATS收集的统计信息可能还不够对于复杂系统可能需要收集更细粒度的统计信息或使用DBMS_STATS.SET_*过程手动设置某些列的直方图。检查初始化参数19c的默认参数值可能不适合你的负载。重点检查memory_target/sga_target/pga_aggregate_target是否分配合理processes/sessions是否满足应用连接数需求undo_retention对于有大量长查询的系统可能需要增大。optimizer_features_enable可以考虑暂时设置为‘11.2.0.4’以保持与迁移前相同的优化器行为但这不是长久之计应在测试后逐步调整到‘19.1.0’。检查等待事件使用AWR或ASH报告分析Top等待事件。常见的迁移后问题包括ITL争用表现为“enq: TX - allocate ITL entry”。这是因为表或索引的INITRANS设置过低在高并发插入/更新时事务槽不够用。解决方法ALTER TABLE ... INITRANS 8;根据并发度调整。热点块争用表现为“buffer busy waits”。可能是由于序列缓存不足CACHE值太小导致索引叶块争用或者是某些小表被频繁全表扫描。需要具体分析AWR报告中的SQL和对象。利用19c新特性开启自动索引ALTER SYSTEM SET optimizer_auto_index_enableTRUE;并观察其建议但初期建议在维护窗口手动创建并验证。考虑使用SQL计划管理SPM来稳定关键SQL的执行计划。4.4 空间与存储管理问题问题现象导入过程中报错“ORA-01653: unable to extend table …”或“ORA-01654: unable to extend index …”。排查与解决表空间自动扩展确保目标PDB的表空间数据文件启用了AUTOEXTEND ON并设置了合理的NEXT和MAXSIZE。ASM磁盘组空间不足如果使用ASM检查磁盘组的剩余空间asmcmd lsdg。确保有足够空间容纳数据文件、重做日志和控制文件的增长。Bigfile Tablespaces在19c中考虑使用大文件表空间来管理超大型表简化空间管理。但要注意备份恢复的粒度会变大。预估失误11g的表中可能含有大量未释放的空间高水位线以下。导入后这些空间会被原样“复制”过来。可以使用ALTER TABLE ... MOVE或ALTER INDEX ... REBUILD在线重组对象释放碎片空间。注意MOVE操作会使索引失效需要重建。迁移完成后我强烈建议在业务低峰期进行一次全库的ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE检查对主要业务表抽样即可以确保数据块的物理完整性。同时更新你的监控系统将新的19c PDB纳入监控范围重点关注性能指标、空间增长和错误日志。最后不要立即销毁11g源库至少保留一个完整的备份和归档并观察新系统稳定运行1-2个业务周期后再根据备份策略进行处置。整个迁移过程文档记录至关重要从评估报告、操作手册到问题处理记录都应完整保存这不仅是项目交付物更是未来运维的宝贵资料。