简介面向 Oracle 数据库运维、升级与迁移场景的时区版本调整脚本包适合需要处理数据库时区版本滞后、配合时区补丁完成版本更新的 DBA 与开发人员参考使用。压缩包共 4 个文件均为 SQL 脚本体积约 16KB整体轻量包含时区版本检查、应用调整及统计辅助等脚本便于在升级前核对环境、升级中执行调整并辅助观察结果。已有 1693 人学习下载说明其在 Oracle 时区维护场景中具有一定参考价值。脚本内附说明可帮助读者理解各脚本用途与执行顺序降低排查时区版本不一致问题时的试错成本对于需要快速定位时区版本状态、整理升级前后核对思路、补充时区补丁操作记录的读者可作为一份实用的辅助工具包也适合团队在变更前做脚本准备与风险核对。1. 时区版本不是改个参数DBMS_DST_scriptsV1.9 到底解决哪类升级窗口凌晨两点某公司的监控告警突然刷屏一批跨时区订单的创建时间整体偏了一小时。排查到最后不是应用代码也不是服务器时钟而是 Oracle 数据库的时区文件版本停在旧规则上。手头这个 DBMS_DST_scriptsV1.9.zip就是围绕 DBMS_DST 包整理的一套时区版本调整脚本把准备、检查、执行、验证和回退动作按阶段串起来减少手工拼命令的随机性。它适合两类人一类是正在做数据库时区升级、需要一份可照着走的操作骨架的 DBA另一类是应用侧用到了 TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE想搞清楚升级会动到哪些表和索引的后端工程师。它不能替代全库备份也不能把不可逆操作变成可逆操作但能把“先查什么、后跑什么、失败看哪里”固定下来。2. 先读懂 DBMS_DST 的版本链时区文件、数据库版本与脚本包 V1.9 的对应关系时区升级最容易翻车的地方不是 DBMS_DST 的过程名记不住而是把几个“版本”混成一锅粥。脚本包版本 V1.9、数据库时区文件版本、DBTIMEZONE、SESSIONTIMEZONE这四个东西名字里都带时区或版本实际含义完全不同。先把它们拆开后面每一条命令才知道自己在改什么、没改什么。2.1 时区文件版本和 DBTIMEZONE 不是一回事Oracle 数据库里有一份时区规则数据记录不同地区夏令时的起止规则、历史偏移和缩写。V$TIMEZONE_FILE里的VERSION就是这份规则数据的版本号DBMS_DST 升级的目标就是它。很多地区调整过夏令时规则旧版本时区文件对新规则的解释会出错典型表现是跨时区数据在某个日期之后整体偏移或者客户端连接时报时区区域找不到。DBTIMEZONE是数据库创建时设定的数据库时区常见为 UTC 或某个固定偏移。它决定数据库内部某些时间值的基准不是时区文件版本。SESSIONTIMEZONE是当前会话的时区TIMESTAMP WITH LOCAL TIME ZONE在查询显示时会受它影响。应用连上来看到的时间偏一小时可能是会话时区不一致也可能是时区文件版本旧两者排查方向完全不同。我一般会先把这三个值一起查出来钉在升级记录里后面应用说时间不对先对比升级前后的会话时区再怀疑 DBMS_DST。这个顺序能省掉很多玄学争论。-- 当前时区文件版本升级的目标就是让 VERSION 变成目标版本 SELECT filename, version FROM v$timezone_file; -- 数据库时区和当前会话时区这两个不是时区文件版本 SELECT dbtimezone, sessiontimezone FROM dual; -- 数据库版本和多租户信息CDB/PDB 环境要确认在哪个容器里执行 SELECT banner_full FROM v$version; SELECT name, cdb, con_id FROM v$database;代码里第一条查询是基线升级前后各跑一次版本号变化才算真正落地。第二条查询用来区分“库时区”和“会话时区”应用时间偏移时先看这里。第三条查询确认数据库大版本和容器信息CDB 环境里时区升级要在正确的容器中做PDB 级别操作和 CDB 级别操作边界不同别在错误的连接里执行脚本。提示V$TIMEZONE_FILE的VERSION才是时区文件版本不要拿脚本包版本 V1.9 去填DBMS_DST.BEGIN_PREPARE的参数。2.2 脚本包 V1.9 的适用边界与阶段划分DBMS_DST_scriptsV1.9.zip 从名字看是围绕 DBMS_DST 的脚本集合版本 V1.9 是脚本包自身的迭代号不是数据库时区版本号。它解决的是操作顺序和检查项固化的问题什么时候查受影响表、什么时候开始准备、什么时候执行升级、升级后验证哪些视图、失败时先看什么。它不解决备份空间不足、备库延迟、应用连接池时区配置这些环境问题。我一般把这类脚本包按阶段整理成五类只读检查、准备、执行、验证、回退。只读检查可以在生产库先跑不改数据准备段会创建 DBMS_DST 的辅助信息执行段才真正改时区数据和受影响表验证段确认版本号、索引、抽样数据回退段依赖备份、闪回或备库切换不是脚本包里一个rollback.sql就能兜住。阶段目标关键过程产出只读检查摸清影响面查版本、查 TSTZ 列、查大表影响表清单和窗口估算准备找受影响表BEGIN_PREPARE、FIND_AFFECTED_TABLES、END_PREPARE待升级表和行数执行升级时区数据BEGIN_UPGRADE、UPGRADE_DATABASE、END_UPGRADE时区文件版本变化验证确认可用性查版本、索引状态、抽样数据验证记录回退出问题时兜底还原点、备份恢复、备库切换回退预案适用边界要提前说清数据库里没有 TSTZ/TSTZLTZ 列应用也不依赖时区规则升级收益有限数据库里有大量 TSTZ 大表升级窗口要按行数和索引重建时间估算Data Guard 环境要把备库延迟和切换演练算进去。脚本包能帮你少打错命令不能替你判断“这个库该不该现在升”。2.3 升级前的四个基线查询把现状钉在纸上动手前先跑只读查询不要一上来就BEGIN_PREPARE。基线记录至少包括当前时区文件版本、数据库时区与会话时区、TSTZ/TSTZLTZ 列分布、数据库角色和备份状态。TSTZ 列分布决定升级要扫哪些表角色决定备库要不要单独排窗口备份状态决定有没有后悔药。下面这段查询把影响面先圈出来。生产库上DBA_TAB_COLUMNS可能很多按 owner 过滤先看业务用户不要全库一把抓。-- 1. 业务用户下所有带时区类型的列 SELECT owner, table_name, column_name, data_type FROM dba_tab_columns WHERE data_type IN (TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE) AND owner NOT IN (SYS, SYSTEM, SYSMAN, DBSNMP) ORDER BY owner, table_name, column_name; -- 2. 这些表的大致行数用来估算升级窗口 SELECT owner, table_name, num_rows, last_analyzed FROM dba_tables WHERE owner APP ORDER BY num_rows DESC NULLS LAST; -- 3. Data Guard 角色和备库延迟 SELECT database_role, open_mode, protection_mode FROM v$database; SELECT name, value FROM v$dataguard_stats WHERE name IN (transport lag, apply lag); -- 4. 闪回和归档状态决定能不能用还原点兜底 SELECT flashback_on FROM v$database; SELECT log_mode FROM v$database;第一条查询返回的列清单要留档升级后再查一次确认列没有变化。第二条按行数排序大表优先安排窗口分区表要单独看分区数量。第三条只在 Data Guard 环境有意义主库升级前确认备库延迟在可接受范围升级窗口内禁止切换。第四条确认闪回和归档状态闪回没开就不要指望CREATE RESTORE POINT能当后悔药。注意基线查询也要记录执行时间、执行人和连接的服务名。多租户环境里同一个脚本在 CDB 根容器和 PDB 里跑出来的结果可能不一样别把 PDB 的查询结果当成整个 CDB 的结论。3. 用 DBMS_DST 跑完一次时区升级准备、执行、验证三段式命令DBMS_DST 的流程看起来只有几个过程真正难的是顺序和状态。准备段没结束就进执行段或者执行段中断后直接重跑BEGIN_UPGRADE都可能把数据库卡在中间态。下面按“准备、执行、验证、回退”四段走每段只做一件事每段结束都有检查点。3.1 准备段BEGIN_PREPARE 与受影响表清单准备段的目标是让 DBMS_DST 扫描数据库找出受目标时区版本影响的表。BEGIN_PREPARE的参数是目标时区版本号不是脚本包版本也不是数据库版本。示例里用 32 只是演示写法实际值以脚本包说明和V$TIMEZONE_FILE的目标版本为准不要照抄。-- 先确认没有残留的准备态或升级态具体视图以当前版本为准 SELECT * FROM dba_dst_upgrade_table; -- 开始准备参数填目标时区版本号示例 32 仅作演示 BEGIN DBMS_DST.BEGIN_PREPARE(32); END; / -- 找出受影响的表和列结果留档用来估算窗口 SELECT * FROM TABLE(DBMS_DST.FIND_AFFECTED_TABLES); -- 准备段结束清理准备状态 BEGIN DBMS_DST.END_PREPARE; END; /BEGIN_PREPARE会建立准备状态FIND_AFFECTED_TABLES只在准备状态下有意义查完必须END_PREPARE否则后续升级流程可能报状态冲突。FIND_AFFECTED_TABLES返回的表清单要按行数排序大表单独评估。准备段本身不改业务数据但会占用一些字典空间生产库上也要安排在低峰别在业务高峰跑全库扫描。提示准备段和执行段之间最好留一个检查点把受影响表清单、行数、索引清单发给应用负责人确认。应用说某张表不能停就在这个检查点提出来不要等执行段再回头。3.2 执行段BEGIN_UPGRADE 到 END_UPGRADE 的顺序执行段才真正改时区数据。BEGIN_UPGRADE的参数同样是目标时区版本号UPGRADE_DATABASE执行全库升级END_UPGRADE收尾。大库上UPGRADE_DATABASE可能跑很久脚本包如果提供分批或并行写法按它的说明来没有说明就用默认串行别自己加并行度。-- 升级前再确认一次版本和残留状态 SELECT filename, version FROM v$timezone_file; SELECT COUNT(*) FROM dba_dst_upgrade_table; -- 开始升级参数填目标时区版本号 BEGIN DBMS_DST.BEGIN_UPGRADE(32); END; / -- 执行全库升级大库按脚本包说明评估分批或并行 BEGIN DBMS_DST.UPGRADE_DATABASE; END; / -- 收尾释放升级状态 BEGIN DBMS_DST.END_UPGRADE; END; /这段代码的顺序不能换。BEGIN_UPGRADE之前如果还有准备态残留先清掉UPGRADE_DATABASE执行期间不要中断会话不要杀进程不要让连接池把会话踢掉。END_UPGRADE之后立刻查V$TIMEZONE_FILE版本号变成目标值才算执行段完成。如果UPGRADE_DATABASE报错中断不要直接重跑整段先看DBA_DST_UPGRADE_TABLE和告警日志确认是续跑还是恢复。过程参数作用注意BEGIN_PREPARE目标时区版本号进入准备态不是脚本包版本FIND_AFFECTED_TABLES无查受影响表只在准备态有效END_PREPARE无结束准备态查完就收BEGIN_UPGRADE目标时区版本号进入升级态确认无残留准备态UPGRADE_DATABASE并行度按版本说明执行升级不要中途杀会话END_UPGRADE无结束升级态之后立刻验证版本3.3 验证段版本号、索引状态与 TSTZ 抽样验证段不要只看版本号。版本号变了只说明时区文件升级了不代表索引都有效、应用查询都正常。要查三样V$TIMEZONE_FILE版本、TSTZ 列上的索引状态、业务表抽样数据。索引状态重点看UNUSABLE大表升级后重建索引的时间要算进窗口。-- 1. 版本号应变成目标版本 SELECT filename, version FROM v$timezone_file; -- 2. 时区类型列上的索引状态 SELECT i.owner, i.index_name, i.table_name, i.status FROM dba_indexes i WHERE i.status VALID AND EXISTS ( SELECT 1 FROM dba_ind_columns c JOIN dba_tab_columns t ON t.owner c.table_owner AND t.table_name c.table_name AND t.column_name c.column_name WHERE c.index_owner i.owner AND c.index_name i.index_name AND t.data_type LIKE TIMESTAMP% ); -- 3. 抽样对比升级前后的同一行数据 SELECT id, created_tz, created_ltz FROM app_order WHERE id :id; -- 4. 升级残留表应为空或符合脚本包预期 SELECT COUNT(*) FROM dba_dst_upgrade_table;第一条确认版本落地。第二条只查时区类型列相关索引避免把普通索引也拉进来。第三条用升级前记录的主键抽样对比同一行在升级前后的显示值注意created_ltz受会话时区影响抽样时固定SESSIONTIMEZONE再比较。第四条确认没有残留待升级表如果还有记录按脚本包说明判断是正常残留还是中断。注意验证段的应用抽样要在应用连接池里跑不要只在自己的 sqlplus 会话里跑。连接池的会话时区、JDBC 参数、中间件时区配置都可能和应用真实查询不同。3.4 回退段备份、闪回与备库切换的边界时区升级不是普通 DML回退不能靠ROLLBACK。脚本包里的回退脚本多数是清理状态或反向执行部分检查不等于数据库级回退。真正兜底的是全库备份、闪回数据库、Data Guard 备库切换。升级前开闪回并建还原点是常见做法闪回没开或闪回区空间不够就不要把还原点当唯一方案。-- 升级前建还原点前提是闪回数据库已开启且闪回区空间足够 CREATE RESTORE POINT before_dst_upgrade GUARANTEE FLASHBACK DATABASE; -- 出问题时的闪回路径示意先关库到 mount再闪回再打开 SHUTDOWN IMMEDIATE; STARTUP MOUNT; FLASHBACK DATABASE TO RESTORE POINT before_dst_upgrade; ALTER DATABASE OPEN RESETLOGS;CREATE RESTORE POINT会占用闪回日志空间大库上要提前看闪回区使用率。FLASHBACK DATABASE会重置日志Data Guard 环境要按备库切换流程处理不能当单机库操作。没有闪回条件就老老实实做全库备份备份恢复时间要写进回退预案不要只写“有备份”。提示回退段最值得花时间的是演练不是写脚本。升级前在模拟项目X里走一遍备份恢复或闪回记录耗时和失败点比生产出事时翻文档有用。4. 避坑与排查时区升级里最容易翻车的五件事时区升级的坑很少集中在 DBMS_DST 过程本身更多在应用连接、索引状态、客户端时区文件、备库同步和中断处理。下面五条按“现象、原因、解决”写都是升级窗口里容易遇到的。每条先别急着改库先把现象和排查路径对齐。4.1 应用时间偏移一小时先查会话时区不要先怪 DBMS_DST现象升级完成后部分应用查询出来的时间比升级前偏一小时数据库里直接查同一行却是对的。原因通常不是时区文件没升级而是应用连接池的会话时区不一致或者TIMESTAMP WITH LOCAL TIME ZONE在显示时依赖会话时区应用侧 JDBC 参数、中间件时区、连接池初始化 SQL 各配了一套。解决顺序是先查应用连接里的SESSIONTIMEZONE再查数据库DBTIMEZONE最后才对比时区文件版本。-- 在应用连接池里执行不要在 DBA 自己的会话里执行 SELECT sessiontimezone, dbtimezone FROM dual; -- 查当前会话的时区偏移 SELECT TO_CHAR(SYSTIMESTAMP, YYYY-MM-DD HH24:MI:SS TZH:TZM) FROM dual;第一条返回应用会话的真实时区第二条看当前时间带时区显示。应用连接池如果返回00:00而业务期望08:00问题就在连接池或 JDBC 参数不在 DBMS_DST。不要用改DBTIMEZONE的方式掩盖问题库里有 TSTZ 数据时改数据库时区风险更高容易把排查方向带偏。4.2 TSTZ 索引变 UNUSABLE升级后必须扫一遍索引状态现象升级后某些跨时区订单查询突然走全表执行计划变差应用超时。原因可能是时区类型列上的索引在升级过程中变成UNUSABLE或者统计信息过期导致优化器选错路径。解决是先查索引状态再决定重建索引还是收集统计信息。不要一上来就ALTER INDEX REBUILD全库扫先按业务表定位。-- 查时区类型列相关索引的状态 SELECT i.owner, i.index_name, i.table_name, i.status FROM dba_indexes i WHERE i.status VALID ORDER BY i.owner, i.table_name; -- 确认某张业务表的索引和列 SELECT index_name, column_name, column_position FROM dba_ind_columns WHERE table_owner APP AND table_name APP_ORDER ORDER BY index_name, column_position; -- 单个索引重建生产上注意并行度和窗口 ALTER INDEX app.idx_app_order_tz REBUILD ONLINE;第一条先圈出非VALID的索引第二条确认索引列是不是时区类型第三条只重建确认受影响的索引。ONLINE减少锁影响但大表重建仍然吃资源窗口要留够。重建后重新收集统计信息别让优化器继续用旧统计。注意索引重建不是越多越好。普通索引状态正常就不要动先把时区类型列相关索引处理完再看执行计划是否恢复。4.3 ORA-01882 反复出现客户端时区文件与库端版本不一致现象升级后部分客户端连接报ORA-01882: timezone region not found或者应用里某个时区名称解析失败。原因常见于客户端时区文件版本旧、JDBC 驱动版本旧或者 SQL 里硬编码了库端不认识的时区区域名。解决是统一客户端时区文件版本升级驱动尽量避免在 SQL 里写死时区名称。-- 库端时区文件版本 SELECT filename, version FROM v$timezone_file; -- 查库里是否存在某个时区区域 SELECT tzname FROM v$timezone_names WHERE tzname Asia/Shanghai; -- 当前会话时区 SELECT sessiontimezone FROM dual;第一条记录库端版本第二条确认时区名称存在第三条看会话时区。客户端报错时先对比客户端时区文件版本和库端版本再看驱动是否支持当前库版本。应用 SQL 里如果硬编码了Asia/Shanghai这类区域名升级后客户端解析不了就会报 ORA-01882改成绑定变量或统一时区配置更稳。4.4 备库延迟与切换失败Data Guard 环境要单独排窗口现象主库升级后备库应用日志变慢或者切换演练时备库时区文件版本和主库不一致。原因可能是升级产生大量 redo备库应用能力跟不上或者升级窗口内做了切换但备库还没应用完。解决是升级前查备库延迟升级窗口内禁止切换升级后分别查主备的V$TIMEZONE_FILE。-- 主库和备库都执行确认角色和时区文件版本 SELECT database_role, open_mode FROM v$database; SELECT filename, version FROM v$timezone_file; -- 备库延迟 SELECT name, value FROM v$dataguard_stats WHERE name IN (transport lag, apply lag);第一条确认角色第二条确认版本第三条看延迟。主备版本不一致时不要做切换先把备库日志应用完。升级窗口内把 Data Guard 切换开关冻结升级完成并验证后再恢复。备库延迟高的环境升级窗口要按 redo 量和应用速度重新估算不要照搬单机库的时间。4.5 升级中断卡在中间态先看残留表再决定恢复还是续跑现象UPGRADE_DATABASE执行到一半会话断开或报错重跑脚本提示状态冲突数据库既不像升级前也不像升级后。原因在于 DBMS_DST 升级不是单事务中断后可能留下升级态和残留表。解决是先查DBA_DST_UPGRADE_TABLE和告警日志确认中断点再决定续跑还是恢复备份。不要盲目重跑BEGIN_UPGRADE。-- 查残留的待升级表 SELECT * FROM dba_dst_upgrade_table; -- 查当前时区文件版本判断升级是否已经部分生效 SELECT filename, version FROM v$timezone_file; -- 查最近告警日志位置去服务器上看对应时间段错误 SELECT value FROM v$diag_info WHERE name Diag Trace;第一条看残留表第二条看版本号第三条拿到告警日志目录。残留表很多且版本号没变说明升级没完成优先评估恢复版本号已变但残留表少量按脚本包说明判断能否续跑。无论哪种先把现场记录留全再动手。升级中断后的盲目重跑是时区升级里最贵的踩坑方式之一。5. 把时区升级做成可重复演练从只读检查到灰度发布的五个习惯时区升级真正值钱的部分不是把 DBMS_DST 过程跑通一次而是把它变成可重复演练的流程。我一般会先在生产库跑只读检查把受影响表、行数、索引清单导出来在模拟环境按同样顺序走一遍准备段和执行段记录每段耗时。演练时把UPGRADE_DATABASE的耗时、索引重建时间、应用抽样结果都记下来生产窗口按演练数据乘一个安全系数不要拍脑袋。验证脚本要固化不要每次临时想查询。下面这张检查表可以直接抄到升级记录里每项都有通过标准和失败动作。检查项通过标准失败动作时区文件版本等于目标版本查中断点不要重跑受影响表无残留或符合脚本预期查DBA_DST_UPGRADE_TABLE时区列索引状态为VALID单索引重建并收集统计应用抽样与升级前记录一致查会话时区和 JDBC 参数备库延迟在可接受范围冻结切换等日志应用完只读检查脚本可以单独放一份升级前跑升级后复跑。下面这段只读查询不改数据适合每次演练前先跑一遍。-- 只读检查版本、时区列、索引、残留表 SELECT filename, version FROM v$timezone_file; SELECT owner, table_name, column_name, data_type FROM dba_tab_columns WHERE data_type IN (TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE) AND owner NOT IN (SYS, SYSTEM, SYSMAN, DBSNMP) ORDER BY owner, table_name; SELECT owner, index_name, table_name, status FROM dba_indexes WHERE status VALID ORDER BY owner, table_name; SELECT COUNT(*) FROM dba_dst_upgrade_table;这段脚本适合放在升级窗口开头和结尾各跑一次输出留档。版本号对比看第一段时区列清单对比看第二段索引状态看第三段残留表看第四段。灰度发布时先选一个业务低峰的应用节点连到升级后的库跑抽样查询和关键业务接口确认会话时区、时间显示、索引执行计划都正常再逐步放量。血泪经验是不要把脚本包里的回退脚本当成数据库回退。时区升级的后悔药只有备份、闪回和备库切换脚本包能帮你把检查顺序固定下来不能替你承担备份责任。从那以后我每次做时区升级都强制先跑只读检查、再建还原点、最后才进准备段哪怕窗口很紧也不省这一步。希望帮到你。本文还有配套的精品资源点击获取
