数据泵导入报错 ORA-39405 提示时区要升级,怎么办?看这篇!

大家好,这里是公众号 DBA学习之路,分享一些学习国产数据库路上的知识和经验。

前言

最近遇到好几次数据泵导入报错 ORA-39405 的问题,需要升级时区,本文正好记录一下解决过程。

问题分析

两套 19C 数据库,补丁版本不一致,源端补丁版本高于目标端,需要将源端的用户数据导入到目标端数据库库,在导入的时候报错如下:

ORA-39405: Oracle Data Pump does not support importing from a source database with TSTZ version 42 into a target database with TSTZ version 32.

查看报错:

[oracle@orcl19c:/home/oracle]$ oerr ora 39405
39405, 00000, "Oracle Data Pump does not support importing from a source database with TSTZ version %s into a target database with TSTZ version %s."
// *Cause:    The source database was at a different time zone version than the
//            target database and there were tables that contained TIMESTAMP
//            WITH TIME ZONE (TSTZ) data.
// *Action:   Convert the target database to the same time zone version or
//            later as the source database or use Oracle Data Pump with
//            conventional data movement to export then import this data.

大致意思就是:

在使用 Oracle Data Pump 进行数据导入时,如果源数据库的时区版本(TSTZ版本)与目标数据库的时区版本不同,就会出现该错误,需要将目标数据库的时区版本更新为与源数据库相同或更高版本。

根据提示,我们需要将目标端数据库时区升级到 42,参考 MOS 文档:

需要安装补丁 Patch 35220732: RDBMS - DSTV42 UPDATE - TZDATA2023C

  1. Request (if needed) and download the 18.0/19.0 DSTv42 Patch 35220732
  2. Unzip the RDBMS DSTv42 Patch 35220732
  3. Apply the RDBMS DSTv42 Patch 35220732 using Opatch.

下载补丁后,根据 README 提示进行升级时区即可。

解决方案

安装时区补丁

安装补丁需要先关闭数据库:

SQL> shu immediate

安装补丁:

## 进入补丁目录
[oracle@orcl19c:/home/oracle]$ cd /home/oracle/35220732

## 安装前检查
[oracle@orcl19c:/home/oracle]$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
Oracle Interim Patch Installer version 12.2.0.1.17
Copyright (c) 2025, Oracle Corporation.  All rights reserved.

PREREQ session

Oracle Home       : /u01/app/oracle/product/19.0.0/db
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/19.0.0/db/oraInst.loc
OPatch version    : 12.2.0.1.17
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19.0.0/db/cfgtoollogs/opatch/opatch2025-02-20_17-23-05PM_1.log

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

## 安装补丁
[oracle@orcl19c 35220732]$ $ORACLE_HOME/OPatch/opatch apply
Oracle Interim Patch Installer version 12.2.0.1.17
Copyright (c) 2025, Oracle Corporation.  All rights reserved.

Oracle Home       : /u01/app/oracle/product/19.0.0/db
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/19.0.0/db/oraInst.loc
OPatch version    : 12.2.0.1.17
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19.0.0/db/cfgtoollogs/opatch/opatch2025-02-20_17-23-11PM_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   35220732  

Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Backing up files...
Applying interim patch '35220732' to OH '/u01/app/oracle/product/19.0.0/db'

Patching component oracle.oracore.rsf, 19.0.0.0.0...
Patch 35220732 successfully applied.
Log file location: /u01/app/oracle/product/19.0.0/db/cfgtoollogs/opatch/opatch2025-02-20_17-23-11PM_1.log

OPatch succeeded.

## 检查补丁是否安装完成
[oracle@orcl19c 35220732]$ $ORACLE_HOME/OPatch/opatch lspatches
35220732;RDBMS - DSTV42 UPDATE - TZDATA2023C
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
29517242;Database Release Update : 19.3.0.0.190416 (29517242)

OPatch succeeded.

安装完成后开启数据库:

SQL> startup

到这补丁安装就算完成了,接下来还需要执行时区升级。

升级时区

在 MOS 文档中看到升级时区有两种方式:

  1. using DBMS_DST package4.7.2 Upgrading the Time Zone Data Using the DBMS_DST Package
  2. using the utltz_* Scripts in the $ORACLE_HOME/rdbms/admin directory:4.7.1 Upgrading the Time Zone Data Using the utltz_* Scripts

这里官方建议使用第二种方式进行升级:

-- 运行 utltz_countstats.sql 显示所有包含 "TIMESTAMP WITH TIME ZONE" 类型的表的优化器统计信息,包括 num_rows(行数)。
SQL> @?/rdbms/admin/utltz_countstats.sql
-- 运行 utltz_countstar.sql 显示了所有包含 "TIMESTAMP WITH TIME ZONE" (TSTZ) 数据类型的表的 count(*) 操作结果。
SQL> @?/rdbms/admin/utltz_countstar.sql
-- 以上两个脚本只需要执行其中一个就行,具体根据统计信息的准确性来选择,第二种需要执行的时间可能较长。

-- dbms_scheduler 表通常包含大量的时区数据,如果不需要该表中的数据,可以在执行升级步骤之前使用以下命令删除它。在运行此命令之前,请停止主要作业,因为如果某些主作业仍在执行,则可能无法删除 dbms_scheduler 表中的所有数据。
SQL> exec dbms_scheduler.purge_log;

-- 其他可能包含大量时区数据的表包括 SYS.WRI$_OPTSTAT_HISTGRM_HISTORY 和 SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY 表。如果您不需要这些数据,可以使用以下命令删除它们:
SQL> select count(*) from SYS.WRI$_OPTSTAT_HISTGRM_HISTORY;
SQL> select count(*) from SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY;
SQL> select systimestamp - dbms_stats.get_stats_history_availability from dual;
SQL> exec dbms_stats.alter_stats_history_retention(0);
SQL> exec DBMS_STATS.PURGE_STATS(systimestamp);
SQL> select count(*) from SYS.WRI$_OPTSTAT_HISTGRM_HISTORY;
SQL> select count(*) from SYS.WRI$_OPTSTAT_HISTHEAD_HISTORY;

-- 等时区数据升级完成,可以使用以下命令将数据保留期限设置回其原始值:
SQL> exec dbms_stats.alter_stats_history_retention(31);

以上为升级时区前的一些准备工作,下面开始正式升级时区:

-- 升级时区
SQL> @?/rdbms/admin/utltz_upg_check.sql
SQL> @?/rdbms/admin/utltz_upg_check.sql
SQL> @?/rdbms/admin/utltz_upg_apply.sql

升级完成后,检查时区版本是否正确:

SQL> col property_name for a30
col value for a30
select property_name, substr(property_value, 1, 30) value
  from database_properties
 where property_name like 'DST_%'
 order by property_name;

PROPERTY_NAME                  VALUE
------------------------------ ------------------------------
DST_PRIMARY_TT_VERSION         42
DST_SECONDARY_TT_VERSION       0
DST_UPGRADE_STATE              NONE

可以看到时区已经升级到 42,再次使用数据泵导入数据成功。

写在最后

这里在延伸一下,从 RU 19.18 开始,时区补丁会跟随 RU 一起安装,但是不会自动更新数据库时区,需要人为执行升级,可参考 MOS:

所以,大家建议大家在安装 RU 19.18 之后的补丁,需要手工升级时区:

## 注意:rac 数据库需要先切换成单机模式进行升级
SQL> @?/rdbms/admin/utltz_upg_apply.sql

具体步骤可以参考 MOS 文档内容。

### 回答1: ORA-39083是Oracle数据库中的一个错误代码,表示数据泵导入操作失败。这个错误通常是由于导入的数据文件或目录不存在、权限不足、数据文件格式不正确或者数据库对象已经存在等原因引起的。要解决这个问题,可以尝试以下几种方法: 1. 检查导入的数据文件或目录是否存在,并且确保有足够的权限访问它们。 2. 检查导入的数据文件格式是否正确,例如是否与导出时使用的格式相同。 3. 如果导入的数据文件已经存在于目标数据库中,可以尝试使用IGNORE=Y参数来忽略已经存在的对象。 4. 如果导入的数据文件中包含了已经存在的对象,可以尝试使用REMAP_SCHEMA参数来重新映射这些对象到一个新的模式中。 5. 如果以上方法都无法解决问题,可以尝试使用TRACE=480300参数来启用详细的跟踪信息,以便更好地诊断问题。 ### 回答2: 在使用impdp进行数据导入时,可能会遇到ORA-39083错误。这个错误通常指的是一个对象导入失败了。 导致导入失败的原因可能包括以下几种: 1. 没有足够的权限:导入数据需要足够的权限,如果用户没有足够的权限,则会导致导入失败并出现ORA-39083错误。 2. 目标表已经存在并且没有被清空:如果导入的数据中的表已经存在,而且表中已经包含数据,则导入失败,并出现报错信息。 3. 导入的数据源文件不存在:如果指定的数据源文件不存在,则导入失败,并出现报错信息。 4. 导入的数据文件没有足够的空间:如果导入的数据文件没有足够的空间容纳导入的数据,则导入失败,并出现报错信息。 对于这些问题,可以根据具体的情况采取以下几种方法来解决: 1. 确保用户具有足够的权限:在进行导入数据之前需要确保用户具有足够的权限。如果没有足够的权限,需要联系管理员进行授权。 2. 清空目标表:在导入数据之前需要确保目标表已经被清空,如果表中已经包含数据,则需要进行清空。 3. 确认数据源文件存在并可用:在进行导入数据之前需要确认数据源文件存在并具有正确的权限设置。如果文件不存在或者权限设置不正确,则需要进行调整。 4. 确认数据文件具备足够的空间:在进行导入数据之前需要确保数据文件具有足够的空间容纳导入的数据。可以通过增加数据文件的大小或者增加磁盘空间来解决问题。 总的来说,ORA-39083错误是导入数据时经常会遇到的问题,可以通过一些基本的和常用的方法来解决。在出现错误时,需要对问题进行逐一排查,确定具体的原因,并选择相应的解决方法。如果遇到比较复杂的问题,则建议联系专业的技术支持人员进行帮助和解决。 ### 回答3: 对于 Oracle 数据库管理员来说,运用 impdp 工具来备份或迁移数据库是很常见的操作。然而,在实际应用中,也会经常面临 impdp 导入报错的情况,其中ORA-39083 错误是很常见的一种。下面我将针对该错误进行详细的解析与处理。 ORA-39083 错误的相关描述 在使用 impdp 工具时,若出现类似如下的错误提示ORA-39083: Object type TABLE failed to create with error: ORA-00959: tablespace 'XXX' does not exist 则说明此次导入失败。其中,ORA-39083 错误的提示信息包括了其失败的对象类型和错误原因等,其中的ORA-00959 错误提示信息则说明了实际导入时的障碍。 ORA-00959 错误的原因分析 ORA-00959 错误的原因由其错误提示信息已经说明了——缺少了相应的表空间。这时,我们需要对其出错的对象进行处理。例如,若我们发现了相应表空间确实没有被创建,或者没有在导入时提前建立好,这时便可以在运用 impdp 工具前,恰当地创建好要导入的表空间。 若已经有相应的表空间且也已经正确创建,但导入仍然失败,这时,我们需要进一步探究导致该错误的具体原因。常见的导致ORA-00959 错误的因素与表空间命名不规范,导致 impdp 工具无法识别相应表空间的情况有关。例如,表空间名称中含有全角字符或者其他特殊字符,均会导致导入失败。 解决豁免: 针对ORA-39083 错误,通常的解决方法是检查表空间是否被正确地创建,确保表空间名称规范、识别正确后再次使用 impdp 工具进行导入。此外,也可以根据错误提示信息中涉及到的具体对象类型,考虑采用更为具体的解决措施,比如说建立其他的 table 或者 view。 最后,防患于未然,不断的学习和掌握 Oracle 工具和技能是重要的,加深自己对数据库系统的理解和管理能力也可以避免此类错误的发生。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Lucifer三思而后行

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值