如何使用逻辑备库从11g滚动升级到19c，大大减少业务停机时间

老苏畅谈运维

已于 2024-08-30 16:02:55 修改

阅读量1k

点赞数 19

分类专栏： oracle 数据迁移 dataguard 文章标签： oracle 数据库 dataguard adg

于 2024-08-30 13:56:11 首次发布

文章来源于老苏畅谈运维，欢迎您转载，转载声明来源老苏畅谈运维

本文链接：https://blog.csdn.net/zhirongsu/article/details/141716412

版权

oracle 同时被 3 个专栏收录

41 篇文章 2 订阅

订阅专栏

dataguard

10 篇文章 0 订阅

订阅专栏

数据迁移

5 篇文章 0 订阅

订阅专栏

本文使用将物理dg临时转换为逻辑dg，然后对逻辑dg进行升级。升级完成后，数据保持与生产同步。确认升级后的环境没有问题，将其切换为主库，接管业务，降低升级过程中的停机时间。从而达到在较少停机时间内，完成Oracle 11g升级到19c的目标。

环境

角色	IP	DB_UNIQUE_NAME	数据库版本	目标升级版本
主库	10.10.10.42	dbtest	11.2.0.4
备库	10.10.10.43	dgdbtest	11.2.0.4	19.23

说明：主备库按照部署物理ADG的方式部署，这里省略部署步骤。

升级前的准备

备库安装19c软件

创建安装目录

$ mkdir -p /u01/app/oracle/product/19.3.0.0/db

解压安装包

--unset配置相关变量,防止误操作
unset ORACLE_BASE
unset ORACLE_HOME
unset ORACLE_SID

$ unzip -q LINUX.X64_193000_db_home.zip  -d /u01/app/oracle/product/19.3.0.0/db

安装19c软件

更新OPatch版本

$ /u01/app/oracle/product/19.3.0.0/db/OPatch/opatch version
OPatch Version: 12.2.0.1.17

OPatch succeeded.
$ unzip -q p6880880_190000_Linux-x86-64.zip -d /u01/app/oracle/product/19.3.0.0/db
replace /u01/app/oracle/product/19.3.0.0/db/OPatch/docs/cversion.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: A  
$ /u01/app/oracle/product/19.3.0.0/db/OPatch/opatch version
OPatch Version: 12.2.0.1.43

OPatch succeeded.

–安装过程合并升级RU

$ export DISPLAY=10.10.10.1:0.0
$ xhost +
$ unzip -q p36233263_190000_Linux-x86-64.zip -d /media/
$ cd /u01/app/oracle/product/19.3.0.0/db

$ ./runInstaller -applyRU /media/36233263/
Preparing the home to patch...
Applying the patch /media/36233263/...
Successfully applied the patch.
The log can be found at: /u01/app/oraInventory/logs/InstallActions2024-08-28_08-14-23PM/installerPatchActions_2024-08-28_08-14-23PM.log
Launching Oracle Database Setup Wizard...

执行root.sh脚本

# /u01/app/oracle/product/19.3.0.0/db/root.sh
Performing root user operation.

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /u01/app/oracle/product/19.3.0.0/db

如果runInstaller -applyRU方式安装数据库，执行意外中断，重新执行提示报错，报错信息如下：

$ ./runInstaller -applyRU /media/36233263/

ERROR: The home is not clean. This home cannot be used since there was a failed OPatch execution in this home. Use a different home to proceed.

解决方法：

$ cd /u01/app/oracle/product/19.3.0.0/db/install
看到新增了一个patch文件，并且大小为0， 将它删除之后，重新runinstaller可以正常执行。
$ rm -rf patch

转为逻辑standby的准备工作

检查不支持的数据类型

并非所有的数据类型都能被逻辑Standby支持，不支持的数据类型有：
BFILE、Encrypted Columns、ROWID, UROWID、XMLType、对象类型、VARRAYS、嵌套表、自定义类型。
通过查询DBA_LOGSTDBY_UNSUPPORTED来确定主数据库中是否含有不支持的对象

--检查方法
sys@DBTEST > select DISTINCT OWNER, TABLE_NAME,COLUMN_NAME,DATA_TYPE,ATTRIBUTES FROM DBA_LOGSTDBY_UNSUPPORTED;

no rows selected

注意：该视图的ATTRIBUTES列，显示对象不被SQL应用支持的原因。
对应不支持的字段表，需要再迁移后，单独导入

检查不支持的表和序列

并非所有的表能被逻辑Standby支持，不支持的表有：

表包只包含LOB (CLOB, NCLOB, BLOB),LONG,LONG RAW,OBJECT TYPE,COLLECTIONS,XML,VARCHAR2 (with a declared column length > 4000 bytes),NVARCHAR2 (with a declared column length > 4000 bytes),RAW (with a declared column length > 4000 bytes)列的表

分区包含系统分区以及关联子分区

Tables and sequences in the SYS schema
Tables with unsupported datatypes
Tables used to support functional indexes
Tables used to support materialized views
Global temporary tables

sys@DBTEST > select * from DBA_LOGSTDBY_UNSUPPORTED_TABLE;

OWNER			       TABLE_NAME
------------------------------ ------------------------------
SZR			       SQL_STSTAB

注意：对于不支持的表，需要迁移后，再单独导入。

检查不支持的PL/SQL包

并非所有的PL/SQL包都能被SQL应用支持。

通常那些不会修改系统元数据（Metadata）的Package在实际应用时不会有问题，如DBMS_OUTPUT、DBMS_RANDOM、DBMS_METADATA之类的包。

那些可能修改系统元数据的Package不会被SQL应用支持，即使它们在Primary执行过，并且被成功传输到逻辑Standby端，也不会执行。如DBMS_JAVA、DBMS_REGISTRY、DBMS_ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESH、DBMS_REDEFINITION、DBMS_SCHEDULER及DBMS_AQ等。只有DBMS_JOB例外，Primary数据库的jobs会被复制到逻辑Standby，不过在逻辑Standby数据库不会执行这些job。

说明：元数据，直接理解成对象的物理定义。对于某表而言，元数据就是表结构，或表的存储属性等。

检查没有主键的表

逻辑复制需要主键或非null唯一键,如果没有主键以及唯一键，则默认用非clob，blob字段的全部列作为主键

SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE
 WHERE (OWNER, TABLE_NAME) NOT IN 
 (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 
 AND BAD_COLUMN = 'Y';

逻辑Standby与Primary的数据库同步是通过SQL应用实现，SQL应用转换的SQL语句在执行时，对于INSERT还好说，对于UPDATE、DELETE操作则必须能够唯一定位到数据库待更新的那条记录。问题就在这里，如果Primary库中表设置不当，可能就无法确认唯一条件。

你可能会说可以通过ROWID唯一嘛！千万要谨记啊，逻辑Standby，为啥叫逻辑Standby，就是因为它只是逻辑上与Primary数据库相同，物理上可能与Primary数据库存在相当大差异。一定要认识到，逻辑Standby的物理结构与Primary是不相同的（即使初始逻辑Standby是通过Primary的备份创建）。

因此想通过ROWID更新显然是不好使的，当然也就不能再将其作为唯一条件。

对于应用可以确保数据唯一，但实际没有创建主键的，可以通过创建RELY DISABLE告诉数据库数据是符合唯一要求的，但是实际上约束并没有起作用。比如在创建逻辑standby的时候，oracle建议对那些没有主键或者唯一索引，且检查发现DBA_LOGSTDBY_NOT_UNIQUE.BAD_COLUMN=Y的表创建rely disable的主键。

ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;

检查不支持的同步用户

sys@DBTEST > SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

OWNER
------------------------------
SYS
SYSTEM
MDSYS
ORDSYS
EXFSYS
DBSNMP
WMSYS
ORACLE_OCM
APPQOSSYS
XS$NULL
APEX_030200
ORDDATA
CTXSYS
ANONYMOUS
OUTLN
DIP
SYSMAN
XDB
ORDPLUGINS
OWBSYS
MGMT_VIEW
SI_INFORMTN_SCHEMA
OLAPSYS

23 rows selected.

不支持的ddl语句

并非所有的SQL语句都能在逻辑Standby端执行，所以尽量在逻辑standby期间少执行ddl语句。
在默认情况下，下列SQL语句在逻辑Standby端会被SQL应用自动跳过：

ALTER DATABASE。  
ALTER MATERIALIZED VIEW。  
ALTER MATERIALIZED VIEW LOG。  
ALTER SESSION。  
ALTER SYSTEM。  
CREATE CONTROL FILE。  
CREATE DATABASE。  
CREATE DATABASE LINK。  
CREATE PFILE FROM SPFILE。  
CREATE MATERIALIZED VIEW。  
CREATE MATERIALIZED VIEW LOG。  
CREATE SCHEMA AUTHORIZATION。  
CREATE SPFILE FROM PFILE。  
DROP DATABASE LINK。  
DROP MATERIALIZED VIEW。  
DROP MATERIALIZED VIEW LOG。  
EXPLAIN。  
LOCK TABLE。  
SET CONSTRAINTS。  
SET ROLE。  
SET TRANSACTION。

另外，由于SQL语句非常灵活，即使是那些能被SQL应用支持的DDL语句，可能在附加了某些特别的参数后，也不会在逻辑Standby端执行，由于数目较多，此处不再一一列举，感兴趣的话请查阅官方文档。

升级步骤

主库创建闪回点（可选）

–对于切换之后，主库计划作为物理备库的，需要先在主库创建闪回点，备库转为逻辑备库之前。

–主库创建闪回点需要确保闪回区的空间足够，归档日志空间足够。

--若主库为启用闪回，需先启用
select flashback_on from v$database;
--查询闪回点
SELECT name, scn, time FROM v$restore_point;  
--mount 模式开启闪回
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE FLASHBACK ON;   
SQL> ALTER DATABASE OPEN;

--创建闪回点
sys@DBTEST > create restore point pre_standby guarantee flashback database;

Restore point created.

物理备库转化为逻辑备库

停止db broker

如果你配置了db broker，建议在主从节点都关掉

SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;

备库关闭日志应用

–有条件的话，可以先把物理standby做一个RMAN全备份，然后中止主备同步

DGDBTEST > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

主库创建日志数据字典

logmnr 根据这个将 redo 转换为逻辑 dg 的 sql，防止转换逻辑dg时长时间没反应

sys@DBTEST > select
SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL,SUPPLEMENTAL_LOG_DATA_MIN
from gv$database;  2    3  

SUP SUP SUPPLEME
--- --- --------
NO  NO	NO
----执行会等待数据库事务结束
sys@DBTEST > EXECUTE DBMS_LOGSTDBY.BUILD

PL/SQL procedure successfully completed.
--自动开启补充日志
sys@DBTEST > select
SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL,SUPPLEMENTAL_LOG_DATA_MIN
from gv$database;
  2    3  
SUP SUP SUPPLEME
--- --- --------
NO  NO	IMPLICIT

备库启动到mount状态

如果备库是 open 状态，无法转换，会报错，需要重启数据库至 mount 状态:

open状态，无法转换，会报错：
ERROR at line 1:
ORA-19953: database should not be open


--单机关闭启动到mount
SHUTDOWN immediate;
STARTUP MOUNT ;
--如果是RAC，需要启动为独占模式
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE;
SQL> SHUTDOWN immediate;
SQL> STARTUP MOUNT EXCLUSIVE;

转为逻辑备库

DGDBTEST > col name for a10;
DGDBTEST > set linesize 300;
DGDBTEST > select name,open_mode,db_unique_name,database_role from v$database;

NAME	   OPEN_MODE		DB_UNIQUE_NAME		       DATABASE_ROLE
---------- -------------------- ------------------------------ ----------------
DBTEST	   MOUNTED		dgdbtest		       PHYSICAL STANDBY


DGDBTEST > ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;

Database altered.

--语句会等待读取到从主库发送过来的日志里面包含LogMiner dictionary
--KEEP IDENTITY 是为了保持 dbid 不变，这是 11g 引入的新特性。10g 只能 ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;
--如长时间卡住，主库再次执行构建 LogMiner 字典

DGDBTEST > select name,open_mode,db_unique_name,database_role,controlfile_type from v$database;

NAME	   OPEN_MODE		DB_UNIQUE_NAME		       DATABASE_ROLE	CONTROL
---------- -------------------- ------------------------------ ---------------- -------
DBTEST	   MOUNTED		dgdbtest		       LOGICAL STANDBY	CURRENT

打开逻辑备库


DGDBTEST > alter database open;

Database altered.

逻辑备库开启event记录，记录不支持的操作，这样可以在切换之前，确认更新的数据库的事务是否存在没有应用的情况，将信息捕获并作为事件记录在 DBA_LOGSTDBY_events 表中。

EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS);
EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');

在逻辑备库中禁用自动删除外部存档日志，避免升级完之后，日志被删除。如果在使用恢复区域存储远程存档日志，则必须确保它有足够的空间来容纳这些日志，否则会影响逻辑备用数据库的正常操作。

EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');

逻辑备库开启同步

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

验证备库是否正常运行

--检查备库的进程状态
SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;
SELECT STATUS FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'READER';

--检查备库日志应用进度
SQL> SELECT THREAD#,SEQUENCE#,FILE_NAME,APPLIED,TIMESTAMP FROM DBA_LOGSTDBY_LOG D WHERE D.SEQUENCE# >=(SELECT MAX(SEQUENCE#)-3 FROM DBA_LOGSTDBY_LOG NB WHERE NB.THREAD#=D.THREAD# AND NB.APPLIED='YES' ) ORDER BY THREAD#,D.SEQUENCE#;

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
SQL> SELECT SYSDATE, APPLIED_TIME,APPLIED_SCN,MINING_TIME, MINING_SCN FROM V$LOGSTDBY_PROGRESS;
SQL> SELECT STATUS FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'READER';

--备库查看不支持事务，查询是否有报错记录：
SET LONG 1000
SET PAGESIZE 180
SET LINESIZE 400
col event for a80
col status for a50
select XIDUSN, XIDSLT, XIDSQN , status , event , event_time  from dba_logstdby_events order by event_time desc;

--主库上非系统用户创建测试表
conn szr/szr
CREATE TABLE tt (  id NUMBER PRIMARY KEY,  name VARCHAR2(50),  age NUMBER);
-- 插入测试数据
INSERT INTO tt (id, name, age)VALUES (1, 'John', 25);
INSERT INTO tt (id, name, age)VALUES (2, 'Jane', 30);
commit;

--主库压测，模拟dml操作
/usr/local/swingbench/bin/charbench -c /usr/local/swingbench/configs/SOE_Server_Side_V2.xml \
-u soe -p oracle -cs "//10.10.10.42/dbtest" -dt thin  -uc 10 \
-a -v "users,tpm,tps,dml,cpu" \
-rr 5 -rt "00:10" -min 50 -max 50 -r "/tmp/testdb.xml"

逻辑备库升级到19c

备库升级前的检查

收集优化器统计信息以减少Oracle 数据库停机时间，如果您的数据库包含数千个字典表，那么 Oracle 强烈建议您在开始升级前一天晚上收集统计信息：

DGDBTEST > EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

PL/SQL procedure successfully completed.

升级前验证物化化视图刷新是否完成，升级 Oracle 数据库之前，必须等到所有具体化视图都已完成刷新。

SELECT s.obj#,o.obj#,s.containerobj#,lastrefreshdate,pflags,xpflags,o.name,o.owner#,
bitand(s.mflags, 8) from obj$ o, sum$ s WHERE o.obj# = s.obj# AND o.type# =42 AND bitand(s.mflags, 8) = 8;

确保升级前没有文件处于备份模式，如果此 SQL 语句指示文件仍在备份中，请等待备份完成，或者在尝试升级之前中止任何不需要的备份。

DGDBTEST > SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';

no rows selected

确保升级前没有文件需要做介质恢复

DGDBTEST > SELECT * FROM v$recover_file;

no rows selected

升级之前解决未完成的分布式事务，通过首先查询以查看任何挂起的事务，然后提交这些事务来完成此操作。必须等到所有挂起的分布式事务都已提交。

SQL> SELECT * FROM dba_2pc_pending;

如果上一步中的查询有返回行，则运行以下语句：

SQL> SELECT local_tran_id FROM dba_2pc_pending;

SQL> EXECUTE dbms_transaction.purge_lost_db_entry('');

SQL> COMMIT;

升级之前清空回收站释放存储空间

在升级过程中，数据库回收站必须为空，以避免可能的 ORA-00600 错误，并将升级时间减至最少。

DGDBTEST > PURGE DBA_RECYCLEBIN;

DBA Recyclebin purged.

复制透明加密 Oracle 钱包

如果您使用 Oracle wallet with Transparent Data Encryption（TDE），并使用 Database Upgrade Assistant（DBUA）升级数据库，则复制 sqlnet.ora 把钱包文件放到新的 ORACLE 目录里。

必须复制 sqlnet.ora 和钱包文件手动启动升级。拷贝 sqlnet.ora file, and the wallet file, ewallet.p12 到新的 Oracle 目录里。

密码区分大小写和升级

默认情况下，Oracle Database 12c release 2(12.2)以上升级为独占模式。独占模式不支持不区分大小写的基于密码的身份验证。
当服务器以独占模式运行时，只有 10G 密码版本的帐户将无法访问。在以前的 Oracle 数据库版本中，可以将身份验证协议配置为允许基于密码的不区分大小写的身份验证，方法是设置 SEC_case_SENSITIVE_LOGON=FALSE。
从 Oracle Database 12c release 2（12.2）开始，默认的基于密码的身份验证协议配置不使用不区分大小写的 10G 密码版本，因为在默认情况下 SQLNET.ORA参数 SQLNET.ALLOWED_LOGON_VERSION_SERVER 值为 12，这是独占模式。

查找使用不区分大小写（10G）版本的用户帐户
select USERNAME from DBA_USERS where (PASSWORD_VERSIONS = '10G ' or PASSWORD_VERSIONS ='10G HTTP ') and USERNAME <> 'ANONYMOUS';
配置参数 sqlnet.ora 中参数 SQLNET.ALLOWED_LOGON_VERSION_SERVER=11 后，再执行升级操作。

升级完成后，通过修改用户口令过期的方式来处理上面查询出来的受到影响的账户。
ALTERUSER username PASSWORD EXPIRE;

开启大小写区分
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = TRUE;

备库关闭同步

备库关闭 sql apply，确保备库没有处于同步模式

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

运行 19c 预升级检查和处理

[oracle@11gto19cdg:~]$ /u01/app/oracle/product/11.2.0/db/jdk/bin/java -jar /u01/app/oracle/product/19.3.0.0/db/rdbms/admin/preupgrade.jar
==================
PREUPGRADE SUMMARY
==================
  /u01/app/oracle/cfgtoollogs/dgdbtest/preupgrade/preupgrade.log
  /u01/app/oracle/cfgtoollogs/dgdbtest/preupgrade/preupgrade_fixups.sql
  /u01/app/oracle/cfgtoollogs/dgdbtest/preupgrade/postupgrade_fixups.sql

Execute fixup scripts as indicated below:

Before upgrade:

Log into the database and execute the preupgrade fixups
@/u01/app/oracle/cfgtoollogs/dgdbtest/preupgrade/preupgrade_fixups.sql

After the upgrade:

Log into the database and execute the postupgrade fixups
@/u01/app/oracle/cfgtoollogs/dgdbtest/preupgrade/postupgrade_fixups.sql

Preupgrade complete: 2024-08-30T09:56:04

1)	检查日志，根据情况，修复相关内容。根据preupgrade.log提示修复，里面方法写的很详细。
2)	执行升级前脚本,它会修复一些它能修复的，其它的会要求手工修复。
SQL>/u01/app/oracle/preupgrade/preupgrade_fixups.sql;
3)  一定记得后面升级完成还要执行升级之后脚本。

cat /u01/app/oracle/cfgtoollogs/dgdbtest/preupgrade/preupgrade.log

根据上面的输出，在升级时候要遵守preupgrade.log里面的建议。整个升级过程都在严格遵守preupgrade.log的建议。
日志中并指出，在升级前执行preupgrade_fixups.sql脚本，在升级后执行postupgrade_fixups.sql脚本。

执行修复脚本

@/u01/app/oracle/cfgtoollogs/dgdbtest/preupgrade/preupgrade_fixups.sql

dbua升级数据库

###ORACLE_HOME变量为11g的目录
###dbua在19c的目录下执行
###需要sys用户的密码
[oracle@11gto19cdg:~]$ cd /u01/app/oracle/product/19.3.0.0/db/bin
[oracle@11gto19cdg:/u01/app/oracle/product/19.3.0.0/db/bin]$ echo $ORACLE_HOME
/u01/app/oracle/product/11.2.0/db
[oracle@11gto19cdg:/u01/app/oracle/product/19.3.0.0/db/bin]$ 

--确保要升级的数据库有在/etc/oratab里面，否则需要手动添加，不然dbua时候识别不到该数据库
# cat /etc/oratab
dbtest:/u01/app/oracle/product/11.2.0/db:N


$ export DISPLAY=10.10.10.1:0.0
$ xhost +
access control disabled, clients can connect from any host
$ ./dbua

###升级时的归档要全部保留，方便闪回

输入sys用户和密码

尽可能解决上面的问题后，在运行下一步

更改环境变量

[oracle@11gto19cdg:/u01/app/oracle/product/19.3.0.0/db/bin]$ ps -ef|grep pmon
oracle   12153     1  0 11:08 ?        00:00:00 ora_pmon_dgdbtest
oracle   12919  4050  0 11:16 pts/3    00:00:00 grep --color=auto pmon
[oracle@11gto19cdg:/u01/app/oracle/product/19.3.0.0/db/bin]$ pwdx 12153
12153: /u01/app/oracle/product/19.3.0.0/db/dbs

$ vi .bash_profile
#export ORACLE_HOME=/u01/app/oracle/product/11.2.0/db
export ORACLE_HOME=/u01/app/oracle/product/19.3.0.0/db

[oracle@11gto19cdg:~]$ source .bash_profile
[oracle@11gto19cdg:~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Aug 30 11:21:59 2024
Version 19.23.0.0.0

Copyright (c) 1982, 2023, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

重启监听

使用19c的监听
$ lsnrctl stop
$ lsnrctl start
$ lsnrctl status

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 30-AUG-2024 11:27:04

Copyright (c) 1991, 2024, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                30-AUG-2024 11:26:36
Uptime                    0 days 0 hr. 0 min. 27 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /u01/app/oracle/diag/tnslsnr/11gto19cdg/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=11gto19cdg)(PORT=1521)))
Services Summary...
Service "dbtest" has 1 instance(s).
  Instance "dgdbtest", status READY, has 1 handler(s) for this service...
Service "dgdbtest" has 1 instance(s).
  Instance "dgdbtest", status READY, has 1 handler(s) for this service...
Service "dgdbtestXDB" has 1 instance(s).
  Instance "dgdbtest", status READY, has 1 handler(s) for this service...
The command completed successfully

升级完成，执行修复sql

[oracle@11gto19cdg:~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Aug 30 11:21:59 2024
Version 19.23.0.0.0

Copyright (c) 1982, 2023, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL> @/u01/app/oracle/cfgtoollogs/dgdbtest/preupgrade/postupgrade_fixups.sql

Session altered.


PL/SQL procedure successfully completed.


PL/SQL procedure successfully completed.


PL/SQL procedure successfully completed.


Package created.

No errors.

Package body created.


PL/SQL procedure successfully completed.

No errors.





Package created.

No errors.

Package body created.

No errors.

升级完成后设置

拷贝tnsnames.ora、 sqlnet.ora 等到19c相关目录

$ cd /u01/app/oracle/product/11.2.0/db/network/admin/
$ cp tnsnames.ora sqlnet.ora /u01/app/oracle/product/19.3.0.0/db/network/admin/

升级后检查

检查版本

SQL>  select name,open_mode,db_unique_name,database_role,version from v$database,v$instance;

NAME	  OPEN_MODE	       DB_UNIQUE_NAME		      DATABASE_ROLE    VERSION
--------- -------------------- ------------------------------ ---------------- -----------------
DBTEST	  READ WRITE	       dgdbtest 		      LOGICAL STANDBY  19.0.0.0.0

这时候我们看到，版本已经变成了19.0.0.0，接下来检查一下是否有无效对象，对于很多老库可能会比较多，我是新库，所以这里是0

检查各组件是否已经正常：

set linesize 400
set pagesize 400
Col Comp_name Format a60
Col Status Format a12
Select Comp_name, status, Version
From Dba_Registry
Order by Comp_name;

COMP_NAME						     STATUS	  VERSION
------------------------------------------------------------ ------------ ------------------------------
JServer JAVA Virtual Machine				     VALID	  19.0.0.0.0
OLAP Analytic Workspace 				     VALID	  19.0.0.0.0
Oracle Database Catalog Views				     VALID	  19.0.0.0.0
Oracle Database Java Packages				     VALID	  19.0.0.0.0
Oracle Database Packages and Types			     VALID	  19.0.0.0.0
Oracle Multimedia					     VALID	  19.0.0.0.0
Oracle OLAP API 					     VALID	  19.0.0.0.0
Oracle Real Application Clusters			     OPTION OFF   19.0.0.0.0
Oracle Text						     VALID	  19.0.0.0.0
Oracle Workspace Manager				     VALID	  19.0.0.0.0
Oracle XDK						     VALID	  19.0.0.0.0
Oracle XML Database					     VALID	  19.0.0.0.0
Spatial 						     VALID	  19.0.0.0.0

13 rows selected.

RAC全部都是VALID，单节点除了RAC是option off其他都是VALID，就意味着升级成功了

开启主备同步

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

启动同步后报错“ORA-23421: job number 4002 is not a job in the job queue”

参考官方文档 ID 2809432.1解决
After successfully upgrading the logical standby database from 11.2.0.4 to 19.11.0.0 and with the primary still on 11.2.0.4, below error is seen while applying logs on logical standby.


ORA-26808: Apply process AS02 died unexpectedly.
ORA-23421: job number 4002 is not a job in the job queue


SQL> alter database stop logical standby apply;

Database altered.

SQL> exec dbms_logstdby.skip('DML','SYS','JOB$');

PL/SQL procedure successfully completed.

SQL> exec dbms_logstdby.skip('SCHEMA_DDL','SYS','JOB$');

PL/SQL procedure successfully completed.

SQL> select statement_opt, name from dba_logstdby_skip where name = 'JOB$';

STATEMENT_OPT															 NAME
-------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DML																 JOB$
SCHEMA_DDL															 JOB$

SQL>  alter database start logical standby apply;

Database altered.

在日志中查看，检查主备同步的状态。

正式迁移（应用停机）

接下来我们需要做的是申请停机窗口，激活逻辑standby为primary，将生产切换到这个已经完成升级的库。

当然这个切换是用switchover还是failover，根据实际需要选择吧，个人比较倾向于用failover，把原来的primary直接shutdown immediate，不要做任何改动，确保一旦需要回退时，把原库直接打开即可。

failover切换

SQL> select name,open_mode,db_unique_name,database_role,version from v$database,v$instance;

NAME	  OPEN_MODE	       DB_UNIQUE_NAME		      DATABASE_ROLE
--------- -------------------- ------------------------------ ----------------
VERSION
-----------------
DBTEST	  READ WRITE	       dgdbtest 		      LOGICAL STANDBY
19.0.0.0.0

 
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;
SQL> select name,open_mode,db_unique_name,database_role,version from v$database,v$instance;

NAME      OPEN_MODE            DB_UNIQUE_NAME  DATABASE_ROLE    VERSION           
--------- -------------------- --------------- ---------------- ----------------- 
DBTEST      READ WRITE           dgdbtest           PRIMARY          19.0.0.0.0

导入不支持复制的表

新环境通过impdp dblink导入逻辑备库不支持复制的表

--创建dblink
create public database link olddb
connect to system
identified by "oracle"
using '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.42)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=dbtest)))';

--查看不支持的表
SQL> col owner for a25;
SQL> col table_name for a50;
SQL> select owner,table_name from DBA_LOGSTDBY_UNSUPPORTED_TABLE;

OWNER			  TABLE_NAME
------------------------- --------------------------------------------------
SZR			  SQL_STSTAB

--新环境备库导入不支持的表
$ impdp SYSTEM/oracle directory=DATA_PUMP_DIR NETWORK_LINK=olddb TABLES=SZR.SQL_STSTAB TABLE_EXISTS_ACTION=TRUNCATE

Import: Release 19.0.0.0.0 - Production on Fri Aug 30 13:22:29 2024
Version 19.23.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Starting "SYSTEM"."SYS_IMPORT_TABLE_01":  SYSTEM/******** directory=DATA_PUMP_DIR NETWORK_LINK=olddb TABLES=SZR.SQL_STSTAB TABLE_EXISTS_ACTION=TRUNCATE 
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 576 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
Table "SZR"."SQL_STSTAB" exists and has been truncated. Data will be loaded but all dependent metadata will be skipped due to table_exists_action of truncate
. . imported "SZR"."SQL_STSTAB"                               4 rows
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Job "SYSTEM"."SYS_IMPORT_TABLE_01" successfully completed at Fri Aug 30 13:22:53 2024 elapsed 0 00:00:24

后续工作

如果确认新的环境没有问题了，新的primary需要调整一些配置：

--查询闪回点
SELECT name, scn, time FROM v$restore_point;  
NAME			    SCN TIME
-------------------- ---------- ---------------------------------------------------------------------------
GRP_1724985410583	1336720 30-AUG-24 10.36.50.000000000 AM

--删除创建的闪回点
DROP RESTORE POINT GRP_1724985410583;  

--修改COMPATIBLE为19c，注意修改为19c之后无法再进行回退
ALTER SYSTEM SET COMPATIBLE = '19.3.0.0.0' SCOPE=SPFILE

另外旧的primary再保留一阵子，以备不测。

关注我，学习更多的数据库知识！
请添加图片描述