简介本资源面向Oracle数据库管理员与运维工程师用于将数据库时区版本升级至最新版本通常需配合官方时区补丁使用。压缩包内共4个SQL脚本文件整体约16KB包含升级前检查与升级执行两类核心脚本另附时区数据统计相关脚本脚本内已写明使用说明按先检查后应用的顺序执行即可完成时区版本调整。该方案经实际环境验证有效可帮助读者规避时区版本不一致引发的数据比对与时间戳异常问题快速完成升级前的兼容性核查与升级后的结果确认。目前已有1693人学习下载适合需要处理Oracle时区升级、排查时区相关故障的DBA参考使用。1. 数据库时区调整这件事为什么总在版本升级时集中爆发每年春秋两季夏令时切换前后总有一批系统在凌晨告警时间戳对不上、定时任务提前或延后一小时、跨库 JOIN 出来的时间字段差了几个钟头。表面看是应用层的问题追下去十有八九落在数据库时区数据没跟上。Oracle 数据库把时区定义和夏令时规则存在一组内部表里随数据库版本发布时固化一旦某个国家调整了夏令时起止规则旧版本数据库里的规则就过期了。DBMS_DST 这套脚本就是干这个的把数据库内部的时区数据从旧版本升到新版本让 TIMESTAMP WITH TIME ZONE 类型的数据在运算、比较、转换时拿到正确的偏移量。它适合谁适合手里维护着 Oracle 数据库、又碰上过时区相关故障的 DBA 和运维工程师。标题里的 V1.9 是脚本包的一个迭代版本核心动作是调用 DBMS_DST 包完成时区文件升级不是改操作系统时区也不是改数据库启动参数这一点先分清楚后面才不会走弯路。2. DBMS_DST 脚本到底改了什么从时区文件到内部表的链路2.1 时区数据在 Oracle 里存在哪几个地方Oracle 的时区信息不是单一文件而是分几层存放。最底层是服务器上的时区文件通常位于$ORACLE_HOME/oracore/zoneinfo目录下文件名类似timezlrg_xx.dat和timezone_xx.dat其中 xx 是时区文件版本号。数据库启动时会读取这些文件把内容加载进一组以TZ_开头的内部表比如V$TIMEZONE_NAMES、V$TIMEZONE_FILE。应用层看到的TIMESTAMP WITH TIME ZONE数据在存储和计算时依赖的就是这组内部表里的规则。所以升级时区本质上是两步先把新的时区文件放到服务器上再通过 DBMS_DST 包把内部表刷新到新版本。只换文件不刷内部表数据库仍然按旧规则算只刷内部表不换文件下次重启又回退。两者必须配套。2.2 DBMS_DST 包提供的几个关键过程DBMS_DST 包对外暴露的过程不多但每个都有明确分工。DBMS_DST.BEGIN_PREPARE和DBMS_DST.END_PREPARE用来做升级前的准备和收尾主要动作是清理上一次可能残留的中间状态。DBMS_DST.BEGIN_UPGRADE启动正式升级它会把内部表标记为待升级并记录当前版本。DBMS_DST.UPGRADE_DATABASE是真正执行数据转换的过程它会扫描所有含时区列的表把旧规则下的数据按新规则重新计算。DBMS_DST.END_UPGRADE结束升级并提交。还有一个DBMS_DST.FIND_AFFECTED_TABLES用来提前找出哪些表有时区列、哪些行会受影响。这几个过程的调用顺序不能乱乱了轻则升级不完整重则内部表状态不一致后续查询报错。2.3 升级前必须确认的三个版本号动手之前先查三个版本号它们决定了你该用哪个时区文件、脚本能不能直接跑。第一个是数据库版本用SELECT * FROM V$VERSION看它决定 DBMS_DST 包的行为差异。第二个是当前时区文件版本用SELECT * FROM V$TIMEZONE_FILE看输出里有一列 VERSION比如 14、18、32 这种数字。第三个是脚本包自带的时区文件版本解压 V1.9 压缩包后在 zoneinfo 目录下看文件名里的数字。目标是把第二个数字升到第三个数字。如果当前版本已经等于或高于脚本包版本就不用升硬升反而可能因为文件不匹配导致内部表加载失败。-- 查数据库版本 SELECT * FROM V$VERSION; -- 查当前时区文件版本 SELECT * FROM V$TIMEZONE_FILE; -- 查当前会话时区设置确认不是会话级临时改动 SELECT SESSIONTIMEZONE, DBTIMEZONE FROM DUAL;上面三条查询里第一条确认数据库大版本第二条拿到当前时区文件版本号第三条排除会话时区干扰。注意DBTIMEZONE和数据库时区文件版本是两回事前者是数据库默认时区偏移后者是规则库版本不要混。2.4 用 FIND_AFFECTED_TABLES 摸清影响面正式升级前跑一次影响面排查心里有数再动手。DBMS_DST 提供了一个查询接口可以列出所有含时区列的表以及受影响的列名。-- 创建用于存放影响面结果的表脚本包里通常已带建表语句 -- 这里演示手动创建 CREATE TABLE dst_affected_tables ( owner VARCHAR2(30), table_name VARCHAR2(30), column_name VARCHAR2(30), row_count NUMBER ); -- 调用 FIND_AFFECTED_TABLES把结果插入临时表 BEGIN DBMS_DST.FIND_AFFECTED_TABLES( affected_tables DST_AFFECTED_TABLES, log_errors TRUE, log_errors_table DST_ERROR_LOG ); END; / -- 查看结果 SELECT * FROM dst_affected_tables ORDER BY row_count DESC;这段代码的逻辑是先建一张结果表再调用FIND_AFFECTED_TABLES把扫描结果写进去最后按行数排序查看。参数affected_tables指定结果表名log_errors打开错误记录log_errors_table指定错误日志表。跑完之后重点看 row_count 大的表这些表在正式升级时耗时最长需要预留足够窗口。如果某张表行数上亿建议先评估是否能在业务低峰期完成或者考虑分批处理。3. 按步骤跑通一次时区升级从解压到验证的完整命令3.1 环境准备与脚本包解压拿到 V1.9 压缩包后不要直接在数据库服务器上解压到任意目录。常见做法是先在测试环境验证确认脚本包里的时区文件版本和数据库版本匹配。解压后目录结构一般包含 zoneinfo 子目录、若干 SQL 脚本和一个 README。zoneinfo 里放的是新时区文件SQL 脚本负责调用 DBMS_DST 包。把 zoneinfo 下的文件复制到$ORACLE_HOME/oracore/zoneinfo注意备份原文件万一升级失败可以回退。# 备份原时区文件 cd $ORACLE_HOME/oracore/zoneinfo mkdir -p backup_$(date %Y%m%d) cp timezlrg_*.dat timezone_*.dat backup_$(date %Y%m%d)/ # 解压脚本包到临时目录 mkdir -p /tmp/dst_v19 unzip DBMS_DST_scriptsV1.9.zip -d /tmp/dst_v19 # 查看解压后的时区文件版本 ls -l /tmp/dst_v19/zoneinfo/ # 复制新时区文件到 ORACLE_HOME cp /tmp/dst_v19/zoneinfo/timezlrg_*.dat $ORACLE_HOME/oracore/zoneinfo/ cp /tmp/dst_v19/zoneinfo/timezone_*.dat $ORACLE_HOME/oracore/zoneinfo/这段命令的关键点备份用日期命名方便回退时定位解压到 /tmp 而不是直接覆盖留出检查窗口复制前先ls确认文件名和版本号。注意复制时如果目标目录已有同名文件会被覆盖所以备份步骤不能省。复制完成后数据库实例需要重启才能读取新文件但重启前先别急下一步还要做内部表准备。3.2 调用 BEGIN_PREPARE 与 BEGIN_UPGRADE重启实例后以 SYSDBA 身份连接依次调用准备和启动升级过程。这两个过程本身很快但会锁定一些内部资源建议在无业务连接时执行。-- 以 SYSDBA 连接 CONNECT / AS SYSDBA; -- 开始准备清理残留状态 BEGIN DBMS_DST.BEGIN_PREPARE(1); END; / -- 查看准备状态确认没有错误 SELECT * FROM DBA_DST_STMT_FAIL; -- 启动升级 BEGIN DBMS_DST.BEGIN_UPGRADE(1); END; / -- 确认升级已启动 SELECT * FROM DBA_DST_STMT_FAIL;BEGIN_PREPARE的参数 1 表示准备阶段编号通常用 1 即可。执行后查DBA_DST_STMT_FAIL如果没有返回行说明准备干净。BEGIN_UPGRADE同样传 1它会把内部表标记为升级中。这一步之后数据库对时区数据的读写会走特殊路径所以不要在此时跑大批量时区相关查询。如果DBA_DST_STMT_FAIL有记录先按错误信息处理不要强行继续。3.3 执行 UPGRADE_DATABASE 并观察进度这是整个流程里最耗时的一步。UPGRADE_DATABASE会遍历所有含时区列的表逐行重新计算。执行前先确认数据库处于归档模式还是非归档模式归档模式下会产生大量归档日志提前检查归档空间。-- 执行升级parallel 参数根据 CPU 核数调整 BEGIN DBMS_DST.UPGRADE_DATABASE( parallel 4, log_errors TRUE, log_errors_table DST_ERROR_LOG ); END; / -- 另开会话观察进度 SELECT COUNT(*) FROM DST_ERROR_LOG; -- 查看当前升级状态 SELECT * FROM DBA_DST_STMT_FAIL;parallel参数控制并行度一般设为 CPU 核数的一半到三分之二设太高会争抢资源设太低耗时拉长。log_errors打开后出错的行会写入DST_ERROR_LOG升级结束后重点看这张表。如果错误行数很少可以单独处理如果大量报错说明时区文件版本和数据库版本不匹配需要回退重来。执行期间不要中断会话中断可能导致内部表状态卡在中间态。3.4 END_UPGRADE 与升级后验证升级完成后调用END_UPGRADE提交并清理中间状态然后做几项验证。-- 结束升级 BEGIN DBMS_DST.END_UPGRADE(1); END; / -- 验证时区文件版本已更新 SELECT * FROM V$TIMEZONE_FILE; -- 抽查一张受影响表的时区列 SELECT column_name, data_type FROM user_tab_columns WHERE table_name YOUR_TABLE AND data_type LIKE %TIME ZONE%; -- 对比升级前后同一行的时间偏移 SELECT id, tz_col, TZ_OFFSET(SESSIONTIMEZONE) FROM your_table WHERE id 1;END_UPGRADE之后V$TIMEZONE_FILE里的 VERSION 应该变成新版本号。抽查表结构确认时区列还在再取一行数据看偏移量是否符合预期。如果业务侧有对时间敏感的任务升级后跑一次全量校验对比关键时间字段的差异。验证通过后把备份的旧时区文件保留至少一个版本周期别急着删。4. 避坑指南时区升级里最容易翻车的五个点4.1 只换文件不刷内部表查询结果依旧按旧规则现象把新时区文件复制到$ORACLE_HOME/oracore/zoneinfo并重启实例后查V$TIMEZONE_FILE发现版本号没变时区转换结果和升级前一样。原因数据库启动时虽然读了新文件但内部TZ_表没有刷新DBMS_DST 的升级过程没执行。解决按第 3 章顺序完整跑一遍BEGIN_PREPARE到END_UPGRADE只换文件不够。4.2 升级窗口选在业务高峰锁等待拖垮应用现象UPGRADE_DATABASE执行期间应用侧大量查询超时报 ORA-00054 资源忙。原因升级过程会对含时区列的表加锁并行度设得高时锁范围更大。解决把升级安排在业务低峰期parallel参数调低到 2 或 1提前用FIND_AFFECTED_TABLES找出大表必要时对大表单独安排窗口。4.3 归档空间不足导致升级中断现象升级跑到一半报 ORA-00257 归档错误会话中断DBA_DST_STMT_FAIL出现记录。原因UPGRADE_DATABASE产生大量重做和归档日志归档目录写满。解决升级前检查V$RECOVERY_FILE_DEST和归档目录剩余空间估算受影响表的总行数预留至少两倍空间。中断后不要直接重跑先按错误日志清理中间状态再重新BEGIN_PREPARE。4.4 时区文件版本高于数据库支持范围现象复制新时区文件后数据库启动报错或BEGIN_UPGRADE直接失败。原因脚本包里的时区文件版本可能高于当前数据库大版本所能识别的上限。解决查数据库版本文档确认支持的时区文件版本范围如果脚本包版本过高换用匹配版本的脚本包不要强行升级。4.5 升级后没做数据校验业务侧时间偏差延迟暴露现象升级完成当天没事几天后定时任务执行时间偏移一小时或报表跨天数据对不上。原因升级只保证规则库更新应用层如果缓存了旧偏移量或硬编码了时区不会自动跟着变。解决升级后跑一次关键业务的时间字段校验对比升级前后同一批数据的偏移量通知应用侧清理时区缓存检查定时任务配置。5. 把时区升级做成可重复执行的检查清单时区升级不是一次性动作每年夏令时规则都可能变把它做成可重复执行的清单下次再遇到就不用从头摸。我自己的习惯是维护一张检查表每次升级前逐项打勾升级后归档记录。检查项命令或动作通过标准数据库版本确认SELECT * FROM V$VERSION记录大版本号当前时区文件版本SELECT * FROM V$TIMEZONE_FILE记录 VERSION 值脚本包版本匹配查看 zoneinfo 文件名不高于数据库支持上限影响面排查FIND_AFFECTED_TABLES大表行数已知归档空间检查SELECT * FROM V$RECOVERY_FILE_DEST剩余空间大于预估两倍备份原时区文件cp到 backup 目录文件可读升级窗口确认业务低峰期无大批量时区查询升级后版本验证SELECT * FROM V$TIMEZONE_FILEVERSION 已更新数据抽查取关键表时区列对比偏移量符合预期应用侧通知清理缓存、检查定时任务确认无硬编码时区这张表里最容易被忽略的是最后两项。很多 DBA 升级完数据库就收工结果应用侧缓存没清问题延迟几天才暴露排查起来更费劲。另一个技巧是升级前把V$TIMEZONE_FILE和DBA_DST_STMT_FAIL的查询结果存成文本升级后对比一眼能看出状态变化。如果升级失败需要回退把备份的时区文件复制回去重启实例再跑一次BEGIN_PREPARE清理中间状态数据库就回到升级前。回退不丢人硬扛着不处理才容易出大事。希望帮到你。本文还有配套的精品资源点击获取