简介PDF文档收录了Oracle 19c认证考试的部分原题面向数据库管理员与备考19c认证的读者重点覆盖多租户架构下的应用PDB创建与同步、PDB跨容器迁移、PDB快照、RMAN备份及AWR快照等核心考点。资源为1个PDF文件约350KB内容精炼适合快速刷题与知识点自查。目前已有327人学习下载。题目附正确答案与简要说明可帮助理解应用PDB使用application root、application seed和同步机制的正确流程区分PDB迁移对归档模式与本地UNDO模式的要求并掌握PDB快照完整副本与稀疏副本的适用场景。建议配合官方文档或实验环境对照验证能更高效地巩固Oracle 19c多租户环境的管理技能。1. Oracle 19c 原题资料第二部分别背题用题反推考点如果你手里拿到的是《Oracle 19c 原题资料PDF第二部分》先别急着从头翻答案。我见过不少备考的人把“第二部分”刷了两三遍题库里哪道选 A 哪道选 C 能默写一到真机环境连show con_name都敲不流畅。原因很简单原题是考点索引不是知识本体。Oracle 19c 的题面翻来覆去绕不开几个稳定方向——版本与补丁号、CDB/PDB 结构、DBCA 建库、监听与连接、SQL 语法陷阱、Data Guard 切换背答案只能用一次用题反推考点可以一直用。这篇就按这个逻辑展开每类题对应什么原理、什么命令、什么坑你在自己机器上照着重现一遍比多看二十页 PDF 都管用。适合正在备考 OCP 1z0-082/083、准备 DBA 面试或者从开发转数据库运维的读者。2. 19c 版本谱系、CDB/PDB 结构与 RU 补丁考点2.1 19c 在 Oracle 版本谱系里的特殊位置Oracle 19c 在版本谱系里的位置很容易被原题拿来挖坑。它属于 12c 这一代架构的长期支持版本Long Term Support而不是像 18c 那样的过渡版本。很多原题会问“Oracle 19c 和 12.2 是什么关系”“19c 是不是独立的新一代”正确理解是19c 基于 12.2 代码基线是 12c 系列的功能终版之后 Oracle 直接跳到 21c中间没有 20c 的正式发布。这个背景决定了 19c 的很多行为习惯必须按 12c 的思路来理解比如容器数据库架构、多租户管理、ALTER SYSTEM的作用域都和 11g 有本质差异。原题里出现频率很高的一类是“以下哪个版本支持某特性”其实就是在考版本谱系。19c 作为长期支持版支持范围覆盖了 12.2 引入的绝大多数特性同时把一些老特性标为废弃比如非容器数据库non-CDB架构。19c 里建 non-CDB 已经不是常规路径了题目问到“19c 能否创建非容器数据库”时答案倾向是不能或已不推荐。这个点如果你只背选项换个问法就会懵因为出题人经常把“non-CDB”“CDB”“PDB”“实例”四个概念混在一起考察你是否清楚它们各自的层级关系。2.2 CDB/PDB 结构19c 默认建库方式与原题陷阱19c 的默认建库结果就是一个 CDB 加一到多个 PDB。数据库CDB是物理整体PDB 是逻辑容器应用连接时看到的是某个 PDB而不是整个 CDB。原题里常出现“一个 CDB 里最多能放多少个 PDB”这种数值题官方文档给出的上限是 4096 个实际生产中受内存和文件数限制一般不会开这么多但考题问的是文档值这点要记牢。动手确认你当前到底在哪个容器里是区分“CDB 级别操作”和“PDB 级别操作”的第一步sqlplus / as sysdba show con_name; SELECT name, open_mode, restricted FROM v$pdbs;这条 SQL 的逻辑并不复杂show con_name直接显示当前会话所在的容器名V$PDBS则列出当前 CDB 下面所有 PDB 的名称、打开模式和是否处于 restricted 状态。参数上要注意open_mode常见值是MOUNTED、READ WRITE、READ ONLY原题喜欢考“PDB 打开方式由谁决定”——答案是ALTER PLUGGABLE DATABASE语句而不是ALTER DATABASE。比如把某个 PDB 打开到读写模式ALTER PLUGGABLE DATABASE ORCLPDB1 OPEN READ WRITE;连接应用时也要区分服务名。PDB 的连接串不是连 CDB而是连//localhost:1521/orclpdb1。如果你用 Navicat 或 DBeaver 连接 Oracle 19c 连不上先看的就是连接串里填的是 CDB 的SERVICE_NAME还是 PDB 的SERVICE_NAME这比怀疑驱动坏了靠谱得多。提示原题里“在 PDB 中创建用户”很容易被写成在 CDB 中执行。CDB 中CREATE USER默认创建的是公共用户名字必须以C##或c##开头否则报 ORA-65096。这是 19c 多租户环境最典型的丢分点。2.3 读版本号 19.25.0.0.241015RU 补丁与原题计算最近很多搜索词里出现“oracle 19c 的版本号 19.25.0.0.241015”这正是 19c 在 2024 年 10 月 15 日发布的季度 Release UpdateRU版本号格式。版本号读法可以拆成四段19是主版本25是 Release Update 序号表示这是第 25 个季度补丁版本241015是补丁的发布日期 2024 年 10 月 15 日。原题不一定会直接考这个日期但会考“RU 和 RUR 的区别”“如何查看当前数据库补丁版本”这类跟进问题。查当前数据库版本和补丁情况用两条 SQL 就够SELECT * FROM v$version; SELECT patch_id, action, status, description FROM dba_registry_sqlpatch ORDER BY action_time;V$VERSION显示的是数据库软件的基本版本号比如Oracle Database 19c Enterprise Edition Release 19.0.0.0.0。DBA_REGISTRY_SQLPATCH才是真正记录 RU 补丁的地方每一行对应一个已应用或已回滚的补丁。patch_id对应补丁号status是SUCCESS表示正常应用。原题里如果给一串版本号让你判断“打了哪个季度的补丁”只要记住前两位数字是 RU 序号、最后六位是发布日期的规则基本不会错。章节里这个考点对照表可以帮你快速做原题定位考点对应 SQL/命令说明数据库基本版本SELECT * FROM v$version;显示 19.0.0.0.0 等基础版本已应用的 RU 补丁SELECT * FROM dba_registry_sqlpatch;看 patch_id 和 status当前所在容器SHOW CON_NAME;区分 CDB/PDB 会话查看所有 PDBSELECT name, open_mode FROM v$pdbs;确认哪些 PDB 已打开PDB 打开模式ALTER PLUGGABLE DATABASE ... OPEN;操作对象是 PDB 不是 CDB3. 用 DBCA 和监听命令复现原题里的“安装与安全配置”3.1 单机 CDB/PDB 的静默建库最小命令原题资料里“oracle 19c 单机 cdb dbca 安装过程”这类搜索词热度很高说明很多人对图形界面 DBCA 的下一步下一步不放心总想知道命令行下到底发生了什么。19c 的 DBCA 支持完全静默建库一条命令就能建出一个带一个 PDB 的 CDB最小可运行版本是这样dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName ORCL \ -sid ORCL \ -createAsContainerDatabase true \ -numberOfPDBs 1 \ -pdbName ORCLPDB1 \ -pdbAdminPassword Oracle_123 \ -sysPassword Oracle_123 \ -systemPassword Oracle_123 \ -storageType FS \ -datafileDestination /u01/app/oracle/oradata \ -recoveryAreaDestination /u01/app/oracle/fra \ -totalMemory 2048 \ -characterSet AL32UTF8 \ -sampleSchema true命令里的核心参数按用途分三组第一组指定数据库身份-gdbName是全局数据库名-sid是实例名单实例环境下两者一致即可第二组指定多租户形态-createAsContainerDatabase true表示建 CDB-numberOfPDBs 1表示额外建一个 PDB-pdbName和-pdbAdminPassword分别是 PDB 的管理员账号和密码第三组是物理存储和初始化参数-storageType FS表示文件系统存储-datafileDestination是数据文件目录-totalMemory是给 Oracle 的内存总量按 MB 计。-sampleSchema true会装上示例 Schema练习 SQL 时很好用。补充说明一个参数细节如果-numberOfPDBs不写DBCA 默认只建 CDB 本体不建额外 PDB。另外 19c 中即便不写-createAsContainerDatabase一般也会按 CDB 处理但建议显式写上避免不同版本身上的默认值差异。建完之后验证是否成功用lsnrctl status看服务注册再用sqlplus / as sysdba执行show con_name确认容器环境。3.2 监听服务无法启动的排查链路“oracle 监听服务无法启动”是原题里极高频的运维场景。很多情况下数据库本身没问题就是lsnrctl起不来客户端Navicat、DBeaver全部报连接超时或 ORA-12541。排查顺序固定是一看日志、二看端口、三看 hosts 解析。# 查看当前监听状态 lsnrctl status # 尝试启动监听 lsnrctl start # 查看监听日志通常能直接看到报错原因 tail -f $ORACLE_HOME/network/log/listener.log # 确认端口是否被占用 netstat -an | grep 1521命令逻辑是按层递进的lsnrctl status如果显示TNS-12541: TNS:no listener说明监听进程压根没起来lsnrctl start会打印启动过程中的错误码listener.log里有最原始的失败原因比如bind失败、权限不足netstat则用来确认 1521 端口是否被其他进程抢占。实际工作中最常见的三个原因第一是/etc/hosts里主机名没有映射到本机 IP监听启动时做反向解析失败第二是 1521 端口被别的程序占用第三是$ORACLE_HOME目录权限不对Oracle 用户无法写监听日志。客户端连接不上时还要多查一层驱动和连接串。Navicat 连 Oracle 需要配置 OCI 环境指向 Instant Client 目录DBeaver 连 Oracle 如果报缺驱动需要在“数据库驱动管理器”里手动下载ojdbc8.jar或ojdbc11.jar。这些看起来是客户端问题但原题经常把“监听正常但连不上”和“驱动缺失”“服务名写错”混在一起出题排查思路要分层次网络通不通、监听有没有注册服务、用户名密码对不对、驱动对不对。3.3 等保审计命令与安全配置考点原题里还经常出现“oracle 等保命令”这个方向实际上是在考安全配置的检查方法。等保 2.0 对数据库的要求集中在口令策略、登录失败处理、审计开启情况三个点。19c 默认密码策略是DEFAULTProfile查看口令有效期和失败尝试次数用这条 SQLSELECT profile, resource_name, limit FROM dba_profiles WHERE resource_name IN (PASSWORD_LIFE_TIME, FAILED_LOGIN_ATTEMPTS);返回结果里PASSWORD_LIFE_TIME如果显示UNLIMITED就不符合等保要求需要改成 90 天或更短FAILED_LOGIN_ATTEMPTS一般要求是 5 或 6。审计配置则看AUDIT_TRAIL参数和统一审计策略是否启用SHOW PARAMETER audit_trail; SELECT name, parameter_path, enabled FROM v$audit_policy_enabled;AUDIT_TRAILDB_EXTENDED表示审计记录写入数据库并带 SQL 文本这是等保检查里推荐形态NONE表示审计关闭属于明显不合规。19c 默认启用统一审计Unified Auditing所以V$AUDIT_POLICY_ENABLED能直接查到当前生效的审计策略。原题在这个考点上喜欢让考生区分“传统审计”和“统一审计”19c 里主线是统一审计如果选项里出现AUDIT_TRAILOS作为 19c 推荐配置基本可以排除。4. SQL、存储过程与显示陷阱原题的高频丢分点4.1 MySQL 与 Oracle 的分页差异与最大值写法开发转 DBA 的人最容易在分页语法上栽跟头因为 MySQL 的LIMIT用习惯了到 Oracle 19c 里会直接报 ORA-00933。19c 已经支持标准 SQL 的FETCH FIRST语法分页可以这样写SELECT employee_id, salary FROM employees ORDER BY salary DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;这段逻辑是跳过前 20 行取接下来 10 行等价于传统页面的“第 3 页每页 10 条”。但原题里考得更多的是老式ROWNUM写法因为在 12c 之前没有FETCH FIRST生产库上大量旧 SQL 还是三层嵌套SELECT * FROM ( SELECT e.*, ROWNUM AS rn FROM ( SELECT employee_id, salary FROM employees ORDER BY salary DESC ) e WHERE ROWNUM 30 ) WHERE rn 20;嵌套顺序是解题关键最内层先完成排序第二层给排序结果赋ROWNUM并截取到第 30 行外层再过滤掉前 20 行。为什么不能直接在外层用ROWNUM 20因为ROWNUM是行被取出时依次赋值的大于某个数的条件永远不成立这是原题特别喜欢挖的坑。“oracle 查询某列最大值”这种搜索词也是同样套路直接答SELECT MAX(salary) FROM employees太简单原题一般会跟着问“取最大值所在的那一行怎么做”。两种标准写法SELECT employee_id, salary FROM employees WHERE salary (SELECT MAX(salary) FROM employees);如果要强调效率可以用排序加FETCH FIRST 1 ROW ONLY的方式但要注意如果有并列第一两种写法结果可能不同。原题如果问“哪种写法能返回所有并列最大值”答案是WHERE salary (SELECT MAX(salary) ...)。4.2 CASE WHEN、TRUNC(SYSDATE) 与 DUAL 的边界CASE WHEN的考点集中在执行顺序和NULL处理上19c 里写法如下SELECT employee_id, CASE WHEN salary 10000 THEN high WHEN salary 5000 THEN mid ELSE low END AS salary_level FROM employees;CASE从上往下匹配命中第一个条件就停止所以条件的顺序会影响结果。另一个常见陷阱是WHEN salary IS NULL不会走ELSE除非显式写WHEN salary IS NULL THEN unknown。跟 MySQL 的IFNULL对应Oracle 里是NVL(salary, 0)这也是 MySQL 转 Oracle 容易踩的点。TRUNC(SYSDATE)的考点是“日期被截断到当天零点”SELECT TRUNC(SYSDATE) AS today, SYSDATE AS right_now FROM DUAL; SELECT TO_CHAR(SYSDATE, yyyy-mm-dd hh24:mi:ss) FROM DUAL;TRUNC(SYSDATE)返回的是没有时分秒的日期和带时间的字段直接比较时where create_time trunc(sysdate)只能匹配到当天 00:00:00 这一瞬间正确做法是create_time TRUNC(SYSDATE) AND create_time TRUNC(SYSDATE) 1。DUAL是 Oracle 特有的哑表固定只有一行一列任何不涉及具体表的表达式都可以在它上面跑。搜索里出现“oracle 中 dual 最多存多大”其实被题目误导了DUAL不是用来存数据的不存在容量概念。4.3 按逗号拆分、身份证科学计数法与存储过程“oracle 按逗号拆分列为多行”是 SQL 题里的热门核心是REGEXP_SUBSTR配合CONNECT BYSELECT TRIM(REGEXP_SUBSTR(A,B,C, [^,], 1, LEVEL)) AS item FROM DUAL CONNECT BY LEVEL REGEXP_COUNT(A,B,C, ,) 1;拆分的实现逻辑分三步REGEXP_COUNT算出逗号数量加一得出一共有几段CONNECT BY LEVEL生成从 1 到段数的序列REGEXP_SUBSTR的第四个参数取第LEVEL段。实际使用中把字符串字面量换成列名即可但要注意CONNECT BY会带来额外的递归展开如果原字符串很长、数据量又大性能会明显下降生产环境建议限制一下LEVEL的上限。“oracle 数据库 sql 导出的身份证信息是科学计数法”也是高频搜索问题。本质是身份证号被存成了NUMBER类型导出到 Excel 时超过 15 位有效数字就变成1.23457E17。查询时用TO_CHAR只是表面上修复显示SELECT TO_CHAR(id_card) AS id_card FROM cust;但TO_CHAR对 NUMBER 转出来的结果也可能带科学计数法更稳的做法是查询工具里把该列当作文本处理或者在表设计阶段就把身份证列定义为VARCHAR2(18)。原题如果问“如何正确显示身份证信息”正确答案通常不是某个函数而是“不该用 NUMBER 类型存”。存储过程考点集中在异常处理和事务控制上CREATE OR REPLACE PROCEDURE raise_sal( p_emp_id IN employees.employee_id%TYPE, p_rate IN NUMBER ) IS v_sal employees.salary%TYPE; BEGIN SELECT salary INTO v_sal FROM employees WHERE employee_id p_emp_id FOR UPDATE; UPDATE employees SET salary v_sal * (1 p_rate) WHERE employee_id p_emp_id; COMMIT; EXCEPTION WHEN NO_DATA_FOUND THEN DBMS_OUTPUT.PUT_LINE(员工不存在); WHEN OTHERS THEN ROLLBACK; RAISE; END raise_sal; /过程逻辑是先把当前工资查出来用FOR UPDATE锁住该行避免并发修改再按比例更新并提交。%TYPE声明变量类型与表列一致避免类型不匹配。异常部分必须在所有分支里都处理到NO_DATA_FOUND只由SELECT INTO触发。原题常问“存储过程里能不能不写COMMIT”答案是可以不写由调用方统一控制事务但过程内部如果真的改了数据而不提交调用方不提交就会一直持锁这在多用户环境容易造成行锁等待。5. Data Guard 主备切换与日志断层的实战落点5.1 先分清 switchover 与 failover再看 resolvable gapData Guard 原题里“oracle 主备切换 resolvable gap两套 dg 库”这个搜索组合说明很多人卡在 switchover 前的日志断层检查上。先分清两个概念switchover是计划内切换主备身份互换两边数据一致不丢数据failover是主库故障后的强制接管可能丢数据。原题里只要出现“计划内维护”“无损切换”答案一定是 switchover。resolvable gap直译是“可解决的日志缺口”意思是备库缺了主库的某些日志但缺的部分还可以从主库获取没有产生永久丢失。这个状态在切换前必须处理干净否则直接 switchover 会报 ORA-16467 或类似错误。判断有没有 gap最经典的是在备库上查V$ARCHIVE_GAP-- 备库执行 SELECT * FROM v$archive_gap;如果这个视图有返回行每一行就是一段缺失日志的thread#、low_sequence#和high_sequence#。再结合V$ARCHIVED_LOG确认哪些日志没应用SELECT thread#, sequence#, first_time, applied FROM v$archived_log WHERE applied NO ORDER BY sequence#;applied NO表示日志已经归档到备库但尚未应用也就是常见的“接收了但没应用”状态。这里还要看V$MANAGED_STANDBY里的进程状态MRP0进程如果没有运行备库就不会应用日志这点原题经常考。5.2 解决日志断层并执行 switchover如果V$ARCHIVE_GAP返回了缺日志常见做法是手工拷贝缺失的归档日志到备库并注册ALTER DATABASE REGISTER PHYSICAL LOGFILE /u01/arch/1_1234_1123456789.dbf; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;第一条语句把手工拷贝过来的日志文件注册进备库的控制文件第二条让备库进入实时恢复模式并应用日志。执行完再查一次V$ARCHIVE_GAP返回空结果就说明断层已经补上。也可以用FAL_CLIENT和FAL_SERVER参数让备库自动从主库拉取缺失日志但手工注册更直观排错时更容易看清每一段的去向。gap 清零之后switchover 的标准命令序列是-- 1. 主库发起切换 ALTER DATABASE SWITCHOVER TO PHYSICAL STANDBY; -- 2. 原主库变为备库后启动恢复 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; -- 3. 原备库执行切换变为主库 ALTER DATABASE SWITCHOVER TO PRIMARY;命令执行顺序不能乱。主库执行第一步之前要确保没有活动事务阻塞典型检查是先查询SELECT database_role, open_mode FROM v$database;切换前主库应处于PRIMARYREAD WRITE备库处于PHYSICAL STANDBYMOUNTED或READ ONLY WITH APPLY。切换完成后原备库变成新主库状态应变为PRIMARYREAD WRITE到这里 switchover 才真正结束。下面这个表总结了主要状态检查点检查目标执行位置SQL/命令期望结果数据库角色主/备SELECT database_role FROM v$database;PRIMARY / PHYSICAL STANDBY日志断层备库SELECT * FROM v$archive_gap;无返回行恢复进程备库SELECT process, status FROM v$managed_standby;MRP0 处于 APPLYING_LOG切换前备库状态备库SELECT open_mode FROM v$database;MOUNTED 或 READ ONLY WITH APPLY切换后验证原备库SELECT open_mode FROM v$database;READ WRITE6. 把“第二部分”的量题盘成自己的命令索引原题资料真正值钱的地方不是那几百道题而是你从题目里提炼出来的命令清单。我一般拿到一份 PDF 后会做三件事先按章节给每道题贴标签标签类型就四种——架构、安装、SQL、高可用然后在每道题的空白处写一条“最小复现命令”比如题目问 19c 版本号就写select * from dba_registry_sqlpatch;题目问监听起不来就写tail -f $ORACLE_HOME/network/log/listener.log最后把那些让你犹豫过、选错过、报错过的题单独拉出来按 ORA 错误号重新排序形成一个自己的 ORA 错误清单。“第二部分”如果按篇幅看通常已经进入中后段这时候你的整理方式要跟着变前面部分可能是概念题为主第二部分往往开始出现场景综合题一道题里同时包含版本、CDB/PDB 和 SQL 三个考点单独背任何一章都不够用。把综合题拆成考点组合比反复刷同样的题效率高得多。还有一个适合面试前快刷的口头复盘法每天从 PDF 里抽三道题不看答案自己把考点、命令、报错现象各说一遍能流畅说出“这道题考的是 gap 检查用v$archive_gap看到有行就说明缺日志”才算过。说不出就翻书翻完第二天再抽同一道。不要只盯着 PDF 的后续部分把目录当索引用每章标题对应一个 19c 知识点旁边标注它关联的 SQL 或命令名复习时一眼能定位。顺手翻开你手上那份 PDF把第二部分的题号旁边写上对应的 sqlplus 命令接下来两天按这个清单逐个过一遍原题资料才算真正盘活。本文还有配套的精品资源点击获取