简介Oracle 19c TZ41补丁P35099667-190000-MSWIN-x86-64.zip是专为Windows 2008及以上版本打造的时区更新文件面向数据库管理员、运维工程师以及需要精确处理跨时区数据的企业技术团队用于解决Oracle数据库在夏令时规则切换、时区数据库版本滞后等场景下出现的时间偏差、性能下降与安全风险。压缩包内共10个文件6个dat文件存储最新时区定义与夏令时规则2个xml文件描述补丁配置与元数据2个txt文件提供安装说明与校验信息整体大小仅352KB体积小巧、定位集中。目前已有703人参与学习适合作为生产环境升级前的预发验证素材或纳入日常数据库维护参考。应用补丁后数据库能够识别更多全球区域的时间规则有效减少因时区数据不准确引发的业务错误同时提升系统在全球化部署下的稳定性与合规性是保障Oracle 19c长期健康运行的关键维护项之一。1. oracle19c 打 TZ41 补丁p35099667-190000-MSWIN-x86-64.zip 到底解决了什么把 Windows 上的 Oracle 19c 时区版本从旧版升到 TZ41是很多 DBA 容易高估的一件事。拿到 p35099667-190000-MSWIN-x86-64.zip 这个文件很多人以为解压、运行 opatch apply 就结束了实际上补丁打完只完成了一半。真正决定时区能不能正确解析的是数据库数据字典里的时区版本号它不会跟着 opatch apply 自动变成 41。这个文件是 Oracle 19c 在 Windows x86-64 平台上的时区补丁包解决的是夏令时规则变更、历史时区偏移修正以及客户端连接时区错乱的问题。适合那些在做 19c 安装、维护或者已经被应用反馈时间差了一小时折磨过一轮的工程师。下面我按自己维护 Windows 单机和 RAC 环境的习惯把从装前检查到打完收尾的完整路径写清楚。2. 装前检查补丁文件、OPatch 版本与 Windows 环境三件套2.1 先看清 p35099667 是什么类型的补丁看到 p35099667-190000-MSWIN-x86-64.zip 这种命名第一件事不是解压而是识别类型。p35099667 是 My Oracle Support 上的补丁号190000 是补丁适用的基线发行版19.0.0.0.0MSWIN 代表 Microsoft Windows 平台x86-64 就是 64 位。这类 TZ 补丁的典型特征是zip 内包含一个新的时区数据文件以及配套的数据库脚本目录。常见做法是在 MOS 检索这个补丁号先看补丁说明里的 Product 和 Bugs Fixed。TZ 补丁会明确写升级时区文件到版本 41并列出修正了哪些地区的时区规则。我一般会额外注意一个细节补丁说明里有没有标注需要 X 版本以上的 OPatch。很多翻车事故就是从这里开始的补丁本身没问题OPatch 太旧跑不动前置检查。另一个容易忽略的点时区补丁和常规 PSU 补丁在目录结构上有区别。TZ 补丁的 zip 解压后补丁目录里除了 patch files还会有专门的 etc 目录和 datapatch 相关脚本。如果你解压后发现目录结构和普通补丁不一样不用慌这是时区类补丁的正常形态。提示先把 zip 里的补丁说明文档通常叫 README.txt 或 html 文件解压出来单独看里面会写清楚使用前必须满足的条件和应用后必须执行的后续步骤。这一步别省Windows 平台的时间戳坑和权限坑往往就藏在文档后半段。2.2 用 opatch lsinventory 核对当前时区版本与 OPatch 版本装前检查的核心是回答三个问题当前 OPatch 版本够不够、当前时区版本是什么、Oracle Home 的 inventory 是否正常。Windows 上和 Linux 不一样opatch 不是 opatch 脚本而是%ORACLE_HOME%\OPatch\opatch.bat需要以管理员身份打开 cmd 执行。set ORACLE_HOMEC:\app\oracle\product\19.0.0\dbhome_1 %ORACLE_HOME%\OPatch\opatch.bat version %ORACLE_HOME%\OPatch\opatch.bat lsinventory第一行把 ORACLE_HOME 指向你要打补丁的 19c 家目录第二行查 OPatch 自身版本第三行列出已安装补丁清单。这里opatch.bat version的输出会直接显示类似 OPatch Version: 12.2.0.1.28 这样的数字把这个值和补丁说明里的最低要求比一下。如果版本低于要求先去下载对应 OPatch 补丁更新它否则后面opatch apply大概率卡在 prerequisite check。lsinventory的输出里我们会关心两处一处是Patch history列出的历史补丁另一处是Oracle Home路径是否正确。Windows 上如果 Oracle Home 路径带空格比如C:\Program Files\Oracle\...命令里必须用引号包住这是我踩过的实际坑。接着进 SQL*Plus 查数据库当前的时区版本这一步和 opatch 是两套体系容易混为一谈SELECT version, version_time FROM v$timezone_file; SELECT DBMS_DST.get_latest_timezone_version FROM dual;第一条语句查的是当前数据库实际使用的时区文件版本号19c 初始安装的版本可能在 32 到 36 之间具体取决于你安装时用的补丁基线。第二条语句查的是数据库软件里自带的最新时区版本。如果第一条返回 40、第二条返回 41说明数据库还在旧时区版本正是这个补丁要解决的问题。2.3 Windows 下解压 zip 的坑路径过长、杀毒软件与目录权限时区补丁虽然不大但 Windows 解压有个经典玄学问题路径超过 260 个字符时系统自带解压工具会报文件名太长或直接静默漏文件。p35099667 补丁目录内部嵌套很深文件名又长我习惯先建一个短路径的临时目录比如C:\temp\p35099667用 7-Zip 或者 WinRAR 右键解压不要直接双击打开的 zip 浏览器里复制文件。mkdir C:\temp\p35099667 cd C:\temp\p35099667 C:\Program Files\7-Zip\7z.exe x D:\download\p35099667-190000-MSWIN-x86-64.zip -oC:\temp\p35099667 -y代码里的-o参数指定解压目标目录注意-o和目标路径之间没有空格。解压完成后进目录确认补丁子目录名字通常是一个以补丁号35099667开头的目录里面有etc、files和bin等子目录。如果目录名是乱的或者没有etc目录说明解压不完整重新解压或者换一台机器解压再拷贝过来都行。杀毒软件是另一个容易让人误判的变量。Windows Defender 或者第三方杀软经常把 Oracle 的 opatch 脚本或时区数据文件当可疑文件处理概率不大但一旦触发就是莫名其妙的找不到文件。我一般会先把解压目录加到杀软白名单同时把%ORACLE_HOME%目录也临时排除扫描打完补丁再恢复。这一步属于运维习惯不属于官方文档要求但值得做。最后是权限检查打开 cmd 时必须右键以管理员身份运行否则 opatch 没有权限写%ORACLE_HOME%\inventory。如果你用的 Windows 用户不是管理员后续opatch apply会在 inventory 更新那一步直接失败报错 ORA- 或者 insufficient privileges看了半天也不知道问题在哪。3. 在 Windows 上用 opatch apply 打 TZ41 补丁的全过程3.1 停止数据库与监听准备干净的维护窗口打时区补丁要在数据库完全关闭的状态下进行。Windows 上 Oracle 数据库通常注册成 Windows 服务实例没停干净的话时区数据文件会被进程占用opatch 写不进去。net stop OracleServiceORCL lsnrctl stop第一条net stop OracleServiceORCL按你的实际服务名改比如OracleServiceORCL或OracleServiceORCL19C第二条停止监听。如果这台机器上还跑着 OEM 代理或者其它 Oracle 相关服务也一并停掉。RAC 环境则要一个节点一个节点来两个节点不能同时打通常是节点 1 停实例打完再启动节点 2 再重复。停止服务后用任务管理器确认没有oracle.exe进程残留。Windows 上经常出现服务停了但后台还有一个进程卡着的情况这种时候 opatch apply 就会在拷贝文件阶段报file is in use。干脆重启一次机器再执行 apply反而最省时间。3.2 执行 opatch apply 并读懂输出进入补丁目录执行 apply命令里两个关键点一是必须以管理员 cmd 运行二是要在补丁目录内执行或者用-phBaseDir指定补丁目录。cd /d C:\temp\p35099667\35099667 set ORACLE_HOMEC:\app\oracle\product\19.0.0\dbhome_1 %ORACLE_HOME%\OPatch\opatch.bat apply -phBaseDir C:\temp\p35099667\35099667-phBaseDir指向补丁解压后的子目录。如果目录里有多个补丁子目录也可以先跑一次opatch.bat apply -report看预检结果-report只做检查不实际应用输出里会列出每个补丁是否满足前置条件。看到类似Patch [35099667] can be applied.这样的行再真正执行 apply。apply 过程会有大量输出不需要逐条看但几个关键行要盯住Prerequisite check CheckApplicable for patch ... passed表示前置检查通过Patch ... applied successfully或者OPatch succeeded.表示补丁写入成功。如果中间出现OUI-开头的错误码说明卡在 OUI 相关检查多半是 OPatch 版本或 inventory 权限问题往下看第 5 章排查。这里要特别说明opatch apply做的是把新的时区数据文件放入%ORACLE_HOME%\oracore\zoneinfo并更新 inventory 记录。这一步完成后软件的时区文件已经是 41但数据库数据字典里记录的时区版本还没有变所以别急着以为大功告成。3.3 打补丁后真正常被漏掉的 datapatch 环节19c 引入 datapatch 工具来处理数据库内部的补丁动作时区补丁也不例外。数据库需要先启动到 open 状态再执行 datapatch否则会报实例未启动。set ORACLE_HOMEC:\app\oracle\product\19.0.0\dbhome_1 set ORACLE_SIDORCL net start OracleServiceORCL %ORACLE_HOME%\OPatch\datapatch.bat -verbosenet start把服务拉起后执行 datapatch 时无需手动startup服务起来后实例会自动 open。-verbose会输出每个补丁在数据库内部的执行进度包括 SQL 脚本和应用状态。跑完后查一下select * from dba_registry_sqlpatch;应该能看到补丁 35099667 的ACTION为APPLY、STATUS为SUCCESS。但 datapatch 成功 ≠ 时区版本升级完成。datapatch 执行的是补丁自带的数据库端脚本它不会替你调用 DBMS_DST 升级时区。这就是标题里 TZ41 补丁整个流程里最容易踩的坑三件套做完数据库时区版本还停在旧值应用层查出来的时间照样是错的。下一章专门讲这一步怎么做。4. 时区版本升级不止是打补丁用 DBMS_DST 把 TZ 升到 414.1 为什么 opatch apply 之后还要单独做时区升级需要先理解 Oracle 的时区体系数据库里有两份时区数据一份是软件文件层面的timezone.dat存在%ORACLE_HOME%\oracore\zoneinfo另一份是数据字典里注册的时区版本号。应用连接的TIMESTAMP WITH TIME ZONE类型数据解析和显示依赖的是数据字典这一份不是文件这一份。opatch apply 更新的是前者DBMS_DST 负责的是后者。所以打补丁后即使v$timezone_file显示文件版本已经是 41只要数据字典没升级应用写入的带时区数据依旧按旧规则解释。默认情况下Oracle 允许新版本向下兼容读取旧数据但写出的新数据可能错一小时这在夏令时切换的地区尤其明显。另一个思考角度是回退。DBMS_DST 提供的升级是有完整后悔药机制的在升级过程中任意时间点只要没有执行END_UPGRADE你都可以通过DOWNGRADE_DATABASE回到旧版本一旦执行了结束标志就回不去了。这也是为什么凡是涉及时区的维护我都建议在业务低谷窗口做并且严格执行下面这套步骤。4.2 最小停机窗口的升级步骤prepare 与 upgrade 分开跑19c 的 DBMS_DST 流程分两段先是生成并填充升级信息再执行实际升级。我们这里用两张表来理解dba_dst_affected_tables记录哪些表里有需要升级的带时区列升级时 Oracle 会开启一个全局数据字典锁把所有受影响的数据做一次内部转换。这两步分开跑可以在 prepare 完成后先观察受影响行数再决定是否继续。SET SERVEROUTPUT ON BEGIN DBMS_DST.BEGIN_PREPARE( parallel TRUE ); END; / BEGIN DBMS_DST.UPGRADE_DATABASE( upgrade_mode DBMS_DST.UPGRADE, parallel TRUE ); END; / BEGIN DBMS_DST.END_UPGRADE; END; /执行这段前数据库必须处于startup upgrade状态。最简单的方式是先把服务停了然后在 cmd 里用sqlplus / as sysdba登入执行startup upgrade;再跑上面的 PL/SQL。三个匿名块对应的动作分别是开始准备阶段扫描所有带时区列的表并生成升级计划、执行升级真正把行内时区数据从旧版本转换成 41、结束升级写 registry 并释放锁。parallel参数这里值得展开。设成TRUE会在升级时使用多进程并行处理受影响表速度明显快但代价是内存和 undo 表空间消耗变大。如果你的数据库是 4 核以下的小机器我建议把两个块里的parallel都改成FALSE宁可慢一点也别在升级中途把共享池挤爆。如果是 RAC不要同时跑两个节点的 DBMS_DST文档不允许实际操作也一样会冲突。升级过程中如果想看进度另开一个会话执行SELECT session_id, state, description FROM dba_dst_upgrade_sessions;这个视图能看到升级会话处于PREPARE、UPGRADE还是COMPLETED。升级过程中实例不能被重启一旦中途断开整个升级会话会处于不可用状态需要从BEGIN_PREPARE重新来。这也是为什么一定要挑维护窗口做。4.3 应用层 JDBC / ODBC 客户端的时区数据同步数据库升到 TZ41 之后应用连上来还会有一个隐性裂缝客户端的 Java 运行时和数据库使用的 IANA 时区数据不是同一份。数据库已经按 41 规则解析但 JDBC 驱动或操作系统的时区库还停留在旧版两边算出来的偏移不一致表现就是应用查到的时间在夏令时切换日前后总差一小时或者 30 分钟。这块我一般会在升级文档里单独写一条操作项给应用服务器上的 JDK 更新时区数据JDK 自带的tzupdater工具可以做这件事把客户端时区数据升到和 TZ41 匹配的版本。操作上应用版本要有发布窗口DBA 要和开发团队约定好数据库升级后一周内必须同步客户端时区库否则没法定位是数据库还是应用的问题。注意时区升级会短暂锁住dba_dst_affected_tables里涉及的表升级期间这些表上的 DML 会受影响。准备阶段完成后用下面这条 SQL 看一下自己库里的受影响范围决定要不要把维护窗口拉长SELECT COUNT(*), owner, table_name FROM dba_dst_affected_tables GROUP BY owner, table_name;如果查出来只有几十行说明库里带时区列的数据很少升级会非常快如果是几百上千万行的日志表那这个窗口至少要按小时算。5. TZ41 补丁常见问题排查从 OPatch 报错到时区升级失败的 5 个坑5.1 现象opatch apply 前置检查失败报 OUI 错误做opatch apply时输出里出现OUI-10054或类似的 Error前置检查直接红叉。这个错误本身不提示 OPatch 版本但如果去查opatch version会发现版本明显偏老低于补丁说明里的要求。原因TZ 补丁通常在 OPatch 12.2.0.1.x 以上版本才支持完整的前置检测逻辑老版本解析不了补丁包里的元数据。解决先更新 OPatch再重新执行 apply。更新 OPatch 的方式是单独下载 OPatch 补丁包解压后用其中的opatch.bat覆盖%ORACLE_HOME%\OPatch目录覆盖前备份旧目录。更新完重新跑opatch.bat version确认再进补丁目录执行 apply。5.2 现象zip 解压后补丁目录里缺少关键子目录解压完p35099667-190000-MSWIN-x86-64.zip发现目录里只有零散的 xml 文件或者没有files、bin目录直接 opatch apply 时报补丁不完整。原因Windows 默认解压工具碰到超长路径会静默跳文件而且跳过的文件不提示导致补丁目录看起来完整实际缺东西。解决用 7-Zip 重新解压到短路径如C:\temp\p35099667解压后对比目录长度确认补丁目录名完整没截断。换工具后目录结构正常apply 不再报缺文件。这个坑在 Windows Server 上比想象中常见尤其是装在C:\Program Files下的 Oracle Home路径叠加解压临时目录很容易超过 260 字符。5.3 现象datapatch 跑完v$timezone_file 仍是旧版本打完补丁、datapatch 显示 SUCCESS但执行SELECT version FROM v$timezone_file;看到的还是 40 甚至更低。原因datapatch 只负责数据库补丁注册时区版本的数据字典升级必须通过 DBMS_DST 显式执行。这是整个流程里最容易误判的一步操作上补丁文档里写了但很多 DBA 看完 opatch 成功就收工了。解决执行第 4 章的 PL/SQL 升级块确认registry$dst中timezone_version变成 41 才算完。任何时候收到应用反馈时间差一小时先把这条 SQL 的结果拉出来别一上来就查应用代码。5.4 现象DBMS_DST 升级中途报 ORA-04030 或 ORA-01650跑DBMS_DST.UPGRADE_DATABASE时数据库在升级阶段弹 ORA-04030进程内存不足或 ORA-01650undo 空间不足升级会话中断。原因parallel TRUE时并行进程吃掉大量共享池内存同时数据转换产生大量 undo小机器上资源直接被推翻。不是补丁问题是资源估算没做足。解决改串行执行两个块都设置parallel FALSE同时把共享池调大比如ALTER SYSTEM SET SHARED_POOL_SIZE512M;视内存实际大小调整不要照抄。因为升级会话中断后要重新走 BEGIN_PREPARE所以建议先调完参数再开始别中途救火。5.5 现象升级完成后应用查询带时区字段依然偏移数据库侧v$timezone_file和registry$dst都已经是 41但应用跑出来的时间差一小时白天还是深夜时间规则混乱。原因客户端时区数据没有同步。数据库按 TZ41 规则解析夏令时但应用服务器的 JDK 或操作系统的时区文件还是旧规则两边对这一秒该按哪个偏移量算结论不一致。原因确认方法在应用服务器上用 Java 直接TimeZone.getTimeZone(America/New_York)看偏移再在数据库执行SELECT TZ_OFFSET(America/New_York) FROM dual;对不上就是客户端时区数据落后。解决是给 JDK 更新时区数据、同步操作系统时区库然后重启应用。这步经常要跨团队协调但本质就是两边时区规则版本不一致造成的假时区 bug。6. 打完 TZ41 怎么验证文件层、数据字典层、业务层都不放过6.1 三步验证法打完整个流程我习惯按三层来验证缺一层都不放心。第一层是软件文件层确认%ORACLE_HOME%\oracore\zoneinfo里的 timezone.dat 时间戳已经变成补丁应用日期第二层是数据字典层确认v$timezone_file和registry$dst的timezone_version都是 41第三层是业务层随便对一张带TIMESTAMP WITH TIME ZONE的表做读写测试把北京时间和一个有夏令时的时区放一起对比。SELECT version, version_time FROM v$timezone_file; SELECT * FROM registry$dst; ALTER SESSION SET TIME_ZONE America/New_York; SELECT TO_CHAR(SYSTIMESTAMP AT TIME ZONE America/New_York, YYYY-MM-DD HH24:MI:SS TZR) AS ny_time, TO_CHAR(SYSTIMESTAMP AT TIME ZONE Asia/Shanghai, YYYY-MM-DD HH24:MI:SS TZR) AS bj_time FROM dual;如果两条结果的时差符合当期夏令时规则并且冬季和夏季切换日前后各测一次都对得上业务层的验证才算通过。我一般会把三条 SQL 的输出存一份到运维记录里作为下次排障的时间基线。6.2 回退的唯一后悔药DOWNGRADE_DATABASE升级后如果应用侧出现大面积兼容问题并且确认是时区版本导致唯一后悔药是DBMS_DST.DOWNGRADE_DATABASE。这个操作同样要在实例startup downgrade状态下执行并且必须在升级会话结束后使用。降级前提前确认registry$dst里记录了旧版本号Oracle 支持回退到升级前的那一版但不能跳版本。这段操作我实际只用过一次是在测试库上验证流程时跑的。印象最深的是降级执行的时间几乎是升级的两倍因为它要把所有被升级过的行反转一遍。所以生产环境动手前先问一句业务到底能不能接受这个维护时长。打完补丁不升级时区等于白忙升级了发现应用没准备好要么憋着长维护窗口降级要么硬扛到客户端升级两个都难受。希望这次的步骤和踩坑记录能帮你在 TZ41 这条路上少走一趟弯路。本文还有配套的精品资源点击获取