简介《Oracle 11g 到 19C 数据库升级详尽指导手册》面向具备一定运维能力的数据库管理员聚焦利用 DBUA 将 11g 单机库安全迁移至 19C 的维护场景。内容覆盖前期备份与恢复、升级路线与环境核对、图形及静默升级方式、必要参数调整以及检查脚本日志和警告等关键注意事项并给出常见故障的处理思路便于读者按顺序核对命令细节、降低割接风险。资源包共 1 个 PDF 文件大小约 3.18MB适合作为升级前预演和现场操作时的速查材料。已有 1361 人学习可帮助 DBA 结合 MOS 参考文档梳理从 11.2.0.4 到 19.x 的完整流程提前发现兼容性与回退准备中的薄弱环节。1. 整理这份 Oracle 11g 数据库升级运维指南时我先不急着点 Oracle 19C DBUA 的下一步整理这份 Oracle 11g 数据库升级运维指南时我先不急着点 Oracle 19C DBUA 的下一步。真正卡人的往往不是图形界面而是源库小版本、操作系统和恢复环境这三笔账11.2.0.3 不能直接上 19CLinux 6 上的 11g 也不能硬装 19CDBUA 只负责升级动作不负责替你补版本路线。这次用的是 11.2.0.4.201020补丁 31537677恢复到升级机再通过 19C 的 DBUA 升到 19.14.0.0.220118。源库保留不动升级机失败还能回退。适合已经能管 11g 实例、准备把单机库迁到 19C 的运维读者新手照着能走熟手重点看版本取舍和恢复时间点。2. 升级前环境准备Oracle 19C 软件、11g 恢复 Home 和 Linux 7 检查2.1 主机与版本路线核对这套升级不是把 11g 的ORACLE_HOME换个路径就完事。升级机上要同时存在两个 Home一个与源库同版本、同补丁的 11g Home用来把源库备份恢复过来另一个是 19C Home用来跑 DBUA。源库继续保留升级机只做恢复和升级失败时把业务切回源库这是最省心的后悔药。角色版本ORACLE_HOME说明源库11.2.0.4.20102031537677源库原路径保留不动用于回退升级机恢复 Home11.2.0.4 同补丁/u02/app/oracle/product/11.2.0/db只用于恢复源库升级机目标 Home19.14.0.0.220118/u01/app/oracle/product/19.14.0/db_1DBUA 从这里启动升级机Linux 7.9 x86_64示例地址192.0.2.1019C 最低要求 Linux 719C 对操作系统的最低要求是 Linux 7。源库如果还在 Linux 6不要在原机硬装 19C常见做法是准备一台 Linux 7 新机把 11g 备份恢复到新机的 11g Home再用新机的 19C Home 执行 DBUA。版本路线也要先看表11.2.0.4 及以上可以直接升 19.x11.2.0.1、11.2.0.2、11.2.0.3 要先到 11.2.0.410.2.0.2 到 10.2.0.5 要先到 11.2.0.4 或 12.1.0.29.2.0.8 及更早要先到 11.2.0.4。DBUA 不会帮你跨过中间版本先决条件检查这一关就会拦下来。源库版本升级路径目标11.2.0.4 及以上直接升级19.x11.2.0.1 / 11.2.0.2 / 11.2.0.3先到 11.2.0.419.x10.2.0.2 至 10.2.0.5先到 11.2.0.4 或 12.1.0.219.x12.1.0.1先到 12.1.0.2 或 12.2.0.119.x9.2.0.8 及更早先到 11.2.0.419.x注意升级机上的 11g Home 不要图省事用低补丁版本恢复高补丁源库数据文件头和回滚段兼容问题排查起来很费时间版本和补丁对齐更稳。2.2 安装 Oracle 19C 软件只装软件不建库19C 软件安装时选“只安装软件”不要顺手建库。DBUA 要接管的是恢复过来的 11g 实例不是新建的 19C 库。安装介质解压到临时目录用响应文件静默安装下面命令里的路径按自己的环境替换。# 以 oracle 用户执行进入 19C 安装介质目录 cd /soft/19c ./runInstaller -silent \ -responseFile /home/oracle/19c_install.rsp \ -ignorePrereqFailure # 安装完成后 root 执行两个脚本 /u01/app/oraInventory/orainstRoot.sh /u01/app/oracle/product/19.14.0/db_1/root.sh-responseFile指向提前改好的响应文件-ignorePrereqFailure只建议在明确知道某条先决条件不影响本次升级时使用否则先决条件失败就停下来看日志。安装响应文件里最关键的是安装选项、ORACLE_HOME、ORACLE_BASE 和操作系统组常见项如下。响应文件控制项取值示例说明安装选项INSTALL_DB_SWONLY只装软件不建库ORACLE_BASE/u01/app/oracle19C 基础目录ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1DBUA 从这里启动操作系统组oinstall、dba按主机实际组名填写安装日志/u01/app/oraInventory/logs失败先看 installActions 日志root.sh必须用 root 执行执行完再回到 oracle 用户检查补丁。19C Home 装好后不要急着建监听先把 11g 恢复库跑通后面 DBUA 会关闭并重启实例监听等到升级完成再统一切到 19C Home 更稳。export ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1 export PATH$ORACLE_HOME/bin:$PATH $ORACLE_HOME/OPatch/opatch lspatches $ORACLE_HOME/bin/sqlplus -Vopatch lspatches用来确认 19C 补丁版本sqlplus -V确认客户端工具版本。两个 Home 并存时最怕环境变量串台我习惯给 11g 和 19C 各写一个 env 文件执行哪一步就 source 哪一个不要在一个会话里来回 export。2.3 准备 11g 恢复 Home 与参数文件目录恢复源库要用 11g Home先确认补丁和源库一致。下面的检查命令在升级机的 11g 环境里执行。export ORACLE_HOME/u02/app/oracle/product/11.2.0/db export PATH$ORACLE_HOME/bin:$PATH $ORACLE_HOME/OPatch/opatch lspatches | grep -E 31537677|11.2.0.4 sqlplus -Vopatch lspatches输出里能看到 31537677 才说明恢复 Home 与源库补丁对齐。sqlplus -V只验证工具可用不代表实例已启动。接下来建好审计目录、控制文件目录和数据文件目录目录权限归 oracle 用户。mkdir -p /u02/app/oracle/admin/srcdbupg/adump mkdir -p /oradata/srcdbupg/controlfile mkdir -p /oradata/srcdbupg/datafile mkdir -p /arch chown -R oracle:oinstall /u02/app/oracle/admin/srcdbupg /oradata/srcdbupg /arch参数文件从源库备份的 spfile 还原后修改下面只列必须改的路径和库名内存、processes、sessions 按源库原值保留并核对目标机资源不要照抄别人的机器。# 恢复库 pfile 关键项库名和路径使用虚构代称 *.db_namesrcdb *.db_unique_namesrcdbupg *.compatible11.2.0.4.0 *.control_files/oradata/srcdbupg/controlfile/control01.ctl *.audit_file_dest/u02/app/oracle/admin/srcdbupg/adump *.diagnostic_dest/u02/app/oracle *.db_recovery_file_dest/arch *.db_recovery_file_dest_size200G *.db_create_file_dest/oradata *.service_namessrcdb,srcdbupg *.remote_login_passwordfileexclusive *.sec_case_sensitive_logonFALSE *.undo_tablespaceUNDOTBS1db_name保持源库名db_unique_name给升级机一个不同名字避免和源库重名。compatible在升级前先保持 11.2.0.4升级完成后再评估是否调整。control_files、audit_file_dest、db_recovery_file_dest都指向升级机本地路径路径必须先建好否则启动会报 OSD 错误。export ORACLE_HOME/u02/app/oracle/product/11.2.0/db export ORACLE_SIDsrcdb export PATH$ORACLE_HOME/bin:$PATH sqlplus / as sysdba EOF startup nomount pfile/home/oracle/pfile.ora; create spfile/u02/app/oracle/product/11.2.0/db/dbs/spfilesrcdb.ora from pfile/home/oracle/pfile.ora; EOF先用 pfile 启动到 nomount再从 pfile 生成 11g Home 下的 spfile。ORACLE_SID必须和db_name对应spfile路径放在 11g Home 的dbs目录下。到这里只完成了参数文件控制文件和数据文件还没恢复。3. 源库备份恢复到升级机RMAN 恢复参数文件、控制文件和归档追平3.1 备份与恢复参数文件、控制文件源库备份过程不在这里展开但备份策略要能支撑升级机恢复全备、归档日志、控制文件自动备份备份片统一放到升级机可访问的/hisbak并记录备份时间点。常见做法是先做一次全备加归档再开始恢复避免恢复过程中归档被删除。# 源库侧常见备份动作按自己的保留策略调整 rman target / EOF CONFIGURE CONTROLFILE AUTOBACKUP ON; BACKUP DATABASE PLUS ARCHIVELOG; BACKUP CURRENT CONTROLFILE FORMAT /hisbak/SRCDB_CONT_%U.ctl; EOFBACKUP DATABASE PLUS ARCHIVELOG会先归档当前日志再备份数据文件和归档CONTROLFILE AUTOBACKUP ON保证控制文件有自动备份。控制文件单独再备一份是给恢复阶段省事后面restore controlfile from可以直接指到文件。升级机上先恢复 spfile再生成可编辑的 pfile。下面命令在 11g Home 环境执行。export ORACLE_HOME/u02/app/oracle/product/11.2.0/db export ORACLE_SIDsrcdb export PATH$ORACLE_HOME/bin:$PATH rman target / EOF startup nomount; restore spfile from /hisbak/spfile_srcdb_20220830.ora; EOF sqlplus / as sysdba EOF create pfile/home/oracle/pfile.ora from spfile; exit EOFstartup nomount只需要参数文件不要求控制文件和数据文件存在。restore spfile from把源库 spfile 还原到 11g Home 的默认位置再用create pfile from spfile导出文本按 2.3 的路径改。改完 pfile 后重新生成 spfile后续启动都走 spfile避免每次手写 pfile 路径。控制文件恢复要在 nomount 之后、mount 之前做。下面命令把控制文件恢复到 pfile 指定的control_files路径。rman target / EOF restore controlfile from /hisbak/SRCDB_CONT_20220830.ctl; alter database mount; catalog start with /hisbak/; EOFrestore controlfile from指定控制文件备份片alter database mount让实例读取控制文件catalog start with把/hisbak下的备份片重新登记进控制文件。控制文件不是当前的时候REPORT SCHEMA可能给出警告这是正常现象先把备份片 catalog 进来再继续。rman target / EOF REPORT SCHEMA; EOFREPORT SCHEMA用来核对数据文件、临时文件清单和路径。如果输出里还是源库的 ASM 路径或旧路径不要慌下一步SET NEWNAME会统一改到升级机本地路径。这里重点看文件数量和表空间确认没有漏掉业务数据文件。3.2 restore database 的时间点与 newname恢复数据文件时用SET NEWNAME把源库路径改到升级机SET UNTIL TIME控制恢复到哪个时间点。下面示例先恢复到备份时间点附近再通过 recover 往后续归档上追。rman target / EOF run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; ALLOCATE CHANNEL C3 DEVICE TYPE DISK; ALLOCATE CHANNEL C4 DEVICE TYPE DISK; SET NEWNAME FOR DATABASE TO /oradata/srcdbupg/datafile/%b; SET UNTIL TIME TO_DATE(2022-08-30:02:00:00,YYYY-MM-DD:HH24:MI:SS); RESTORE DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFSET NEWNAME FOR DATABASE TO里的%b表示保留原文件名只换目录减少文件名冲突。SET UNTIL TIME是 restore 的时间上限不是最终恢复时间后面 recover 可以继续往后走。通道数量按备份片所在磁盘的吞吐调整通道不是越多越好I/O 打满后反而互相拖慢。restore 完成后要让控制文件指向新文件再执行 recover。下面示例先切到 copy再追到更晚的时间点。rman target / EOF SWITCH DATABASE TO COPY; run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; ALLOCATE CHANNEL C3 DEVICE TYPE DISK; ALLOCATE CHANNEL C4 DEVICE TYPE DISK; SET UNTIL TIME TO_DATE(2022-08-30:07:00:00,YYYY-MM-DD:HH24:MI:SS); RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFSWITCH DATABASE TO COPY让控制文件正式使用 restore 出来的副本少了这一步后面打开数据库还会去找旧路径。RECOVER DATABASE应用归档和在线日志SET UNTIL TIME控制追到哪个时间点。时间点不要一次追到源库当前时间先追到一个可校验的中间点打开只读确认数据文件一致再继续追。如果归档足够可以再追一次到更晚时间。下面示例追到 12:00实际业务窗口按自己的备份和归档情况改。rman target / EOF run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; ALLOCATE CHANNEL C3 DEVICE TYPE DISK; ALLOCATE CHANNEL C4 DEVICE TYPE DISK; SET UNTIL TIME TO_DATE(2022-08-30:12:00:00,YYYY-MM-DD:HH24:MI:SS); RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOF每次 recover 后看 RMAN 输出里应用的归档序列和 SCN确认没有跳号。归档备份片和在线归档都可以作为来源catalog start with之后 RMAN 才能识别备份片里的归档。时间点越靠近源库当前时间升级后业务验证越完整但升级窗口也越长取舍点在业务能接受的停写窗口。3.3 read only 校验和继续追归档数据文件恢复到一个阶段后用只读方式打开做一次文件头和基本查询校验。只读打开不会写数据文件适合在升级前确认恢复库可用。sqlplus / as sysdba EOF alter database open read only; select name, open_mode from v$database; select file#, name, status from v$datafile; select file#, name, status from v$tempfile; EOFopen read only成功后v$database.open_mode显示READ ONLYv$datafile里所有数据文件状态应为 online。此时可以跑几条业务只读 SQL确认核心表能访问。只读打开后如果还要继续追归档必须先关库再启到 mount不能直接在 read only 状态做恢复。sqlplus / as sysdba EOF shutdown abort; startup mount; EOF rman target / EOF run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; ALLOCATE CHANNEL C3 DEVICE TYPE DISK; ALLOCATE CHANNEL C4 DEVICE TYPE DISK; RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFshutdown abort在测试恢复库上可以用生产库不要照搬。startup mount后继续RECOVER DATABASE不写SET UNTIL TIME表示尽量追到最后一个可用归档。追到没有归档时常见报错是RMAN-06054: media recovery requesting unknown archived log意思是要某个序列的归档但备份里没有。先list backup of archivelog all看已有序列再从源库补拷缺失归档catalog start with后继续 recover。rman target / EOF list backup of archivelog all; EOFlist backup of archivelog all的输出重点看线程号、序列号、低 SCN 和完成时间。缺的归档序列如果源库还在直接从源库归档目录拷到/hisbak或/arch再 catalog。不要在没有确认归档完整性的情况下强行打开读写升级前的恢复库越干净DBUA 阶段越少黑匣子。4. DBUA 执行升级19C Home 环境变量、图形界面和静默模式4.1 升级前检查监听、无效对象、时区、归档DBUA 启动前先做一轮检查别让无效对象和归档问题把升级窗口吃掉。下面 SQL 在恢复库的 11g 环境执行确认版本、组件、无效对象和归档模式。-- 在恢复库 11g 环境执行 select banner from v$version; select name, open_mode, log_mode from v$database; select comp_name, status, version from dba_registry; select count(*) invalid_count from dba_objects where status INVALID; select destination, status, error from v$archive_dest where destination is not null;v$version确认源库版本v$database.log_mode应为 ARCHIVELOG本文还有配套的精品资源点击获取
简介《Oracle 11g 到 19C 数据库升级详尽指导手册》面向具备一定运维能力的数据库管理员聚焦利用 DBUA 将 11g 单机库安全迁移至 19C 的维护场景。内容覆盖前期备份与恢复、升级路线与环境核对、图形及静默升级方式、必要参数调整以及检查脚本日志和警告等关键注意事项并给出常见故障的处理思路便于读者按顺序核对命令细节、降低割接风险。资源包共 1 个 PDF 文件大小约 3.18MB适合作为升级前预演和现场操作时的速查材料。已有 1361 人学习可帮助 DBA 结合 MOS 参考文档梳理从 11.2.0.4 到 19.x 的完整流程提前发现兼容性与回退准备中的薄弱环节。1. 整理这份 Oracle 11g 数据库升级运维指南时我先不急着点 Oracle 19C DBUA 的下一步整理这份 Oracle 11g 数据库升级运维指南时我先不急着点 Oracle 19C DBUA 的下一步。真正卡人的往往不是图形界面而是源库小版本、操作系统和恢复环境这三笔账11.2.0.3 不能直接上 19CLinux 6 上的 11g 也不能硬装 19CDBUA 只负责升级动作不负责替你补版本路线。这次用的是 11.2.0.4.201020补丁 31537677恢复到升级机再通过 19C 的 DBUA 升到 19.14.0.0.220118。源库保留不动升级机失败还能回退。适合已经能管 11g 实例、准备把单机库迁到 19C 的运维读者新手照着能走熟手重点看版本取舍和恢复时间点。2. 升级前环境准备Oracle 19C 软件、11g 恢复 Home 和 Linux 7 检查2.1 主机与版本路线核对这套升级不是把 11g 的ORACLE_HOME换个路径就完事。升级机上要同时存在两个 Home一个与源库同版本、同补丁的 11g Home用来把源库备份恢复过来另一个是 19C Home用来跑 DBUA。源库继续保留升级机只做恢复和升级失败时把业务切回源库这是最省心的后悔药。角色版本ORACLE_HOME说明源库11.2.0.4.20102031537677源库原路径保留不动用于回退升级机恢复 Home11.2.0.4 同补丁/u02/app/oracle/product/11.2.0/db只用于恢复源库升级机目标 Home19.14.0.0.220118/u01/app/oracle/product/19.14.0/db_1DBUA 从这里启动升级机Linux 7.9 x86_64示例地址192.0.2.1019C 最低要求 Linux 719C 对操作系统的最低要求是 Linux 7。源库如果还在 Linux 6不要在原机硬装 19C常见做法是准备一台 Linux 7 新机把 11g 备份恢复到新机的 11g Home再用新机的 19C Home 执行 DBUA。版本路线也要先看表11.2.0.4 及以上可以直接升 19.x11.2.0.1、11.2.0.2、11.2.0.3 要先到 11.2.0.410.2.0.2 到 10.2.0.5 要先到 11.2.0.4 或 12.1.0.29.2.0.8 及更早要先到 11.2.0.4。DBUA 不会帮你跨过中间版本先决条件检查这一关就会拦下来。源库版本升级路径目标11.2.0.4 及以上直接升级19.x11.2.0.1 / 11.2.0.2 / 11.2.0.3先到 11.2.0.419.x10.2.0.2 至 10.2.0.5先到 11.2.0.4 或 12.1.0.219.x12.1.0.1先到 12.1.0.2 或 12.2.0.119.x9.2.0.8 及更早先到 11.2.0.419.x注意升级机上的 11g Home 不要图省事用低补丁版本恢复高补丁源库数据文件头和回滚段兼容问题排查起来很费时间版本和补丁对齐更稳。2.2 安装 Oracle 19C 软件只装软件不建库19C 软件安装时选“只安装软件”不要顺手建库。DBUA 要接管的是恢复过来的 11g 实例不是新建的 19C 库。安装介质解压到临时目录用响应文件静默安装下面命令里的路径按自己的环境替换。# 以 oracle 用户执行进入 19C 安装介质目录 cd /soft/19c ./runInstaller -silent \ -responseFile /home/oracle/19c_install.rsp \ -ignorePrereqFailure # 安装完成后 root 执行两个脚本 /u01/app/oraInventory/orainstRoot.sh /u01/app/oracle/product/19.14.0/db_1/root.sh-responseFile指向提前改好的响应文件-ignorePrereqFailure只建议在明确知道某条先决条件不影响本次升级时使用否则先决条件失败就停下来看日志。安装响应文件里最关键的是安装选项、ORACLE_HOME、ORACLE_BASE 和操作系统组常见项如下。响应文件控制项取值示例说明安装选项INSTALL_DB_SWONLY只装软件不建库ORACLE_BASE/u01/app/oracle19C 基础目录ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1DBUA 从这里启动操作系统组oinstall、dba按主机实际组名填写安装日志/u01/app/oraInventory/logs失败先看 installActions 日志root.sh必须用 root 执行执行完再回到 oracle 用户检查补丁。19C Home 装好后不要急着建监听先把 11g 恢复库跑通后面 DBUA 会关闭并重启实例监听等到升级完成再统一切到 19C Home 更稳。export ORACLE_HOME/u01/app/oracle/product/19.14.0/db_1 export PATH$ORACLE_HOME/bin:$PATH $ORACLE_HOME/OPatch/opatch lspatches $ORACLE_HOME/bin/sqlplus -Vopatch lspatches用来确认 19C 补丁版本sqlplus -V确认客户端工具版本。两个 Home 并存时最怕环境变量串台我习惯给 11g 和 19C 各写一个 env 文件执行哪一步就 source 哪一个不要在一个会话里来回 export。2.3 准备 11g 恢复 Home 与参数文件目录恢复源库要用 11g Home先确认补丁和源库一致。下面的检查命令在升级机的 11g 环境里执行。export ORACLE_HOME/u02/app/oracle/product/11.2.0/db export PATH$ORACLE_HOME/bin:$PATH $ORACLE_HOME/OPatch/opatch lspatches | grep -E 31537677|11.2.0.4 sqlplus -Vopatch lspatches输出里能看到 31537677 才说明恢复 Home 与源库补丁对齐。sqlplus -V只验证工具可用不代表实例已启动。接下来建好审计目录、控制文件目录和数据文件目录目录权限归 oracle 用户。mkdir -p /u02/app/oracle/admin/srcdbupg/adump mkdir -p /oradata/srcdbupg/controlfile mkdir -p /oradata/srcdbupg/datafile mkdir -p /arch chown -R oracle:oinstall /u02/app/oracle/admin/srcdbupg /oradata/srcdbupg /arch参数文件从源库备份的 spfile 还原后修改下面只列必须改的路径和库名内存、processes、sessions 按源库原值保留并核对目标机资源不要照抄别人的机器。# 恢复库 pfile 关键项库名和路径使用虚构代称 *.db_namesrcdb *.db_unique_namesrcdbupg *.compatible11.2.0.4.0 *.control_files/oradata/srcdbupg/controlfile/control01.ctl *.audit_file_dest/u02/app/oracle/admin/srcdbupg/adump *.diagnostic_dest/u02/app/oracle *.db_recovery_file_dest/arch *.db_recovery_file_dest_size200G *.db_create_file_dest/oradata *.service_namessrcdb,srcdbupg *.remote_login_passwordfileexclusive *.sec_case_sensitive_logonFALSE *.undo_tablespaceUNDOTBS1db_name保持源库名db_unique_name给升级机一个不同名字避免和源库重名。compatible在升级前先保持 11.2.0.4升级完成后再评估是否调整。control_files、audit_file_dest、db_recovery_file_dest都指向升级机本地路径路径必须先建好否则启动会报 OSD 错误。export ORACLE_HOME/u02/app/oracle/product/11.2.0/db export ORACLE_SIDsrcdb export PATH$ORACLE_HOME/bin:$PATH sqlplus / as sysdba EOF startup nomount pfile/home/oracle/pfile.ora; create spfile/u02/app/oracle/product/11.2.0/db/dbs/spfilesrcdb.ora from pfile/home/oracle/pfile.ora; EOF先用 pfile 启动到 nomount再从 pfile 生成 11g Home 下的 spfile。ORACLE_SID必须和db_name对应spfile路径放在 11g Home 的dbs目录下。到这里只完成了参数文件控制文件和数据文件还没恢复。3. 源库备份恢复到升级机RMAN 恢复参数文件、控制文件和归档追平3.1 备份与恢复参数文件、控制文件源库备份过程不在这里展开但备份策略要能支撑升级机恢复全备、归档日志、控制文件自动备份备份片统一放到升级机可访问的/hisbak并记录备份时间点。常见做法是先做一次全备加归档再开始恢复避免恢复过程中归档被删除。# 源库侧常见备份动作按自己的保留策略调整 rman target / EOF CONFIGURE CONTROLFILE AUTOBACKUP ON; BACKUP DATABASE PLUS ARCHIVELOG; BACKUP CURRENT CONTROLFILE FORMAT /hisbak/SRCDB_CONT_%U.ctl; EOFBACKUP DATABASE PLUS ARCHIVELOG会先归档当前日志再备份数据文件和归档CONTROLFILE AUTOBACKUP ON保证控制文件有自动备份。控制文件单独再备一份是给恢复阶段省事后面restore controlfile from可以直接指到文件。升级机上先恢复 spfile再生成可编辑的 pfile。下面命令在 11g Home 环境执行。export ORACLE_HOME/u02/app/oracle/product/11.2.0/db export ORACLE_SIDsrcdb export PATH$ORACLE_HOME/bin:$PATH rman target / EOF startup nomount; restore spfile from /hisbak/spfile_srcdb_20220830.ora; EOF sqlplus / as sysdba EOF create pfile/home/oracle/pfile.ora from spfile; exit EOFstartup nomount只需要参数文件不要求控制文件和数据文件存在。restore spfile from把源库 spfile 还原到 11g Home 的默认位置再用create pfile from spfile导出文本按 2.3 的路径改。改完 pfile 后重新生成 spfile后续启动都走 spfile避免每次手写 pfile 路径。控制文件恢复要在 nomount 之后、mount 之前做。下面命令把控制文件恢复到 pfile 指定的control_files路径。rman target / EOF restore controlfile from /hisbak/SRCDB_CONT_20220830.ctl; alter database mount; catalog start with /hisbak/; EOFrestore controlfile from指定控制文件备份片alter database mount让实例读取控制文件catalog start with把/hisbak下的备份片重新登记进控制文件。控制文件不是当前的时候REPORT SCHEMA可能给出警告这是正常现象先把备份片 catalog 进来再继续。rman target / EOF REPORT SCHEMA; EOFREPORT SCHEMA用来核对数据文件、临时文件清单和路径。如果输出里还是源库的 ASM 路径或旧路径不要慌下一步SET NEWNAME会统一改到升级机本地路径。这里重点看文件数量和表空间确认没有漏掉业务数据文件。3.2 restore database 的时间点与 newname恢复数据文件时用SET NEWNAME把源库路径改到升级机SET UNTIL TIME控制恢复到哪个时间点。下面示例先恢复到备份时间点附近再通过 recover 往后续归档上追。rman target / EOF run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; ALLOCATE CHANNEL C3 DEVICE TYPE DISK; ALLOCATE CHANNEL C4 DEVICE TYPE DISK; SET NEWNAME FOR DATABASE TO /oradata/srcdbupg/datafile/%b; SET UNTIL TIME TO_DATE(2022-08-30:02:00:00,YYYY-MM-DD:HH24:MI:SS); RESTORE DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFSET NEWNAME FOR DATABASE TO里的%b表示保留原文件名只换目录减少文件名冲突。SET UNTIL TIME是 restore 的时间上限不是最终恢复时间后面 recover 可以继续往后走。通道数量按备份片所在磁盘的吞吐调整通道不是越多越好I/O 打满后反而互相拖慢。restore 完成后要让控制文件指向新文件再执行 recover。下面示例先切到 copy再追到更晚的时间点。rman target / EOF SWITCH DATABASE TO COPY; run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; ALLOCATE CHANNEL C3 DEVICE TYPE DISK; ALLOCATE CHANNEL C4 DEVICE TYPE DISK; SET UNTIL TIME TO_DATE(2022-08-30:07:00:00,YYYY-MM-DD:HH24:MI:SS); RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFSWITCH DATABASE TO COPY让控制文件正式使用 restore 出来的副本少了这一步后面打开数据库还会去找旧路径。RECOVER DATABASE应用归档和在线日志SET UNTIL TIME控制追到哪个时间点。时间点不要一次追到源库当前时间先追到一个可校验的中间点打开只读确认数据文件一致再继续追。如果归档足够可以再追一次到更晚时间。下面示例追到 12:00实际业务窗口按自己的备份和归档情况改。rman target / EOF run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; ALLOCATE CHANNEL C3 DEVICE TYPE DISK; ALLOCATE CHANNEL C4 DEVICE TYPE DISK; SET UNTIL TIME TO_DATE(2022-08-30:12:00:00,YYYY-MM-DD:HH24:MI:SS); RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOF每次 recover 后看 RMAN 输出里应用的归档序列和 SCN确认没有跳号。归档备份片和在线归档都可以作为来源catalog start with之后 RMAN 才能识别备份片里的归档。时间点越靠近源库当前时间升级后业务验证越完整但升级窗口也越长取舍点在业务能接受的停写窗口。3.3 read only 校验和继续追归档数据文件恢复到一个阶段后用只读方式打开做一次文件头和基本查询校验。只读打开不会写数据文件适合在升级前确认恢复库可用。sqlplus / as sysdba EOF alter database open read only; select name, open_mode from v$database; select file#, name, status from v$datafile; select file#, name, status from v$tempfile; EOFopen read only成功后v$database.open_mode显示READ ONLYv$datafile里所有数据文件状态应为 online。此时可以跑几条业务只读 SQL确认核心表能访问。只读打开后如果还要继续追归档必须先关库再启到 mount不能直接在 read only 状态做恢复。sqlplus / as sysdba EOF shutdown abort; startup mount; EOF rman target / EOF run { ALLOCATE CHANNEL C1 DEVICE TYPE DISK; ALLOCATE CHANNEL C2 DEVICE TYPE DISK; ALLOCATE CHANNEL C3 DEVICE TYPE DISK; ALLOCATE CHANNEL C4 DEVICE TYPE DISK; RECOVER DATABASE; RELEASE CHANNEL C4; RELEASE CHANNEL C3; RELEASE CHANNEL C2; RELEASE CHANNEL C1; } EOFshutdown abort在测试恢复库上可以用生产库不要照搬。startup mount后继续RECOVER DATABASE不写SET UNTIL TIME表示尽量追到最后一个可用归档。追到没有归档时常见报错是RMAN-06054: media recovery requesting unknown archived log意思是要某个序列的归档但备份里没有。先list backup of archivelog all看已有序列再从源库补拷缺失归档catalog start with后继续 recover。rman target / EOF list backup of archivelog all; EOFlist backup of archivelog all的输出重点看线程号、序列号、低 SCN 和完成时间。缺的归档序列如果源库还在直接从源库归档目录拷到/hisbak或/arch再 catalog。不要在没有确认归档完整性的情况下强行打开读写升级前的恢复库越干净DBUA 阶段越少黑匣子。4. DBUA 执行升级19C Home 环境变量、图形界面和静默模式4.1 升级前检查监听、无效对象、时区、归档DBUA 启动前先做一轮检查别让无效对象和归档问题把升级窗口吃掉。下面 SQL 在恢复库的 11g 环境执行确认版本、组件、无效对象和归档模式。-- 在恢复库 11g 环境执行 select banner from v$version; select name, open_mode, log_mode from v$database; select comp_name, status, version from dba_registry; select count(*) invalid_count from dba_objects where status INVALID; select destination, status, error from v$archive_dest where destination is not null;v$version确认源库版本v$database.log_mode应为 ARCHIVELOG本文还有配套的精品资源点击获取
