企业官网建设流程全解析

简介：面向 Oracle 数据库管理员与运维工程师，内容聚焦 19c 时区版本由 32 升级至 42 的操作，并针对数据泵（Data Pump）导入过程中 TSTZ（带时区时间戳）报错给出排查思路与处理建议。压缩包共 10 个文件，以 dat 数据文件为主，配合 xml 配置文件与 txt 说明文档，便于核对升级所需的时区数据与参数设置，整体仅 377KB，结构轻量。目前已有 1372 人学习下载，适合正在规划或执行 Oracle 时区升级，以及遭遇跨时区数据迁移报错的人员参考。通过梳理时区版本差异、TSTZ 字段兼容性问题和数据泵参数调整方法，读者能快速定位报错原因，并在升级前后做好数据备份与验证测试。

1. 时区版本不一致：TSTZ数据半路翻车的真实原因

一次数据库迁移任务里，expdp 导出只跑了几十分钟，impdp 导入却在大表上报出 ORA-01882：timezone region not found，任务直接挂起。排查到最后，根子是 oracle19c 升级时区版本 32->42 这件事没做——源库数据里的 TSTZ 字段带着新的时区规则，目标库时区文件还停在 32，解析不了。这不是数据坏，也不是字符集问题，是时区版本错位。

接下来的内容把时区版本升级和数据泵 TSTZ 报错串成一条线：判断版本差、跑标准脚本升到 42、回 expdp/impdp 验证，再列几个生产环境的坑。适合正在做 19c 迁移、备库恢复或数据泵导入的 DBA 和数据工程师；如果 impdp 正卡在时区相关报错上，可以直接对标定位。

2. 动手前先诊断：两张视图加一条 SQL，把时区问题从黑匣子里拉出来

2.1 时区版本到底在管什么：TSTZ 数据为什么认版本

时区问题在我早期是个黑匣子：报错来得莫名其妙，查 nls_lang、查 session_time_zone 都解决不了。后来把原理补上才明白，TSTZ 字段存储的不只是时间的数字部分，还带时区区域名（比如某个城市的 IANA name）或者与 UTC 的偏移量。Oracle 把区域名到偏移量的换算规则放在一个可升级的时区文件里，文件版本决定了数据库对全球各地区历史规则的认识。

时区版本号从 32 到 42，跨度很大。每升一个版本，文件里都会多出若干条全球规则调整，比如某地区在某年改变了标准偏移、取消或恢复了夏令时。旧版本文件没有这些规则，读取数据时算出来的偏移就会差一小时，或者更干脆，连区域名都识别不了，直接报错。这类问题只影响 TIMESTAMP WITH TIME ZONE 和 TIMESTAMP WITH LOCAL TIME ZONE 两种类型的数据，普通 DATE、TIMESTAMP 不受影响，所以平时系统没有感知，一到数据迁移时集中爆发。

实际工作中的判断逻辑很简单：如果源库处于 32，目标库也停在 32，而导出的数据里恰好带有目标库不认识的新区域 ID，impdp 就会报错。这种错和数据库版本高低、字符集、坏块都没关系，就是时区文件层面的知识缺口。理解这一点后，我不会再靠玄学去猜，而是直接把两边版本拉出来对比。

2.2 三件套查询：确认源库/目标库版本与受影响对象

在升任何东西之前，先回答三个问题：当前版本是多少？数据库软件支持升到多少？全库有哪些对象在用 TSTZ？用下面这段 SQL 一次性查完：

-- 当前数据库时区文件版本，version 就是你要看的数字 SELECT version, version_time FROM v$timezone_file; -- 数据库软件支持的时区版本上限，19c 打完时区补丁后一般是 42 SELECT DBMS_DST.GET_LATEST_TIMEZONE_VERSION() AS latest_tz_version FROM DUAL; -- 找出所有带 TSTZ 类型的表列，确认影响面 SELECT owner, table_name, column_name, data_type FROM dba_tab_cols WHERE data_type IN ('TIMESTAMP WITH TIME ZONE', 'TIMESTAMP WITH LOCAL TIME ZONE') ORDER BY owner, table_name;

第一条v$timezone_file查的是当前数据库正在使用的时区文件版本，version_time是文件的生成时间，可以辅助判断它到底新到什么程度。第二条用DBMS_DST.GET_LATEST_TIMEZONE_VERSION()查软件内置的最新版本号。19c 在补丁到位的情况下返回 42；如果返回值低于 42，说明时区补丁还没装上，光跑升级脚本是升不到 42 的，得先补系统补丁。第三条从dba_tab_cols查出所有 TSTZ 类型列，包含 owner、table_name、column_name 和 data_type，定位影响面。

执行上述 SQL 需要一定权限，v$timezone_file所有用户都能查，dba_tab_cols需要 dba 或 select any dictionary 权限。如果你手上只有业务账号，换成all_tab_cols并把 owner 条件限制为自己的 schema 即可。

三条结果合在一起看，升级的必要性就清楚了：如果第三条返回 0 行，说明没有 TSTZ 数据，那么 impdp 报错大概率与时区版本无关，不用走升级路径，这是最干净的边界判断。如果返回大量行，路径就很明确：升级时区版本再导数据。我还会顺手统计一下每条 TSTZ 列的数据量，用来预估升级脚本要处理多久：

SELECT owner, table_name, column_name, num_distinct, num_nulls FROM dba_tab_cols WHERE data_type IN ('TIMESTAMP WITH TIME ZONE', 'TIMESTAMP WITH LOCAL TIME ZONE') ORDER BY table_name;

num_distinct和num_nulls来自统计信息，能大概看出这张表的 TSTZ 列有多少不同值、有多少空值。空值多的表升级时基本可以秒过，分布广的表才是耗时大头。这个预估不是精确的，但足够你在变更窗口里判断“今晚能不能跑完”。

2.3 版本不匹配时数据泵会报什么错：别误判成坏块

升级前最好知道“不升级会发生什么”，避免报错来了到处瞎猜。我遇到过的现场是：源库 11.2 时区版本 32，目标库 19c 初始版本也是 32，表面看版本一致，但源库数据里带了一个新区域名，目标库不认识。impdp 跑了两小时，到某张带 TSTZ 列的大表时日志里冒出ORA-01882: timezone region not found。

这个错误从字面看更像数据损坏，容易被带偏去查坏块、查字符集。但它的真实含义是：数据里的区域名在目标库时区文件里查不到。处理方向只有两个：要么把目标库时区版本升上去，要么改数据。前者是根治，后者只适合应急。另外要提醒一句，impdp 日志里经常先出现包裹错误 ORA-39112，再两层之后才看到具体的 ORA-01882，不要看到第一行错误就下结论，往日志后面翻一翻 cause 部分，真正的根因信息更多时候埋在底部。

区分 TSTZ 报错和普通数据错误有个土办法：单独导一张只含主键和 TSTZ 列的小表，如果 impdp 依旧报同样的错误，而普通类型的小表能正常过，那就锁定到时区版本问题。这个测试成本很低，能省去一大圈查数据库日志的时间。

3. 升级 32->42：OLTRUP_TZ 脚本完整流程与多租户细节

3.1 前置准备：受限模式、检查残留会话、备份你的后悔药

时区版本升级不是改一个初始化参数就完事，它要重建全库所有 TSTZ 数据，属于数据库结构级的变更，必须用 Oracle 自带的标准脚本oltrup_tz.sql，位置在$ORACLE_HOME/rdbms/admin/下面。动手之前三步准备，一步都不能省。

第一步做一次完整备份。时区版本升级是单向的：文件一旦改成 42，同一套环境里不会再保留 32 的旧文件，想回退只能靠备份恢复。我在生产环境一律用 RMAN 全库一致性备份，如果你那边是虚拟化或云环境，底层快照也可以，前提是快照覆盖范围包含所有数据文件和控制文件。也有团队用可传输表空间做备份，但时区升级涉及全库 TSTZ 数据，物理备份最省心。

第二步把数据库切到受限模式。TSTZ 数据重建期间不允许业务会话写入，命令如下：

sqlplus / as sysdba ALTER SYSTEM ENABLE RESTRICTED SESSION; SELECT count(*) FROM v$session WHERE username IS NOT NULL;

ALTER SYSTEM ENABLE RESTRICTED SESSION拦住新连接，但已有会话和连接池残留不会自动断开。查v$session后把非系统会话逐一 kill。生产环境最容易在这个环节翻车：你以为受限了，其实连接池里一堆旧会话还挂着，升级跑一半被新写入打扰。

第三步确认没有活动事务和定时任务：

SELECT count(*) FROM v$transaction; SELECT job, what FROM dba_jobs_running;

v$transaction返回 0 表示没有活动事务。dba_jobs_running查老式 DBMS_JOB；如果用的是 DBMS_SCHEDULER，换成DBA_SCHEDULER_RUNNING_JOBS再查一次。定时任务如果在升级期间触发 TSTZ 写入，会造成重建数据不完整，必须提前停。

3.2 执行升级脚本：@$ORACLE_HOME/rdbms/admin/oltrup_tz.sql

脚本执行本身不复杂，核心命令就一条：

cd $ORACLE_HOME/rdbms/admin sqlplus / as sysdba SQL> @oltrup_tz.sql

脚本跑起来后会先输出一段说明文字，然后提示输入目标时区版本号，输入42回车。接着它会做一致性检查，再输出一个预估时间。我在模拟项目X 上跑的时候，预估时间是“大约 1 天”，这里的一天指的是脚本全量处理 TSTZ 数据所需时长，不是让你坐等一天。预估时间跟你 2.2 节查到的 TSTZ 数据量直接相关，数据分布越广耗时越长。

脚本内部调用DBMS_DST包的升级流程：先BEGIN_UPGRADE把时区文件切成 42，再逐表扫描重写 TSTZ 数据。这个过程中数据库保持 open，但只能有系统后台进程在运行。如果升级期间有新用户连接进来，查询就可能访问到新旧混合状态的时区文件，典型表现就是 ORA-01882 或 ORA-30089 随机出现，这时候不要怀疑脚本坏了，先回去查会话。

第一次跑完后，脚本会提示需要重启数据库。按它的要求执行SHUTDOWN IMMEDIATE再STARTUP，然后第二次执行同一个脚本。第二次的目的不是重建数据，而是处理元数据并把时区版本最终锁定。注意两次提示不一样：第一次输入 42 后出现预估时间，第二次很快结束，这是正常的。如果你把第二次跑成第一次的输出，说明数据库没重启成功。

3.3 升级完成后的验证与多租户扩展

收尾用一条 SQL 确认版本：

SELECT version, version_time FROM v$timezone_file;

返回 version 是 42，主库升级就完成了。但如果你用的是 19c 多租户架构，别在这里停下。CDB 环境里时区文件本体挂在 CDB 根，但每个 PDB 都有独立的 TSTZ 数据，需要单独执行同样流程。我在一个带三个 PDB 的客户现场就吃过亏：CDB 根升到 42，切进 PDB 一查还是 32，数据泵导入照样报错。

正确做法是 CDB 根跑完并重启验证后，逐个 PDB 连接进去，重复oltrup_tz.sql的两次执行。为避免遗漏我一般写成循环：

for pdb in pdb1 pdb2 pdb3; do sqlplus / as sysdba <<EOF ALTER SESSION SET CONTAINER=$pdb; @$ORACLE_HOME/rdbms/admin/oltrup_tz.sql EOF done

这个循环脚本有个前提：PDB 名称必须提前核对，CONTAINER切换后当前目录下的脚本相对路径会变化，所以@后面必须写绝对路径。生产环境我更倾向挨个 PDB 手工执行，循环适合已经确认全部 PDB 名、且升级窗口足够宽松的情况。每次执行完，都要在对应 PDB 里用v$timezone_file验证一次，不要攒到最后一起查。

4. 数据泵 TSTZ 报错治理：升级后导出导入的完整操作顺序

4.1 从报错日志定位：alert.log 与 impdp 日志里的关键词

数据泵报错的定位，比直接看 impdp 过程输出要深一层。我按三步走：

第一步看 impdp 自己的日志。TSTZ 报错通常留下ORA-01882或ORA-30089之类关键词，但 impdp 经常把它裹进 ORA-39112 这类包裹错误里，日志正文看不到具体字样。所以第二步去看实例 alert 日志：

grep -E "ORA-0188|ORA-3008|timezone" \ $ORACLE_BASE/diag/rdbms/*/*/trace/alert_*.log | tail -50

这一步往往能把错误产生的源头抓出来，有时能直接看到表名和操作类型。第三步做小范围测试：把源库目标表和 TSTZ 列单独导一次，看问题是不是只在特定数据行出现。这能帮你判断升级是否彻底生效，还是只改了文件版本、数据重建没做干净。

还有一个定位技巧：如果 impdp 日志里先出现 ORA-39112，不要停在第一层错误上，继续往日志下方翻，找到“cause”相关的行，真正的时区错误通常在那里。我见过有人拿着 ORA-39112 去查表空间和 SEGMENT 参数，绕了一天，其实第二层就是时区版本问题。

4.2 expdp/impdp 参数与一个顺手的测试表样例

升级完成后，数据泵命令本身不需要新增参数，但我在正式导全量之前，会用一张带 TSTZ 列的小表跑端到端测试：

expdp system/oracle@source_db \ directory=DATA_PUMP_DIR \ dumpfile=test_tstz.dmp \ tables=APP_USER.MSG_LOG \ content=data_only \ logfile=test_exp.log impdp system/oracle@target_db \ directory=DATA_PUMP_DIR \ dumpfile=test_tstz.dmp \ tables=APP_USER.MSG_LOG \ content=data_only \ table_exists_action=replace \ logfile=test_imp.log

content=data_only只导数据，推快点；table_exists_action=replace保证重复测试时重建表结构，不会因已存在而中止。这里要说明一个常见误解：expdp的VERSION参数控制导出文件格式版本，不是时区文件版本。源库 11.2、目标库 19c，导出时加不加VERSION=19.1都不决定 TSTZ 能否导入成功；真正决定它的是目标库时区文件能否解析数据里所有区域名。所以升级时区版本是前置条件，不是数据泵参数能替代的。

如果手头没有现成的小表，就造一张。造数时故意用一个不那么常见的时区区域名，比如某个小城市的 IANA name，这样能测出目标库时区版本的覆盖度。只造北京时间或者 UTC 测不出什么，因为所有版本都认识它们。

测试数据导入通过后，再回头调正式的导出参数。我一般会给正式 impdp 命令加上EXCLUDE=STATISTICS和REUSE_DUMPFILES=Y，前者避免导入时重算统计信息浪费时间，后者方便同一文件名反复重跑，省得清理历史文件。这两个参数和 TSTZ 无关，但能避免测试阶段常见的重复导入报错。

4.3 实在不能升级时的过渡方案：时间字段中转（不推荐长期）

有一种情况需要绕过而不是根治：目标库因为补丁、架构或者变更窗口限制，暂时升不了时区文件。这时候如果数据泵任务不能停，我一般做中间层转换——把 TSTZ 列在导出前转成 VARCHAR2 字符串，导入后再还原成 TSTZ。实际操作不是一条 ALTER 就能改列类型，要分三步：新增一个 VARCHAR2 临时列，用 UPDATE 把 TSTZ 内容转成带偏移的字符串，然后删掉旧列、把临时列改回 TSTZ。核心转换语句是：

-- 先加临时列 ALTER TABLE app_user.msg_log ADD ( create_tstz_tmp VARCHAR2(40) ); -- 核心转换语句：把 TSTZ 写成带时区偏移的字符串 UPDATE app_user.msg_log SET create_tstz_tmp = TO_CHAR(create_tstz, 'YYYY-MM-DD HH24:MI:SS.FF TZH:TZM'); -- 删除旧列并重命名（实际执行前记得确认无依赖） ALTER TABLE app_user.msg_log DROP COLUMN create_tstz; ALTER TABLE app_user.msg_log RENAME COLUMN create_tstz_tmp TO create_tstz;

目标导入端反向做一遍：先建 VARCHAR2 接收，再TO_TIMESTAMP_TZ(create_tstz_tmp, 'YYYY-MM-DD HH24:MI:SS.FF TZH:TZM')回到 TSTZ。这个方案有三个硬伤：一是某些时区区域名带夏令时语义，转成偏移量后冬季和夏季的偏移值不同，但区域名可能会被业务代码用来判断具体城市规则，信息有损；二是数据量一大，全表 UPDATE 和后续校验占用资源很高；三是无法应对存储过程里直接用 TSTZ 做计算的部分。所以只适合临时救火，长期必须回到时区升级。

实践中有个简单判断标准：拿一张真实业务表，把 TSTZ 列放到 VARCHAR2 再还原，对比还原后的值和原值是否完全一致。存在偏差就说明中转方案对该表不可行，必须升级时区版本。这个验证成本低，值得在写应急预案时提前做一次。

5. 升级与迁移常见问题：四条踩坑记录（现象->原因->解决）

5.1 受限模式被新连接绕过，升级跑到一半不消停

现象：oltrup_tz.sql 跑起来后，日志里持续刷出 ORA-01882，查 v$session 发现不断有新的 JDBC 连接进来，升级时间比预估长了一倍不止。

原因：我只执行了ALTER SYSTEM ENABLE RESTRICTED SESSION，但连接池客户端在连接被拒后，会立刻换一个新连接重试。受限会话拦住的是新建立的会话，却没有阻止连接池反复试探和中间件的自动重连机制。

解决：这类全库数据重建操作之前，先停监听或把动态注册关掉，让外部连接根本没有机会到达实例。我们现场的做法是lsnrctl stop，保持数据库 open 受限状态跑脚本；脚本确认完成后，再启动监听。顺手把残留会话也清理干净：

-- 找出非后台会话，确认后 kill SELECT sid, serial#, username, program, event FROM v$session WHERE username IS NOT NULL AND type != 'BACKGROUND';

从那以后，凡是涉及全库数据重建，我都默认先停监听，再开受限模式。

5.2 备库时区版本没同步，redo apply 直接卡住

现象：主库升级成功后，备库 alert 日志出现时区解析类错误，MRP0 进程异常停止，数据保护状态进入降级模式，需要人工干预才能恢复同步。

原因：主库把 TSTZ 数据重写后，生成的 redo 里带了最新时区版本对应的规则变化。备库时区文件还是 32，apply 时解析不了这些新规则，直接中断。备库不会因为主库升级而自动升级自己的时区文件。

解决：主库执行升级动作之前，先把备库的补丁和时区文件装到同版本。这样主库 redo 里新版本规则过来时，备库能解析出来。如果备库已经中断，只能重建或通过快照恢复实例，再追应用归档。预防性检查很简单，直接在备库执行版本查询：

SELECT version, version_time FROM v$timezone_file;

这个坑我记到今天：升级任务写进变更单时，主备库同步更新必须列为一二两步，而不是可选项。

5.3 升级后应用会话继续报 ORA-01882

现象：数据库版本确认是 42，应用侧重启后还是报 ORA-01882，报错频率没降。

原因：连接池里存量的会话还持有旧时区版本的信息。数据库时区文件升级过程中，已建立会话的会话时区状态不会自动刷新。应用服务器一般不会主动断开旧连接，于是旧会话继续用坏状态执行 SQL。

解决：升级时区文件后必须让应用彻底断连。一种方式是ALTER SYSTEM KILL SESSION配合应用全量重启；另一种是调整连接池配置，把空闲连接回收时间缩短到分钟级，再触发一次应用重启。我在一个数据中台环境里用的方案是：升级窗口最后安排一次应用全量重启，同时把中间件连接池的 idleTimeout 从 30 分钟改到 5 分钟，效果立竿见影。

判断是不是连接池问题有个小技巧：直接用 SQLPlus 以业务账号连接数据库跑同一条查询，如果 SQLPlus 正常、应用报错，那问题基本锁定在应用侧连接池，不需要再折腾数据库。

5.4 多租户里只升了 CDB 根，PDB 里查还是 32

现象：CDB 根v$timezone_file显示 42，但切到某个 PDB 后版本还是 32，PDB 里跑 TSTZ 查询或导入任务依旧报错。

原因：时区文件本体是 CDB 级别，但每个 PDB 的 TSTZ 元数据需要单独完成升级。只升 CDB 根，相当于换了总水管，但每个房间里的末梢水管还残留旧水，不通一次，房间里的水还是旧的。

解决：按第 3.3 节的方式逐个 PDB 执行oltrup_tz.sql，首次执行、重启、二次执行一个都不能少。我习惯每升完一个 PDB 就查一次版本并记录，而不是全部跑完再一起查。先列出所有 PDB：

SELECT name, open_mode FROM v$pdbs ORDER BY name;

确认列表后逐个执行升级脚本。这样做的好处是出错能定位到是哪一个 PDB，不用回看脚本执行的中间状态。

6. 升级后的验证与回归：五分钟自检清单

6.1 五分钟自检：一张视图、两个查询、一次往返

升级完成不是终点，验证到位才算关单。我给自己定了一个五步自检，全程五分钟，可以直接贴到运维文档里：

-- 第 1 步：版本必须是 42 SELECT version, version_time FROM v$timezone_file; -- 第 2 步：所有 TSTZ 列仍然存在，类型没有被脚本改坏 SELECT count(*) AS tstz_col_count FROM dba_tab_cols WHERE data_type IN ('TIMESTAMP WITH TIME ZONE', 'TIMESTAMP WITH LOCAL TIME ZONE'); -- 第 3 步：随机抽一条带 TSTZ 的数据，做一次往返读 SELECT to_char(create_tstz, 'TZH:TZM') FROM app_user.msg_log WHERE ROWNUM = 1;

第 1 步没通过，说明升级没完成；第 2 步如果 count 比升级前少了，大概率是数据重建阶段有对象没有处理干净；第 3 步是为了确认区域名能正常解析。这里的关键点在于TZH:TZM只显示偏移量，不显示区域名，如果这块能拿到非空值，说明最底层的偏移计算链路是通的。

6.2 回归测试：用真实历史时间戳做一次换算对比

最后做一个回归：在升级前后各取同一批历史 TSTZ 数据的偏移量差值。数据库时区版本升级可能改变部分历史时刻的夏令时规则，如果你正好处理的是业务上的历史数据，这块跑偏是真实存在的。我在一个跨时区的订单系统上就遇到过：升级后某年 3 月的一个订单时间从+08:00变成了+09:00，事后排查确认是那个地区在当年春天取消了夏令时，旧文件按旧规则偏移，新文件按新规则修正。这类问题不会报错，但会静默影响统计报表。

我的做法是升级前跑一次SELECT to_char(ts, 'YYYY-MM-DD HH24:MI TZH:TZM') FROM t WHERE ...导出两份结果，升级后再跑一次，人工比对边界值。比对通过再收尾。从那以后我每次做时区升级或数据泵迁移，都强制走完这一整套：先查版本、再造数测试、再全量导入、最后回归边界。希望帮到你。

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