简介这份Oracle 19c原题资料PDF第二部分聚焦多租户架构下的高级管理特性面向备考Oracle认证的DBA以及需要系统掌握19c PDB管理的数据库维护人员。内容基于考试原题提炼出多个核心知识点创建并同步应用PDB的正确步骤包括应用根中安装应用、创建应用种子、以及将应用PDB与应用根同步PDB在CDB间迁移时要求CDB处于归档模式和本地回滚模式以保障接近零停机的迁移过程PDB快照可以被创建为完整副本或稀疏副本且依赖于源PDB的现有存储快照。此外还涉及RMAN备份CDB时的控制文件与联机重做日志备份规则以及AWR快照的自动生成条件。每个问题均附带正确答案与解析帮助读者理解原理并灵活应对实际环境中的类似场景。资源为单个PDF文件包体仅350KB轻量便携。已有327人学习下载适合作为考前冲刺或日常运维查阅的浓缩参考。1. 从 19c 多租户考点看 DBA 的日常边界Oracle 19c 的考试原题里最容易被低估的不是那些需要背的语法而是多租户架构下「应用容器」与「普通 PDB」的管理差异。第二部分的题目反复围绕 Application PDB、PDB 迁移、快照、Flashback 和 AWR 展开这些恰好是生产环境里最容易踩坑的地方。比如应用 PDB 的同步顺序很多人会习惯性地先建 PDB 再同步到根但题目给出的正确顺序是先在应用根安装应用再创建种子和应用 PDB最后同步——这个顺序反了共享表就访问不到。这份资料适合两类人一类是准备 OCP 19c 认证的考生另一类是已经在管多套 CDB、但没系统梳理过应用容器行为的 DBA。下面几章我会按题目覆盖的技术点展开把命令和参数摆出来对照着生产场景说清楚边界。2. 多租户应用容器Application PDB 的创建与同步2.1 为什么 Application PDB 需要独立于普通 PDB普通 PDB 之间如果要共享表通常只能通过数据库链接DB Link或物化视图维护成本高。Oracle 19c 引入 Application Container 后应用根Application Root里可以保存应用的公共表应用 PDB 通过同步机制获得这些表的元数据或数据。这样多个应用 PDB 共用一套应用表升级应用时只需在应用根上执行一次安装脚本再同步到所有应用 PDB不用逐库重复执行。题目中的 SALES_APP 场景核心不是怎么建表而是怎么让两个应用 PDB 访问同一个应用根下的公共表。很多人会误以为把公共表放在 CDB$ROOT 里就算共享但应用公共表必须放在应用根里CDB$ROOT 里放的是系统级公共对象。识别这一点的关键是看题中「install the SALES_APP application, including the common tables, in the application root」这一步。2.2 创建应用容器与应用根应用容器本质上是一个特殊的 PDB创建时指定AS APPLICATION CONTAINER。常见做法是用CREATE PLUGGABLE DATABASE创建应用根然后创建应用种子和应用 PDB。下面是创建应用容器并安装应用的最小步骤-- 在 CDB$ROOT 中创建应用容器Application Root CREATE PLUGGABLE DATABASE sales_app_root AS APPLICATION CONTAINER ADMIN USER app_admin IDENTIFIED BY App#2024 FILE_NAME_CONVERT (/u01/app/oracle/oradata/CDB1/pdbseed, /u01/app/oracle/oradata/CDB1/sales_app_root); ALTER PLUGGABLE DATABASE sales_app_root OPEN; ALTER SESSION SET CONTAINER sales_app_root; -- 创建应用种子 CREATE PLUGGABLE DATABASE sales_app_seed AS APPLICATION SEED FILE_NAME_CONVERT (/u01/app/oracle/oradata/CDB1/pdbseed, /u01/app/oracle/oradata/CDB1/sales_app_seed); ALTER PLUGGABLE DATABASE sales_app_seed OPEN; -- 创建应用 PDB CREATE PLUGGABLE DATABASE sales_app1 FROM sales_app_seed; ALTER PLUGGABLE DATABASE sales_app1 OPEN;代码里AS APPLICATION CONTAINER是应用容器与普通 PDB 的分水岭AS APPLICATION SEED生成的应用种子专门用于批量创建应用 PDB普通 PDB 种子pdbseed不能直接当作应用种子使用。FILE_NAME_CONVERT指定了目标路径转换规则生产环境里如果使用了 OMF也可以省略但显式写出来更便于排错。2.3 应用种子与应用 PDB 的同步机制同步是应用容器最关键的机制。应用根里安装应用后应用 PDB 并不会自动拿到公共表必须显式执行同步。题目给出的正确顺序是先在应用根安装应用步骤 1再创建应用种子步骤 3然后创建应用 PDB步骤 5最后同步应用 PDB 到应用根步骤 6。注意步骤 7 是同步到应用种子步骤 8 是同步种子到根这些在最小步骤里可以省略。同步命令如下ALTER SESSION SET CONTAINER sales_app_root; -- 安装应用生成版本号和同步标记 BEGIN DBMS_APPLICATION_INSTALL.INSTALL( application_name SALES_APP, application_version 1.0, install_action create_tables); END; / -- 同步所有应用 PDB 到应用根 ALTER PLUGGABLE DATABASE APPLICATION SALES_APP SYNC;DBMS_APPLICATION_INSTALL.INSTALL是应用容器安装应用的入口install_action里可以写建表、建视图等 DDL。ALTER PLUGGABLE DATABASE APPLICATION ... SYNC会把应用根上的应用变更传播到所有已挂载的应用 PDB。常见误区是直接在应用 PDB 里执行建表语句这会把表变成应用 PDB 的私有对象与公共表的定位相悖。判断标准很简单公共对象的 DDL 必须从应用根发起。操作执行位置作用安装应用公共表应用根定义应用元数据和公共对象创建应用种子应用根提供应用 PDB 的初始模板创建应用 PDB应用根基于种子生成业务库同步应用 PDB应用根把应用变更推向已存在的应用 PDB从生产实践看应用容器适合那些多个 PDB 需要共享同一套业务表的场景比如 SaaS 平台的多租户数据分区。但要注意同步会锁住应用根上的相关对象所以应用发布窗口要避开业务高峰。3. PDB 迁移与快照零停机与存储快照的取舍3.1 迁移 PDB 的日志模式与 UNDO 要求将 PDB 从一个 CDB 迁移到另一个 CDB实现近零停机需要满足三个条件源库 CDB1 和目标库 CDB2 都必须处于归档模式并且都使用本地 UNDO 模式。这个结论来自原题第 2 题的正确答案 BCD很多人只记得「归档模式」忽略了本地 UNDO 这个硬性要求。原因在于 PDB 迁移Relocate是通过数据文件拷贝加增量 Redo 应用完成的如果使用共享 UNDO 模式PDB 的 undo 段与 CDB 根绑定无法独立分离而本地 UNDO 模式下每个 PDB 有自己的 undo 表空间迁移时才能保证一致性。检查当前数据库的 UNDO 模式SELECT name, value FROM v$parameter WHERE name LIKE %undo_tablespace%; SELECT con_id, tablespace_name FROM cdb_tablespaces WHERE tablespace_name LIKE UNDO%;如果发现是共享 UNDO需要先转换为本地 UNDO。转换步骤在 19c 上相对简单但要注意 PDB 必须处于关闭状态ALTER PLUGGABLE DATABASE pdb1 CLOSE; ALTER PLUGGABLE DATABASE pdb1 LOCAL UNDO; ALTER PLUGGABLE DATABASE pdb1 OPEN;3.2 使用 DBCA 或 SQL 迁移 PDB从 19c 开始DBCA 支持远程克隆 PDB实际上底层是在源库 CDB$ROOT 和目标库 CDB$ROOT 之间建立数据库链接然后执行克隆。原题第 6 题的正确答案 AD 指出DBCA 会创建从本地 CDB$ROOT 到远程 CDB$ROOT 的数据库链接并在克隆完成后打开克隆的 PDB。手动的 SQL 方式同样基于数据库链接核心命令是CREATE PLUGGABLE DATABASE pdb1_relocated FROM pdb1cdb2_link RELOCATE FILE_NAME_CONVERT (/u01/oradata/cdb2/pdb1, /u01/oradata/cdb1/pdb1);RELOCATE是 PDB 迁移的关键字它与普通克隆的区别是迁移会把源 PDB 标记为不可用源库的数据字典中该 PDB 会被移除但复制过程允许源 PDB 继续提供服务直到最后一步切换。常见失败原因有这几类目标库未开启归档 (ORA-19809 之类)数据库链接指向了远端 PDB 而不是 CDB$ROOT源 PDB 未打开传输过程中日志切换太快导致归档缺失。排错时先看告警日志和v$session里的Datapump会话如果卡在等待日志切换说明归档频率过高可以考虑把迁移窗口内的 redo log 增大。3.3 PDB 快照的完整副本与稀疏副本原题第 3 题问的是 19c 中关于创建 PDB 快照的说法正确答案是 BCPDB 快照可以是源 PDB 的完整副本也可以是稀疏副本。注意这里有个容易混淆的点题目中的正确选项没有提到「依赖存储快照」虽然实际上 19c 的快照 PDB 往往依赖底层存储快照但在考试原题的语境下快照 PDB 本身可以看作独立副本而稀疏副本则依赖源 PDB 的存储快照。生产环境里我一般用稀疏快照做测试因为它只保存变化的数据块创建速度快。命令如下CREATE PLUGGABLE DATABASE pdb1_snap FROM pdb1 SNAPSHOT COPY;SNAPSHOT COPY默认会使用存储层的快照能力比如 ASM 或企业存储的快照如果存储不支持Oracle 会回退到完整拷贝。完整快照则去掉SNAPSHOT COPY即可CREATE PLUGGABLE DATABASE pdb1_fullcopy FROM pdb1;判断何时用哪种主要看空间和恢复粒度。完整副本适合需要独立长期运行的测试环境稀疏副本适合临时验证一个变更或补丁因为底层共享源 PDB 的数据文件源 PDB 一旦删除快照也会失效。4. Flashback 家族的边界数据归档与撤销段依赖4.1 哪些 Flashback 操作依赖于 UNDO原题第 15 题给出了六种 Flashback 技术问哪些依赖撤销段UNDO里的数据。正确答案是 1、2、5对应 FLASHBACK TABLE ... TO TIMESTAMP、SELECT ... AS OF SCN、SELECT ... VERSIONS BETWEEN SCN。而 FLASHBACK TABLE ... TO BEFORE DROP 依赖的是回收站RecyclebinFLASHBACK DATABASE 依赖的是闪回日志ALTER TABLE ... FLASHBACK ARCHIVE 依赖的是闪回数据归档Flashback Data Archive三者都不依赖 UNDO。这个分类在实际排错中很重要。比如用户误删了数据如果想知道某个时刻的行版本必须用 VERSIONS 查询这时 UNDO 的保留时长直接决定能回看多久。如果 UNDO 表空间被事务冲掉就会报 snapshot too old。4.2 Flashback Data Archive 的创建与修改Flashback Data ArchiveFDA是表级的历史数据追踪方案它使用独立表空间保存所有历史版本不依赖 UNDO。原题第 13 题和第 14 题考察了 FDA 的修改和特性。第 13 题正确答案是 A修改保留期会立即清除超过新保留期的历史数据。第 14 题正确答案是 CDE可以在无默认 FDA 的情况下显式指定表启用 FDA 后不能直接删除必须先禁用或解除关联FDA 避免了 flashback query 的 snapshot too old 错误。创建 FDA 的完整流程-- 创建独立的表空间避免与业务表空间混用 CREATE TABLESPACE fda_ts DATAFILE /u01/app/oracle/oradata/ORCL/fda01.dbf SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 50G; -- 创建闪回数据归档 CREATE FLASHBACK ARCHIVE fda_default TABLESPACE fda_ts QUOTA 10G RETENTION 2 YEAR; -- 为表启用 FDA ALTER TABLE sales.customers FLASHBACK ARCHIVE fda_default;RETENTION 2 YEAR表示保存两年。如果后续需求变化用MODIFY RETENTION调整ALTER FLASHBACK ARCHIVE fda_default MODIFY RETENTION 1 YEAR;这里要特别提醒修改保留期是立即生效并清理旧数据的不是「以后慢慢清」。原题第 13 题的正确答案就是 A很多考生会误选 B报错不允许缩短其实 Oracle 允许缩短保留期并立即 purge 超限数据。所以线上改保留期前先确认旧数据是否还需要。4.3 闪回表与依赖对象用FLASHBACK TABLE ... TO BEFORE DROP恢复误删的表时依赖对象的处理有固定规则。原题第 16 题正确答案是 CDLOB 段和表上的约束包括主键、唯一约束等非外键约束会被闪回而触发器、物化视图和引用完整性约束不会被闪回。也就是说恢复表后索引和约束大多还在但触发器需要重新启用物化视图需要刷新重建。实际执行闪回表时要注意表必须开启行移动ALTER TABLE customers ENABLE ROW MOVEMENT; FLASHBACK TABLE customers TO TIMESTAMP TO_TIMESTAMP(2025-01-15 10:00:00,YYYY-MM-DD HH24:MI:SS); ALTER TABLE customers DISABLE ROW MOVEMENT;ENABLE ROW MOVEMENT是闪回表的前提因为闪回需要修改行的物理位置。生产环境执行前建议先记录当前 SCN再闪回到目标 SCN避免时间戳模糊导致闪回到预期之外的状态。5. 诊断与备份AWR、ADDM 与 RMAN 的配合5.1 AWR 快照的生成条件原题第 5 题问 AWR 快照哪些是真的正确答案是 BDF总是自动创建默认每小时一次、在 STATISTICS LEVEL 为 TYPICAL 时生成、在 STATISTICS LEVEL 为 ALL 时生成。注意 BASIC 级别会关闭 AWR所以选项 E 错误。AWR 快照默认保留 8 天但可以配置保留更久甚至永久选项 A 说「can be retained forever」也是真的但正确答案是 BDF说明题目认为「一直保留」不是 AWR 快照的固有特性而是可以通过配置实现。考试时以正确答案为准。实际工作中手动创建快照更常见EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();生成 AWR 报告SELECT * FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(1, 100, 120));5.2 ADDM 与 Compare Period原题第 18 题正确答案是 BCADDM 在每个 AWR 快照后自动运行DBA 也可以手动运行。第 19 题用 ADDM Compare Period 报告来对比两个时期的性能差异。第 21 题和第 20 题都提到 24x7 数据库挂起时应该使用实时 ADDMReal-Time ADDM直接从 SGA 读取数据而不是依赖 AWR 快照因为可能来不及生成快照。手动运行 ADDM 分析最近两次快照DECLARE l_task_name VARCHAR2(30); BEGIN l_task_name : DBMS_ADVISOR.CREATE_TASK( advisor_name ADDM, task_name mytask, task_desc Run ADDM manually); DBMS_ADVISOR.SET_TASK_PARAMETER(l_task_name, INSTANCE, 1); DBMS_ADVISOR.SET_TASK_PARAMETER(l_task_name, START_SNAPSHOT, 100); DBMS_ADVISOR.SET_TASK_PARAMETER(l_task_name, END_SNAPSHOT, 102); DBMS_ADVISOR.EXECUTE_TASK(l_task_name); END; /如果是数据库已经 hang 住连接不进 SQL*Plus常见做法是先用sqlplus -prelim / as sysdba进入初步模式然后查询v$diag_info和v$session里的阻塞链。原题直接给的是「使用紧急监控从 SGA 读取数据」对应的是 ASH 和 hang analysis 视图。5.3 RMAN 备份 PDB 与性能瓶颈原题第 4 题正确选项是 AB可以在 CDB$ROOT 下创建控制文件备份但归档日志备份不能直接从 PDB 连接创建在 PDB 里不能创建控制文件备份。第 9 题说 SBT 备份时读阶段是瓶颈且 FORCE LOGGING 已启用两个改进手段是禁用 FORCE LOGGING因为它会在备份期间生成大量日志影响读性能和增大数据库缓冲区缓存减少物理读。实际备份 PDB 时最保险的 RMAN 命令是rman target / BACKUP DATABASE PLUS ARCHIVELOG;如果要只备份某个 PDBBACKUP PLUGGABLE DATABASE sales_app1;RMAN 操作必须在 CDB$ROOT 下执行连接到 PDB 只能执行逻辑导出或部分操作。诊断备份读瓶颈时可以用SELECT * FROM v$backup_async_io WHERE type_nameSBT ORDER BY small_read_reqs DESC;关注small_read_reqs和large_read_reqs的比例如果大量小型读说明 RMAN 的复用度不够可以调整backup filesperset或增加通道。6. 考前与实战用原题定位 19c 实施盲区6.1 从原题到生产环境的转换验证原题里有一个值得注意的考点CDB 中创建 PDB 时USER_TABLESPACE子句的用途第 10 题正确答案 BD。它可以在从非 CDB 迁移到 PDB 时指定包含哪些用户表空间也可以在拔插 PDB 时排除所有用户表空间只保留 SYSTEM、SYSAUX、TEMP。这个功能在生产中的典型场景是把旧库迁移到 19c 多租户时只迁移业务表空间而不迁移临时表空间。实际迁移命令示例CREATE PLUGGABLE DATABASE newpdb FROM non_cdb USER_TABLESPACES (EXAMPLE, USERS) FILE_NAME_CONVERT (/data/noncdb, /data/oradata/NEWPDB);6.2 常用参数与视图速查下面列出原题涉及的核心查询视图和参数备查主题视图/参数用途应用容器DBA_APPLICATIONS, DBA_PDBS查看应用版本、PDB 状态本地 UNDOV$PARAMETER (undo_tablespace)确认每个 PDB 独立 undoFlashback ArchiveDBA_FLASHBACK_ARCHIVE, DBA_FLASHBACK_ARCHIVE_TABLES查看归档保留期和关联表AWR 阈值DBA_THRESHOLDS, DBA_ALERT_HISTORY查看告警阈值与历史RMAN 备份V$BACKUP_DEVICE, V$RMAN_OUTPUT查看通道与备份进度6.3 常见误判与应对原题第 7、8、23 题围绕阈值和服务器生成告警。要点是所有告警都与 STATISTICS_LEVEL 有关设为 BASIC 时不生成告警有状态告警在问题解决后自动清除无状态告警可以手动清除DBA_ALERT_HISTORY可以查询清除后的历史告警。生产环境最常见的误判是认为告警一定由 SMON 进程发出实际上空间类告警由 MMON 进程定期检查。排查时先看V$ALERT_TYPES判断告警类型再对应到DBA_THRESHOLDS里设置的阈值。如果原题第 25 题提到的opatch auto出现失败常见原因是root脚本未执行或OPatch目录权限不对。检查补丁是否已应用可以用opatch lsinventory -detail最后说一个很实际的经验考试原题里的说法和生产行为常有细微出入比如「AWR 快照可以永久保留」这种说法在考试里被判为错但生产上其实可以设置retention FORVER。刷题时不要背答案而是把每个选项变成一条验证命令在测试环境里跑一遍这样 19c 的坑才能变成你的经验。本文还有配套的精品资源点击获取