简介面向 Oracle 数据库管理员与运维工程师内容聚焦 19c 时区版本由 32 升级至 42 的操作并针对数据泵Data Pump导入过程中 TSTZ带时区时间戳报错给出排查思路与处理建议。压缩包共 10 个文件以 dat 数据文件为主配合 xml 配置文件与 txt 说明文档便于核对升级所需的时区数据与参数设置整体仅 377KB结构轻量。目前已有 1372 人学习下载适合正在规划或执行 Oracle 时区升级以及遭遇跨时区数据迁移报错的人员参考。通过梳理时区版本差异、TSTZ 字段兼容性问题和数据泵参数调整方法读者能快速定位报错原因并在升级前后做好数据备份与验证测试。1. 时区版本不一致TSTZ数据半路翻车的真实原因一次数据库迁移任务里expdp 导出只跑了几十分钟impdp 导入却在大表上报出 ORA-01882timezone 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而导出的数据里恰好带有目标库不认识的新区域 IDimpdp 就会报错。这种错和数据库版本高低、字符集、坏块都没关系就是时区文件层面的知识缺口。理解这一点后我不会再靠玄学去猜而是直接把两边版本拉出来对比。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-42OLTRUP_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/oraclesource_db \ directoryDATA_PUMP_DIR \ dumpfiletest_tstz.dmp \ tablesAPP_USER.MSG_LOG \ contentdata_only \ logfiletest_exp.log impdp system/oracletarget_db \ directoryDATA_PUMP_DIR \ dumpfiletest_tstz.dmp \ tablesAPP_USER.MSG_LOG \ contentdata_only \ table_exists_actionreplace \ logfiletest_imp.logcontentdata_only只导数据推快点table_exists_actionreplace保证重复测试时重建表结构不会因已存在而中止。这里要说明一个常见误解expdp的VERSION参数控制导出文件格式版本不是时区文件版本。源库 11.2、目标库 19c导出时加不加VERSION19.1都不决定 TSTZ 能否导入成功真正决定它的是目标库时区文件能否解析数据里所有区域名。所以升级时区版本是前置条件不是数据泵参数能替代的。如果手头没有现成的小表就造一张。造数时故意用一个不那么常见的时区区域名比如某个小城市的 IANA name这样能测出目标库时区版本的覆盖度。只造北京时间或者 UTC 测不出什么因为所有版本都认识它们。测试数据导入通过后再回头调正式的导出参数。我一般会给正式 impdp 命令加上EXCLUDESTATISTICS和REUSE_DUMPFILESY前者避免导入时重算统计信息浪费时间后者方便同一文件名反复重跑省得清理历史文件。这两个参数和 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 里带了最新时区版本对应的规则变化。备库时区文件还是 32apply 时解析不了这些新规则直接中断。备库不会因为主库升级而自动升级自己的时区文件。解决主库执行升级动作之前先把备库的补丁和时区文件装到同版本。这样主库 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 后版本还是 32PDB 里跑 TSTZ 查询或导入任务依旧报错。原因时区文件本体是 CDB 级别但每个 PDB 的 TSTZ 元数据需要单独完成升级。只升 CDB 根相当于换了总水管但每个房间里的末梢水管还残留旧水不通一次房间里的水还是旧的。解决按第 3.3 节的方式逐个 PDB 执行oltrup_tz.sql首次执行、重启、二次执行一个都不能少。我习惯每升完一个 PDB 就查一次版本并记录而不是全部跑完再一起查。先列出所有 PDBSELECT 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 ...导出两份结果升级后再跑一次人工比对边界值。比对通过再收尾。从那以后我每次做时区升级或数据泵迁移都强制走完这一整套先查版本、再造数测试、再全量导入、最后回归边界。希望帮到你。本文还有配套的精品资源点击获取