★ FEATURED ARTICLE 简介该资源为Oracle 19c数据库时区版本35补丁包专门面向使用Oracle 19.3版本、需要解决ORA-39405 TSTZ版本报错问题的DBA与运维人员。补丁通过更新TSTZ时区数据将数据库时区版本提升至35安装前可通过SELECT * FROM v$timezone_file命令确认当前时区版本。需特别注意此补丁仅适用于Oracle 19.3其他版本使用会报错作者后续还会上传适配19c全版本的补丁。压缩包共10个文件以dat数据文件、xml配置文件和txt说明文档为主整体约394KB体积小巧便于快速部署。目前已有2561人学习下载适合需要修复时区版本不一致、保障跨时区数据正确性的数据库从业者参考使用。1. 一次凌晨三点的告警让我重新认识了时区补丁去年冬天某公司一套跑在 Oracle 19c 上的核心账务系统在凌晨三点突然批量报错日志里清一色是ORA-01882: timezone region not found。业务侧反馈是「跨月结息时区转换全乱了」DBA 第一反应是数据库挂了重启之后问题依旧。排查到天亮才发现根因是应用侧 JDBC 驱动升级后带了一个新的时区文件而数据库端的时区版本还停留在旧版两边对不上。这件事之后我把 Oracle 19c 的时区补丁升级流程重新梳理了一遍今天要拆的就是这个p31335037_190000_Linux-x86-64.zip——Oracle 19c 的时区版本 35 补丁包专门用于 Linux x86-64 平台。它解决的核心问题就一个把数据库内置的时区定义从旧版本升到 v35让TIMESTAMP WITH TIME ZONE、FROM_TZ、AT TIME ZONE这些操作在跨时区、跨夏令时规则变更时不再翻车。适合谁任何在 Linux 上跑 Oracle 19c、业务涉及多时区或历史时区数据、又不想因为时区规则过期被业务方追着跑的 DBA 和运维。2. 时区版本 35 到底改了什么从 DST 规则到 TZ 文件2.1 为什么 Oracle 要单独发时区补丁很多人以为时区是操作系统的事数据库跟着 OS 走就行。但 Oracle 数据库内部维护了一套独立的时区定义存放在$ORACLE_HOME/oracore/zoneinfo/目录下跟 OS 的/usr/share/zoneinfo是两套东西。原因在于 Oracle 需要保证TIMESTAMP WITH TIME ZONE类型的数据在数据库层面有确定性的转换规则不能因为 OS 升级了 tzdata 就导致同一行 SQL 在不同时间返回不同结果。所以 Oracle 会定期发布时区补丁把 IANA 时区数据库的最新变更同步进来。版本 35 对应的就是 IANA tzdata 的某次更新主要涉及若干地区的夏令时起止规则调整、历史时区偏移修正以及部分时区别名的增删。这些变更听起来离你很远但只要你的表里有带时区的时间戳字段或者 SQL 里用了AT TIME ZONE就一定会受影响。2.2 补丁包里有什么解压p31335037_190000_Linux-x86-64.zip之后你会看到几个关键文件文件/目录作用README.txt补丁说明包含前置条件和操作步骤etc/config/inventory.xmlOPatch 用的补丁元数据files/oracore/zoneinfo/新的时区数据文件核心就是这些files/bin/可能包含tzupgrade相关工具真正干活的是zoneinfo目录下的文件它们会被复制到$ORACLE_HOME/oracore/zoneinfo/覆盖旧版本。但注意不是复制完就生效还需要执行tzupgrade工具来更新数据库内部的时区版本号否则数据库仍然认为自己在用旧版本。2.3 升级前必须确认的三件事第一确认当前数据库的时区版本。执行SELECT version FROM v$timezone_file;如果返回的不是 35说明需要升级。第二确认$ORACLE_HOME下有足够的权限OPatch 和tzupgrade都需要对oracore目录有写权限。第三确认数据库处于可停机窗口因为tzupgrade在更新时区版本时可能需要重启实例尤其是当存在带时区的时间戳索引时。提示不要跳过README.txt里面会写明这个补丁是否依赖其他前置补丁以及是否需要在特定补丁集之上应用。3. 动手升级从解压到 tzupgrade 的完整命令链3.1 环境准备与补丁解压假设你已经把补丁包上传到了/u01/soft/目录并且以 oracle 用户登录。先解压cd /u01/soft unzip p31335037_190000_Linux-x86-64.zip -d p31335037 cd p31335037 ls -l解压后你会看到README.txt和etc、files等目录。先读 READMEcat README.txt | head -80重点看「Prerequisites」和「Installation Steps」两节。常见的前置条件包括OPatch 版本不低于某个值、数据库版本必须是 19.0.0、不能有正在运行的升级脚本等。3.2 用 OPatch 应用补丁Oracle 19c 的时区补丁通常可以通过 OPatch 直接 apply也可以手动复制文件。推荐用 OPatch因为它会记录补丁 inventory方便回滚。# 设置环境变量 export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export PATH$ORACLE_HOME/OPatch:$PATH # 检查 OPatch 版本 opatch version # 应用补丁 cd /u01/soft/p31335037 opatch applyopatch apply会提示你确认ORACLE_HOME是否正确输入y继续。如果报错OPatch failed with error code 73通常是 inventory 不一致需要先跑opatch lsinventory -detail检查。3.3 执行 tzupgrade 更新时区版本OPatch 应用完成后文件已经就位但数据库内部的时区版本号还没变。需要执行tzupgrade# 确认 tzupgrade 存在 ls $ORACLE_HOME/bin/tzupgrade # 查看当前版本 $ORACLE_HOME/bin/tzupgrade -l # 执行升级 $ORACLE_HOME/bin/tzupgrade -u-l参数列出当前时区文件版本和数据库版本-u执行升级。执行-u之前确保数据库处于 mount 状态或至少没有活跃的时区相关事务。如果数据库是 open 的tzupgrade可能会提示需要重启。-- 升级完成后在 SQL*Plus 中验证 SELECT version FROM v$timezone_file;返回 35 就说明升级成功。3.4 参数说明与常见变体tzupgrade的常用参数参数含义-l列出当前时区版本-u升级到时区文件中的最新版本-r回滚到上一个版本需要备份-f强制升级跳过某些检查我一般会先-l确认再-u升级升级完再-l复核。如果业务不允许停机可以先用-l看是否支持在线升级但多数情况下时区升级需要短暂停机。4. 避坑指南时区补丁升级的五个血泪教训4.1 ORA-01882 升级后反而更频繁现象升级完时区补丁应用连接数据库时报ORA-01882: timezone region not found的次数反而多了。原因应用端的 JDBC 驱动或客户端时区文件版本比数据库端更新两边不一致。数据库升到 v35但客户端还是旧版或者反过来。解决确保应用服务器上的orai18n.jar或 JDBC 驱动版本与数据库时区版本匹配。最稳妥的做法是数据库和客户端使用同一版本的时区文件。如果无法统一在 JDBC 连接串中显式指定时区避免依赖默认区域。4.2 tzupgrade 执行到一半卡住现象tzupgrade -u执行后长时间无响应或者报ORA-01555快照过旧。原因数据库中有大量带时区的时间戳数据升级时需要扫描并转换如果 UNDO 表空间不足或存在长事务就会卡住。解决升级前确保 UNDO 表空间有足够空间并且没有长时间运行的未提交事务。可以先在测试库上跑一遍估算时间。如果数据量极大考虑分批次处理或使用-f强制模式但强制模式有风险需谨慎。4.3 升级后历史数据时间偏移现象升级后查询历史订单发现某些跨夏令时的时间戳比之前多或少了一小时。原因时区版本 35 修正了某些地区的历史 DST 规则之前存储的TIMESTAMP WITH TIME ZONE数据在转换时使用了新规则导致显示值变化。解决这是预期行为不是 bug。如果业务要求历史数据保持原样需要在升级前导出受影响的数据升级后对比。对于新写入的数据新规则是正确的。建议在升级前用SELECT语句抽样检查受影响的时间段。4.4 OPatch 报错 “inventory is corrupted”现象opatch apply时报Oracle Home inventory is corrupted或Central Inventory is corrupted。原因之前的手动操作或非正常卸载导致 inventory 文件损坏。解决先备份$ORACLE_HOME/inventory和/etc/oraInst.loc然后尝试用opatch lsinventory -detail看能否恢复。如果不行需要从其他同版本环境复制 inventory 或重新安装 OPatch。这个坑比较深建议操作前对ORACLE_HOME做冷备。4.5 忘记升级 RAC 其他节点现象RAC 环境中只升级了节点 1节点 2 仍然报时区错误。原因时区补丁是ORACLE_HOME级别的RAC 每个节点都有自己的ORACLE_HOME需要逐个升级。解决在 RAC 环境中先升级一个节点验证无误后再滚动升级其他节点。注意tzupgrade在 RAC 中需要在每个实例上分别执行或者使用srvctl停止实例后统一升级。注意升级前一定要对数据库做全备尤其是SYSTEM和UNDO表空间。时区升级虽然通常可回滚但回滚过程可能比升级更麻烦。5. 验证与回滚怎么确认升级真的生效了5.1 三层验证法升级完成后不要只看v$timezone_file返回 35 就完事。我一般会做三层验证第一层数据库层面SELECT version FROM v$timezone_file; SELECT * FROM v$timezone_names WHERE tzname America/New_York;第二层SQL 行为层面-- 测试跨时区转换 SELECT FROM_TZ(TIMESTAMP 2024-03-10 02:30:00, America/New_York) AT TIME ZONE UTC FROM dual;对比升级前后的返回值确认 DST 规则已更新。第三层应用层面让应用侧跑一个涉及时区转换的冒烟测试用例确认 JDBC 连接和查询结果正常。5.2 回滚路径如果升级后出现严重问题回滚步骤# 停止数据库 sqlplus / as sysdba SHUTDOWN IMMEDIATE; # 回滚 tzupgrade $ORACLE_HOME/bin/tzupgrade -r # 回滚 OPatch cd /u01/soft/p31335037 opatch rollback -id 31335037 # 启动数据库 STARTUP;回滚后再次检查v$timezone_file确认版本回到升级前。注意回滚tzupgrade需要之前有备份否则可能无法回退到精确的旧版本。5.3 一个容易忽略的细节客户端时区文件数据库升级完别忘了应用服务器上的 Oracle 客户端。客户端时区文件通常在$ORACLE_HOME/oracore/zoneinfo/下如果客户端也装了 Oracle同样需要更新。对于 thin JDBC 驱动时区文件打包在orai18n.jar里需要替换为对应版本。我见过太多案例数据库升了客户端没升结果ORA-01882阴魂不散。从那以后我每次做时区补丁升级都会强制走一遍「数据库版本检查 → 客户端版本检查 → 应用连接串检查」的三步清单缺一步都不动手。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
