简介：本资源是Oracle Database 19c（19.0.0.0.190416DBRU）专用的时区版本35补丁包，专为解决ORA-39405错误及TSTZ时区版本不匹配问题设计，适用于已部署Oracle 19.3版本的Linux x86-64环境，用于将数据库时区文件升级至TSTZ35版本（可通过SELECT * FROM v$timezone_file;验证）。补丁包共10个文件，含6个dat数据文件（承载时区定义核心数据）、2个xml配置文件（描述时区映射与元信息）及2个txt说明文档（含README与安装指引），结构精简、职责明确，总大小仅394KB，便于快速部署与回滚。目前已有2562人学习下载，反映出该补丁在生产环境时区升级、数据库迁移及Data Pump导出导入场景中的高频需求。用户可直接解压应用，获取完整时区更新能力、官方补丁编号（p31335037）对应的技术依据，以及适配19.0基础版的精准版本控制逻辑。
1. Oracle 19c 时区版本35补丁（p31335037）到底解决什么问题？不是升级、不是重装，而是“时间感知”的精准校准
你有没有遇到过这样的场景：某天凌晨2点，数据库里一条按SYSDATE插入的订单记录，时间戳却显示为01:59:59；或者跨时区应用同步时，Oracle 的TIMESTAMP WITH TIME ZONE字段在查询中自动转换出错，导致报表数据偏差一小时；更隐蔽的是，某些金融类批处理作业在夏令时切换日（如3月第二个周日）凌晨触发异常中断——日志里只报ORA-01878: found a field longer than expected，但查遍字段定义和SQL语法，根本找不到问题源头。这些都不是SQL写错了，也不是索引失效了，而是 Oracle 内部时区规则库（Time Zone File, TZFILE）与操作系统或业务所在地区实际政策脱节所致。p31335037 这个补丁，就是 Oracle 官方为 19.0.0 版本发布的「时区版本35」（TZ Version 35）更新包，它不改动数据库结构、不重启实例、不重建数据文件，只替换$ORACLE_HOME/oracore/zoneinfo/下那组二进制时区定义文件（timezlrg.dat,timezone.dat等），让SYSTIMESTAMP、FROM_TZ、AT TIME ZONE等所有依赖时区语义的操作，真正对齐 IANA 时区数据库 2020a 版本所收录的全球35次时区变更——包括巴西取消夏令时、摩洛哥延长夏令时、美国亚利桑那州纳瓦霍保留地特殊规则等共127个国家/地区的细微调整。它适合所有已稳定运行 Oracle 19c 生产库、但近期因时区政策变动出现时间逻辑异常的 DBA 和运维工程师，尤其适用于金融、航空、跨境物流等对时间精度要求达秒级的系统。这不是可选项，而是当你的SELECT TZ_OFFSET('America/New_York') FROM DUAL;返回值与权威时区服务（如 time.is）不一致时，必须打上的“时间校准补丁”。
2. 补丁本质与部署逻辑：为什么必须用 opatch 而不是手动覆盖文件？
2.1 时区文件不是普通配置文件：它是 Oracle 内核级硬编码依赖的二进制资源
很多人第一反应是：“不就是几个.dat文件吗？我直接下载解压，把新文件拷过去覆盖不就行了？”——这是最典型的翻车起点。Oracle 的时区定义并非以文本形式加载，而是编译进libnnz19.so、libclntsh.so.19.1等核心共享库的符号表中，并通过ora_time_zone_file这个内部常量指向内存映射地址。timezlrg.dat是主时区规则集（含 DST 历史变迁），timezone.dat是轻量级别映射索引，二者必须严格版本匹配，且文件头包含 CRC32 校验码。若手动覆盖，opatch lsinventory将无法识别该变更，后续打其他补丁时可能因校验失败而回滚；更严重的是，ALTER DATABASE SET TIME_ZONE = 'Asia/Shanghai';这类操作会触发内核重新解析时区文件，若文件结构损坏或版本错配，实例可能在ALTER SYSTEM CHECKPOINT阶段直接 core dump。p31335037 的设计逻辑是：它不是一个独立补丁，而是 Oracle OPatch 框架下的「Bundle Patch」类型补丁，其etc/config/inventory.xml中明确定义了patch_type="timezone"，要求 OPatch 在 apply 前执行三重校验：① 检查$ORACLE_HOME是否为 19.0.0.0.0（非 RU/RUR）；② 核对当前时区文件版本（通过SELECT * FROM V$TIMEZONE_FILE;获取VERSION字段）是否为34或更低；③ 验证timezlrg.dat文件头 Magic Number 是否为0x545A4631（TZF1）。只有全部通过，OPatch 才会启动原子化替换流程：先备份原文件到$ORACLE_HOME/.patch_storage/.../backup/，再用adrci记录操作上下文，最后调用libclntsh的tzfile_load()函数热重载内存映射。这整个过程不可跳过，也不能用cp -f替代。
2.2 OPatch 版本强约束：13.9.4.2.7 是 19c 时区补丁的最低准入门槛
Oracle 对 OPatch 有严格的向后兼容策略。p31335037 要求 OPatch 最低版本为13.9.4.2.7（发布于2020年6月），低于此版本的 OPatch（如常见的 13.9.4.0.0）在执行opatch apply时会直接报错OPatch failed with error code 73，并提示This patch requires OPatch version 13.9.4.2.7 or higher。这个错误不是警告，而是硬性拦截——因为旧版 OPatch 缺少对timezone类型补丁的元数据解析器，无法识别patch.xml中的<timezone_version>35</timezone_version>节点，会误判为非法补丁包。验证当前 OPatch 版本的方法不是opatch version（该命令返回的是 OPatch 工具自身版本号），而是执行：
$ORACLE_HOME/OPatch/opatch version -oh $ORACLE_HOME输出中需明确看到OPatch Version: 13.9.4.2.7或更高。若版本不足，必须先下载p6880880_190000_Linux-x86-64.zip（OPatch 13.9.4.2.7 for 19c）并按官方流程升级 OPatch 本身。注意：升级 OPatch 不需要停库，但必须确保$ORACLE_HOME/OPatch目录下无正在运行的opatch进程（可用ps -ef | grep opatch确认），且$ORACLE_HOME/OPatch/jlib中的opatch.jar和$ORACLE_HOME/OPatch/ocm/lib中的emocmutl.jar必须同时更新，否则会出现java.lang.NoClassDefFoundError: oracle/opatch/OPatchException。
2.3 补丁包结构解析：为什么必须解压到空目录且不能重命名
p31335037_190000_Linux-x86-64.zip解压后生成一个名为31335037的目录，其内部结构是 OPatch 严格约定的：
31335037/ ├── etc/ │ └── config/ │ └── inventory.xml # 定义补丁类型、目标版本、冲突规则 ├── files/ │ └── oracore/ │ └── zoneinfo/ │ ├── timezlrg.dat # 主时区规则（约 4.2MB） │ └── timezone.dat # 映射索引（约 1.1MB） └── README.txt # 包含适用范围、已知限制、回滚步骤关键约束有三点：①目录名必须为31335037—— OPatch 在apply时会从当前路径提取目录名作为补丁 ID，若解压成p31335037_patch或tz35，OPatch 将无法关联inventory.xml中的<patch_id>31335037</patch_id>，报错Patch ID not found in inventory；②必须解压到空父目录—— 若解压到/tmp/oracle_patches/下，而该目录内已有其他补丁（如31281355），OPatch 可能因缓存污染读取错误的inventory.xml；③files/子目录路径不可变—— OPatch 通过硬编码路径$ORACLE_HOME/oracore/zoneinfo/定位目标位置，若有人把timezlrg.dat提前拷到$ORACLE_HOME/oracore/zoneinfo/下再运行opatch apply，OPatch 会检测到目标文件已被修改，触发Conflicts detected并中止。因此标准解压命令只能是：
mkdir -p /tmp/patch_tz35 && cd /tmp/patch_tz35 unzip /path/to/p31335037_190000_Linux-x86-64.zip # 此时当前目录下必须只有 31335037/ 一个子目录 ls -l # 输出应为：drwxr-xr-x 3 oracle oinstall 4096 Jun 15 10:22 313350373. 实战部署四步法：从预检到生效验证，每一步都带可验证命令
3.1 预检阶段：用三条 SQL 和两个 Shell 命令锁定风险点
部署前必须确认三件事：当前时区版本、数据库状态、补丁兼容性。缺一不可，否则可能在 apply 过程中卡死或静默失败。
第一步：确认当前时区版本
-- 以 SYS 用户连接数据库（无需停库） SELECT VERSION, CON_ID FROM V$TIMEZONE_FILE;正常输出应为：
VERSION CON_ID ---------- ------ 34 0若VERSION为35，说明已打过该补丁，重复 apply 会报错Patch is already applied；若为36+，则此补丁不适用（需找更高版本时区补丁）；若CON_ID不为0（即存在多租户），需额外检查 PDB 是否处于READ WRITE状态（SELECT NAME, OPEN_MODE FROM V$PDBS;），因为时区文件是 CDB 级资源，但 PDB 的SYSTIMESTAMP解析依赖 CDB 的timezlrg.dat。
第二步：确认数据库未处于受限会话模式
# 在操作系统层面执行（非 SQL） $ORACLE_HOME/bin/sqlplus / as sysdba <<EOF SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF SELECT DECODE(RESTRICTED, 'ENABLED', 'RESTRICTED', 'NORMAL') FROM V\$INSTANCE; EXIT; EOF输出必须为NORMAL。若为RESTRICTED，需先执行ALTER SYSTEM DISABLE RESTRICTED SESSION;，否则 OPatch apply 会因无法获取完整实例信息而超时。
第三步：用 OPatch 自检补丁冲突
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /tmp/patch_tz35/31335037该命令会扫描$ORACLE_HOME中所有已安装补丁，检查是否存在与31335037冲突的补丁（如旧版时区补丁p29882501）。若输出Prereq check passed.则安全；若出现Conflicts detected，需按提示先opatch rollback冲突补丁。注意：此步骤耗时约 2~5 分钟，不要因无输出就强行 Ctrl+C。
3.2 Apply 阶段：静默模式 + 日志归档的原子化执行
进入补丁目录后，必须使用-silent模式执行，避免交互式提示中断流程（尤其在自动化脚本中）：
cd /tmp/patch_tz35/31335037 $ORACLE_HOME/OPatch/opatch apply -silent -oh $ORACLE_HOME > /tmp/opatch_tz35_apply.log 2>&1关键参数说明：
-silent：禁用所有用户确认提示（如 “Do you want to proceed?”），确保脚本可复现；-oh $ORACLE_HOME：显式指定 Oracle Home，防止 OPatch 因环境变量混乱定位错误目录；> /tmp/opatch_tz35_apply.log 2>&1：将 stdout 和 stderr 合并重定向到日志，便于事后审计。
成功执行后，日志末尾应出现：
OPatch succeeded.且V$TIMEZONE_FILE.VERSION仍显示34（这是正常现象，因为时区文件热加载不触发视图刷新）。此时补丁文件已复制到$ORACLE_HOME/.patch_storage/31335037_/...备份目录，但内存中的时区规则尚未更新。
3.3 生效阶段：无需重启，但必须强制刷新内存映射
这是最容易被忽略的关键步骤。很多 DBA 打完补丁就去验证，发现SYSTIMESTAMP还是老结果，以为补丁失败，其实只是没触发热重载。Oracle 提供了专用命令强制刷新：
-- 仍以 SYS 用户执行 ALTER SYSTEM SET EVENTS '32767 trace name context forever, level 10'; -- 等待 5 秒 EXEC DBMS_DST.FLUSH_TRIGGERS; -- 立即生效 ALTER SYSTEM FLUSH SHARED_POOL;解释：
ALTER SYSTEM SET EVENTS ...是 Oracle 内部调试事件，level 10表示启用时区文件重载跟踪（不影响性能）；DBMS_DST.FLUSH_TRIGGERS清空时区相关 PL/SQL 缓存（如FROM_TZ函数的解析结果）；FLUSH SHARED_POOL强制释放 shared pool 中所有与时间相关的 cursor（如SELECT SYSTIMESTAMP FROM DUAL的执行计划），迫使下次执行时重新加载新时区规则。
执行完毕后，V$TIMEZONE_FILE.VERSION仍不会变，但SYSTIMESTAMP已生效。验证命令：
SELECT SYSTIMESTAMP, TZ_OFFSET(SESSIONTIMEZONE) FROM DUAL; -- 对比打补丁前后，同一时刻执行，OFFSET 值应更新（如巴西圣保罗从 -02:00 变为 -03:00）3.4 验证阶段：用 IANA 官方测试用例交叉验证
不能只信SYSTIMESTAMP，必须用 Oracle 官方推荐的 IANA 测试集验证。下载tzdata2020a.tar.gz（IANA 2020a 版本源码），解压后进入test/目录，找到test_tz.c编译为测试程序：
gcc -o test_tz test_tz.c -I$ORACLE_HOME/rdbms/public -L$ORACLE_HOME/lib -lclntsh ./test_tz America/Sao_Paulo 2020-10-18 00:00:00输出应为UTC-03:00（补丁前为UTC-02:00）。更实用的是 SQL 验证：
-- 测试巴西夏令时取消（2020年10月18日起） SELECT FROM_TZ(CAST(TIMESTAMP '2020-10-17 23:00:00' AS TIMESTAMP), 'America/Sao_Paulo') AT TIME ZONE 'UTC' AS utc_before, FROM_TZ(CAST(TIMESTAMP '2020-10-18 00:00:00' AS TIMESTAMP), 'America/Sao_Paulo') AT TIME ZONE 'UTC' AS utc_after FROM DUAL;补丁前：两行均为2020-10-18 02:00:00 UTC（错误，应有1小时跳跃）；
补丁后：utc_before为2020-10-18 02:00:00 UTC，utc_after为2020-10-18 03:00:00 UTC（正确，体现 DST 取消后的连续性）。
4. 避坑指南：五条血泪经验总结，每一条都来自真实翻车现场
4.1 现象：opatch apply卡在Validating patches...阶段超过30分钟，CPU 占用率 100%
原因：OPatch 在校验时区文件 CRC 时，会逐字节读取timezlrg.dat（4.2MB）并计算 SHA256，若该文件被其他进程（如备份脚本rsync或监控 agent）加了共享锁，OPatch 会无限等待。常见于使用inotifywait监控$ORACLE_HOME变更的运维脚本。
解决：执行lsof +D $ORACLE_HOME/oracore/zoneinfo/查看哪些进程正占用timezlrg.dat，kill -9掉对应 PID 后重试。切勿用touch修改文件时间戳试图绕过校验——这会导致 OPatch 认为文件被篡改而拒绝应用。
4.2 现象：Apply 成功，但SELECT TZ_OFFSET('Europe/London') FROM DUAL;仍返回+00:00（应为+01:00夏令时）
原因：TZ_OFFSET函数返回的是会话时区（SESSIONTIMEZONE）的偏移，而非系统时区。若客户端连接时未设置TIME_ZONE，Oracle 默认用操作系统时区（/etc/localtime），而 Linux 系统时区文件（/usr/share/zoneinfo/）未同步更新，导致SESSIONTIMEZONE仍是旧值。
解决：在 SQL*Plus 连接后立即执行ALTER SESSION SET TIME_ZONE = 'Europe/London';，再查TZ_OFFSET；或在sqlnet.ora中添加SQLNET.TIME_ZONE = Europe/London，确保所有连接统一。
4.3 现象：PDB 中SYSTIMESTAMP正确，但 CDB$ROOT 中仍为旧时间
原因：多租户环境下，CDB$ROOT 的SYSTIMESTAMP依赖 CDB 的时区文件，但 PDB 的SYSTIMESTAMP会继承 CDB 的timezlrg.dat，而V$TIMEZONE_FILE视图在 PDB 中不可见（仅 CDB 可查）。若 PDB 处于MOUNTED状态，其时区缓存未刷新。
解决：对每个 PDB 执行ALTER PLUGGABLE DATABASE <pdb_name> OPEN READ WRITE;，然后在 PDB 中执行ALTER SYSTEM FLUSH SHARED_POOL;。
4.4 现象：回滚补丁后，V$TIMEZONE_FILE.VERSION仍显示35
原因：opatch rollback只恢复文件，但内存映射未清除。Oracle 不提供ALTER SYSTEM UNLOAD TIMEZONE命令，必须重启实例才能彻底回退。
解决：执行opatch rollback -id 31335037后，必须重启数据库：srvctl stop database -d <db_name>→srvctl start database -d <db_name>。切勿相信VERSION视图未变就认为回滚失败。
4.5 现象：应用补丁后，某些 Java 应用（如 WebLogic 连接池）报ORA-00604: error occurred at recursive SQL level 1
原因：Java JDBC 驱动（ojdbc8.jar）内置了时区规则缓存，若驱动版本低于 19.3，会继续使用本地缓存的旧时区数据，与数据库新规则冲突。
解决：升级 JDBC 驱动至ojdbc8-19.12.0.0.jar或更高，并在连接 URL 中添加?useTimezone=true&serverTimezone=UTC参数强制同步。
5. 进阶验证：用真实业务 SQL 检测时区补丁是否真正落地
5.1 构建时区敏感型业务场景验证集
不能只依赖SYSTIMESTAMP，必须模拟真实业务逻辑。以下三个 SQL 是某跨境支付系统上线前必跑的验证用例，覆盖了时区补丁最易出错的边界：
场景一：跨时区交易时间对账（核心验证）
-- 假设交易发生在纽约时间 2020-11-01 01:30:00（夏令时结束日，时钟拨回1小时） -- 正确逻辑：该时间在纽约是模糊的（01:30:00 出现两次），Oracle 应按 IANA 规则解析为 DST 结束后的标准时间 SELECT FROM_TZ(CAST(TIMESTAMP '2020-11-01 01:30:00' AS TIMESTAMP), 'America/New_York') AT TIME ZONE 'UTC' AS utc_time, CASE WHEN EXTRACT(HOUR FROM FROM_TZ(CAST(TIMESTAMP '2020-11-01 01:30:00' AS TIMESTAMP), 'America/New_York') AT TIME ZONE 'UTC') = 5 THEN 'CORRECT: DST ended, now EST (UTC-5)' ELSE 'ERROR: Still using EDT (UTC-4)' END AS validation_status FROM DUAL;补丁前：utc_time为2020-11-01 05:30:00 UTC（错误，应为06:30:00 UTC）；
补丁后：utc_time为2020-11-01 06:30:00 UTC（正确，表明已识别 DST 结束）。
场景二：历史数据时间窗口查询（性能验证）
-- 查询 2019-03-10 至 2019-03-11 的订单（美国春令时开始日，02:00:00 跳至 03:00:00） -- 正确逻辑：`BETWEEN` 应跳过不存在的 02:00:00~02:59:59 时间段 EXPLAIN PLAN FOR SELECT COUNT(*) FROM orders WHERE order_time BETWEEN FROM_TZ(CAST(TIMESTAMP '2019-03-10 01:00:00' AS TIMESTAMP), 'America/Chicago') AND FROM_TZ(CAST(TIMESTAMP '2019-03-11 01:00:00' AS TIMESTAMP), 'America/Chicago'); SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);补丁前：执行计划中access("ORDER_TIME">=... AND "ORDER_TIME"<=...)显示全表扫描（因时区转换失败，无法走索引）；
补丁后：access条件变为order_time >= TIMESTAMP '2019-03-10 01:00:00 -06:00' AND order_time <= TIMESTAMP '2019-03-11 01:00:00 -05:00'，且filter消失，证明索引可用。
5.2 自动化验证脚本：五分钟生成补丁健康报告
将上述验证逻辑封装为可定时执行的 Shell 脚本，避免人工遗漏：
#!/bin/bash # tz35_health_check.sh ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1 export ORACLE_HOME export PATH=$ORACLE_HOME/bin:$PATH # 生成验证SQL cat > /tmp/tz35_test.sql <<'EOF' SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF SPOOL /tmp/tz35_report.log PROMPT === Timezone Version Check === SELECT 'Current TZ Version: ' || VERSION FROM V$TIMEZONE_FILE; PROMPT === NYC DST End Validation === SELECT 'NYC DST End UTC: ' || TO_CHAR(FROM_TZ(CAST(TIMESTAMP '2020-11-01 01:30:00' AS TIMESTAMP), 'America/New_York') AT TIME ZONE 'UTC', 'YYYY-MM-DD HH24:MI:SS') FROM DUAL; PROMPT === Chicago Spring Forward Validation === SELECT 'Chicago Spring Forward Gap: ' || CASE WHEN FROM_TZ(CAST(TIMESTAMP '2019-03-10 02:00:00' AS TIMESTAMP), 'America/Chicago') IS NULL THEN 'GAP DETECTED (CORRECT)' ELSE 'NO GAP (ERROR)' END FROM DUAL; SPOOL OFF EXIT; EOF # 执行并解析结果 $ORACLE_HOME/bin/sqlplus -s / as sysdba @/tmp/tz35_test.sql >/dev/null 2>&1 # 关键字匹配生成结论 if grep -q "2020-11-01 06:30:00" /tmp/tz35_report.log && grep -q "GAP DETECTED" /tmp/tz35_report.log; then echo "[PASS] Timezone patch 31335037 is fully effective." exit 0 else echo "[FAIL] Timezone patch verification failed. Check /tmp/tz35_report.log" exit 1 fi该脚本执行后输出[PASS]或[FAIL]，可直接集成到 Ansible Playbook 或 Jenkins Pipeline 中，作为补丁部署流水线的 gate check。
5.3 长期维护建议：建立时区补丁生命周期管理表
时区补丁不是一劳永逸的。IANA 每年发布 2~4 次时区更新（通常在3月、6月、9月、12月），Oracle 会随之发布新补丁（如 p32545013 对应 TZ Version 36）。建议在数据库中创建一张轻量级管理表，记录所有时区补丁的部署状态：
CREATE TABLE tz_patch_log ( patch_id VARCHAR2(20) PRIMARY KEY, version NUMBER NOT NULL, applied_date DATE DEFAULT SYSDATE, applied_by VARCHAR2(30), notes VARCHAR2(200) ); INSERT INTO tz_patch_log VALUES ('31335037', 35, SYSDATE, 'DBA_TEAM', 'TZ Version 35 for 19c'); COMMIT;后续每次打新补丁，只需INSERT一行，并定期执行：
SELECT patch_id, version, applied_date, CASE WHEN version = (SELECT MAX(version) FROM tz_patch_log) THEN 'LATEST' ELSE 'OUTDATED' END status FROM tz_patch_log ORDER BY applied_date DESC;这样，当某天又出现时间异常时，DBA 第一时间就能判断：“是不是该升级 TZ Version 37 了？”而不是从头排查。
从那以后我每次部署 Oracle 补丁，都会在opatch apply前先跑一遍opatch prereq，apply 后立即执行DBMS_DST.FLUSH_TRIGGERS，最后用tz35_health_check.sh生成报告存档——不是怕出错，而是怕出错后花三天时间倒查才发现是时区补丁没生效。希望帮到你。
本文还有配套的精品资源，点击获取
