简介面向Windows环境下维护Oracle 19c数据库的DBA这份TZ41补丁包用于修复与时间区域相关的性能、安全及稳定性问题并更新全球时区与夏令时规则数据确保跨时区数据处理与报告准确。整个zip压缩包仅352KB共10个文件以6个dat时区数据文件为主体另含2个xml配置文件和2个txt说明文档结构紧凑、用途明确解压后可直接核对README中的操作指引。已有703人学习/下载适合需要为生产或测试环境打补丁的中高级数据库管理员。应用补丁时可按README.txt指引配合OPatch工具完成时区数据库升级规避因日期时间偏差引发的报表错误或合规风险同时提升Windows平台上Oracle数据库的稳定性和安全性。Oracle 19c作为主流数据库版本及时安装TZ41补丁有助于保持时区数据与全球法规一致减少跨区域业务的隐性故障。1. 先弄明白 TZ41 补丁是干什么的时区文件落后数据库时间就会集体跑偏上个月处理一套 Windows 上的 oracle19c业务报凌晨时区切换后TIMESTAMP WITH TIME ZONE字段整体差一小时查到最后是数据库时区版本停在旧文件上。标题里这个p35099667-190000-MSWIN-x86-64.zip就是 Oracle 为 Windows x86-64 平台 19c 发布的时区版本 41TZ41补丁190000 表示基础版本 19.0.0.0.0适用于整个 19c 系列。它做的事分两层替换 ORACLE_HOME 里的时区文件为 TZ41再用脚本把库内已有历史时区数据迁到新版本。这篇笔记覆盖检查、应用、验证和回滚边界重点提 Windows 上服务停止、注册表残留和 opatch 权限这三类高频坑。适合正在规划 19c 季度补丁窗口的 DBA也适合刚接手历史库、想一次把时区问题理干净的人。2. 动手打补丁前先查三样东西时区版本、补丁内容、业务影响面TZ 补丁和普通小补丁不一样的在于它既动 ORACLE_HOME 里的文件也要改数据库里的数据字典和历史数据。文件替换失败顶多补丁白打数据迁移没做好就可能出现半夜批处理大面积报错。所以跑任何命令之前先获得三个答案当前版本、补丁里有什么、哪些业务受影响。2.1 当前库的时区版本和 DST 状态用三条 SQL 问清楚用系统管理员身份登录 SQL*Plus先看当前容器再看时区文件版本最后查 DST 相关属性。-- 登录后先确认当前容器 SHOW con_name; -- 数据库当前加载的时区文件及版本 SELECT * FROM v$timezone_file; -- DST 升级相关属性 SELECT property_name, property_value FROM database_properties WHERE property_name LIKE DST\_% ESCAPE \;v$timezone_file返回三列核心看FILENAME和VERSION。如果FILENAME timezlrg_41.dat且VERSION 41说明文件层面已经到位如果显示timezlrg_40.dat或更低那就是需要打这个补丁的典型状态。DATABASE_PROPERTIES里重点看三行DST_PRIMARY_TZ_VERSION表示主时区版本DST_SECONDARY_TZ_VERSION表示升级前的旧版本DST_UPGRADE_STATE表示升级进度。正常未升级状态是NONE如果它是UPGRADE IN PROGRESS说明库里还有一笔没走完的时区升级事务这时候直接打补丁会把状态彻底搅乱。多租户环境还要多留个心眼。19c 默认是 CDBSHOW con_name显示结果应该是CDB$ROOT。如果当前会话落在某个 PDB 里先执行ALTER SESSION SET CONTAINER CDB$ROOT;再继续。跨容器检查时直接用CDB_PROPERTIES一次看全所有容器SELECT con_id, property_name, property_value FROM cdb_properties WHERE property_name LIKE DST\_% ESCAPE \ ORDER BY con_id;这样能避免只查了根容器、漏掉 PDB 的情况。实际运维中我见过不止一次根容器已经 41某个 PDB 还停在 38业务从那个 PDB 取数时时间偏移照旧。2.2 补丁包解压后你会看到什么一个补丁 ID 目录三类内容下载回来的 zip 在 Windows 上解压常见做法是放到一个独立目录别直接解到 ORACLE_HOME 里方便 opatch 读取和后续清理。mkdir C:\install\patch cd C:\install\patch tar -xf p35099667_190000_MSWIN-x86-64.zip解压后得到一个以补丁号命名的目录35099667。目录里通常包含三类内容第一类是etc下的补丁元数据和配置opatch 靠这些 XML 判断补丁编号、适用范围、前置依赖第二类是files下的实际替换文件TZ 补丁的核心在oracore/zoneinfo路径下的timezlrg_41.dat和timezone_41.dat前者是大时区文件后者是小时区文件第三类是脚本和说明文本部分版本会直接把utltzuv2.sql这类升级脚本也放进补丁目录方便离线环境使用。解压后建议逐个检查files下文件的时间戳确认是补丁发布日前后生成。如果某个文件时间戳特别旧说明压缩包不完整或者被安全软件拦截过。Windows 服务器上经常出现杀毒软件把.dat文件当可疑对象隔离的情况补丁应用时提示找不到文件先去看隔离区。2.3 业务影响面判断不是所有库都急着打但这几类必须打先给结论只存DATE和普通TIMESTAMP的库短期内不打影响不大但只要用了TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE或者 SQL 里有AT TIME ZONE做跨时区转换就必须在时区规则变化后尽快升级。判断依据不复杂查一遍数据字典即可SELECT owner, table_name FROM dba_tab_columns WHERE data_type IN (TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE) AND ROWNUM 50;查出来的表如果达到两位数说明业务对时区规则依赖不轻。还有一个容易漏的场景外部系统通过 JDBC、ODBC 写入带时区的数据应用层可能已经把时间换算过一遍数据库再按旧规则解析就叠了两层误差。这类系统即使库内没有带时区字段也要评估客户端驱动版本是否与 TZ41 匹配。另一个常见误解是认为 RU 补丁会顺带把 TZ 数据迁完。实际情况是RU 补丁可能内嵌了 TZ41 文件opatch apply完成后v$timezone_file直接显示 41但库内历史数据仍停留在旧版本必须单独执行迁移脚本。文件到了 41 不代表数据到了 41这是整个 TZ 补丁过程里最容易被忽略的一条。3. 在 Windows x86-64 上应用 TZ41 补丁从停服务到 utltzuv2 的完整流程Windows 平台和 Linux 的差别不仅在命令上还在进程模型和权限模型上。Linux 下停掉监听和实例后进程基本就清了Windows 上net stop之后经常还有oracle.exe赖在内存里opatch 替换文件时直接失败。所以整个过程我会按准备的严格程度分成四步走。3.1 动手前先做三件事停服务、留备份、确认进程第一件事是停 Windows 服务。用services.msc查看具体服务名典型名称是OracleServiceORCL和OracleOraDB19Home1TNSListener。以管理员身份打开命令提示符逐一停止net stop OracleOraDB19Home1TNSListener net stop OracleServiceORCL第二件事是确认进程没有残留。服务停止后任务管理器里可能还有后台进程没退出tasklist | findstr /i oracle如果看到oracle.exe仍存在别急着taskkill。先尝试通过 ORADIM 做一次受控关闭oradim -shutdown -sid ORCL -shuttype immediate这一步会把实例以 immediate 方式关闭比直接杀进程干净得多。如果 ORADIM 也没能清掉再用taskkill /F /PID处理具体进程号。注意把监听和实例都停干净再往下走否则 opatch 的前置检查会在最后一步报文件被占用。第三件事是备份。TZ 升级会改动sys.dst$等数据字典表以及一批带时区列的数据不能只靠补丁回滚兜底。常见做法是先做 RMAN 全库备份或者至少把SYSTEM、SYSAUX、UNDO表空间做一致性备份rman target / RMAN backup database plus archivelog;备份耗时取决于库大小但这一步值得做。TZ 迁移脚本跑到一半失败时备份是唯一可靠的后悔药。3.2 opatch apply参数与成功输出确认 OPatch 工具版本不低于 12.2.0.1.x19c 的时区补丁对 OPatch 版本有要求。检查版本%ORACLE_HOME%\OPatch\opatch.bat version版本满足后进入补丁应用阶段。把环境变量指到当前 ORACLE_HOME然后用opatch.bat apply指向补丁目录。set ORACLE_HOMEC:\app\oracle\product\19.0.0\dbhome_1 set ORACLE_SIDORCL cd /d %ORACLE_HOME%\OPatch opatch.bat apply C:\install\patch\35099667 -invPtrLoc %ORACLE_HOME%\oraInst.loc-invPtrLoc是指定中央目录指针文件的位置。Windows 上 opatch 默认通过注册表找 ORACLE_HOME一旦机器上装过多套 Oracle 或者卸载不干净注册表里残留路径会把 opatch 引到错误目录。显式指定oraInst.loc是最稳妥的绕开方式。执行过程里重点看两处输出前置检查是否全部通过结尾是否出现OPatch succeeded。检查补丁是否进清单opatch.bat lsinventory -patch这条命令会列出当前 ORACLE_HOME 已经应用的所有补丁确认 35099667 在其中。如果失败日志路径在%ORACLE_HOME%\cfgtoollogs\opatch\opatch_*.log翻日志比反复重跑更有效。到这里只完成了文件替换。数据库里那一堆历史时区数据还是原来的版本下一步必须跑升级脚本。3.3 数据库内时区迁移utltzuv2.sql 的两种执行路径时区迁移的标准做法是通过 Oracle 自带的utltzuv2.sql脚本完成。这个脚本位于%ORACLE_HOME%\rdbms\admin下它封装了DBMS_DST包的开始和结束两个阶段还会在中间步骤做一致性检查。先登录 SQL*Plussqlplus / as sysdbaSHOW con_name; -- 必须显示 CDB$ROOT SELECT property_name, property_value FROM database_properties WHERE property_name LIKE DST\_% ESCAPE \; ?/rdbms/admin/utltzuv2.sql脚本是交互式的会依次问升级类型、表空间、并行度和日志目录。升级类型一般选 1表示从当前版本一路升到目标版本如果当前时区版本离 41 太远选 2 先做中间版本升级。表空间建议给它一个业务不密集的表空间并行度 4 到 8 之间日志目录不要包含中文和空格Windows 上 sqlplus 对带空格路径的处理经常翻车。跑脚本期间不要开业务会话去查那些带时区列的表。脚本内部会锁定sys.dst$及相关转换表活跃会话一多锁等待会把整个窗口拖长。数据量大的库这个脚本可能要跑一两个小时甚至更久按数据量而不是按表数量估时间。脚本正确结束后DST_UPGRADE_STATE应该回到NONEDST_PRIMARY_TZ_VERSION变成 41。这时候还差一步重新编译失效对象。?/rdbms/admin/utlrp.sql时区升级会让一批视图、函数、物化视图失效utlrp.sql负责重新编译。跳过这一步后面应用连接时大概率遇到ORA-04068: existing state of packages has been discarded。跑完后查一下失效对象数量SELECT count(*) FROM dba_objects WHERE status INVALID;数量接近零才算收尾干净。3.4 单机与 RAC 的区别MSWIN 平台上的滚动与一次性脚本Windows 上的 RAC 节点同样使用这份MSWIN-x86-64补丁包但执行方式要区分。单机环境停掉服务后一次opatch apply就结束RAC 环境常见做法是滚动处理先停节点一的实例和服务在该节点执行opatch.bat apply完成后启动数据库服务再切到节点二重复。如果使用opatch auto做滚动需要集群里所有节点都能被正常识别Windows 服务依赖偶尔会让它失败所以按节点手工操作更可控。库内迁移脚本则不同数据库级别的utltzuv2.sql只需要在其中一个节点执行但执行前要把整个库切到受限会话模式或者只保留一个实例运行。ALTER SYSTEM ENABLE RESTRICTED SESSION;原因很简单迁移过程要改的是数据字典表多实例并发跑同一个 DDL 会造成锁等待和状态混乱。等脚本跑完再ALTER SYSTEM DISABLE RESTRICTED SESSION;把另外节点正常拉起来。这里不能为了赶时间两个节点同时跑TZ 升级不是可以并行加速的普通 DDL。4. 升级后验什么TZ 版本、升级状态与回滚边界补丁打完之后最怕的不是升级失败而是误以为成功。v$timezone_file显示 41数据库属性里却还挂着UPGRADE IN PROGRESS这种状态最迷惑人。验证工作要有顺序先文件层再数据层最后回滚策略。4.1 三个状态值NONE、UPGRADE IN PROGRESS、END_UPGRADE_IN PROGRESSDATABASE_PROPERTIES里的DST_UPGRADE_STATE是判断时区升级进度的关键属性。三个状态常见值如下属性值出现阶段业务可用性NONE未开始升级或已全部完成正常UPGRADE IN PROGRESSDBMS_DST.BEGIN_UPGRADE执行后受限避免写带时区数据END_UPGRADE IN PROGRESS第二阶段进行中接近完成但仍不要开业务utltzuv2.sql是一个长事务正常跑完时状态应该是NONE。如果看到UPGRADE IN PROGRESS或END_UPGRADE IN PROGRESS说明升级没有收口。这时候最忌讳的是直接重启数据库重启不会重置这个状态它记录在数据字典表里只能通过继续执行升级步骤或从备份恢复来消除。标准验证命令SELECT property_name, property_value FROM database_properties WHERE property_name IN (DST_UPGRADE_STATE, DST_PRIMARY_TZ_VERSION); SELECT version FROM v$timezone_file;两条结果对上v$timezone_file.version 41DST_PRIMARY_TZ_VERSION 41DST_UPGRADE_STATE NONE。这才代表补丁真正落地。4.2 数据字典里新旧两个时区版本共存会带来什么危害升级中断最典型的危害是历史数据与当前时区规则不匹配。Oracle 在处理 TSTZ 数据时会结合数据库当前时区文件和行内存储的时区 ID 做换算。如果文件已经是 41而部分行的元数据还停留在 40 甚至 38查询时可能出现ORA-08180: no data found based on the specified date或者ORA-01882: timezone region not found。出现这类报错时用视图确认受影响的表和错误明细SELECT * FROM dba_dst_affected_tables; SELECT * FROM dba_dst_affected_errors;dba_dst_affected_tables列出需要迁移时区数据的业务表dba_dst_affected_errors列出升级过程中转换出错的行。如果这两张视图里有数据说明迁移没有完整结束。可尝试的操作是把升级继续跑完或者从备份恢复后重跑而不是手工去改业务表里的时区 ID那些内部值不是给 DBA 直接改的。还有一个常见现象升级完成后大量对象失效但业务没重启连接池旧连接的会话里还缓存着旧状态。这时应用侧报错数据库侧检查一切正常。处理方法就是让应用完全断开连接重建别只做连接池内单个连接的 reset。4.3 回滚边界到底哪种场景能 opatch rollback哪种只能恢复备份回滚策略要看走到哪一步不能一刀切。最安全的回滚窗口是opatch apply刚完成、还没执行utltzuv2.sql之前。这时候数据库数据没动用opatch rollback把文件回退到旧时区版本库内数据和新文件没产生交集基本无损。一旦utltzuv2.sql跑完回滚就不建议了。因为库内大量时区数据已经按 TZ41 规则重建文件和数据之间的对应关系变了。此时把文件回退到 TZ40等于让数据库拿旧尺子量新数据出现的是时间偏移和解析错误而不是简单回到升级前。场景推荐手段结果opatch 已应用脚本未跑opatch rollback文件回旧版本数据未动脚本执行中失败根据 DST_UPGRADE_STATE 判断是否续跑续跑优先脚本已完整结束不建议回滚补丁只能从备份恢复脚本中途失败时先尝试续跑而不是立刻回滚。utltzuv2.sql的设计允许断点继续前提是日志中能看到明确的最后完成步骤。如果续跑多次都卡在同一个步骤那就不要恋战直接走备份恢复再重新评估并行度参数。5. TZ41 补丁避坑记录Windows 平台上的四个高频问题以下是按现象、原因、解决三段式记录的踩坑经历。每一条都在实际环境里遇到过按出现频率排序。5.1 opatch apply 的最后一步报“无法删除文件”服务明明已经停了现象opatch 前置检查全部通过执行到接近结束时报错提示某个oracle.exe或oraocci19.dll文件被占用无法替换。 原因用net stop停了 Oracle 服务但 SQL*Plus 会话、监听子进程或调度后台任务没有完全退出文件句柄还挂着。Windows 对正在被进程打开的文件默认不允许删除替换opatch 因此失败。 解决先列出残留进程并定位 PIDtasklist | findstr /i oracle能用 ORADIM 关实例就优先用避免直接 taskkill 造成数据库状态不一致。如果机器上有多个实例把所有实例相关的服务都停掉只停一个解决不了句柄占用。判定不了具体是哪个进程锁文件时重启服务器是最快的出路重启后先确认服务不会自动拉起数据库再重跑补丁。5.2 utltzuv2.sql 执行到一半实例重启属性停在 UPGRADE IN PROGRESS现象迁移脚本跑了一会儿实例因人为误操作或断电重启。重启后查询DATABASE_PROPERTIESDST_UPGRADE_STATE仍然是UPGRADE IN PROGRESS业务虽然能连库但读写带时区列开始报ORA-08180。 原因TZ 升级是两阶段过程第一阶段BEGIN_UPGRADE已完成并记录了升级状态第二阶段END_UPGRADE没来得及跑。这个状态不在内存里而是持久化在数据字典中重启不会自动清除。 解决先查dba_dst_affected_errors确认没有需要手工干预的错误再以受限会话模式重新执行utltzuv2.sql。脚本检测到UPGRADE IN PROGRESS状态后会从断点继续而不是重新开始。如果续跑仍然失败且错误指向数据字典内部表冲突不要手动删除sys.dst$相关表那会让数据库起不来。备份恢复是唯一可控的选择。5.3 打完补丁连接正常但应用侧只要一读带时区的列就报 ORA-01882现象数据库侧验证一切正常应用重启连接池后读取TIMESTAMP WITH TIME ZONE字段的接口批量报ORA-01882: timezone region not found。 原因客户端驱动自带的时区数据文件还是旧版本。尤其常见于旧 JDBC 驱动比如ojdbc6或更早版本它们内部维护了一套独立的时区映射和数据库 TZ41 规则不一致。 解决先排除数据库侧问题SELECT DBTIMEZONE, SESSIONTIMEZONE FROM DUAL; ALTER SESSION SET TIME_ZONE Asia/Shanghai;能正常执行说明服务器侧合法时区没问题问题在客户端。让应用完全断开所有连接清掉连接池缓存再替换为 Oracle 19c 配套的ojdbc8或ojdbc11。这类问题在升级后出现得很规律基本就是驱动旧了。5.4 opatch lsinventory 找不到新补丁显示却指向了另一个 ORACLE_HOME现象执行opatch lsinventory -patch输出里看不到 35099667再看路径显示的 ORACLE_HOME 根本不是当前数据库所在的目录甚至指向一个已经卸载删除的旧目录。 原因Windows 上 opatch 默认通过注册表定位 Oracle 主目录。之前卸载 oracle19c 时注册表清理不干净残留了HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDB19Home1之类的键值opatch 按注册表顺序找到了错误路径。 解决先用opatch lsinventory加-invPtrLoc参数指定当前oraInst.loc绕开注册表确认补丁实际安装结果。如果确认是注册表残留干扰再决定是否清理reg query HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE /s找到指向不存在目录的键先导出备份再删除。删注册表这件事要克制拿不准的键不要动能用-invPtrLoc绕开就别冒险清理。安全第一。6. 把 TZ41 补丁操作固化成运维脚本一次验证、一条回归、一个窗口TZ 补丁的特点是频率低、间隔长半年甚至一年才碰一次纯靠记忆操作容易临时翻车。我习惯把验证步骤写成一个批处理脚本每次打完补丁直接跑一遍输出一目了然。先准备验证 SQL 文件verify_tz41.sqlSET PAGESIZE 100 SET LINESIZE 200 COLUMN PROPERTY_NAME FORMAT A30 COLUMN PROPERTY_VALUE FORMAT A30 SELECT property_name, property_value FROM database_properties WHERE property_name LIKE DST\_% ESCAPE \ ORDER BY 1; SELECT version FROM v$timezone_file;再写 Windows 批处理echo off set ORACLE_HOMEC:\app\oracle\product\19.0.0\dbhome_1 set ORACLE_SIDORCL %ORACLE_HOME%\bin\sqlplus -S / as sysdba C:\scripts\verify_tz41.sql输出里能看到DST_UPGRADE_STATE NONE和VERSION 41就算过关。回归验证用一条带边界时区的查询比只查版本更能发现规则差异ALTER SESSION SET TIME_ZONE Pacific/Honolulu; SELECT FROM_TZ(TIMESTAMP 2024-11-03 01:30:00, America/New_York) AT TIME ZONE UTC AS utc_result FROM dual;2024 年 11 月 3 日是美国夏令时回拨的日子America/New_York在这个时间点有重复的一小时。如果时区规则文件没更新这条查询的换算结果会偏差一个小时或者直接报时区不存在。把它作为补丁后的固定回归用例比单纯查版本号有说服力得多。窗口排期上建议把 TZ 补丁和季度 RU 放在同一个维护窗口。先确认 RU 是否已内嵌 TZ41如果内嵌就不需要单独打这个补丁但库内迁移脚本仍然要跑。标准顺序是检查补丁清单执行utltzuv2.sql跑utlrp.sql最后用上面的脚本验证。过去几年我养成的习惯是每份 RU 说明里先划出时区版本这一行再决定要不要额外安排补丁窗口。时区问题平时看不见等夏令时边界事件出现时才处理代价是业务侧数据对不上。希望这篇能帮你在自己环境里把整套流程跑顺。本文还有配套的精品资源点击获取