简介：这份资源是面向Oracle数据库管理员与运维工程师的时区版本升级脚本包，用于将Oracle数据库的时区版本调整至最新，通常需配合官方时区补丁一起使用，适合需要处理时区数据、排查时区相关异常的中高级DBA参考。压缩包内共4个SQL脚本，整体约16KB，均为可直接执行的脚本文件，其中包含升级前的检查脚本与升级应用脚本，并附有使用说明，按先检查、后应用的顺序执行即可完成时区版本调整。目前已有1693人学习下载，说明该方案在实际运维场景中具备一定参考价值。脚本对执行顺序与前置条件有明确提示，能帮助读者快速判断当前时区版本状态、评估升级影响并落地调整操作，减少因时区不一致引发的数据统计与时间显示问题，是一份轻量且实用的Oracle时区维护工具集。

1. 一次时区升级引发的数据库启动故障，让我重新认识了 DBMS_DST

去年帮一个做跨境业务的朋友处理过一次数据库故障，至今印象深刻。他们的 Oracle 数据库跑在海外机房的 Linux 服务器上，某天操作系统时区从夏令时切回标准时，数据库里的 TIMESTAMP WITH TIME ZONE 字段集体偏移了一小时，报表数据全乱。更麻烦的是，他们之前手动改过数据库时区文件，结果STARTUP时直接报 ORA-01804，数据库起不来。后来翻出这套 DBMS_DST_scriptsV1.9.zip 脚本包，才把时区版本一步步升上去、把数据修正回来。这套脚本本质上是 Oracle 官方 DBMS_DST 包的一层封装，把原本需要手工拼 SQL 的时区升级流程做成了可重复执行的脚本集。它适合两类人：一是正在做 Oracle 数据库跨时区迁移的 DBA，二是遇到时区文件版本落后、需要升级 DST 版本才能打补丁的运维。如果你只是本地开发库，时区问题基本不会找上门；但只要涉及跨国业务、跨时区数据同步，这套东西迟早要用。

2. 环境准备：Oracle 版本、权限与脚本包结构核对

2.1 先确认数据库版本和当前 DST 版本

DBMS_DST 这个包从 Oracle 10g 就存在，但不同版本的行为差异很大。10g 时代它只能查不能升，11g 开始支持完整的升级流程，12c 之后又加入了PREPARE_DST_UPGRADE等新过程。所以第一步不是急着解压脚本，而是先连上数据库把底细摸清楚。

-- 查看数据库版本，决定后续用哪套升级路径 SELECT version FROM v$instance; -- 查看当前数据库时区文件版本 SELECT * FROM v$timezone_file; -- 查看当前 DST 版本号，这个数字是后续所有操作的基准 SELECT DBMS_DST.GET_DST_UPGRADE_INFO FROM dual;

v$timezone_file返回的version字段就是当前时区文件版本，比如 14、18、26 这些数字。DBMS_DST.GET_DST_UPGRADE_INFO在 11g 之后才可用，返回的是当前 DST 版本和可升级到的目标版本。我一般会先把这两个值记下来，后面每一步操作都要对照，避免升到一半发现版本对不上。

2.2 权限和表空间检查

DBMS_DST 的执行需要EXECUTE权限，通常授予 DBA 角色。但脚本包里有些步骤会创建临时表、写入日志表，所以还需要CREATE TABLE和CREATE PROCEDURE权限。如果是生产库，建议单独建一个升级用户，不要直接用 SYS。

-- 创建专用升级用户（如果还没有） CREATE USER dst_upgrade IDENTIFIED BY "临时密码"; GRANT DBA TO dst_upgrade; GRANT EXECUTE ON DBMS_DST TO dst_upgrade; -- 检查 SYSTEM 表空间剩余空间，升级过程会写入日志 SELECT tablespace_name, bytes/1024/1024 AS free_mb FROM dba_free_space WHERE tablespace_name = 'SYSTEM';

常见做法是给 SYSTEM 表空间留至少 500MB 空闲，因为DBMS_DST在升级时会往SYS.DST$系列表里写大量记录。如果空间不够，升级到一半报 ORA-01653 会很麻烦。另外，如果数据库开了归档，最好在升级前做一次全备，这是后悔药。

2.3 脚本包解压与目录结构

DBMS_DST_scriptsV1.9.zip 解压后一般包含这几个部分：sql/目录下是核心脚本，log/是日志输出目录，README或changelog说明版本差异。我拿到包之后习惯先看 changelog，确认 1.9 相比 1.8 改了什么——通常是小版本修复了某些版本下的兼容问题。

# 解压到指定目录，不要放在 /tmp 下，重启会丢 unzip DBMS_DST_scriptsV1.9.zip -d /opt/oracle/dst_upgrade/ # 查看目录结构 ls -l /opt/oracle/dst_upgrade/ # 典型输出：sql/ log/ README.md changelog.txt # 给脚本执行用户赋权 chown -R oracle:oinstall /opt/oracle/dst_upgrade/ chmod -R 750 /opt/oracle/dst_upgrade/

脚本包里的 SQL 文件通常按执行顺序编号，比如01_check_env.sql、02_prepare_upgrade.sql、03_upgrade_dst.sql、04_verify.sql。不要跳步执行，也不要把多个脚本合并成一个跑，中间任何一步出错都需要停下来看日志。

3. 安装与配置：从检查到升级的完整命令链

3.1 执行环境检查脚本

脚本包里的第一个文件一般是环境检查，它会调用DBMS_DST的几个查询过程，把当前状态输出到日志。这一步不修改任何数据，可以放心跑。

-- 01_check_env.sql 的核心内容，手工执行也类似 SET SERVEROUTPUT ON DECLARE l_dst_version NUMBER; BEGIN -- 获取当前 DST 版本 SELECT DBMS_DST.GET_DST_UPGRADE_INFO INTO l_dst_version FROM dual; DBMS_OUTPUT.PUT_LINE('当前 DST 版本: ' || l_dst_version); -- 检查是否有未完成的升级 FOR r IN (SELECT * FROM sys.dst$upgrade_state) LOOP DBMS_OUTPUT.PUT_LINE('发现未完成升级记录: ' || r.state); END LOOP; END; /

GET_DST_UPGRADE_INFO返回的是当前数据库能识别的最新 DST 版本，如果这个值小于v$timezone_file里的版本，说明时区文件比数据库内核新，需要升级数据库补丁而不是跑这个脚本。sys.dst$upgrade_state是 DBMS_DST 的内部状态表，如果里面有残留记录，说明上次升级没走完，必须先清理再重跑。

3.2 准备阶段：PREPARE_DST_UPGRADE

准备阶段做两件事：一是把受时区影响的数据找出来，二是创建升级所需的临时表。这一步会锁部分表，建议在业务低峰期执行。

-- 02_prepare_upgrade.sql 核心逻辑 BEGIN -- 准备升级，指定目标 DST 版本 DBMS_DST.PREPARE_DST_UPGRADE( target_version => 32, -- 目标版本号，根据脚本包说明填写 error_on_overlap => TRUE -- 遇到重叠时间报错而非静默处理 ); END; / -- 查看准备阶段发现的受影响表 SELECT * FROM sys.dst$affected_tables; SELECT * FROM sys.dst$error_table;

target_version这个参数不能乱填，必须和脚本包 changelog 里标注的版本一致。error_on_overlap设为 TRUE 时，如果某条数据在时区切换时落在重叠区间，会直接报错并记录到dst$error_table，而不是自动选一个时间。我一般会先设 TRUE 跑一遍，把有问题的数据挑出来人工确认，再设 FALSE 重跑。dst$affected_tables里列出的是所有含 TIMESTAMP WITH TIME ZONE 字段的表，升级前最好对这些表做一次逻辑备份。

3.3 执行升级：UPGRADE_DST

这是核心步骤，会实际修改数据库的时区元数据。执行时间取决于受影响表的数量和大小，小库几分钟，大库可能几小时。

-- 03_upgrade_dst.sql 核心调用 BEGIN DBMS_DST.UPGRADE_DST( error_on_overlap => FALSE, -- 准备阶段已处理过重叠，这里放行 parallel_degree => 4 -- 并行度，根据 CPU 核数调整 ); END; / -- 升级过程中查看进度 SELECT * FROM sys.dst$upgrade_state;

parallel_degree默认是 1，如果服务器 CPU 核多、IO 跟得上，可以调到 4 或 8 加速。但不要超过 CPU 核数的一半，否则并行争抢反而变慢。dst$upgrade_state里的state字段会从PREPARE变成UPGRADE再变成DONE，如果卡在某个状态超过预期时间，先查v$session看有没有阻塞。

3.4 收尾：PURGE_DST_UPGRADE 和验证

升级完成后必须执行清理，否则残留的临时表会占用空间，而且下次升级会报状态冲突。

-- 04_verify.sql 里的清理和验证 BEGIN DBMS_DST.PURGE_DST_UPGRADE; -- 清理升级临时数据 END; / -- 验证升级结果 SELECT * FROM v$timezone_file; -- version 应该变成目标版本 SELECT DBMS_DST.GET_DST_UPGRADE_INFO FROM dual; -- 应返回新版本号 -- 抽查一张受影响表的数据 SELECT COUNT(*) FROM 业务表 WHERE 时区字段 IS NOT NULL;

PURGE_DST_UPGRADE会删除sys.dst$系列表里的临时记录，但不会动业务数据。验证时除了看版本号，一定要抽查几张核心业务表，确认时区字段的值没有异常偏移。我遇到过升级后版本号对了、但某张历史表的时区字段全部变成 NULL 的情况，原因是那张表在准备阶段被标记为受影响，但升级时因为权限问题跳过了。

4. 避坑与排查：时区升级中最容易翻车的五个点

4.1 ORA-01804：时区文件版本不匹配

现象：执行PREPARE_DST_UPGRADE时报 ORA-01804，提示 timezone file version mismatch。

原因：数据库内核的 DST 版本和v$timezone_file里的版本不一致，通常是之前手动替换过时区文件，或者打了不匹配的补丁。

解决：先查SELECT * FROM v$timezone_file;和SELECT DBMS_DST.GET_DST_UPGRADE_INFO FROM dual;，如果前者大于后者，说明时区文件太新，需要升级数据库补丁而不是跑脚本；如果前者小于后者，直接跑脚本升级即可。不要试图手工改v$timezone_file，那是只读视图。

4.2 升级卡在 PREPARE 状态超过两小时

现象：sys.dst$upgrade_state里 state 一直是 PREPARE，v$session显示会话在等待。

原因：准备阶段会扫描所有含时区字段的表，如果某张大表没有索引或者统计信息过期，扫描会非常慢。另一个常见原因是表被其他会话锁住。

解决：先查SELECT * FROM v$lock WHERE type = 'TM';看有没有阻塞。如果有，杀掉阻塞会话或等它结束。如果是扫描慢，可以中断升级（DBMS_DST.ABORT_DST_UPGRADE），先收集相关表的统计信息，再重跑。中断后必须执行PURGE_DST_UPGRADE清理状态，否则下次跑会报错。

4.3 升级后业务数据时间偏移

现象：版本号升级成功，但查询业务表发现时间字段比实际时间多或少了几小时。

原因：准备阶段error_on_overlap设了 FALSE，导致重叠区间的数据被自动选了一个时间，而这个选择不符合业务预期。或者数据库的TIME_ZONE参数在升级前后发生了变化。

解决：升级前一定要用error_on_overlap => TRUE跑一遍准备阶段，把dst$error_table里的数据导出来人工确认。升级后如果发现偏移，不要急着改数据，先用SELECT TZ_OFFSET('时区名') FROM dual;确认数据库当前时区偏移，再对照业务预期判断是数据问题还是时区参数问题。

4.4 脚本包版本与数据库版本不兼容

现象：执行脚本时报 PLS-00306 或 ORA-06550，提示参数数量或类型不对。

原因：DBMS_DST_scriptsV1.9 里的某些脚本调用了新版本才有的过程参数，而目标数据库是 11g 早期版本，不支持这些参数。

解决：看脚本包 changelog 里标注的最低数据库版本要求。如果数据库版本低于要求，要么升级数据库，要么找旧版脚本包。不要试图注释掉报错的参数，那样可能导致升级逻辑不完整。

4.5 升级后无法回退

现象：升级完成后发现业务异常，想回退到旧版本，发现没有回退脚本。

原因：DBMS_DST 的升级是单向的，PURGE_DST_UPGRADE之后旧版本的元数据就被清理了，没有官方的回退过程。

解决：唯一的后悔药是升级前的全备。我一般会在升级前做两件事：一是RMAN全备，二是把sys.dst$系列表导出成平面文件。如果升级后出问题，只能从备份恢复，没有捷径。所以生产库升级前必须确认备份可用，并且预留足够的回退窗口。

5. 装完怎么验证：三个必须跑一遍的检查

升级做完不等于万事大吉，我习惯用下面三个检查确认环境真的跑通了。第一个是版本一致性检查，第二个是数据抽样比对，第三个是模拟时区切换。

-- 检查一：版本一致性 SELECT '时区文件版本' AS item, version AS value FROM v$timezone_file UNION ALL SELECT 'DST升级信息', TO_CHAR(DBMS_DST.GET_DST_UPGRADE_INFO) FROM dual; -- 检查二：受影响表数据抽样 SELECT COUNT(*) AS total_rows, COUNT(时区字段) AS non_null_rows, MIN(时区字段) AS min_time, MAX(时区字段) AS max_time FROM 核心业务表; -- 检查三：模拟时区切换，确认无报错 ALTER SESSION SET TIME_ZONE = 'America/New_York'; SELECT SYSTIMESTAMP FROM dual; ALTER SESSION SET TIME_ZONE = 'Asia/Shanghai'; SELECT SYSTIMESTAMP FROM dual;

检查一里两个值必须一致，如果v$timezone_file的 version 是 32，GET_DST_UPGRADE_INFO返回的也应该是 32。检查二重点看non_null_rows是否等于total_rows，如果有 NULL 说明升级过程中有数据丢失。检查三切换两个时区，如果SYSTIMESTAMP返回正常且偏移正确，说明时区元数据已经生效。

下面这张表是我整理的不同 Oracle 版本对应的 DST 版本参考，实际以脚本包 changelog 为准：

最后说一个我自己的习惯：每次跑完 DBMS_DST 升级，我都会把v$timezone_file、dst$upgrade_state和抽样查询的结果一起存到一个文本文件里，命名带上日期和版本号。这样下次再升级时，能直接对比上次的状态，不用凭记忆猜。时区这东西平时不声不响，一出问题就是全局性的，多留一份记录不亏。希望帮到你。

本文还有配套的精品资源，点击获取