企业官网建设流程全解析

简介：甲骨文认证助理（OCA）分类模拟题第十五套（附答案解析）是一套面向数据库初学者和认证备考者的自测练习题集，重点覆盖数据库升级、数据泵迁移、空间管理、数据库升级助手等核心考点。资源打包为单份Word文档，包含十五道不定项选择题和配套答案，压缩包总大小仅七十九千字节，打开即练、非常轻便。目前已有一百三十七人浏览学习过这套题。题目围绕升级前预检查、手工升级时需复制哪些文件、网络模式数据泵操作、升级后审核机制迁移等易混淆场景展开，每道题均附详细解析，可帮助读者快速检验对甲骨文数据库基础管理与维护概念的掌握程度；同时还能通过答案解析回顾字符集转换、表空间扩展、预升级工具的使用等细节，在刷题中系统补齐知识盲点，适合考前冲刺与查漏补缺。

1. OCA 升级考题里的三个工具：DBUA、Data Pump 与手工升级的分界线

准备 OCA 认证时，最容易被模拟题绕进去的就是升级和迁移。这套分类模拟题把 Oracle 从旧版本走向 12c 的所有岔路口都摆出来了：同样是“把数据库弄到 12c”，DBUA、Data Pump、手工升级三种方式的适用边界完全不一样。一个典型的反直觉结论是：DBUA 只升级数据库，不升级 Oracle 软件；Data Pump 迁移则要求数据库必须处于 OPEN 读写状态，而不是装载模式。很多考生在这一点上栽跟头，因为答案不是“哪个工具更高级”，而是“哪个操作在哪种状态下才合法”。这套题适合两类人：一类是准备 OCA 考试、需要把升级和迁移题一次性理清的考生；另一类是日常要碰 11g 到 12c 升级的运维 DBA，想借题目把 DBUA、preupgrd.sql、Data Pump 网络模式这些操作的边界条件抠清楚。下面按升级准备、Data Pump、多租户、备份恢复、升级后收尾五个层面拆开讲，每个知识点都对应到具体题目和实际运维场景。

2. preupgrd.sql 与升级启动状态：先弄清数据库是谁、在哪、以什么模式打开

2.1 预升级信息工具的运行前提：旧 Home、OPEN 模式、非 UPGRADE

第 9 题问的是 preupgrd.sql 运行前数据库应该如何启动。正确答案是 B：用 STARTUP OPEN 在旧 Oracle Home 上启动数据库。这个答案背后有一个很关键的时间线问题：preupgrd.sql 是升级前的检查工具，此时数据库还完全运行在旧版本环境里，还没有进入升级流程。所以它既不需要 STARTUP UPGRADE，也不可能在新 Home 上启动——新 Home 上的数据库软件此时还没完成安装配置。第 10 题紧接着考输出内容：preupgrd.sql 的产物是 preupgrade_fixups.sql 和 postupgrade_fixups.sql 两个脚本。前者在升级前运行，后者在升级后运行，而不是“给出升级指令”或“交互式询问”。

我一般会建议考生把第 9、10 题连起来记一个操作序列。在旧 Oracle Home 里执行 sqlplus / as sysdba 后，先确保实例是 OPEN 状态，然后运行 @?/rdbms/admin/preupgrd.sql。注意这个 @? 符号会自动展开成当前 ORACLE_HOME，所以这个脚本必须在旧 Home 的 SQL*Plus 会话里执行。脚本执行完会在当前目录（通常是 ORACLE_BASE/cfgtoollogs 或你指定的目录）生成修复脚本和一份升级前检查报告。常见做法是先看报告里列出的 warning 项，逐条评估后再决定 fixup 脚本里哪些要执行、哪些要手工处理。第 13 题把这个问题延伸到“最小化停机时间”：备份、跑 preupgrd.sql、升级后重编译无效对象、收集数据字典统计信息、跑 Post-Upgrade Status 工具，这些都可以在数据库打开的状态下做。唯独 catctl.pl 不行，它只能在 UPGRADE 模式下运行。这个区分特别重要，因为很多人把“并行升级”理解成“在线升级”，其实 catctl.pl 执行期间普通用户是连不进来的。

2.2 UPGRADE 模式的保护机制与手工升级要复制的文件

第 14 题是一个非常接地气的场景：数据库以 UPGRADE 模式打开，普通用户来连接会发生什么？答案是 D：连接会失败，除非有 SYSDBA 权限。UPGRADE 模式本质上是一个受限启动状态，实例只接受 SYSDBA（以及被显式授予相应权限的会话）登录，避免普通事务在数据字典升级过程中插入不一致的数据。这个机制让我想起第一次手工升级 11.2.0.4 到 12.1.0.2 时遇到的现象：我以 UPGRADE 模式启动后，应用连接池疯狂报 ORA-01033，排查了半天才意识到是升级模式把非 SYSDBA 会话挡在门外了。所以这里给新手一个建议：升级窗口要提前通知应用侧，或者在监听器层面把服务临时摘掉，避免连接报错刷屏影响你判断真正的升级问题。

第 11 题考的是手工升级时要从旧 Home 复制什么文件到新 Home。答案是 B 实例参数文件和 C 密码文件。理由很实际：参数文件（spfile 或 pfile）和密码文件的默认位置都跟 ORACLE_HOME 强相关，升级后新 Home 里没有这两个文件，数据库就起不来或者无法用 SYSDBA 远程登录。控制文件不用复制，因为它指向的数据文件才是本体，控制文件在升级过程中会被重建或复用；时区文件也不需要复制，新 Home 自带新的时区文件版本。第 12 题则把 DBUA 和手工升级的使用方式做了区分：DBUA 必须在新的 Oracle Home 下运行，启动和关闭数据库的操作全部由 DBUA 自己接管，不需要你手工 STARTUP UPGRADE。题目里 A、B 选项都是在“手工启动数据库”的前提下讨论的，这在 DBUA 场景下根本不成立——你只要保证数据库当前是关闭的，DBUA 会自动完成剩余动作。

提示：手工升级和 DBUA 升级的文件准备逻辑不同。手工升级要求你手动复制参数文件和密码文件；DBUA 虽然也会读旧库的参数和密码，但它在新 Home 下会自动处理，不需要你手动复制。考试里凡是选项出现“手工复制密码文件”且主体是 DBUA 的，基本都是干扰项。

第 16 题问的是“用 utlrp.sql 重编译无效 PL/SQL 之后再打开数据库”这个操作顺序的影响。正确答案是 C：数据库会打开，用户首次用到还没重编译的 PL/SQL 对象时会触发自动编译。这个知识点在真实运维中特别有存在感——很多 DBA 担心升级后没跑 utlrp.sql 会出事，实际上 Oracle 在运行时会自动重编译，只是首次调用会变慢。因此生产环境的标准做法是：升级完成后尽快跑 utlrp.sql 把绝大多数无效对象处理掉，而不是等到用户访问时才触发编译。第 17 题是 DBUA 升级后的一个经典翻车场景：远程用户连不上数据库。原因是升级后 DBUA 会关闭数据库，如果旧 Home 的监听器被关掉，而新 Home 的监听器没有启动或没有正确配置服务名，远程连接自然失败。曾有同行升级完 12c 后排查了一下午，最后发现只是新 Home 的 listener.ora 里少了数据库服务注册，用 lsnrctl status 一看就露馅了。这套模拟题把这个坑单独拎出来，就是在提醒你：升级不只是跑通 DBUA，还要把监听器的启停顺序纳入检查清单。

3. Data Pump 迁移与网络模式：导出前提、连接方向与字符集转换

3.1 导出操作的数据库状态：OPEN 与读写缺一不可

第 6 题问的是哪种情况下必须执行 Data Pump 导出。答案是 D：数据库必须打开。这个答案表面简单，背后是 Data Pump 的架构逻辑：expdp 导出的不是一个静态文件快照，而是通过主表（master table）记录导出进度，并实时从数据字典和表数据中抽取内容。如果数据库处于 MOUNT 状态，数据字典都不可用，主表无法写入，导出必然失败。只读模式也不行——主表需要有可写的表空间来存放导出元数据。第 2 题把这个逻辑延伸到升级场景：为什么升级不是“零额外空间”？因为数据字典对象在升级后会膨胀，SYSTEM 和 SYSAUX 表空间需要额外空间；同时升级过程对字典表的大量 DML/DDL 会产生重做与归档。第 3 题再从工具能力角度做了补充：Data Pump 支持 10g 以后所有版本的数据迁移（9i 只能走老的 exp/imp），支持字符集转换，也支持 32 位到 64 位平台迁移。

这里有一个我踩过的坑可以分享。有次用 expdp 导一个 12.1 的库，源库字符集是 WE8ISO8859P1，目标库是 AL32UTF8，导出时没有指定 CONTENT 和 EXCLUDE 参数，结果导入后部分中文注释变成了乱码。后来才意识到 Data Pump 的字符集转换覆盖的是数据内容，但如果你在导出前没有用 SELECT * FROM NLS_DATABASE_PARAMETERS 确认两端字符集兼容性，某些边缘字符还是会出问题。所以 OCA 考试里“Data Pump 可以执行字符集转换”这个结论，在实战里还要加一个前提：转换发生在导入端，且建议先用 SCHEMA 级小范围测试验证转换结果。

3.2 网络模式的真实工作方向：dblink 指向源库、impdp 在目标端跑

第 4 题是 Data Pump 网络模式里最容易混淆的一个点。正确答案是 C：在目标数据库中创建一个指向源数据库的数据库链接，并在目标数据库中运行 impdp。很多人会本能地认为“网络模式嘛，当然是在源端 expdp 导出、目标端 impdp 导入”，但实际架构完全相反——网络模式 import 的收数动作发生在目标端，由 impdp 通过 database link 直接从源库读取对象和数据。整个操作只由 impdp 驱动，expdp 根本不参与。源库只需要有能被访问的账号，目标库创建 dblink 指向源库，然后 impdp 的 network_link 参数指向这个 dblink 即可。

这段逻辑想通之后，第 7 题就顺了：完整导入时目标表空间不存在，会发生什么？答案是 B：如果目标数据库启用了 Oracle 托管文件（OMF），会自动创建表空间。这一点在真实迁移里经常被忽略——只想着数据，没想着表空间映射。如果没有启用 OMF，就需要在导入前手工创建同名表空间，否则会报 ORA-00959 之类的错误。第 24 题把 Data Pump 和 dblink 迁移与“先升级再插入 CDB”的路线并列，说明逻辑迁移在迁移到 PDB 场景下也完全可行。

3.3 Data Pump 升级路径的选择依据

第 3 题的 ABC 三个正确选项其实是在描述 Data Pump 的能力边界：版本跨度（10g 之后的任何版本）、字符集转换、跨平台迁移。第 24 题则给出了两条绕过“低版本不能直接插 CDB”限制的方法：要么把 11g 就地升级到 12.1.0.1 或更新版本再插入；要么用 Data Pump 或 dblink 做逻辑迁移到新 PDB，原库保持原版本不动。这两种路线的取舍在实战中很清晰：就地升级加插入适合数据量大、停机窗口充足的环境；Data Pump 逻辑迁移适合需要顺便做 Schema 整理、压缩或跨平台搬家的场景。

提示：Data Pump 迁移不要求数据库处于 RESTRICTED 模式，但生产环境导出时建议用 PARALLEL 参数控制并发度，并在导出前用 DBMS_STATS.GATHER_SCHEMA_STATS 收集一次统计信息，避免导出的一致性子查询在高峰期影响 OLTP 性能。

4. 多租户 PDB 操作：插入、服务、权限与视图范围的边界

4.1 非 CDB 插入 CDB：字符集、版本和 DBMS_PDB.DESCRIBE

第 20 题考的是非 CDB 插入 CDB 的必要条件，答案是 A：CDB 和非 CDB 必须使用相同数据库字符集。很多考生会选 D（必须 12c 或 11g 终级版本），因为听起来合理——但正确答案里根本没有这个限制，因为 11g 数据库在插入前必须先升级到 12c，这是一个前置动作而不是“必要条件”。第 24 题把这个问题做了延伸：低于 12.1 的库怎么进 CDB？要么就地升级到 12.1.0.1+ 再插入，要么走 Data Pump/dblink 逻辑迁移。B 选项是一个隐藏痛点：DBMS_PDB.DESCRIBE 包只存在于 12c 环境中，低版本数据库无法直接调用它生成 XML 文件。也就是说，11g 数据库不能“原地描述然后插入 CDB”，必须先升级成 12c 非 CDB。

第 23 题考拔掉 PDB 的条件，答案是 C 和 D：PDB 必须关闭，且必须用 DBMS_PDB.DESCRIBE 生成 XML 元数据文件。这道题在实战中的含义是：拔 PDB 不等于删除数据文件，只要你不显式指定 INCLUDING DATAFILES，文件都还在原位置，属于“可后悔”操作。与此配套的还有数据字典层面两个常用查询，我贴在下面：

-- 查看 PDB 的 open_mode 和整体状态 SELECT name, open_mode, restricted, open_time FROM v$pdbs ORDER BY con_id; -- 用 DBMS_PDB 生成 PDB 描述文件，注意 PDB 必须处于 CLOSED 状态 ALTER PLUGGABLE DATABASE hrpdb CLOSE; BEGIN DBMS_PDB.DESCRIBE( pdb_name => 'HRPDB', pdb_descr_file => '/u01/backup/hrpdb.xml' ); END; /

上面第一段 SQL 用来确认当前 CDB 里所有 PDB 的状态，第二段是拔库的标准动作。注意 pdb_descr_file 参数是绝对路径，且目录必须存在；如果 PDB 还在 OPEN 状态，DBMS_PDB.DESCRIBE 会报错，这是 OCA 题和面试题里都爱埋伏笔的地方。另外，CDB 里如果已经启用了 TDE 或其他加密配置，生成的 XML 文件里还会包含加密信息，换环境插入时要一并迁移对应的 wallet 文件——这个点题里没提，但真实运维一定跑不掉。

4.2 公共用户、本地用户和 CONTAINER=ALL 的权限语义

第 30 题是一道典型的“用户创建后能不能连 PDB”的题。答案是 B：C##JW 存在于根容器和所有 PDB 中，但只拥有连接根容器的权限。这里有两个机制叠加：第一，在根容器创建的带 C## 前缀的用户是公共用户，自动存在于每个容器；第二，GRANT 操作默认作用域是当前容器，CONNECT 角色只授予了根容器里的 C##JW。因此他进不了任何 PDB，除非 DBA 在对应容器里重新授予 CONNECT。第 31 题考的就是这个授予动作的语法边界：想让公共用户在所有 PDB 都有 SELECT ANY TABLE，必须写 CONTAINER=ALL。这个子句对于很多从非 CDB 环境转过来的 DBA 来说是个新维度，因为 12c 之前根本没有“容器级授权”的概念。

第 32 题对应的是本地角色与公共角色的分配矩阵。正确答案是 C（不正确的是：公共角色只能授予公共用户）。实际上公共角色可以授予本地用户，本地角色也可以授予公共用户。这个矩阵我整理成了一张表，考试前可以拿来默写：

第 28、29 题考的是视图可见性与表空间归属。连接到 PDB 时，DBA_DATA_FILES 只显示当前 PDB 的数据文件；想看 CDB 全量必须连根容器查 CDB_DATA_FILES。V$DATAFILE 也遵循同样规则。第 29 题的答案是 C：唯独撤消表空间是根容器管理、所有 PDB 共用的，所以连接 PDB 的会话能用根容器的 UNDO。这个知识点有一个直接实战价值：如果根容器 UNDO 表空间满了，所有 PDB 的 DML 都会受到影响，而你在 PDB 里查 DBA_DATA_FILES 还看不到 UNDO 文件——排障时很容易绕远路。

4.3 PDB 服务、打开状态和初始化参数的判定方法

第 25 题考 PDB 服务的创建途径：标准做法是创建/克隆/插入 PDB 时自动生成服务；如果还要额外服务，可以用 srvctl（RAC 或 Oracle Restart 环境）或 DBMS_SERVICE 包。第 26 题是一道综合题：CDB01 执行 shutdown immediate、startup mount、alter database open 之后，各容器的状态是什么。正确答案是 E：根容器 OPEN，种子数据库 READ ONLY，定义了触发器或由 Oracle Restart 管理的 PDB 自动打开。这里要注意区分：PDB 默认不会跟着 CDB 一起打开，除非设置了 OPEN 触发器或由 srvctl 注册管理。第 27 题考的是 PDB 可修改参数的判定列：V$PARAMETER.ISPDB_MODIFIABLE 为 TRUE 才可以在 PDB 级修改。这道题实战意义很强——比如 optimizer_adaptive_features 这类参数在 PDB 级别是否可改，直接影响你在多租户环境里怎么调优。

-- 在 PDB 会话中列出所有可修改的初始化参数及其当前值 SELECT name, value, ispdb_modifiable, isdefault FROM v$parameter WHERE ispdb_modifiable = 'TRUE' AND isdefault = 'FALSE' ORDER BY name;

这个查询在执行 PDB 级别的调优时很实用：先确认参数可修改，再用 ALTER SYSTEM SET ... CONTAINER=CURRENT 设置。需要注意的是，如果参数在 CDB 级别已经被改成非默认值，PDB 级会继承它，查询结果里 isdefault 会是 FALSE，这是正常现象。

第 21 题是关于 PDB 会话建立的路径。正确答案是 B 和 D：用户通过监听器上的服务名登录 PDB，登录后可以从一个 PDB 通过 dblink 连到同一 CDB 里另一个 PDB。A 选项的错误在于 IPC 连接只能用于本地根容器，这跟数据库服务的注册机制有关——监听器服务名指向的是 PDB 的 service_name，不是 SID。第 22 题考 CREATE DATABASE 创建 CDB 时的最小语法，答案是 A：ENABLE PLUGGABLE DATABASE 是唯一必需的子句。B（CHARACTER SET）、C（SEED FILE_NAME_CONVERT）都不是必须的，其中 SEED FILE_NAME_CONVERT 只有在不使用 OMF 时才需要显式指定。第 35 题接着考参数继承：PDB 创建时自动继承 CDB 级参数，拔出再插回（同一个或另一个 CDB），PDB 级自定义参数会保留在 PDB 的 spfile 里。这个特性是 12.2 以后才完善的，如果考试里遇到 12.1 的环境，要额外小心这个选项的成立条件。

5. 备份恢复与资源计划避坑：控制文件丢失的恢复顺序与 INVALID 导入条件

5.1 RMAN 恢复控制文件的顺序：非装载模式是唯一入口

第 34 题是一道操作排序题，也是多租户环境下 RMAN 最典型的灾难恢复场景：控制文件全部丢失，只有自动备份。正确顺序是 D：⑧ 非装载模式启动 CDB 实例 → ⑥ 从自动备份还原控制文件 → ⑦ 恢复数据库 → ④ 用 RESETLOGS 打开数据库 → ⑤ 打开所有可插入容器。核心逻辑只有一个：控制文件还原只能在 MOUNT 状态下做，而多租户环境的 MOUNT 状态只属于根容器。很多人排序错在第一步就试图连接 PDB——PDB 在没有控制文件的前提下根本不会出现在实例里，你连目标 PDB 会直接报 ORA-01507 之类错误。第 33 题对 RMAN 在多租户环境的能力边界做了补充，正确选项是 B、D、E：表空间级备份可以跨越不同 PDB（只要连接到根容器），SYSBACKUP 可以按 PDB 本地授予给本地用户，也可以授予公共用户。A 是干扰项——备份控制文件不需要一定连根容器；C 也是干扰项——单独备份 PDB 不要求必须连接目标 PDB，连根容器一样可以从 CDB 层面备份。

这套题目背后有一个实战建议：多租户环境的备份策略应当分成两级。第一级由连接到根容器的 RMAN 会话统一备份整个 CDB（含所有 PDB 的数据文件和控制文件）；第二级在需要单独恢复某个 PDB 时，用 BACKUP PLUGGABLE DATABASE 做局部备份。这样既能控制备份脚本数量，又能保证单个 PDB 的恢复粒度。

5.2 资源计划导入的六种失效条件

第 37 题是整套题里最细的一道：非 CDB 里的资源计划，什么情况下导入 CDB 后会失效。正确答案是 A：原资源计划有 12 个使用者组。原因是 CDB 对从非 CDB 导入的资源计划施加了三条硬性约束——使用者组不能超过 8 个、只能有第一级资源分配、不能包含子计划。这三条我在实际项目中踩过一次：迁移一个老系统时，源库资源计划里设了 11 个使用者组，导入后 PDB 里的资源计划直接变成 INVALID，业务侧的并行查询全部退化成单线程。当时查了半天的 V$RSRC_PLAN 和 DBA_RSRC_PLAN_DIRECTIVES，最后才发现是数量超限。

下面这张表把这道题涉及的几个约束条件整理出来：

修复这个问题的标准操作是把原资源计划压缩到 8 个使用者组以内，删除子计划，然后重新导入。如果你遇到的是生产环境且不能马上改，临时缓解手段是删除资源计划，让 PDB 退回到无资源计划的默认竞争状态——这总比所有 SQL 都排队要好。

5.3 多租户下的避坑检查单

从上面两组题延伸出来，我每次在多租户环境做升级或迁移，都会强制过一遍下面这几项。第一，控制文件丢失后不要尝试先 OPEN PDB，任何 PDB 存在的前提都是 CDB 的 MOUNT 正常；第二，插拔 PDB 前确认字符集一致，否则 DBMS_PDB.DESCRIBE 生成的 XML 在插入时会因为字符集不匹配直接报错，这属于“症状在插入、病根在字符集”的问题；第三，导入资源计划前先统计使用者组数量，超过 8 个就提前压缩，别等 INVALID 后才后悔；第四，公共用户授权必须显式写 CONTAINER=ALL，否则你以为是全库授权，实际只在当前容器生效。最后一条是血泪教训：有次给 C##MONITOR 用户授予 SELECT ANY TABLE，漏写了 CONTAINER=ALL，结果所有 PDB 的监控报表都报权限不足，排查到半夜才发现是授权作用域的问题。

第 35 题还有一个衍生场景值得注意：如果把同一 PDB 拔出来插到另一个 CDB，自定义参数会保留，但这个 PDB 原本依赖的 CDB 级参数（如 db_files、sga_target）如果有差异，插入后需要重新核对。这个场景的处理方式是插入前先对比两个 CDB 的 spfile 中关键参数，尤其关注 memory_target、db_block_size、compatible 这几个不能在线修改的参数。

第 36 题考的是 PDB 资源分配的默认行为，答案是 B 和 C：CDB 默认没有资源分配计划，所有 PDB 平等竞争；如果启用了 min/max 分配，一个 PDB 即使其他 PDB 都不忙，也不能超过自己的 max 限制。这个默认逻辑在实战中经常被误解——很多人以为 PDB 之间天然有资源隔离，其实不配资源计划就是抢。

6. 升级后的收尾技巧：审计迁移、无效对象重编译与监听器检查

升级完成不等于收工，真正决定升级质量的是打开数据库之后那几个小时。第 8 题问 12c 升级后哪个组件不再可用，答案是 C：Oracle Warehouse Builder 升级后不再集成在数据库中，但可以外部安装继续使用；Data Vault、Oracle Label Security 都保留，标准审计默认启用。第 15 题是审计相关的核心考点：升级后统一审核（Unified Auditing）不会自动启用，旧的细粒度审核继续运行；一旦启用统一审核，原有的标准审核和细粒度审核立即停止。新旧审计体系不能并行，所以切换前要把旧审计记录导出留底。我在升级 12c 时踩过这个坑：启用统一审核后，应用审计日志突然少了近一半，起初怀疑丢数据，后来才明白是旧审核策略被停用了。

第 16 题讲的是无效 PL/SQL 对象：utlrp.sql 没跑完就把数据库打开，用户首次调用未编译对象时会自动重编译，但会拖慢第一次调用。实战中的标准做法是在升级脚本里安排 utlrp.sql 尽早执行，并配合一个定时查询 V$COMPILE 来观察重编译进度。第 17 题是升级后最常见的连不上远程问题：DBUA 升级成功但远程用户无法连接，要按“监听器是否启动、是否注册到新 Home、tnsnames 是否指向新服务名、密码文件是否复制”的顺序排查——后两个文件的复制问题不会让连接直接报错，但会让你在后续登录时报 ORA-01017，干扰判断方向。

从那以后，我每次升级收尾都强制自己走一遍固定的验证清单：先查 V$SESSION 确认没有非 SYSDBA 会话混入；再启动统一审核并把旧审计记录归档；然后跑一遍 utlrp.sql 并连续观察 V$COMPILE；最后用远程客户端执行一次完整业务登录验证。这套流程覆盖了题里埋的审计、编译、监听三类坑。做 DBA 的都知道，升级失败的表象永远千奇百怪，但根因大多是这几个老问题。希望帮到你，考场上别踩我踩过的坑。

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