企业官网建设流程全解析

简介：这份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，最后同步。

很多新手会选 A（1,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、D：CDB1 和 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 pdb1@dblink_to_cdb1 RELOCATE PARALLEL 4;

迁移命令的核心是RELOCATE关键字。执行后 Oracle 会自动做三件事：创建数据文件副本、持续应用源库 redo、在源库 PDB 状态变为"正在迁移"后自动完成切换。PARALLEL 4是并行度参数，数据文件较多的场景可以调到 8，但我建议先从 4 起步，观察源库的 I/O 压力再往上调。迁移过程中如果目标库实例重启，整个操作会回滚，源库不受影响——这点跟普通的CREATE PDB FROM ...不同，值得在变更方案里提前写明回滚路径。

2.3 PDB 快照：完整副本还是稀疏副本，取决于存储

第三题考 PDB 快照的底层机制。正确选项是 B 和 C：PDB 快照可以是源 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、5：FLASHBACK 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、F：AWR 快照总是自动创建，STATISTICS_LEVEL 为 TYPICAL 或 ALL 时生成。这里有个隐蔽的配置项：如果 STATISTICS_LEVEL 是 BASIC，AWR 不会生成任何快照，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_SIZE=1M)'; # 配置数据库 FORCE LOGGING（可以关闭） SQL> ALTER DATABASE NO FORCE LOGGING; # 增加数据库缓冲区缓存（注意这需要重启实例） SQL> ALTER SYSTEM SET db_cache_size=8G SCOPE=SPFILE;

选项 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 lsinventory

opatch auto 比传统 opatch 的优势是自动处理集群环境下的补丁顺序和依赖关系。但它的日志在$ORACLE_BASE/cfgtoollogs/opatchauto目录下，如果中途失败，必须看这个日志定位是哪个 PDB 应用失败，单独回滚那个 PDB 的补丁，而不是整个环境回滚。

5.4 环境变量管的配置：哪些路径是环境变量控制的

第 24 题正确答案是 A、B、E：OFA 路径、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/admin

ORA_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 四个高价值方向，题目质量比很多网上流传的题库要高——至少它考的每个点都能在生产场景中找到对应物。希望这份拆解能帮你从"背答案"上升到"理解为什么选这个"，下次遇到类似的故障时，能直接调用对应的操作路径。希望帮到你。

本文还有配套的精品资源，点击获取