简介这套Oracle 19c原题资料PDF第一部分定位为Oracle Database 19c认证科目1Z0-082的备考题库适合已掌握SQL基础、正在冲刺认证的数据库从业者与学生。内容以英文原题带答案解析的方式呈现开篇即覆盖DROP TABLE操作带来的实际影响包括被删除表是否进入回收站、约束与索引的联动删除以及序列、同义词和视图不受影响的边界判断同时梳理本地命名、目录命名和EasyConnect三类连接解析方式各自的前置条件与故障切换能力并对多行子查询的GROUP BY、HAVING用法及WHERE条件组合等易混淆点给出逐一辨析。每道题均标明正确选项并附简短解释便于考生对照错因、强化记忆。包体为单个PDF文件大小仅674KB轻量便携适合手机或电脑随时刷题。目前已有594人学习下载属于高频使用的考试复习材料。通过研读这些原题可帮助读者熟悉1Z0-082的真实出题风格与选项陷阱深入理解Oracle 19c在数据字典、连接解析、子查询与条件逻辑方面的细节从而提升答题准确率为正式考试做好针对性准备。1. 这份 Oracle 19c 原题资料不只是刷题是把考点还原成实操先说结论这份 PDF 与其说是 1Z0-082 的题库不如说是一份「以题带点」的 Oracle 19c 知识点索引。每一道题背后都是一个可以在 SQL*Plus 里亲手验证的行为——DROP TABLE 到底动了哪些对象、目录命名要不要配 TNS_ADMIN、多行子查询能不能带 GROUP BY这些不是死记硬背的答案而是可以在自己 19c 环境里敲一遍就能看到结果的东西。适合两类人一类是备考 OCP 1Z0-082 的考生需要把零散知识点串成体系另一类是日常维护 Oracle 19c 的 DBA想补一补 SQL 语义边界和 Net Services 配置细节。资料本身是 PDF 格式题目按 Exam A 顺序排列答案解析紧跟其后这份「原题 解析」的结构决定了它更适合做第二轮复习——第一轮看书建体系第二轮拿它查漏。2. 围绕 DROP TABLE 的隐式依赖从回收站到索引约束的连锁反应2.1 DROP TABLE 到底动了谁序列、同义词、视图、索引、约束的各自命运题面问的是DROP TABLE hr.employees之后哪些说法为真标准答案是 DEF——索引和约束随表删除表进回收站。但更值得琢磨的是另外三个选项为什么是错的这背后是 Oracle 对依赖对象的分类处理逻辑。A 选项说序列会被删错。序列是独立对象不归属于某个表。你在 employees 表上建过EMP_SEQDROP TABLE 之后这个序列还在只是它 nextval 产生的值不再被任何列消费而已。B 选项说同义词被删也错。公共同义词和私有同义词都是独立对象DROP TABLE 只删除表本身同义词会变成「失效状态」——你查询它时会报 ORA-00980但同义词这个对象还在数据字典里。C 选项说视图被删同样错。视图是依赖表的独立对象表被 drop 后视图还在只是变成 invalid需要ALTER VIEW ... COMPILE或者等下次访问时自动重新编译编译失败就报错。而 E 和 F 为什么对因为约束和索引是表的附属段——主键约束、唯一约束、检查约束、外键约束都定义在表结构上表没了它们自然没了索引无论是普通 B-tree 还是函数索引物理上都存储在表所在的表空间里DROP TABLE 时 Oracle 会连同索引段一起清理。D 选项涉及回收站机制从 10g 开始默认开启DROP TABLE不是物理删除而是把表和它的相关段改名放进回收站你可以用FLASHBACK TABLE hr.employees TO BEFORE DROP恢复。实操验证方式很简单-- 先建一张测试表带上主键、索引、序列和同义词 CREATE TABLE hr.employees_test AS SELECT * FROM hr.employees WHERE 10; ALTER TABLE hr.employees_test ADD CONSTRAINT pk_emp_test PRIMARY KEY (employee_id); CREATE INDEX idx_emp_test_name ON hr.employees_test(last_name); CREATE SEQUENCE seq_emp_test START WITH 1; CREATE SYNONYM syn_emp_test FOR hr.employees_test; -- 执行 DROP 后检查依赖对象 DROP TABLE hr.employees_test; SELECT object_name, object_type, status FROM user_objects WHERE object_name LIKE %EMP_TEST%; SELECT object_name, object_type FROM user_objects WHERE object_name IN (SEQ_EMP_TEST,SYN_EMP_TEST);第一条查询能看到回收站里的表名被改成了BIN$...格式索引和约束对应的记录也跟着进了回收站或消失第二条查询能看到序列和同义词还在同义词状态变成 INVALID。这就是为什么生产环境 DROP TABLE 之前一定要先查依赖——UTL层、报表层、ETL 任务都可能挂着同义词和视图表一删整条链路全断。2.2 回收站带来的运维习惯DROP 前查依赖DROP 后留后悔药回收站是「后悔药」但也是磁盘黑洞。一张 500GB 的表被 DROP 后段还在回收站里占着空间表空间剩余空间不会变多。这时候如果业务要扩表你会惊讶地发现空间不够——不是没空间是空间被回收站占着。我的习惯是两件事并行。第一DROP 之前先查依赖-- 查引用该表的外键约束 SELECT owner, constraint_name, table_name, status FROM all_constraints WHERE r_constraint_name IN ( SELECT constraint_name FROM all_constraints WHERE table_name EMPLOYEES AND owner HR ); -- 查依赖该表的视图和同义词 SELECT owner, name, type, status FROM all_dependencies WHERE referenced_name EMPLOYEES AND referenced_owner HR;第二DROP 之后立刻确认回收站占用该清就清-- 查看回收站空间占用 SELECT owner, tablespace_name, SUM(bytes)/1024/1024 AS mb FROM dba_recyclebin GROUP BY owner, tablespace_name; -- 只清特定表的回收站条目 PURGE TABLE hr.employees_test;这里有个细节PURGE TABLE后面跟的是原始表名不是回收站里的BIN$名。如果你同时 drop 了同名的表两次回收站里会有两个BIN$条目PURGE TABLE会把两个都清掉。想精确清一个就得用PURGE TABLE BIN$xxxxx$0这种带引号的完整回收站名。2.3 关于 DROP 的一个反直觉结论CASCADE CONSTRAINTS 不是万能的题目没提CASCADE CONSTRAINTS但这是 DROP TABLE 最容易用错的选项。DROP TABLE ... CASCADE CONSTRAINTS只会级联删除外键约束不会删视图、同义词、序列更不会删引用该表的物化视图。很多人以为加了这个参数就能把依赖对象一锅端实际上它只处理外键关系——比如 employees 表被 departments 表的外键引用不加 CASCADE 直接 DROP 会报 ORA-02449加了才能删掉。但视图和同义词依旧变成 invalid 状态留在库里。所以生产环境删表标准动作应该是先查外键和依赖再决定是CASCADE CONSTRAINTS还是手动 drop 外键最后 DROP 完检查 invalid 对象数量有没有异常增长SELECT object_type, COUNT(*) FROM user_objects WHERE status INVALID GROUP BY object_type;3. Oracle Net 命名方法TNS 解析的三种姿势与配置边界3.1 从 tnsnames.ora 到 Easy Connect三种命名方法的适用边界1Z0-082 对网络命名方法的考查集中在 Local Naming、Directory Naming、Easy Connect 三者的配置条件和能力边界。题目答案选 CEF但每个选项都值得展开。Local Naming 是绝大多数单实例环境用的方式——客户端通过tnsnames.ora文件里的网络服务名去解析目标数据库的地址、端口和服务名。它要求客户端机器上设置了TNS_ADMIN环境变量指向 tnsnames.ora 所在目录否则默认去$ORACLE_HOME/network/admin找。这就是 E 选项要表达的意思。但要注意TNS_ADMIN不是必须设置的如果你把文件放在默认位置就不用管这个变量。所以「本地命名需要设置 TNS_ADMIN」这个说法本身就不严谨准确说是「如果需要自定义文件位置才要设置」。Directory Naming 走的是 LDAP 目录服务器客户端通过目录服务解析连接信息。B 选项说它需要设置TNS_ADMIN这是错的——它需要配置的是LDAP_REGISTRATION_ENABLED和目录服务器地址跟 TNS_ADMIN 没关系。C 选项说 Directory Naming 支持 Connect-Time Failover这是对的。LDAP 里可以配置多个地址列表客户端在连接时按顺序尝试一个地址失败就换下一个。Easy Connect 是最轻量的方式不需要任何配置文件。客户端直接用host:port/service_name字符串就能连——比如sqlplus hr/hr192.168.1.100:1521/orclpdb。D 选项说 Easy Connect 支持 TCP/IP 和 SSL对的。19c 里 Easy Connect 的语法比早期版本丰富多了支持net_service_name里带多个地址做 failover也支持:dedicated/:shared指定服务器类型。3.2 本地方案怎么选单实例、RAC、DG 的不同推荐实际配置时选哪种命名方法取决于你的架构。单实例开发库我无脑推荐 Easy Connect——零配置文件一条连接串走天下。RAC 环境建议 Local Naming 配合地址列表做负载均衡和 failover。DG 环境同样是 Local Naming 更合适因为主备切换后连接串不用改。Directory Naming 只在公司有统一 LDAP 基础设施、DBA 团队规模较大时才值得引入否则维护 LDAP 的成本远大于收益。配置 Local Naming 的标准动作# 1. 确认 TNS_ADMIN 指向的目录 echo $TNS_ADMIN # 如果为空默认使用 $ORACLE_HOME/network/admin # 2. 编辑 tnsnames.ora添加一个服务名条目 ORCL19C (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 192.168.1.100)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME orclpdb) ) )参数说明SERVER DEDICATED表示每次连接分配专用服务器进程适合开发测试生产环境并发高时用SHARED走共享服务器进程。SERVICE_NAME是数据库的服务名不是实例名——RAC 多个实例共用一个服务名客户端连的是服务名由监听把请求路由到实例。验证配置用tnsping这是最直接的连通性测试工具tnsping ORCL19C看到OK (10 msec)说明解析和网络都通。如果报ORA-12154: TNS:could not resolve the connect identifier specified九成是 tnsnames.ora 路径不对或文件里有语法错误。3.3 TNS_ADMIN 的隐性坑多版本 Oracle 客户端共存时最容易翻车一台机器上装了 11g 客户端和 19c 客户端TNS_ADMIN只能指向一个目录。如果指向 11g 的 admin 目录19c 的工具比如 SQL*Plus 19c也会用这个目录下的 tnsnames.ora——但 11g 和 19c 的 tnsnames.ora 语法不完全兼容19c 特有的参数比如CONNECT_TIMEOUT在 11g 客户端里会被忽略或直接报错。我一般这样规避统一用 19c 的 admin 目录作为 TNS_ADMIN 指向tnsnames.ora 里只写 11g 兼容的语法或者干脆给不同版本的客户端分别建 admin 目录启动脚本里按工具版本切换 TNS_ADMIN。一个更省事的方案是全部走 Easy Connect彻底绕开 tnsnames.ora 的路径问题——反正 19c 的 Easy Connect 已经支持 failover 和负载均衡了小规模环境完全够用。4. SQL 语义与函数行为把题目答案变成可验证的查询实验4.1 多行子查询与 WHERE 条件优先级AND 和 OR 的运算顺序陷阱题目里关于多行子查询的正确答案是 ACE——可以包含 GROUP BY、HAVING可能返回多个值。但 B 选项说「不能返回多个列」其实是错的多行子查询完全可以返回多列只要外层用元组比较或者 EXISTS 配合。D 选项说子查询里不能再嵌套子查询这也是错的子查询嵌套深度没有硬性限制。WHERE 条件的题目更典型它考察的是 AND 优先级高于 OR 这个基本规则。A 选项和 B 选项的差异就在于括号改变了逻辑分组-- A 等价于: borrowed_date SYSDATE AND (transaction_type RM AND member_id IN (A101,A102)) -- B 等价于: (borrowed_date SYSDATE AND transaction_type RM) OR member_id IN (A101,A102)B 和 E 的结果一致因为它们本质都是「日期等于今天且类型为 RM」或「会员 ID 在给定列表里」这两个条件的并集。这类题在开发中最常见的翻车场景是你想表达「今天借阅的 RM 类型图书」结果忘了加括号SQL 变成了「今天借阅的 RM 类型图书或者所有会员 A101/A102 的借阅记录」——数据量一大查询结果多出几千行。验证这类优先级问题不需要真实业务表用 DUAL 就能做实验-- 模拟三个条件观察不同括号组合下 WHERE 的筛选结果 WITH t AS ( SELECT 1 AS borrowed_date, RM AS transaction_type, A101 AS member_id FROM dual UNION ALL SELECT 1, BK, A102 FROM dual UNION ALL SELECT 0, RM, A999 FROM dual ) SELECT * FROM t WHERE borrowed_date 1 AND (transaction_type RM OR member_id IN (A101,A102));这段 SQL 返回第一行日期对、类型对、会员对和第三行日期对、类型不对但会员 ID 在列表里。把括号去掉再跑一次结果完全不一样——第三行也会被筛掉因为 AND 先执行transaction_type RM为假整体第一个条件就为假。这就是为什么代码评审时我要求所有多条件 WHERE 一律显式加括号不靠默认优先级。4.2 单行函数的三个易错点TRUNC、FLOOR、CEIL 的行为差异题目里 MOD 和 CEIL 的说法是对的TRUNC 只能用于 NUMBER 是错的FLOOR 的定义也写反了。这几个函数值得逐个验证-- MOD: 返回除法余数 SELECT MOD(17, 5) FROM dual; -- 2注意余数符号跟随被除数 -- TRUNC: 支持 NUMBER 和 DATE 两种类型 SELECT TRUNC(99.99) FROM dual; -- 99截断而不是四舍五入 SELECT TRUNC(99.99, 1) FROM dual; -- 99.9保留一位小数 SELECT TRUNC(SYSDATE) FROM dual; -- 今天的 00:00:00 -- FLOOR: 返回小于等于参数的最大整数 SELECT FLOOR(99.99) FROM dual; -- 99 SELECT FLOOR(-99.99) FROM dual; -- -100注意负数要向负无穷方向取整 -- CEIL: 返回大于等于参数的最小整数 SELECT CEIL(99.01) FROM dual; -- 100 SELECT CEIL(-99.99) FROM dual; -- -99TRUNC 最常见的误用是拿它做四舍五入——它只截断不四舍五入。要四舍五入用ROUND(99.99, 1)得到 100.0。FLOOR 和 CEIL 对负数的行为也常被忽视FLOOR(-99.99) 是 -100 而不是 -99CEIL(-99.99) 是 -99。这在财务计算里如果没注意符号结果会差一整个整数。CONCAT 函数的坑在于它只能接两个参数。CONCAT(a,b,c)会直接报 ORA-00909你得嵌套CONCAT(CONCAT(a,b),c)。而||运算符没有这个限制可以无限拼接。所以题目里说 CONCAT 可以组合任意数量值是错的。4.3 BETWEEN、LIKE、IN 的等价写法% 通配符和边界值有一道题问WHERE city %AN%和WHERE city IN (%AN%)能不能查出正确结果——都不能。和IN做的是精确匹配%是通配符只有LIKE才识别通配符。这个考点在开发环境里翻车率极高尤其是从别的语言转过来的人习惯了字符串模糊匹配用contains或到 Oracle 里就忘了 LIKE。正确写法是-- 模糊匹配城市名包含 AN 的记录 WHERE city LIKE %AN%如果你想匹配以 A 或 B 开头的姓氏可以用LIKE A% OR LIKE B%也可以用正则REGEXP_LIKE(last_name, ^[AB])。但要注意BETWEEN的边界是闭区间——BETWEEN UPPER(A) AND UPPER(B%)这种写法是错的BETWEEN 右边不能接通配符。4.4 INTERVAL 数据类型YEAR TO MONTH 和 DAY TO SECOND 的边界限制关于 INTERVAL 的题目标准答案是 DE。INTERVAL YEAR TO MONTH 支持年区间但没有「月区间只能限制在单个年内」这回事——INTERVAL 13 MONTH完全合法它表示 1 年零 1 个月。F 选项说 YEAR 字段必须为正数也是错的INTERVAL -1 YEAR合法表示往前一年。实操里 INTERVAL 最常见的用法是计算时间差-- 计算两个日期间隔结果类型是 INTERVAL DAY TO SECOND SELECT TO_TIMESTAMP(2025-01-15 10:30:00,YYYY-MM-DD HH24:MI:SS) - TO_TIMESTAMP(2025-01-14 08:00:00,YYYY-MM-DD HH24:MI:SS) AS diff_interval FROM dual; -- 把 INTERVAL 转为可读的天数和小时 SELECT EXTRACT(DAY FROM (SYSTIMESTAMP - TIMESTAMP 2025-01-14 08:00:00)) AS days_diff FROM dual;EXTRACT可以从 INTERVAL 里抽出年、月、日、时、分、秒。注意INTERVAL DAY TO SECOND的默认精度是 2 位秒毫秒会被截断——想要毫秒得显式声明INTERVAL DAY(3) TO SECOND(6)。5. 避坑与排查1Z0-082 原题验证中的常见翻车记录5.1 替代变量用 和 混搭会话二次提示现象脚本里同时用了emp_id和dept_id跑第二次时emp_id还在提示输入dept_id却不提示了。原因每次执行都提示只在该会话内提示一次之后的值被缓存。这是 19c SQL*Plus 对替代变量的标准行为。解决如果希望某个变量在脚本里复用且只提示一次统一用每次都要提示的临时值用。想强制重新提示变量执行UNDEFINE dept_id清除缓存或者在 SQL*Plus 里执行SET DEFINE ON重新开启。5.2 ALTER DATABASE MOVE DATAFILE 时表还能查DML 却报锁等待现象执行ALTER DATABASE MOVE DATAFILE /u01/sales01.dbf TO /u02/sales02.dbf过程中SELECT 能跑UPDATE 卡住直到命令完成。原因MOVE DATAFILE 在 12c 是 ONLINE 操作允许查询但移动过程中会对相关段短暂加锁DML 要等文件移动完毕才能继续。题目答案 AB 说的就是这个。如果文件很大这段时间可能很长DML 堆积。解决生产环境移动大文件前先看文件大小和表空间使用率估算移动时间窗口期短就接受锁等待窗口期长就考虑用DBMS_FILE_TRANSFER先复制到目标位置再切换。另外注意MOVE DATAFILE不能跨平台/u01和/u02在同一个操作系统的不同挂载点没问题跨操作系统类型要用RMAN CONVERT。5.3 SQL*Plus 里跑题目 SQL报错 ORA-00933 或 ORA-00923现象从 PDF 里复制题目 SQL 到 SQL*Plus经常报ORA-00933: SQL command not properly ended或ORA-00923: FROM keyword not found where expected。原因PDF 里可能有不可见字符、全角逗号、弯引号。题目里的引号、逗号、括号经常被 PDF 排版转成 Unicode 字符SQL*Plus 不认。解决复制后先粘到记事本或 VS Code 里做一次「全角转半角」再粘到 SQL*Plus。更稳的方式是自己手敲关键部分别直接复制。写脚本时用cat或vi确认文件编码是 UTF-8 无 BOM。5.4 SYSDATE 和字符串比较隐式转换导致全表扫描现象WHERE join_date 10-02-2018能出结果但执行计划显示全表扫描线上数据量大时慢得离谱。原因NLS_DATE_FORMAT 是 DD-MON-YY字符串 10-02-2018 被隐式转成日期时用的是DD-MON-YY格式10-02-2018 月份部分 02 不是 MON 格式Oracle 可能报错或按错误语义解析。这题答案选 C 就是因为它是唯一需要显式 TO_DATE 的选项。解决日期比较永远用TO_DATE(2018-10-02,YYYY-MM-DD)显式转换别依赖 NLS 隐式转换。顺便检查一下NLS_DATE_FORMAT和NLS_TIMESTAMP_FORMAT是否一致不一致会在不同会话出现诡异结果。5.5 序列缓存值在实例关闭后丢失业务出现断号现象数据库正常关闭再启动序列 nextval 跳了一大截主键出现空洞。原因序列CACHE默认 20实例关闭时缓存里未使用的值直接丢弃下次启动从磁盘记录的下一个值开始。这不是 bug是设计行为。题目答案说「序列未分配的缓存值在实例关闭时会丢失」就是这个。解决核心业务表如果要求主键严格连续用NOCACHE但性能下降能接受断号就保持默认 CACHE。两种方案没有绝对对错关键是业务方要提前确认。5.6 考试环境与生产环境行为不一致答案在 19c 和 21c 有差异现象在 21c 上验证题目答案发现和 PDF 给的参考答案不一致尤其是回收站行为和默认值相关题目。原因Oracle 不同版本对默认行为和对象处理有调整21c 的一些默认参数和 19c 不一样。题目是 19c 原题答案约定在 19c 环境成立。解决验证题目统一用 19c 环境最好是19.17的补丁版本。虚拟机装 19c 时选择 Enterprise Edition别用 XE——XE 的功能阉割可能影响结果。6. 用 SQL*Plus 做一套自测错题复盘脚本把原题变成可持续用的验证工具PDF 题目刷完一遍之后真正拉开差距的是错题复盘。我习惯把每道错题整理成一条 SQL 脚本跑一遍看实际输出把答案背后的行为验证一遍。这里给一套我经常用的脚本模板直接存成.sql文件在 SQL*Plus 里执行。-- 文件名: verify_questions.sql -- 用法: sqlplus hr/hrorclpdb verify_questions.sql SET ECHO ON SET FEEDBACK OFF SET LINESIZE 200 SET PAGESIZE 100 SET SERVEROUTPUT ON -- 实验1: 验证 DROP TABLE 后同义词的状态 CREATE TABLE t_verify AS SELECT 1 AS id FROM dual; CREATE SYNONYM syn_verify FOR t_verify; DROP TABLE t_verify; SELECT object_name, object_type, status FROM user_objects WHERE object_name SYN_VERIFY; -- 实验2: 验证 WHERE 优先级 WITH t AS ( SELECT 1 AS borrowed_date, RM AS transaction_type, A101 AS member_id FROM dual UNION ALL SELECT 1, BK, A102 FROM dual UNION ALL SELECT 0, RM, A999 FROM dual ) SELECT * FROM t WHERE borrowed_date 1 AND (transaction_type RM OR member_id IN (A101,A102)); -- 实验3: 验证 FLOOR 和 CEIL 对负数的行为 SELECT FLOOR(-99.99) AS floor_neg, CEIL(-99.99) AS ceil_neg FROM dual; -- 实验4: 验证多行子查询能否带 GROUP BY SELECT department_id FROM employees GROUP BY department_id HAVING COUNT(*) 1; SET FEEDBACK ON SET ECHO OFF这段脚本的逻辑说明第一个实验验证同义词不随表删除而消失状态变 INVALID第二个实验验证括号对 WHERE 逻辑分组的影响第三个实验验证 FLOOR 和 CEIL 对负数的取整方向第四个实验验证多行子查询确实可以包含 GROUP BY 和 HAVING。每条实验的预期输出你可以在跑之前先自己推理一遍跑完对比推理错误的地方就是你的知识盲区。复盘时我习惯在脚本里直接写注释标注「预期结果」和「实际结果」-- 实验5: 验证 INTERVAL 的 YEAR 字段是否必须为正 -- 预期: INTERVAL -1 YEAR 合法返回 -1 -- 实际: 合法说明题目 F 选项错误 SELECT INTERVAL -1 YEAR FROM dual;这个习惯帮我解决过一个实际问题团队的 ETL 脚本里用了TRUNC(SYSDATE) - 1取昨天的数据某天发现少了当天的数据。排查半天发现有人在脚本里把TRUNC(SYSDATE)改成了SYSDATE去比较导致边界时间条件失效。从那以后凡是涉及日期边界的 SQL我都强制在验证脚本里跑一遍TO_CHAR(TRUNC(SYSDATE), YYYY-MM-DD HH24:MI:SS)确认时间点再上线。这套验证脚本的价值不只是备考它本身就是一个可复用的 SQL 行为测试集。你每遇到一个拿不准的行为就往里加一条实验跑一遍看结果错题本会越来越薄。希望帮到你。本文还有配套的精品资源点击获取