Oracle 19c Windows TZ41时区补丁与DBMS_DST迁移避坑

简介：面向 Windows 环境下 Oracle 19c 数据库运维人员与 DBA 的 TZ41 时区补丁包，针对跨时区数据处理、夏令时规则更新以及数据库运行稳定性需求，适用于 Windows Server 2008 及以上平台。压缩包共 10 个文件，由 6 个 dat 数据文件、2 个 xml 配置与元数据文件、2 个 txt 说明文本组成，整体约 352KB，体积不大但结构清晰，便于核对补丁内容、时区库版本与发布信息。已有 712 人学习，说明其在 Oracle 时区维护场景中具备一定参考价值。Oracle 时区管理关系到全球用户访问同一数据库时的时间显示与统计口径，TZ41 补丁涉及时区规则和夏令时信息的更新，可辅助排查跨区域报表、日志时间戳与业务数据一致性问题。读者可将其作为了解补丁适用范围、评估升级影响、核对版本信息以及开展合规审计的资料依据与排错参考。

1. 一条命令、十几项准备：Windows 上装 TZ41 的真实成本

在 Windows 机器上给 Oracle 19c 打时区补丁，反直觉的地方在于：opatch apply只有一行，准备工作却有十几项，而翻车几乎全发生在那十几项里。这次要装的是 TZ41 时区补丁，补丁号 p35099667，包名 p35099667-190000-MSWIN-x86-64.zip，对应 19c（19.0.0.0）的 Windows 64 位平台，也就是圈里常说的 ORACLETZ41。它和普通 RU 补丁不是一类东西：打完以后，数据库那份时区定义文件会被整体替换，旧的TIMESTAMP WITH TIME ZONE数据要么跟着迁，要么就永远停在一个不会再被解释的版本上。装错了通常不会当场报错，等业务跨时区的时间戳差出一小时，才是真正难查的时候。下面按我实际在一台 Windows Server 上走通的顺序，从环境盘点、OPatch 升级、apply、避坑一直写到验证和回退。

2. 环境盘点：TZ41 落地前要核对的四组参数

Windows 上的 Oracle 装法比 Linux 随意得多，一台机器上并存 client home、dbhome、Grid 的情况非常常见。补丁打错 home 这件事，在 Linux 上顶多是报错，在 Windows 上却可能“看起来成功”，因为 OPatch 认的是环境变量，不是你心里想的那个路径。

2.1 先把 ORACLE_HOME 和 ORACLE_SID 钉死

不要接着上一个窗口继续用。以管理员身份重新开一个干净的 cmd，把环境变量整个过一遍，比后面花两小时排查省事得多。

:: 管理员身份打开新的 cmd，先把所有 ORACLE 相关变量打出来 set | findstr /I "ORACLE" :: 从注册表再核一遍，Windows 上每个 home 都在这里登记 reg query "HKLM\SOFTWARE\Oracle\KEY_OraDB19Home1" /v ORACLE_HOME

set | findstr这条会输出ORACLE_HOME、ORACLE_SID、ORACLE_BASE、TNS_ADMIN、NLS_LANG等一串。重点看两个：ORACLE_HOME必须指向 19c 的库 home（典型路径是C:\app\<用户>\product\19.0.0\dbhome_1），不能指到 client 的 home 上；ORACLE_SID决定后面startup起的是哪个实例，多实例机器上这一项错了，你会对着一台根本没打补丁的库做验证。

注册表那条是交叉验证。如果set出来的路径和注册表里的ORACLE_HOME对不上，说明有第三方软件（某些备份代理、监控 agent）改过系统变量，后面每一步都要手动set覆盖，别指望继承。

确认完路径再看库本身：

:: 客户端版本 sqlplus -v :: 实例名、状态、完整版本号 sqlplus / as sysdba SQL> select instance_name, status from v$instance; SQL> select banner_full from v$version; SQL> exit

sqlplus -v输出里应该是 19.0.0.0.0 这一档。v$instance的status现在是OPEN，一会儿要关掉。v$version的banner_full会带上具体的 Release Update 号，把它记下来——TZ41 补丁是否与当前 RU 冲突，opatch prereq只能检查一部分，最终还是要拿这个号和补丁 README 里的前置条件对。

2.2 补丁包解压：文件名里每个字段都有用

p35099667-190000-MSWIN-x86-64.zip这个名字不是随便起的：35099667是补丁号，190000对应 19.0.0.0 版本线，MSWIN是平台标识，x86-64是位数。四个字段里任何一个不匹配，后面的操作都是白费。

:: 补丁包千万不要解压到 ORACLE_HOME 里面，单独找个盘 mkdir D:\patch cd /d D:\patch :: 用系统自带解压或第三方工具都行，关键是解完确认层级 dir /b D:\patch dir /b D:\patch\35099667

第二条dir的输出里，应该能直接看到README.txt、etc、files、custom这些条目。如果看到的是另一个35099667目录，说明解压时多套了一层，后面opatch apply会直接报“不是有效补丁”。这个坑后面第 5 章还会细说，先在这里埋个伏笔。

解压完先别急着敲命令，把 README 翻一遍：

:: 在 README 里定位几个关键段落 findstr /I /C:"OPatch Version" /C:"Prerequisites" /C:"space" /C:"Platform" D:\patch\35099667\README.txt

重点确认四件事：要求的最低 OPatch 版本、需要的磁盘空间、有没有前置补丁要先打、平台标识是不是MSWIN x86-64。这四个值决定了第 3 章要不要先升级 OPatch，以及第 4 章的预检要重点看哪几项。

2.3 备份：给回滚留好后路

时区补丁的回退比普通补丁麻烦，因为它动的是数据解释规则，不是纯二进制。备份要分两层做：一层是 ORACLE_HOME 里的 OPatch 目录和 inventory，一层是数据库本身。

:: 第一层：OPatch 目录和 inventory，这是回滚的最后一道保险 cd /d %ORACLE_HOME% xcopy OPatch D:\backup\OPatch_before_tz41\ /E /I /H /Y xcopy inventory D:\backup\inventory_before_tz41\ /E /I /H /Y

/E带空目录一起复制，/I让目标按目录处理（不存在就建），/H把隐藏文件也带上，/Y关掉覆盖确认。这四个参数缺一个，备份就可能不完整——尤其是/H，inventory里有几个隐藏的 XML 不带它会被跳过，回滚时 OPatch 会告诉你“补丁记录不存在”。

第二层是数据库备份。时区补丁本身不改业务数据，但如果你后面要走DBMS_DST迁移历史时间戳，那就必须有可回退的库备份。常见的做法是打补丁前做一次全备，或者至少把SYSTEM、SYSAUX和一个业务 schema 备份出来。

最后看空间：

:: 看系统盘和 ORACLE_HOME 所在盘的剩余量 fsutil volume diskfree C: fsutil volume diskfree D:

TZ41 本身占几百 MB，但 OPatch 在 apply 过程中会解压临时文件、生成回滚脚本，峰值可能是补丁体积的两三倍。留 5 GB 以上比较稳妥，低于这个数就先清盘。

2.4 停机顺序：先关库，再停服务

Windows 上最容易出问题的不是打补丁，是停服务。顺序反了会留下僵死的oracle.exe，占着 dll 不放，apply 跑到一半报文件无法删除。

:: 第一步：正常关库，这一步才是干净停机的关键 sqlplus / as sysdba SQL> shutdown immediate; SQL> exit :: 第二步：停 Windows 服务 net stop OracleServiceORCL :: 第三步：停监听 lsnrctl stop :: 第四步：确认没有残留进程 tasklist | findstr /I "oracle tnslsnr"

shutdown immediate会回滚未提交事务并做检查点，比shutdown abort安全得多。后面net stop停的是 Windows 服务壳，它不会替你关库——如果跳过第一步直接停服务，Oracle 会走一次崩溃恢复，下次起库时间会明显变长。

tasklist的输出必须是空的（除了oracle.exe相关的其他服务进程）。如果还有残留，先别急着taskkill，回过去看看是不是有别的实例还在跑——多实例机器上停错服务是很常见的事。

到这里为止，四组参数核对完，可以开始动 OPatch 了。

3. OPatch 升级：版本不够比补丁打错更难查

19c 出厂的 OPatch 版本普遍偏低，12.2.0.1.15 到 12.2.0.1.25 这个区间很常见，而 TZ41 这类时区补丁对 OPatch 有明确的最低版本要求。版本不够的时候，opatch apply不是当场拒绝，而是走到一半报一个错误的错误码，或者把 files 拷进去了、inventory 却没更新——库还能起，补丁实际上只装了一半。这种半装状态是排障里最费时间的。

3.1 先看现状，别猜

:: 进 OPatch 目录，两个命令都要跑 cd /d %ORACLE_HOME%\OPatch opatch version opatch lsinventory

opatch version输出类似：

OPatch Version: 12.2.0.1.25 OPatch succeeded.

opatch lsinventory会打印当前 home 的路径、已装补丁列表、以及 inventory 的位置。这两个命令跑通了，说明 OPatch 本身没坏，可以往下走；跑不通（比如报java.lang.UnsupportedClassVersionError或者找不到opatch.bat），先解决 OPatch 自身的问题，别往补丁上赖。

判断标准很简单：拿opatch version的数字，和 README 里写的最低版本对一遍。低于就升级，等于或高于就可以跳过这一整章。

3.2 换 OPatch 的正确手法：改名，不要删

:: 1) 确认服务已经停了，OPatch 目录被占用就换不掉 net stop OracleServiceORCL :: 2) 旧 OPatch 改名留底，不要直接删 cd /d %ORACLE_HOME% ren OPatch OPatch_bak_tz41 :: 3) 把新版 OPatch 解压到 ORACLE_HOME 根目录 :: 解压完的正确结构是 %ORACLE_HOME%\OPatch\opatch.bat :: 如果是 %ORACLE_HOME%\OPatch\OPatch\opatch.bat，把里层目录提上来

这里有个反复出现的细节：新版 OPatch 压缩包解开后本身就是一个OPatch目录，如果直接解压到%ORACLE_HOME%\OPatch，会变成两层套娃。正确的做法是解压到%ORACLE_HOME%这一层，让它自然覆盖或新建OPatch。

换完必须验证：

cd /d %ORACLE_HOME%\OPatch opatch version opatch lsinventory | findstr /I "Oracle Home OPatch Version"

lsinventory不带参数只输出摘要，够用来确认 home 路径对不对。要完整记录，就重定向到文件：

:: 打补丁前的完整清单，出问题时拿它对比 opatch lsinventory -detail > D:\backup\lsinventory_before_tz41.txt

-detail会把每个已装补丁的组件版本都列出来，输出几百行很正常。存成文件的好处是，万一 apply 之后 inventory 被写坏，你手里还有一份原始清单可以比对。

3.3 JAVA_HOME 是 Windows 上特有的干扰项

Windows 版 OPatch 内部会调 Java，opatch.bat里通常写死用%ORACLE_HOME%\jdk\bin\java.exe或者%ORACLE_HOME%\oui\jre。但如果系统里装过别的 JDK，并且JAVA_HOME、PATH被改过，个别版本的 OPatch 会优先用外部 Java，然后报类版本不兼容。

:: 如果 opatch 报 UnsupportedClassVersionError 之类，先清掉外部 JAVA_HOME 再试 set JAVA_HOME= opatch version

这条不能根治所有情况，但能排掉一大半“莫名其妙”的启动失败。如果清掉JAVA_HOME之后还报，就去%ORACLE_HOME%\OPatch下看opatch.bat里JAVA_HOME被写成了什么，再决定要不要临时改。

3.4 OPatch 换完之后的三项复查

第一项，inventory 还认这个 home。opatch lsinventory的输出里，Oracle Home那一行必须是你刚换过 OPatch 的那个路径，不能是别的。

第二项，没有异常告警。输出里不该出现There is no inventory、Oracle Home is not registered这类话。出现了就说明第 3.2 步的目录层级或者备份还原有问题。

第三项，opatch prereq能跑。随便找个补丁目录试一下：

:: 拿补丁目录做一次空跑，确认 OPatch 能读出补丁元数据 cd /d D:\patch\35099667 opatch prereq CheckPatchSpace -ph ./

这一条只需要看它有没有报“无法解析补丁”，能正常输出检查结果就说明 OPatch 和补丁包的对接没问题。真正的预检放在下一章做。

4. apply 实操：p35099667 打进去的完整命令序列

前面都是铺垫，这一章是真正动刀的地方。命令本身很短，但每一条之前要知道它在检查什么，出错时才知道往哪看。

4.1 三项预检：先问清楚再动手

cd /d D:\patch\35099667 :: 1) 补丁自身需要的磁盘空间够不够 opatch prereq CheckPatchSpace -ph ./ :: 2) 这个补丁和当前 ORACLE_HOME 里已装补丁有没有冲突 opatch prereq CheckConflictAgainstOHWithDetail -ph ./ :: 3) 系统级临时空间够不够 opatch prereq CheckSystemSpace -ph ./

-ph ./是指“补丁目录就是当前目录”，这个点是相对路径，必须在补丁根目录下执行。三条命令的通过标志都是Prereq "..." passed.，任何一条出现failed就先停手。

CheckPatchSpace查的是补丁解压和写入 ORACLE_HOME 需要的空间，它只看补丁这一侧，不看你系统盘还剩多少——所以第 2 章那次fsutil不能省。

CheckConflictAgainstOHWithDetail是三项里最重要的一条。它会把补丁里的组件版本和 inventory 里记录的已装补丁做比对，输出里如果出现Conflicts with the patch或Please rollback the patch之类的提示，说明当前 home 上已经装了版本不兼容的补丁，硬打会把库打到无法启动的状态。

CheckSystemSpace查的是系统临时目录。Windows 上%TEMP%经常在 C 盘，如果 C 盘只剩几百 MB，这一项会直接失败，但很多人以为是补丁问题。

4.2 opatch apply：交互与静默两种走法

:: 确认当前窗口的 ORACLE_HOME 就是目标 home echo %ORACLE_HOME% :: 进补丁目录，正式打 cd /d D:\patch\35099667 opatch apply

执行后会先打印补丁元数据，然后停在：

Do you want to proceed? [y|n]

输入y回车。后面还会问一次是否确认更新 inventory，同样y。整个过程大概几分钟，中间会打印大量Copying file和Patching file的行。

如果要把这一步写进自动化脚本，用静默模式：

:: -silent 只输出结果不打印进度，适合批处理 :: -local 只处理本机节点，单机环境加上更稳 :: echo y 把确认喂进去，避免卡在交互提示 echo y | opatch apply -silent -local

-local在单机环境里其实可以不写，但在装了 Grid 或者多个 home 的机器上，它能防止 OPatch 去动别的节点。-silent的代价是失败时只给错误码和简短描述，中间过程全丢，所以第一次打建议用交互模式，看清每一步。

关于-invPtrLoc：这个参数指向oraInst.loc文件，一般不需要手动加。只有在 OPatch 报“找不到 inventory 位置”的时候，才需要显式指定一个指向%ORACLE_HOME%\inventory的oraInst.loc。

跑到最后，成功标志只有一行：

OPatch succeeded.

出现这一行之前，任何一个OPatch failed with error code都不能算成功，哪怕它后面还跟了一句OPatch succeeded。

4.3 打完立刻做的两件事：起库、看 inventory

:: 起服务 net start OracleServiceORCL lsnrctl start :: 起库 sqlplus / as sysdba SQL> startup SQL> select version, dbtimezone from v$timezone_file; SQL> exit

v$timezone_file的version应该是 41。这里有个高频误判：补丁装完、实例还没重启的时候，查v$timezone_file看到的还是内存里加载的旧版本号，很多人据此断定“补丁没生效”，然后反复重装。这个视图读的是实例加载的时区文件映射，必须以重启后的结果为准。

再确认 inventory：

cd /d %ORACLE_HOME%\OPatch opatch lsinventory -detail | findstr /C:"35099667" /C:"TZ41"

能匹配到补丁号和描述行，说明 inventory 已经更新。如果这里查不到，但OPatch succeeded打印过，那就回到第 5 章看“半装状态”那一条。

4.4 DBMS_DST：什么时候必须走，怎么走

补丁换掉的是时区定义文件，但库里历史存下来的TIMESTAMP WITH TIME ZONE列是按旧规则算出来的。DBMS_DST就是重算这些列的包。走不走它，取决于库里有没有这类数据。

先检查：

-- 扫全库，列出所有受时区变更影响的列 @?/rdbms/admin/utltzuv2.sql

这个脚本会输出一段结果，如果有受影响的列，会按 schema、表名、列名列出来。没有输出受影响列，DBMS_DST就可以跳过，补丁到此为止。

如果有，分两步走，第一步是演练：

-- 准备阶段：只做模拟，不改真实数据 exec DBMS_DST.BEGIN_PREPARE(41); -- 看演练过程中有没有报错的表 select * from sys.dst$error_table; -- 演练结束，清掉临时状态 exec DBMS_DST.END_PREPARE;

BEGIN_PREPARE里的 41 就是 TZ 版本号，必须和v$timezone_file.version对得上。演练阶段会走一遍全部受影响列的转换逻辑，但把结果丢弃，目的是提前暴露数据类型不兼容、约束冲突这类问题。

演练没问题，再进正式升级：

-- 正式升级：这一步会锁表，务必放在维护窗口里 exec DBMS_DST.BEGIN_UPGRADE(41); -- 升级过程中查进度 select * from sys.dst$upgrade_status; -- 全部完成后收尾 exec DBMS_DST.END_UPGRADE(41);

BEGIN_UPGRADE和END_UPGRADE之间不能有任何 DDL，应用也要停掉。这一步在多租户环境下要格外注意：utltzuv2.sql在 CDB 根上跑一次，然后每个 PDB 都要单独进去跑一次，DBMS_DST的升级也是按容器分别执行的。只在根容器上跑完就以为万事大吉，是 19c 上很典型的一个疏漏。

5. 避坑与排查：TZ41 在 Windows 上最常翻车的五个地方

这一章的五条，是我自己踩过或者在别人机器上见过的。每条按“现象、原因、解决”写，照着对号入座就行。

5.1 apply 秒退：目录层级和 home 指针

现象：opatch apply敲下去立刻返回，报Patch is not a valid patch或者No patch to apply。

原因：传进去的目录不是补丁根目录。最常见的是解压时多套了一层，变成D:\patch\35099667\35099667\README.txt。第二种是当前目录不在补丁根下，-ph ./解析到了一个空目录。

解决：dir /b D:\patch\35099667必须能直接列出README.txt。如果是套娃结构，把里层目录的内容整体上提一层，或者干脆重新解压到D:\patch下。

现象：opatch lsinventory输出的Oracle Home不是你要打补丁的那个路径。

原因：机器上有多个 ORACLE_HOME，当前 cmd 窗口继承的环境变量被别的软件改过，或者你是从某个 Oracle 自带的快捷方式里打开的窗口。

解决：新开一个管理员 cmd，手动set ORACLE_HOME=C:\app\...\dbhome_1，再cd /d %ORACLE_HOME%\OPatch执行。不要在旧窗口里“将就一下”，环境变量这种东西将就一次就要多花两小时。

5.2 文件被占用：进程没停干净

现象：apply 跑到一半报Unable to remove file、Permission denied，或者干脆OPatch failed with error code 73。

原因：Windows 上oracle.exe在不重启的情况下不会释放某些 dll；杀毒软件实时扫描会锁住刚写入的文件；Windows Search 索引服务也会插一脚。

解决：先按顺序停干净，再查残留。

tasklist | findstr /I "oracle tnslsnr" net stop OracleServiceORCL net stop OracleTNSListener

如果tasklist还有oracle.exe，说明有实例没关干净——回sqlplus里确认是不是还有别的 SID 在跑。确认全部关掉后还有残留，才用taskkill /F /IM oracle.exe。这个命令是猛药，用之前一定确认库已经正常关闭，否则下次起库要走实例恢复。

杀毒软件这一侧，常见的做法是把%ORACLE_HOME%和补丁目录临时加进排除列表，打完再拿掉。

5.3 半装状态：inventory 里有，功能不生效

现象：opatch lsinventory能看到 35099667，但v$timezone_file还是旧版本号。

原因：三种可能。一是数据库没做完整重启，实例还加载着旧映射；二是你连的是另一个实例，补丁打在 A 库上，验证在 B 库上做；三是补丁只打在了一个 home 上，机器上还有第二个 19c home 没打。

解决：先shutdown immediate，再net stop，再net start，最后startup，顺序不能省。然后用select instance_name from v$instance确认实例名，用select value from v$parameter where name='db_unique_name'确认库身份。多 home 机器上，opatch lsinventory要在每个 home 里各跑一次。

5.4 时区数据没迁：utltzuv2 的输出被忽略

现象：补丁装完，版本号也对，但业务侧跨时区的时间戳开始差一小时，而且只在历史数据上差，新写入的正常。

原因：只换了时区文件，历史TIMESTAMP WITH TIME ZONE数据没走DBMS_DST迁移。新数据按新规则解释，老数据还停在旧规则上。

解决：回去跑@?/rdbms/admin/utltzuv2.sql，按输出决定是否执行第 4.4 节的BEGIN_PREPARE和BEGIN_UPGRADE。这一步要在维护窗口做，因为升级过程会锁表。

5.5 回退失败：inventory 对不上

现象：opatch rollback -id 35099667报补丁不存在，或者报Cannot rollback patch。

原因：inventory 被后续操作改过，或者补丁在同一个 home 上被重复 apply 过，回滚脚本覆盖了原始记录。也可能是当初换 OPatch 时把 inventory 一起弄丢了。

解决：用第 2.3 节备份的OPatch目录和inventory整体还原，再走数据库备份恢复。这也是为什么备份那一步要用xcopy /E /I /H /Y——少一个/H，隐藏的 XML 没备份到，回滚时就只能干瞪眼。

6. 装完怎么验证：三层检查把 TZ41 钉死

补丁装完不等于装对。我一般分三层验：OPatch 层看记录，数据库层看版本，数据层看有没有漏迁的列。

:: 第一层：补丁记录。能看到补丁号和 TZ41 描述才算装上 cd /d %ORACLE_HOME%\OPatch opatch lsinventory -detail | findstr /C:"35099667" /C:"TZ41"

-- 第二层：数据库运行时版本。必须是重启之后查 select version, dbtimezone from v$timezone_file; -- 补丁动作记录，确认 apply 的时间和状态 select patch_id, action, status, action_time from dba_registry_sqlpatch where patch_id = 35099667;

-- 第三层：数据层。没有输出受影响列，或者输出后已走完 DBMS_DST @?/rdbms/admin/utltzuv2.sql

三层的通过标准整理成一张表，方便照着核：

还有一项容易被跳过的验证：拿一条带TIMESTAMP WITH TIME ZONE的业务 SQL 手工跑一次，比对返回值在打补丁前后是否一致。如果这条 SQL 的结果变了，说明有数据被迁移了，得回头确认这是预期行为还是漏配了什么。

回退预案也要在打补丁当天就准备好，不要等出事了才想：

:: 回退单 <p> <a href="https://download.csdn.net/download/u012944313/88926428" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>