Oracle 11g单库升级至19C单库（跨版本DG逻辑主备同步方式）

本案例使用跨版本DG逻辑主备同步方式（11g逻辑备库方式同步到19c）完成数据库升级，即DG+常规数据库升级方式实现Oracle数据库滚动大版本升级，大幅减少停机时间，完成Oracle11g升级到19c数据库

一、案例环境

主库数据库版本：11.2.0.4 主库db_unique_name:orcl 升级后目标数据库版本：19.3.0.0 操作系统：linux7.9 数据库ORACLE_HOME：/u01/app/oracle/product/11.2.0/db_1 备库数据库版本：11.2.0.4 备库db_unique_name:orcl_st 升级后目标数据库版本：19.3.0.0 操作系统：linux7.9 数据库ORACLE_HOME：/u01/app/oracle/product/11.2.0/db_1 19C数据库ORACLE_HOME：/u01/app/oracle/product/19.3.0/db_1

二、过程概述

1、物理主备环境搭建（ADG）

2、物理主备转为逻辑主备

3、逻辑备库取消同步，将备库升级为19c（常规升级方式都行，例如DBUA、autoupgrade等）

4、逻辑备库重新恢复与主库的备库，此时主备环境中，主库为11g，逻辑备库19C！

5、正式升级开始，停止业务，将逻辑备库切换为主库，应用连接指向新的19c数据库！！

6、升级完毕后，旧环境的处理，旧环境指原先的主库，处理方式有如下四种

1）旧环境直接丢弃，新架构为19c单库方式，不再使用DG主备架构 2）旧环境同样升级为19c，作为逻辑备库与主库进行同步，后面也可以重新switchover到旧环境 3）旧环境恢复到物理备库(需要使用还原点)，然后作为物理备库与主库进行同步，通过应用新环境的redo日志升级到19c，后面也可以重新switchover到旧环境 4）旧环境直接重构（推倒重来），重新搭建19c物理主备环境

三、特别注意事项

逻辑备库的约束性，逻辑主库的同步方式有很多限制（约束），需要认真核查和分析，具体有如下7点
1、逻辑复制不支持的表字段类型

2、逻辑复制不支持的表

3、逻辑复制不支持的PL/SQL包

4、逻辑复制没有主键的表

5、逻辑复制不支持的同步用户

6、逻辑复制的DDL事务的限制

7、逻辑复制包含数据字典的语句限制（11g和19c版本部分数据字典表有变化不一致）
在文章的第五部分"逻辑备库的约束性和局限性"详细描述

四、具体升级步骤

1、物理主备环境搭建（ADG）
参考文章《Oracle 11g DataGuard主备架构搭建（集群对单库）》
2、备库主机上安装19c软件，并准备好环境变量配置文件
参考文章《Oracle 19c数据库软件和数据库静默安装》《Oracle 19c单机安装总结_linux7》
3、逻辑备库的约束性、局限性分析和排查
详见文章第五部分"逻辑备库的约束性和局限性"
4、可选，主库创建还原点（闪回点）

还原点的创建主要用于旧环境的处理，使得旧环境可以恢复到物理备库，需要先在主库创建还原点（闪回点），该还原点的创建时间必须在备库转为为逻辑备库之前！！！这一点很重要！另外需要确保闪回区的空间、归档日志空间足够 create restore point pre_log_standby guarantee flashback database; 备注： 1)还原点不会同步至物理备库 2)强制保证的还原点，无需数据库开启闪回功能，只要闪回目录有设置，数据库会自动开启。如下： SQL> create restore point pre_log_standby guarantee flashback database; Restore point created. SQL> select flashback_on from v$database; FLASHBACK_ON ------------------ RESTORE POINT ONLY 检查还原点： select * from v$restore_point;

5、物理备库转化为逻辑备库
1）取消备库日志应用

su - oracle sqlplus "/as sysdba" select open_mode,database_role,protection_level,protection_mode,switchover_status,force_logging from v$database; alter database recover managed standby database cancel;

2）主库初始化日志数据字典

初始化日志数据字典 execute dbms_logstdby.build; 作用： 1）构建LogMiner数据字典：它为主库的数据字典（包含所有表、列的定义等元数据）创建一份一致性快照。这份快照就是逻辑备库用来解析主库Redo日志中DML/DDL操作的"翻译手册"。 2）写入Redo日志并传输：构建好的数据字典信息会被写入主库的Redo日志流中。随后，这些日志会被传输到备库，为备库的初始化提供必要的元数据。 3）自动启用补充日志（Supplemental Logging）：为确保逻辑备库能唯一识别变更的行，该过程会自动为主库开启库级的补充日志，模式为 PRIMARY KEY。如果主库未开启，逻辑备库将无法正常工作 备注： 1）是一个一次性的动作，用于在主库上生成初始数据字典并写入Redo日志，是创建逻辑备库的前提 2）执行前务必停掉备库的日志应用 3）执行会等待数据库事务结束 4）执行后会自动开启补充日志，如下： select SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL,SUPPLEMENTAL_LOG_DATA_MIN from gv$database; 执行前 SQL> select SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL,SUPPLEMENTAL_LOG_DATA_MIN 2 from gv$database; SUP SUP SUPPLEME --- --- -------- NO NO NO SQL> EXECUTE DBMS_LOGSTDBY.BUILD; PL/SQL procedure successfully completed. 执行后 SQL> select SUPPLEMENTAL_LOG_DATA_FK,SUPPLEMENTAL_LOG_DATA_ALL,SUPPLEMENTAL_LOG_DATA_MIN 2 from gv$database; SUP SUP SUPPLEME --- --- -------- NO NO IMPLICIT

3）将备库启动为mount

//单机环境下 su - oracle sqlplus "/as sysdba" shutdown immediate; startup mount ; //如果是RAC集群，需要以独占模式启动 ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE; srvctl stop database -d orcl -o immediate; sqlplus "/as sysdba" STARTUP MOUNT EXCLUSIVE;

4）备库转化为逻辑备库角色（备库上执行）

方法一:指定新的db_name

指定与主数据库不同的数据库名称以标识新的逻辑备用数据库。 如果使用的是服务器参数文件（spfile） 在发出此语句时，数据库将更新该文件有关新逻辑备用数据库的相应信息。如果使用spfile文件，数据库会发出一条消息，提醒设置关闭数据库后，修改db_name参数 ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;

方法二:保留相同的db_name(滚动升级使用这种方式)

alter database recover to logical standby keep identity; 备注：语句会等待读取到从主库发送过来的日志里面包含LogMiner dictionary

5）检查、确认备库角色已经转为逻辑备库

select database_role,name,controlfile_type from v$database; SQL> select database_role,name,controlfile_type from v$database; DATABASE_ROLE NAME CONTROL ---------------- --------- ------- LOGICAL STANDBY ORCL CURRENT

6）调整逻辑备库的日志路径，逻辑备库日志有4种类型online log(archive log),standby log（Foreign Archived Logs）需要将日志归档分开

mkdir -p /oradata/arch/online/orcl_st mkdir -p /oradata/arch/standbylog/orcl_st 1）归档online log alter system set LOG_ARCHIVE_DEST_1='LOCATION=/oradata/arch/online/orcl_st VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl_st'; 2）primary role的归档路径（当备库转为主库时，会使用这个路径） alter system set LOG_ARCHIVE_DEST_2='service=orcl LGWR ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=30 net_timeout=300 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=orcl'; 3）归档standby log ,也叫Foreign Archived Logs，逻辑备库接收到主库的日志，由于日志的DBID可能不一样，所以叫做外部归档日志，日志无法通过RMAN进行备份删除，如果设置了闪回区，则日志会存放在闪回区里面 alter system set LOG_ARCHIVE_DEST_3='LOCATION=/oradata/arch/standbylog/orcl_st VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=orcl_st';

7）打开逻辑备库

备注：如果使用KEEP IDENTITY，不需要使用RESETLOGS,如果使用的是RECOVER TO LOGICAL STANDBY db_name的方式则需要open resetlogs shutdown immediate; startup mount; alter database open; select database_role,name,controlfile_type,open_mode from v$database; SQL> select database_role,name,controlfile_type,open_mode from v$database; DATABASE_ROLE NAME CONTROL OPEN_MODE ---------------- --------- ------- -------------------- LOGICAL STANDBY ORCL CURRENT READ WRITE

8）逻辑备库开启event记录，记录不支持的操作，这样可以在切换之前，记录更新的数据库的事务是否存在没有应用的情况

EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS); EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE'); 说明： EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE'); 开启逻辑备库对"不支持操作"的捕获与记录功能,捕获的信息会写入 DBA_LOGSTDBY_EVENTS 视图中; EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS); 默认保留最近的100条事件记录，但可以通过DBMS_LOGSTDBY.APPLY_SET过程的MAX_EVENTS_RECORDED参数调整，最大值可达10,000;

9）逻辑备库开启日志同步

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

10）逻辑备库同步验证小测试

主库上执行 create user user1 identified by user1; grant dba to user1; create table user1.t1_lob (c1 blob,c2 clob); create table user1.t1 (id number); insert into user1.t1 values(3); commit; create table user1.t2 as select * from dba_users; create tablespace tbs2 datafile '/oradata/orcl/tbs2.dbf' size 10m; 备库上检查是否正常同步过来 select count(*) from user1.t2 ; select file_name from dba_data_files a where tablespace_name='TBS2';

6、逻辑备库同步情况检查

检查进程状态 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'; 检查日志应用进度 alter session set nls_date_format = 'yyyymmdd hh24:mi:ss'; select sysdate,applied_time, applied_scn, mining_time, mining_scn from v$logstdby_progress; 查看不支持事务 set long 1000 set linesize 200 pagesize 999 select event_timestamp, event, status from dba_logstdby_events order by event_timestamp;

7、逻辑备库升级至19c（新环境19c的新逻辑备库开启同步，并确认同步情况）

禁用自动删除foreign archive log，避免升级完之后，日志被删除 EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE'); 关闭日志应用 ALTER DATABASE stop LOGICAL STANDBY APPLY; 关闭逻辑备库安全访问保护 ALTER DATABASE GUARD NONE; 使用常规方式将逻辑备库升级到19C 参考文章《Oracle 11g单库升级至19c单库（autoupgrade方式）》 注意： 1）升级之前，停止11g监听 lsnrctl stop 2)升级之前，需要将tnsname.ora和密码文件复制到19cHOME目录 export PATH=$PATH:/u01/app/oracle/product/19.3.0/db_1/jdk/bin export ORACLE_HOME_11G=/u01/app/oracle/product/11.2.0/db_1 export ORACLE_HOME_19C=/u01/app/oracle/product/19.3.0/db_1 cp $ORACLE_HOME_11G/network/admin/tnsnames.ora $ORACLE_HOME_19C/network/admin/ cp $ORACLE_HOME_11G/dbs/orapworcl $ORACLE_HOME_19C/dbs/orapworcl 3）升级之后，注意环境变量使用19c的环境以及监听都要使用19c ##默认配置19c bash_profile文件 mv /home/oracle/.bash_profile /home/oracle/.bash_profile_11g mv /home/oracle/.bash_profile_19c /home/oracle/.bash_profile ##移除源11g的HOME目录 mv /u01/app/oracle/product/11.2.0/db_1 /u01/app/oracle/product/11.2.0/db_1_bak2 source /home/oracle/.bash_profile env|grep ORACLE cat >>$ORACLE_HOME/network/admin/sqlnet.ora <<EOF SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8 SQLNET.ALLOWED_LOGON_VERSION_SERVER=8 EOF 4）升级完成以后，以19c启动监听 lsnrctl start 新环境19c的新逻辑备库开启复制 ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

8、正式升级开始（停止业务、逻辑主备切换、应用连接切换、业务测试）

0）停止业务！！ 1）主库切换为逻辑备库 主库切换为逻辑备库,由于主备的版本已经不一致，不能采用正常逻辑备库的二阶段切换方式（prepare+convert） ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; 2）新环境备库关闭应用 ALTER DATABASE stop LOGICAL STANDBY APPLY ; 3）新环境通过impdp dblink导入逻辑备库不支持复制的表 创建dblink(dblink创建可以正式升级前完成) create public database link old_orcl connect to system identified by "oracle" using 'orcl'; create directory expdh as '/home/oracle'; 查看不支持的表 select owner,table_name from DBA_LOGSTDBY_UNSUPPORTED_TABLE; 新环境备库导入不支持的表 impdp SYSTEM/oracle directory=expdh NETWORK_LINK=old_orcl TABLES=dbmon.t1_lob TABLE_EXISTS_ACTION=replace 备注： a.如果不支持的表很多，或者表中LOB字段数据量很大，需要具体分析，来加快数据的导入速度！例如LOB字段的表，需要单独并发方式完成导出导入！ b.提前规划好这些表和数据的处理方案！ 4）新环境备库正式切换为主库 新环境备库正式切换为主库，升级完成，应用可以直接访问新环境 SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS -------------------- TO PRIMARY ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 5）应用连接指向新的19c数据库 6）业务测试

9、升级完毕后，旧环境的处理
1）第一种，旧环境直接丢弃，新架构为19c单库方式，不再使用DG主备

19C新主库清空主备的相关参数即可 alter system set LOG_ARCHIVE_DEST_2='' scope=both; alter system set LOG_ARCHIVE_DEST_3='' scope=both; alter system set fal_server='' scope=both; alter system set fal_client='' scope=both; alter system set log_archive_config=NODG_CONFIG scope=both; alter system reset db_file_name_convert scope=spfile; alter system reset log_file_name_convert scope=spfile; alter system reset standby_file_management scope=both; 备注： 1）NODG_CONFIG 的含义是“无Data Guard配置”，它会清除之前通过 DG_CONFIG 选项指定的所有数据库唯一名（DB_UNIQUE_NAME）列表 2）db_file_name_convert、log_file_name_convert两个静态参数，下次重启生效，不影响数据库正常使用！不影响DG架构清理！

2）第二种，旧环境同样升级为19c，作为逻辑备库与主库进行同步，后面也可以重新switchover到旧环境

禁用自动删除foreign archive log，避免升级完之后，日志被删除 关闭日志应用 关闭逻辑备库安全访问保护 使用常规方式将逻辑备库升级到19C 调整逻辑备库的日志路径 上述步骤和前面文章内容一样，不再赘述！！ 第一次开启复制 注意:由于之前的切换没有使用二阶段的方式，所以数据字典没有初始化，第一次开启需要使用NEW PRIMARY db_link_to_b的方式 创建dblink，需要system用户级别的权限 create public database link new_orcl to system identified by "oracle" using 'orcl_st'; 开启同步 ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY new_orcl;

3）第三种，旧环境恢复到物理备库(需要使用还原点)，然后作为物理备库与主库进行同步，通过应用新环境的redo日志升级到19c，后面也可以重新switchover到旧环境

1）将tnsnames.ora、密码文件、参数文件复制到19c的HOME目录下 export ORACLE_HOME_11G=/u01/app/oracle/product/11.2.0/db_1 export ORACLE_HOME_19C=/u01/app/oracle/product/19.3.0/db_1 cp $ORACLE_HOME_11G/dbs/spfileorcl.ora $ORACLE_HOME_19C/dbs/spfileorcl.ora cp $ORACLE_HOME_11G/network/admin/tnsnames.ora $ORACLE_HOME_19C/network/admin/ cp $ORACLE_HOME_11G/dbs/orapworcl $ORACLE_HOME_19C/dbs/orapworcl 2）使用19c版本软件启动数据库到mount startup mount 3）恢复到还原点pre_log_standby flashback database to restore point pre_log_standby; 4）转化为物理备库角色 当前还是逻辑备库角色 select database_role,open_Mode from v$database; DATABASE_ROLE OPEN_MODE ---------------- -------------------- LOGICAL STANDBY MOUNTED 转成物理standby ROLE ALTER DATABASE CONVERT TO PHYSICAL STANDBY; 后台alert日志中会感知到dbid变化，类似如下： CONVERT TO PHYSICAL STANDBY: Complete - Database mounted as physical standby Completed: ALTER DATABASE CONVERT TO PHYSICAL STANDBY 2026-07-09T12:37:59.624970+08:00 rfs (PID:14434): Primary database is in MAXIMUM PERFORMANCE mode 2026-07-09T12:37:59.630534+08:00 rfs (PID:14434): Selected LNO:11 for T-1.S-67 dbid 1764462403 branch 1238153935 2026-07-09T12:37:59.726921+08:00 rfs (PID:14436): Opened log for T-1.S-1 dbid 1764462403 branch 1238153935 rfs (PID:14436): A new recovery destination branch has been registered rfs (PID:14436): New Archival REDO Branch(resetlogs_id): 1238153935 Prior: 1236681669 rfs (PID:14436): Archival Activation ID: 0x69417d2d Current: 0x0 rfs (PID:14436): Effect of primary database OPEN RESETLOGS 5）执行日志应用操作 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; 备注：在日志应用过程中，会自动跳到下个incarnation日志，使得物理主备完成同步！！ 报错处理：如果出现如下错误 Managed Standby Recovery starting Real Time ApplyMRP0: Background Media Recovery waiting for new incarnation during transient logical upgrade procedure 要确认还原点是否在备库convert to 逻辑备库之前，转化逻辑备库会生成一个新的incarnation，并在主库标致KCCDI2HMRP flag，这样在备库media recovery的时候，会主动进行incarnation切换，以应用新的incarnation日志 6）打开物理备库 Alter database recover managed standby database cancel; Alter database open; alter database recover managed standby database using current logfile disconnect from session; 7）测试物理主备同步情况

4）第四种，旧环境直接重构（推倒重来），重新搭建19c物理主备环境
参考文章《Oracle 11g DataGuard主备架构搭建（集群对单库）》

10、COMPATIBLE参数修改（修改COMPATIBLE为19c，注意修改为19c之后无法再进行回退）

alter system set compatible = '19.0.0' scope=spfile;

五、逻辑备库的约束性和局限性

1、逻辑复制不支持的表字段类型

不支持的字段类型: rowid urowid nested tables objects with nested tables identity columns(oracle 12c) 查询不支持的字段类型,对应不支持的字段表，需要再迁移后，单独导入 select distinct owner, table_name,column_name,data_type from dba_logstdby_unsupported;

2、逻辑复制不支持的表

1）表中只包含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)列的表 2）分区包含系统分区以及关联子分区 3）sys、system用户下的表、Oracle内置Schema（如HR、OE的部分表）会被自动跳过 检查不支持的表,对于不支持的字段表，需要再迁移后，单独导入 select owner,table_name from dba_logstdby_unsupported_table; 查看被SQL Apply跳过的Schema SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

3、逻辑复制不支持的PL/SQL包

不支持的PL/SQL包（一般对系统元数据进行修改的包，不支持） DBMS_JAVA DBMS_REGISTRY DBMS_ALERT,DBMS_SPACE_ADMIN DBMS_REFRESH DBMS_AQ,DBMS_RESOURCE_MANAGER

4、逻辑复制没有主键的表
逻辑复制（如 SQL Apply）无法像物理复制那样使用 ROWID 来定位数据行。因此，它依赖主键或非空唯一键来唯一标识一行数据。逻辑复制需要主键或非null唯一键,如果没有主键以及唯一键，则默认用非clob，blob字段的全部列作为主键。

检查没有主键的表包含无长度限定范围的列，如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'; 1）从 DBA_LOGSTDBY_NOT_UNIQUE 中选出所有没有主键和非空唯一索引的表。 2）排除那些本身就不被逻辑备库支持的表（DBA_LOGSTDBY_UNSUPPORTED）。 3）筛选出 BAD_COLUMN 字段值为 'Y' 的表，即包含 LONG 或 BLOB 等无界限数据类型的表 对于应用可以确保数据唯一，但实际没有创建主键的，可以通过创建RELY DISABLE告诉数据库数据是符合唯一要求的，但是实际上约束并没有起作用。比如在创建逻辑standby的时候，oracle建议对那些没有主键或者唯一索引，且检查发现DBA_LOGSTDBY_NOT_UNIQUE.BAD_COLUMN=Y的表创建rely disable的主键。 ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE; DISABLE：这个约束在数据库中并不会被启用，不会执行任何校验，也不会创建对应的索引。因此，它可以被添加在任何表上，即使数据不唯一也不会报错。 RELY：这是一个声明，用来告诉 Oracle 优化器或逻辑复制组件：我（DBA/应用）向你保证，这些列的组合在数据行中是唯一的。逻辑复制会采信这个声明，并使用指定的列来唯一标识行。 注意：RELY DISABLE 约束只是一个声明，它不提供任何约束保护。如果应用插入了重复数据，约束不会阻止，但可能导致逻辑复制过程出错

5、逻辑复制不支持的同步用户

SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA'; 一般都是内部用户，11g版本中有22个，这里不一一列举出来

6、逻辑复制的DDL事务限制

对于create as操作的，逻辑备库应用会转变为create+insert 对于在同一时间发生DDL,DML事务在同一个对象上的，逻辑备库应用会丢弃DML操作 如表执行DDL操作触发了表的DML操作，那这一部分DML操作会被逻辑备库丢掉（跳过） 主库执行的DDL操作，会在逻辑备库重新执行，所以对应DDL里面包含确定的非文本值，如sysdate当前时间函数,会导致主备之间两边的数据不一致；例如:ALTER TABLE user1.t1 ADD (created date default sysdate); 查询DBA_LOGSTDBY_EVENTS视图：这是查看逻辑备库事件（包括被跳过的DDL）的主要视图 开启逻辑备库对"不支持操作"的捕获与记录功能,捕获的信息会写入 DBA_LOGSTDBY_EVENTS 视图中 EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE'); 默认保留最近的100条事件记录，但可以通过DBMS_LOGSTDBY.APPLY_SET过程的MAX_EVENTS_RECORDED参数调整，最大值可达10,000，如下 EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS);

7、逻辑复制包含数据字典的语句限制（11g和19c版本部分数据字典表有变化不一致）

升级之后，19c备库应用主库涉及数据字典的语句可能会操作失败，因为主备库两端的数据字典表已经不一致了。 例如，dba_objects在11g是15列，而在19c已经是26列了，这时候只能通过备库skip问题表