使用逻辑备库的方式进行数据库升级

角色 IP DB_UNIQUE_NAME 数据库版本 目标升级版本
主库 192.168.56.155 db11g 11.2.0.4
备库 192.168.56.166 db11gdg 11.2.0.4 19.23
说明：主备库按照部署物理ADG的方式部署，这里省略部署步骤。

环境准备：
1 准备主备环境（oracle的物理主备库）
2 要升级的备库上面安装19c的oracle软件
3 19c软件升级psu到最新的版本



第一步：切换逻辑备库前检查：

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

select DISTINCT OWNER, TABLE_NAME,COLUMN_NAME,DATA_TYPE,ATTRIBUTES FROM DBA_LOGSTDBY_UNSUPPORTED;

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

1.2 检查不支持的表和序列
并非所有的表能被逻辑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

select * from DBA_LOGSTDBY_UNSUPPORTED_TABLE;

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

1.3 检查不支持的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。
说明：元数据，直接理解成对象的物理定义。对于某表而言，元数据就是表结构，或表的存储属性等。


1.4 检查没有主键的表
逻辑复制需要主键或非null唯一键,如果没有主键以及唯一键，则默认用非clob，blob字段的全部列作为主键
Y ：表示该表中有采用大数据类型的字段，比如LONG啦，CLOB啦之类。如果表中除log列某些行记录完全匹配，则该表无法成功应用于逻辑standby。
       standby会尝试维护这些表，不过你必须保证应用不允许。
   N ：表示该表拥有足够的信息，能够支持在逻辑standby的更新，不过仍然建议你为该表创建一个主键或者唯一索引/约束以提高log应用效率

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;


1.5 检查不支持的同步用户
SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

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



1.6 不支持的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;

--创建闪回点
create restore point pre_standby guarantee flashback database;
Restore point created.


第三步： 关闭物理备库同步

如果你配置了db broker，建议在主从节点都关掉
SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE;


备库关闭日志应用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;


第四步：物理备库转换为逻辑备库

主库创建日志数据字典
logmnr 根据这个将 redo 转换为逻辑 dg 的 sql，防止转换逻辑dg时长时间没反应

select
SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL,SUPPLEMENTAL_LOG_DATA_MIN
from gv$database;

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

PL/SQL procedure successfully completed.
--自动开启补充日志
select
SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL,SUPPLEMENTAL_LOG_DATA_MIN
from gv$database;
 
SUP SUP SUPPLEME
--- --- --------
NO NOIMPLICIT

备库启动到mount状态



--单机关闭启动到mount
SHUTDOWN immediate;
STARTUP MOUNT ;
--如果是RAC，需要启动为独占模式 我们的是单机
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE;
SQL> SHUTDOWN immediate;
SQL> STARTUP MOUNT EXCLUSIVE;
转为逻辑备库
col name for a10;
set linesize 300;
select name,open_mode,db_unique_name,database_role from v$database;

NAME   OPEN_MODEDB_UNIQUE_NAME       DATABASE_ROLE
---------- -------------------- ------------------------------ ----------------
DBTEST   MOUNTEDdgdbtest       PHYSICAL STANDBY


ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;

相关日志：
Mon Nov 18 03:24:15 2024
ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY
Media Recovery Start: Managed Standby Recovery (db11g)
Serial Media Recovery started
Managed Standby Recovery not using Real Time Apply
Media Recovery Log /u03/app/arch/1_16_1184806360.dbf
Media Recovery Log /u03/app/arch/1_17_1184806360.dbf
Media Recovery Log /u03/app/arch/1_18_1184806360.dbf
Incomplete Recovery applied until change 983957 time 11/18/2024 03:18:27
Media Recovery Complete (db11g)
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after incomplete recovery UNTIL CHANGE 983957
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Resetting resetlogs activation ID 654463381 (0x27025195)
Online log /u03/app/oracle/oradata/DB11GDG/onlinelog/o1_mf_1_mm5xbw7w_.log: Thread 1 Group 1 was previously cleared
Online log /u03/app/oracle/oradata/DB11GDG/onlinelog/o1_mf_2_mm5xbx1w_.log: Thread 1 Group 2 was previously cleared
Online log /u03/app/oracle/oradata/DB11GDG/onlinelog/o1_mf_3_mm5xbxvt_.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 983955
Mon Nov 18 03:24:17 2024
Setting recovery target incarnation to 3
RECOVER TO LOGICAL STANDBY: Complete - Database mounted as logical standby
Completed: ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY





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

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

NAME   OPEN_MODEDB_UNIQUE_NAME       DATABASE_ROLECONTROL
---------- -------------------- ------------------------------ ---------------- -------
DBTEST   MOUNTEDdgdbtest       LOGICAL STANDBYCURRENT
打开逻辑备库
--如果使用KEEP IDENTITY，则不需要使用RESETLOGS,使用RECOVER TO LOGICAL STANDBY db_name的方式需要open resetlogs
alter database open;




第五步：开启event 记录
逻辑备库开启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';

--检查备库日志应用进度
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#;

ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
SELECT SYSDATE, APPLIED_TIME,APPLIED_SCN,MINING_TIME, MINING_SCN FROM V$LOGSTDBY_PROGRESS;
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 zc/zc

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;


INSERT INTO tt (id, name, age)VALUES (3, 'Jane', 30);
commit;



第七步：升级前检查

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

7.2 升级前验证物化化视图刷新是否完成，升级 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;

7.3 确保升级前没有文件处于备份模式，如果此 SQL 语句指示文件仍在备份中，请等待备份完成，或者在尝试升级之前中止任何不需要的备份。
SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';

no rows selected

7.4 确保升级前没有文件需要做介质恢复
SELECT * FROM v$recover_file;

no rows selected

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

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

DGDBTEST > PURGE DBA_RECYCLEBIN;

DBA Recyclebin purged.

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

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

7.9 密码区分大小写和升级
默认情况下，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，这是独占模式。

7.10查找使用不区分大小写（10G）版本的用户帐户
select USERNAME from DBA_USERS where (PASSWORD_VERSIONS = '10G ' or PASSWORD_VERSIONS ='10G HTTP ') and USERNAME <> 'ANONYMOUS';

7.11配置参数 sqlnet.ora 中参数 SQLNET.ALLOWED_LOGON_VERSION_SERVER=11 后，再执行升级操作。

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

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

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

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;




第八步：预升级检查

预升级检查和处理
/u03/app/oracle/product/11.2.0/db_1/jdk/bin/java -jar /u02/app/oracle/product/19.9.0/db_1/rdbms/admin/preupgrade.jar

[oracle@rac2 dbs]$ /u03/app/oracle/product/11.2.0/db_1/jdk/bin/java -jar /u02/app/oracle/product/19.9.0/db_1/rdbms/admin/preupgrade.jar
==================
PREUPGRADE SUMMARY
==================
/u03/app/oracle/cfgtoollogs/db11gdg/preupgrade/preupgrade.log
/u03/app/oracle/cfgtoollogs/db11gdg/preupgrade/preupgrade_fixups.sql
/u03/app/oracle/cfgtoollogs/db11gdg/preupgrade/postupgrade_fixups.sql

Execute fixup scripts as indicated below:

Before upgrade:

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

After the upgrade:

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

Preupgrade complete: 2024-11-18T03:56:28


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


第九步：正式升级：

dbua升级数据库
###ORACLE_HOME变量为11g的目录
###dbua在19c的目录下执行
###需要sys用户的密码
cd /u02/app/oracle/product/19.9.0/db_1/bin
echo $ORACLE_HOME
/u03/app/oracle/product/11.2.0/db_1


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



[oracle@rac2 dbs]$ export DISPLAY=192.168.56.1:0.0
[oracle@rac2 dbs]$ xhost +
access control disabled, clients can connect from any host
xhost: must be on local machine to enable or disable access control.

[oracle@rac2 dbs]$ cd /u02/app/oracle/product/19.9.0/db_1/bin
[oracle@rac2 bin]$ echo $ORACLE_HOME
/u03/app/oracle/product/11.2.0/db_1/
[oracle@rac2 bin]$
[oracle@rac2 bin]$ ls
./dbua



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

输入sys用户和密码

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


更改环境变量

执行修复sql

@/u02/app/oracle/cfgtoollogs/dbua/upgrade2024-11-18_04-48-30AM/db11g/postupgrade_fixups.sql


第十步： 后续步骤和检查
10.1 修改环境变量

.bash_profile


10.2 修改监听到19c
$ lsnrctl stop
$ lsnrctl start
$ lsnrctl status


10.3 修改tnsnames.ora sqlnet.ora



升级后检查
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
--------- -------------------- ------------------------------ ---------------- -----------------
DB11G READ WRITE db11gdg LOGICAL STANDBY 19.0.0.0.0

组件
SQL> 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;SQL> SQL> SQL> SQL> 2 3

COMP_NAME STATUS VERSION
------------------------------------------------------------ ------------ ------------------------------
JServer JAVA Virtual Machine VALID 19.0.0.0.0
OLAP Analytic Workspace VALID 19.0.0.0.0
OLAP Catalog OPTION OFF 11.2.0.4.0
Oracle Application Express VALID 3.2.1.00.12
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



第十一步：
开启主备同步
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.



其他操作：
1 导入不支持的表

环境通过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


2 删除闪回点

-查询闪回点
SELECT name, scn, time FROM v$restore_point;  
NAME   SCN TIME
-------------------- ---------- ---------------------------------------------------------------------------
GRP_17249854105831336720 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