简介这份PDF是Oracle 19c认证考试原题资料的第二部分面向备考OCP认证或需要系统掌握19c多租户架构的数据库管理员。压缩包内共有1个PDF文件大小约350KB内容围绕多租户环境下的核心考点展开。目前已有327人学习。题目覆盖应用PDB创建与同步的正确步骤、PDB在线迁移对归档模式与本地回滚模式的要求、PDB快照的完整与稀疏副本差异以及恢复管理器RMAN备份和自动工作负载仓库AWR快照的触发条件等高频困惑点每道题均给出正确选项和简要解析方便对照官方文档验证。尤其是多租户中应用PDB与应用根同步、迁移前后端条件这类易错细节能帮助读者快速抓住考试重点。虽然内容精简但选择了最典型的场景作为例题适合在考前用来排查知识盲区也能为日常管理容器数据库和可插拔数据库提供参考。1. 把 Oracle 19c 原题当操作手册读这份资料到底在考什么拿到这份 Oracle 19c 原题资料PDF第二部分时我第一反应是又一份题库。但拆完 25 道题后我改变了看法它覆盖的恰好是生产环境 DBA 最常翻车的几个深水区——多租户架构下的 PDB 生命周期管理、Flashback 系列技术的适用边界、AWR/ADDM/ASH 三件套的定位区别、RMAN 备份在 CDB 环境下的行为差异。如果你正在准备 OCP 或 19c 迁移相关的认证或者刚接手一套多租户架构的生产库这份资料能帮你快速校验我知道的和考试认可的之间有多大差距。下面我按知识点重新组织这些题目你会发现它们不是孤立考点而是一条完整的故障处理链路。2. 多租户架构应用容器、PDB 迁移与快照的四个关键决策多租户是 19c 绕不开的核心这份资料里至少有 8 道题在考它。我先说结论这部分题目表面上在考语法实际在考你对 CDB 组件协作关系的理解——应用根、应用种子、应用 PDB 三者如何配合以及不同操作对归档模式、UNDO 模式的硬性要求。2.1 创建 Application PDBs先建应用根还是先建种子原题第一问就给了一个典型场景SALES_APP1 和 SALES_APP2 两个应用 PDB 要访问同一组公共表。给出的 8 个步骤里正确顺序是 1→5→6——直接在应用根安装应用含公共表再创建应用 PDB最后同步。很多新手会选 A1,3,5,7觉得应用种子是必经之路。这里有个认知差应用种子Application Seed的价值在于预置应用模板让后续创建应用 PDB 更快。如果只有两个 PDB 要创建直接走应用根安装 创建 PDB 同步就够了种子的开销反而多余。判断标准是数量批量创建应用 PDB 时种子才有优势。-- 应用根中安装应用含公共表 ALTER PLUGGABLE DATABASE application_root OPEN; ALTER PLUGGABLE DATABASE application_root SET DEFAULT APPLICATION CONTAINER; -- 在应用根中创建应用 CREATE APPLICATION sales_app USING /tmp/sales_app_app.xml; -- 基于应用根创建应用 PDB CREATE PLUGGABLE DATABASE sales_app1 FROM application_root AS APPLICATION CONTAINER PATH_PREFIX /u01/app/oracle/oradata/CDB1/sales_app1; -- 创建后同步应用 PDB 与应用根 ALTER PLUGGABLE DATABASE sales_app1 SYNC APPLICATION;这段脚本的逻辑是先在应用根里把公共对象装好再让应用 PDB 通过同步拿到一致的元数据。CREATE APPLICATION会读取应用描述文件XML 格式里面声明了公共表、视图、包等对象。注意PATH_PREFIX参数——如果不指定Oracle 会把 PDB 的数据文件放在 CDB 默认目录下后续迁移时容易踩路径坑。我一般会显式指定让每个 PDB 的物理文件独立成目录备份和搬迁都清爽。2.2 PDB 迁移归档模式加本地 UNDO缺一不可第二题考的是把 PDB1 从 CDB1 迁到 CDB2要求近零停机。正确选项是 B、C、DCDB1 和 CDB2 都必须开启归档模式且都处于本地 UNDO 模式。这里面有两点容易忽略。第一为什么目标库也要求归档因为迁移过程中源库的 redo 需要持续传送到目标库目标库要能应用这些 redo没有归档日志就断档了。第二为什么必须是本地 UNDO 而不是共享 UNDO因为 19c 的 PDB 迁移Relocate本质上是数据文件传输 redo 应用每个 PDB 的 UNDO 必须独立管理共享 UNDO 模式根本无法满足把 PDB 从 A 库剥离、挂到 B 库这个动作。-- 源库 CDB1 检查配置 SELECT name, open_mode, force_logging FROM v$database; SELECT property_name, property_value FROM database_properties WHERE property_name LOCAL_UNDO_ENABLED; -- 目标库 CDB2 执行迁移在 CDB2 的 CDB$ROOT 中执行 CREATE PLUGGABLE DATABASE pdb1 FROM pdb1dblink_to_cdb1 RELOCATE PARALLEL 4;迁移命令的核心是RELOCATE关键字。执行后 Oracle 会自动做三件事创建数据文件副本、持续应用源库 redo、在源库 PDB 状态变为正在迁移后自动完成切换。PARALLEL 4是并行度参数数据文件较多的场景可以调到 8但我建议先从 4 起步观察源库的 I/O 压力再往上调。迁移过程中如果目标库实例重启整个操作会回滚源库不受影响——这点跟普通的CREATE PDB FROM ...不同值得在变更方案里提前写明回滚路径。2.3 PDB 快照完整副本还是稀疏副本取决于存储第三题考 PDB 快照的底层机制。正确选项是 B 和 CPDB 快照可以是源 PDB 的完整副本也可以是稀疏副本。这道题的陷阱在 A 和 D——快照 PDB 到底依不依赖源 PDB 的存储快照。答案是依赖。Oracle 19c 的快照 PDB 必须基于底层的存储快照能力如 ASM 的 snapshot 特性或存储厂商的快照功能快照本身是存储层的 Copy-On-Write 副本。选项 D 说快照复制 PDB 不依赖现有存储快照这是错的——因为快照 PDB 是使用存储快照创建的副本没有存储快照这个前提就不存在快照 PDB 这个操作。-- 创建快照 PDB基于存储快照 CREATE PLUGGABLE DATABASE sales_snap FROM sales_app1 SNAPSHOT; -- 创建完整副本 PDB CREATE PLUGGABLE DATABASE sales_copy FROM sales_app1;实际使用中我的习惯是测试环境用完整副本CREATE PDB FROM ...因为不依赖存储快照能力随便哪个环境都能跑生产环境的快速回滚场景才用快照 PDB因为稀疏副本几乎不占额外空间回滚时秒级恢复。但前提是你的存储支持快照——用普通文件系统ext4、xfs跑数据文件的库老老实实用完整副本。2.4 DBCA 克隆远程 PDB数据库链接 打开状态两个容易记反的点第六题考 DBCA 克隆远程 PDB 的步骤正确答案是 A 和 D从本地 CDB$ROOT 创建指向远程 CDB$ROOT 的数据库链接克隆完成后打开克隆的 PDB。这里有个反直觉的点数据库链接指向的是远程的 CDB$ROOT不是远程的 PDB。为什么因为 DBCA 克隆 PDB 是通过在本地 CDB$ROOT 执行 CREATE PLUGGABLE DATABASE来实现的这条命令需要访问远程 CDB$ROOT 来读取 PDB 的元数据。很多人在配 dblink 时习惯指向业务 PDB结果报权限不足——因为克隆操作需要的元数据视图如 DBA_PDBS在 CDB$ROOT 里才有完整信息。另一个坑是选项 C 和 D 的区分克隆完成后 PDB 是打开状态不是 mount 状态。这意味着克隆操作会自动执行OPEN如果你需要在克隆后进行额外配置比如重命名、调整存储参数必须先关闭再修改。实际运维中我建议克隆后先别急着开放业务访问先做一次完整的对象比对——源 PDB 和克隆 PDB 的用户、表空间、权限配置可能会因为 dblink 的访问权限差异而不一致。3. 闪回技术家族这不是一个功能是六个工具各管一段题目 11 到 16 集中考闪回但很多人把 Flashback Query、Flashback Drop、Flashback Data Archive 混为一谈。这批题的价值在于帮你划清边界每个闪回技术依赖什么、不依赖什么、适用什么场景。我按依赖资源把它们分成三类。3.1 依赖 UNDO 的三个Flashback Query、Version Query、Transaction Query第 15 题给了六个语句问哪些依赖 UNDO 表空间的数据。正确答案是 1、2、5FLASHBACK TABLE TO TIMESTAMP、SELECT AS OF SCN、VERSIONS BETWEEN。这三者的共同点是读取历史版本的数据行而历史版本就存在 UNDO 表空间里。UNDO 保留期越长能追溯的时间越早。注意第 4 题Flashback Database不依赖 UNDO它依赖闪回日志Flashback Log存储在快速恢复区。第 6 题Flashback Data Archive也不依赖 UNDO它把历史数据归档到独立的表空间由后台进程持续写入。-- 查询某行数据在某个时间点的值依赖 UNDO SELECT * FROM customers AS OF TIMESTAMP TO_TIMESTAMP(2024-03-01 10:00:00, YYYY-MM-DD HH24:MI:SS); -- 查询一行数据在两个 SCN 之间的所有版本依赖 UNDO SELECT * FROM customers VERSIONS BETWEEN SCN 123456 AND 123999; -- 闪回单张表到指定时间点依赖 UNDO FLASHBACK TABLE customers TO TIMESTAMP TO_TIMESTAMP(2024-03-01 10:00:00, YYYY-MM-DD HH24:MI:SS);这三个命令的参数差异是关键AS OF一次性查询某个时间点VERSIONS BETWEEN列出所有中间版本FLASHBACK TABLE直接修改表数据。实际排障时我会先用VERSIONS BETWEEN确认数据是在哪个时间点变的再用FLASHBACK TABLE精准恢复。生产环境执行FLASHBACK TABLE前必须确认两件事目标表上没有未提交事务以及操作期间表不能被访问——否则会报 ORA-08189不能闪回因为表上有未提交的 DML。3.2 不依赖 UNDO 的两个Flashback Drop 和 Flashback Database第 11 题里选项 B 说 FLASHBACK DROP 要求 RECYCLEBIN 参数为 ON这是对的。Flashback Drop 的机制是把被删除的表放进回收站Recyclebin跟 UNDO 完全无关。第 16 题进一步细化用 Flashback Table 恢复一张被删除的表后触发器和约束能否恢复正确答案是 C 和 D——LOB 段和一众约束除了外键约束会被闪回但触发器不会自动恢复。-- 查看回收站中的对象 SELECT object_name, original_name, type, droptime FROM user_recyclebin; -- 从回收站恢复表 FLASHBACK TABLE customers TO BEFORE DROP; -- 确认恢复后的约束状态 SELECT constraint_name, constraint_type, status FROM user_constraints WHERE table_name CUSTOMERS;恢复后我会主动检查两类对象触发器需要手动重建和外键约束不会闪回指向该表的其他表外键需要重新启用。实际踩过坑删表后半小时执行闪回表回来了但应用程序报触发器不存在——因为触发器在闪回操作中不恢复必须在恢复后从备份中重新创建。从那以后我每次做 Flashback Drop 恢复都会习惯性先查ALL_TRIGGERS对比恢复前后差异。3.3 Flashback Data Archive改短保留期的隐藏坑第 13 题的考点很实用Flashback Data Archive 的保留期从 4 年改成 2 年会发生什么正确答案是 A——所有超过 2 年的历史数据会被自动清理。这个自动清理的机制很多人不清楚。FDA 后台进程会周期性扫描归档表空间把超过保留期限制的版本数据删除。注意它删的是 FDA 里存储的历史版本不是当前表数据。这里有个实际运维中容易踩的坑盲目调短保留期可能触发大规模清理操作导致归档表空间突然出现大量 IO。如果你在生产库上执行类似 ALTER FLASHBACK ARCHIVE建议先观察归档大小和历史数据量在低峰期执行。-- 查看当前 FDA 配置 SELECT flashback_archive_name, retention_in_days FROM dba_flashback_archive; -- 修改保留期为 2 年 ALTER FLASHBACK ARCHIVE fdal MODIFY RETENTION 2 YEAR; -- 查看清理进度通过 FDA 后台任务的等待事件 SELECT event, total_waits, time_waited FROM v$system_event WHERE event LIKE %Flashback%;3.4 Flashback Transaction两个前置条件的顺序不能反第 12 题考 Flashback Transaction 的前置条件正确答案是 B 和 D。注意 B 说的是 EXECUTE 权限授予 DBMS_FLASHBACK 包D 说的是为主键启用补充日志——这两个缺一不可而且是先启用补充日志再授予权限。补充日志为什么关键Flashback Transaction 需要回滚指定事务及其依赖事务Oracle 必须能从 redo 日志中解析出行的主键值才能在 [Flashback Version Query] 中定位事务链。没有补充日志redo 里压根不记录足够的主键信息后面的操作全白搭。这块 19c 跟 12c 的要求一致。-- 1. 启用主键补充日志需要在 PDB 中执行 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; -- 2. 授予权限 GRANT EXECUTE ON sys.dbms_flashback TO app_user; -- 3. 使用 Flashback Transaction 回滚指定事务 BEGIN DBMS_FLASHBACK.TRANSACTION_BACKOUT( num_of_names 1, names XA_123456, options DBMS_FLASHBACK.CASCADE); END; /DBMS_FLASHBACK.TRANSACTION_BACKOUT的参数options控制回滚方式CASCADE会连带回滚依赖该事务的后继事务NOCASCADE只回滚指定事务如果存在依赖会报错。我处理生产事故时优先用NOCASCADE先试报错后再评估波及范围避免一下子回滚太多连带事务。4. 性能诊断三件套AWR、ADDM、ASH 的职责边界与配合关系第 5 题、第 18 到 22 题考的都是性能诊断工具但很多 DBA 把它们当成同一个东西的不同入口。这批题的价值在于帮你理清AWR 负责采集ADDM 负责分析ASH 负责定位。三者是上下游关系不是并列关系。4.1 AWR 快照自动生成的前提条件不止 STATISTICS_LEVEL第 5 题的正确答案是 B、D、FAWR 快照总是自动创建STATISTICS_LEVEL 为 TYPICAL 或 ALL 时生成。这里有个隐蔽的配置项如果 STATISTICS_LEVEL 是 BASICAWR 不会生成任何快照ADDM 也跑不了。-- 检查当前 STATISTICS_LEVEL SHOW PARAMETER statistics_level; -- 手动创建 AWR 快照 EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); -- 查看 AWR 快照列表 SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot ORDER BY snap_id DESC FETCH FIRST 5 ROWS ONLY;DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT()不传参数会创建一个标准的 AWR 快照。手动创建快照适合在变更前后各打一个点用来对比变更对性能的影响。注意 AWR 快照无法删除最近的两个快照——这是 Oracle 防止误操作的保护机制。4.2 ADDM自动分析结束后自动运行结论在 AWR 报告之外第 18 题考 ADDM 的运行时机每个 AWR 快照之后自动执行。第 19 题更进一步在两个时间段之间做性能对比应该用 ADDM Compare Period 报告。-- 在指定快照范围内运行 ADDM 分析 EXEC DBMS_ADDM.ANALYZE_INSTANCE(1, 2); -- 生成对比报告 SELECT DBMS_ADDM.COMPARE_PERIOD( LEGACY, -- 第一时段名称 1, -- 起始快照 ID 2, -- 结束快照 ID CURRENT, -- 第二时段名称 3, -- 起始快照 ID 4 -- 结束快照 ID ) AS comparison_report FROM dual;实际使用中我习惯对比变更前后各一个时段比如升级后 15:00-16:00 和升级前 15:00-16:00。这两份报告的核心指标是 Overall Impact总体影响单位是平均活动会话数——这个数字能直接告诉你新版本让系统多消耗了多少资源。4.3 ASH基于采样而不是日志这才是它能定位问题的原因第 22 题里正确选项包括 F 和 G——ADDM Compare Period 可以比较两个非连续时段ASH 报告基于等待事件采样。第 20 题和第 21 题的对比很有意思同一场景问怎么检测性能下降原因一个答案是应急监控从 SGA 直接取数据分析另一个答案也类似但后者补充了 ASH 数据。这两道题考的其实是实例挂起时的诊断路径。数据库 hang 住时AWR 快照可能已经写不了了ADDM 依赖 AWR 快照自然也无法生成报告。此时唯一能救命的是 ASH——它按秒采样当前活动会话数据保留在 SGA 中即使实例快要挂掉你还能从 SGA 里读出最近一段时间的活动会话记录。-- 生成 ASH 报告 SELECT output FROM TABLE(DBMS_WORKLOAD_REPOSITORY.ASH_REPORT_HTML( C0001, -- DB ID 1, -- 起始快照 ID 2, -- 结束快照 ID 1, -- 起始时间秒 3600 -- 结束时间秒 ));ASH 报告的关键得分点是 Top User Events 和 Top SQL。当实例 hang 住先看 Top User Events 有没有 log file sync 或 enq: TX 这类典型等待事件再看 Top SQL 有没有异常的全表扫描或者在执行某些可疑的 PL/SQL 包。定位到具体 SQL 后通过V$ACTIVE_SESSION_HISTORY直接查它的采样记录能看到它在等什么——是等锁、等 I/O 还是等 CPU。4.4 阈值与告警STATELESS 和 STATEFUL 的清理逻辑不一样第 7 题和第 8 题考服务器生成告警。正确答案是有状态告警清除后可在 DBA_ALERT_HISTORY 中查询空间使用类告警会在问题解决后自动清除指标是特定时间段的统计计数。第 8 题里正确场景包括本地管理表空间空闲空间低于阈值每秒登录数超过阈值总登录数超过阈值——三个都跟数值超过设定门槛有关提醒你这些场景的共性必须先定义阈值才有告警。-- 查看当前所有的告警 SELECT reason, metric_name, severity, message_type, creation_time FROM dba_alert_history ORDER BY creation_time DESC FETCH FIRST 10 ROWS ONLY; -- 查看告警阈值设置 SELECT object_name, metric_name, warning_value, critical_value FROM dba_thresholds;DBA_THRESHOLDS视图是关键——它记录了每个指标如表空间使用率的警告值和临界值。注意表空间使用率的告警在 19c 里默认是启用的默认警告值 85%、临界值 97%可以按业务需要调整。第 8 题的选项 A 是干扰项字典管理表空间不支持空间使用率告警——19c 中所有表空间都是本地管理的字典管理表空间在 9i 之后就没新库会用了看到这个选项可以直接排除。5. RMAN 备份CDB 环境下的连接目标是核心考点第 4、9、24、25 题把 RMAN 在 19c 下的行为差异考了个遍。多数人以为 RMAN 备份就是跑个命令但 19c 多租户环境下你在哪里连接 RMAN直接决定了你能干什么。5.1 在 CDB$ROOT 能做什么、在 PDB 能做什么第 4 题的正确答案是 A 和 B——在 CDB$ROOT 连接 RMAN 时可以备份在线 redo 日志也可以备份控制文件。选项 D 和 E 的对比更关键归档日志备份不能在 PDB 里做控制文件备份也不能在 PDB 里做。# 连接到 CDB$ROOT正常方式 rman target / as sysbackup # 备份 CDB包括所有 PDB 的数据文件、控制文件、参数文件 RMAN BACKUP DATABASE PLUS ARCHIVELOG; # 在 CDB$ROOT 中备份指定 PDB 的表空间 RMAN BACKUP TABLESPACE sysaux_sales_app1;注意第 4 题的选项 C在 CDB$ROOT 中连接 RMAN直接BACKUP TABLESPACE某 PDB 的表空间是允许的——但更常见的做法是先ALTER TABLESPACE ... BEGIN BACKUP再文件级备份或者直接用BACKUP DATABASE一把梭。选项 E 说连接 PDB 时不能备份控制文件这是对的RMAN 在 PDB 里只支持数据文件级别的备份控制文件、参数文件、redo 日志这些 CDB 级对象的备份必须连 CDB$ROOT。5.2 压缩备份读阶段瓶颈调 buffer 还是调 buffer cache第 9 题是 RMAN 备份性能调优SBT 通道磁带备份时压缩级别 0 增量备份的读阶段是瓶颈问怎么改善。正确答案是 B 和 C。# 配置 RMAN 磁带备份 I/O 缓冲区 RMAN CONFIGURE CHANNEL DEVICE TYPE SBT PARMS ENV(TAPE_BUFFER_SIZE1M); # 配置数据库 FORCE LOGGING可以关闭 SQL ALTER DATABASE NO FORCE LOGGING; # 增加数据库缓冲区缓存注意这需要重启实例 SQL ALTER SYSTEM SET db_cache_size8G SCOPESPFILE;选项 A 的增加磁带 I/O 缓冲区是常见误选——它解决的是写阶段瓶颈不是读阶段。读阶段的瓶颈在从磁盘读取数据块到内存这个环节跟 tape buffer 没关系。选项 B关闭 FORCE LOGGING的理由是FORCE LOGGING 开启时RMAN 备份读到的块会包含大量 redo 生成的变更块内版本碎片多压缩效率低读压力大。这个参数在生产库上要谨慎——关闭后某些直接路径操作不记日志丢失数据时可能恢复不了。5.3 opatch auto谁必须有 root、谁不需要第 25 题考了 opatch auto 的权限要求。正确答案必须由 root 用户调用会在打补丁期间自动关闭并重启所有 Oracle Grid Infrastructure 和数据库进程。补丁通过 opatchauto 工具应用。实际打补丁时我注意到一个细节题目问哪些是正确的选项里有一个看似合理的干扰项——修补过程必须关闭并重启所有 CDB$ROOT。但实际上 opatchauto 会为每个 PDB 单独处理不需要关 CDB。这个区别能帮你判断 opatchauto 的执行效率和潜在影响面它逐个 PDB 应用补丁每个 PDB 会有短暂不可用但整个 CDB 不需要一次性停机。# 使用 opatchauto 应用补丁需要 root sudo /u01/app/oracle/product/19.3.0/dbhome_1/OPatch/opatchauto apply /tmp/patch_34567891 # 验证补丁应用结果 sudo /u01/app/oracle/product/19.3.0/dbhome_1/OPatch/opatch lsinventoryopatch auto 比传统 opatch 的优势是自动处理集群环境下的补丁顺序和依赖关系。但它的日志在$ORACLE_BASE/cfgtoollogs/opatchauto目录下如果中途失败必须看这个日志定位是哪个 PDB 应用失败单独回滚那个 PDB 的补丁而不是整个环境回滚。5.4 环境变量管的配置哪些路径是环境变量控制的第 24 题正确答案是 A、B、EOFA 路径、Oracle Net 配置文件位置、安装过程中临时磁盘空间都由环境变量决定。特性是环境变量决定路径路径决定配置文件位置配置文件里再写具体监听端口、数据库名等业务配置。实际运维中我遇到过一个问题TNS_ADMIN环境变量没设置导致 SQL*Plus 找不到tnsnames.ora。注意这个变量的行为——不设置时 Oracle Net 默认找$ORACLE_HOME/network/admin但如果你之前改了sqlnet.ora里的命名方式路径就变了。# 查看当前环境变量 echo $ORACLE_HOME echo $TNS_ADMIN echo $ORA_TMPDIR # 手动指定监听配置目录 export TNS_ADMIN/u01/app/oracle/product/19.3.0/dbhome_1/network/adminORA_TMPDIR是安装时的临时目录变量它控制的是 Oracle Universal Installer 在安装过程中解压安装文件的位置。安装完成后这个变量基本没用但它如果指向一个空间不足的目录安装会中途失败——这是一类不太常见但确实存在的安装失败原因。6. 用原题反向校准你的 19c 运维习惯聊到这儿这份原题资料的价值已经不只是刷题备考它更像一面镜子能照出日常运维习惯和 Oracle 官方认证认知之间的偏差。我拆题时对照自己踩过的坑整理了三条值得落地的习惯。第一执行任何 PDB 级操作前强制做双查查目标库的本地 UNDO 状态和归档模式。原题中 PDB 迁移的三个前提条件里归档模式和本地 UNDO 是最容易在实际环境里被忽略的——大多数测试库为了省空间会关掉归档真到迁移时才发现CREATE PLUGGABLE DATABASE ... RELOCATE直接报错 ORA-65081。我建议把这步固化到脚本模板里-- 检查迁移前提条件 SET LINESIZE 200 SELECT property_name, property_value FROM database_properties WHERE property_name LOCAL_UNDO_ENABLED; SELECT log_mode, force_logging, open_mode FROM v$database;第二Flashback Table 恢复后把检查触发器和外键约束当成固定流程。原题 16 题明确告诉你了触发器不恢复外键约束不恢复。但很多人包括我第一次恢复时满脑子都是表回来了忘了这茬直到应用报错才回头补建。我的习惯是恢复后立刻执行一段检查脚本-- 恢复后检查缺失对象 SELECT object_name, object_type, status FROM user_objects WHERE status INVALID UNION ALL SELECT constraint_name, CONSTRAINT, status FROM user_constraints WHERE status DISABLED;第三实例 hang 住时不要重启先尝试从 SGA 掏 ASH 数据。原题 20/21 题的核心就是restart 是最后手段。真到这一步先试试sqlplus -prelim模式连进去通过 ASH 视图查最新采样-- 从 SGA 读取最近 5 分钟的活动会话 SELECT session_id, session_serial#, event, sql_id, wait_time, time_waited FROM v$active_session_history WHERE sample_time SYSDATE - INTERVAL 5 MINUTE ORDER BY sample_time DESC FETCH FIRST 20 ROWS ONLY;如果连sqlplus -prelim都进不去那确实得重启了。但多数情况下先读 ASH 数据能让你拿到关键等待事件为重启后的分析保留第一手证据。这三个习惯都是从原题反推出来的。说句实在话我当年备考 19c 时也刷过不少题库但真正让我在运维中少踩坑的是把答案变成操作习惯的过程。这份原题资料的第二部分恰好覆盖了多租户、闪回、性能诊断、RMAN 四个高价值方向题目质量比很多网上流传的题库要高——至少它考的每个点都能在生产场景中找到对应物。希望这份拆解能帮你从背答案上升到理解为什么选这个下次遇到类似的故障时能直接调用对应的操作路径。希望帮到你。本文还有配套的精品资源点击获取