oracle 19c彻底移除transient logical standby，dbms_transient_logical包已从数据字典删除，调用即报ora-00904；官方明确标注该功能自12.2起废弃，19c仅支持标准logical standby配合autoupgrade滚动升级。
Oracle 19c **不支持** Transient Logical Standby 用于滚动升级——这个功能在19c中已被彻底移除，官方文档明确标注为“deprecated since 12.2”且在19c中不可用。所有试图调用 DBMS_TRANSIENT_LOGICAL.STANDBY 或依赖 transient logical 模式的操作都会报 ORA-00904: "DBMS_TRANSIENT_LOGICAL" invalid identifier 或 PLS-00201: identifier 'DBMS_TRANSIENT_LOGICAL' must be declared。
为什么19c里找不到 DBMS_TRANSIENT_LOGICAL
Transient Logical Standby 是 Oracle 11g R2 引入的临时逻辑备库机制，仅用于极短时间内的版本验证（如补丁测试），它不持久化字典、不写归档、不支持 DDL 同步，且要求主备严格同版本。从 12.2 开始，Oracle 就标记该包为 deprecated；到 19c，整个 package 已从数据字典中删除，DBA_REGISTRY 中查不到，ALL_OBJECTS 中也无对应对象。
- 执行
SELECT object_name FROM dba_objects WHERE owner = 'SYS' AND object_name LIKE '%TRANSIENT%';返回空集 -
catqm.sql和catlogstdby.sql脚本中均不再包含 transient 相关代码 - Oracle 19c 升级白皮书（Doc ID 2553158.1）明确指出：“Transient Logical Standby is not supported in Oracle Database 19c”
19c滚动升级唯一可行路径：Logical Standby + autoupgrade
真正能落地的方案是标准 Logical Standby（非 transient），配合 autoupgrade 分阶段升级备库。关键不是“临时”，而是“可验证、可重建、可回退”：
- 主库（11g）必须启用
ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS，仅ADD SUPPLEMENTAL LOG DATA不够，否则 UPDATE/DELETE 会丢失 - 转换前务必运行
EXEC DBMS_LOGSTDBY.BUILD，否则备库无法解析 11g 的 redo 日志为 SQL - 升级备库时，必须先停
SQL Apply（ALTER DATABASE STOP LOGICAL STANDBY APPLY），再执行autoupgrade -mode UPGRADE，否则大概率触发ORA-00054 - 19c 备库启动后，不能直接 resume，必须用
DBMS_LOGSTDBY.INSTANTIATE_TABLE补全 schema 差异，再重新配置LOG_ARCHIVE_DEST_2指向 11g 主库
容易被忽略的兼容性雷区
很多团队卡在“同步看似正常，但切换后应用报错”，根源常是这些未显式暴露的问题：
-
DBA_LOGSTDBY_UNSUPPORTED中查出XMLTYPE字段，但表上有函数索引——逻辑 DG 不复制函数索引定义，切换后索引失效 - 主库用
SECUREFILE LOB，而 11g 默认是BASICFILE，autoupgrade不自动迁移 LOB 存储类型，需手动ALTER TABLE ... MOVE LOB(...) STORE AS SECUREFILE - 19c 默认启用
ENABLE_DDL_LOGGING=TRUE，但逻辑 DG 不同步 DDL 日志事件，导致备库缺少部分审计元数据，DBA_LOGSTDBY_EVENTS里可能堆积大量DDL MISMATCH - 切换前未在主库禁用自动维护任务（
DBMS_AUTO_TASK_ADMIN.DISABLE），19c 备库升级后首次启动时，自动收集统计信息会争抢字典锁，拖慢SQL Apply恢复速度
真正要花时间的不是命令执行，而是对每张表的主键完备性、每个字段的数据类型、每条业务 SQL 在 SQL Apply 下的行为做交叉验证——工具不会替你读业务逻辑。
