Oracle-expdp报错ORA-08103: object no longer exists

2023-10-24 09:04

本文主要是介绍Oracle-expdp报错ORA-08103: object no longer exists,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

问题:

        用户的expdp备份任务,不定期出现执行报错的情况,报错ORA-08103: object no longer exists

Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
ORA-39126: Worker unexpected fatal error in KUPW$WORKER.FETCH_XML_OBJECTS [REF_CONSTRAINT:"OWNER"."FK_TABLENAME"] 
ORA-08103: object no longer exists
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPW$WORKER", line 9715
----- PL/SQL Call Stack -----object      line  objecthandle    number  name
0x103697dc58     21979  package body SYS.KUPW$WORKER
0x103697dc58      9742  package body SYS.KUPW$WORKER
0x103697dc58     11838  package body SYS.KUPW$WORKER
0x103697dc58      2808  package body SYS.KUPW$WORKER
0x103697dc58     10422  package body SYS.KUPW$WORKER
0x103697dc58      1824  package body SYS.KUPW$WORKER
0x1027151600         2  anonymous block
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

问题分析:

        expdp导出期间发生ORA-08103: object no longer exists的错误,通常原因为导出任务操作的对象发生了DDL操作,引发object_data_id发生了改变,导致操作的对象object_data_id不一致,出现找不到对象的情况,按照这个思路对问题开始进行分析

        首先,每次报错日志显示的对象都是在外键约束对象REF_CONSTRAINT:"OWNER"."FK_TABLENAME",所以检查这个外键约束的最近一次DDL时间以及约束所在表的最近一次DDL时间,都在2018年6月,不在报错发生的时间点

​​SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
1 select constraint_name,constraint_type,status,table_name,owner,LAST_CHANGE
2 from dba_constraints
3 where constraint_name='FK_TABLENAME';
​
​
CONSTRAINT_NAME                CON STATUS                   TABLE_NAME                     OWNER                          LAST_CHANGE
------------------------------ --- ------------------------ ------------------------------ ------------------------------ -------------------
FK_TABLENAME                R   ENABLED                      TABLENAME                     OWNER                    2018-06-21 16:32:26
​
​
SQL> 1  select owner,object_name,CREATED,last_ddl_time2  from dba_objects3* where object_name='TABLENAME'
​
OWNER                                    OBJECT_NAME                    CREATED             LAST_DDL_TIME
---------------------------------------- ------------------------------ ------------------- -------------------
OWNER                                    TABLENAME                   2018-06-21 16:11:00 2018-06-25 14:40:29
​
SQL>

        由于报错的日志无法确认具体是哪个对象导致的,所以我们需要通过开启errorstack 定位到具体8103错误的操作语句对象

--使用sys用户在导出备份开始之前设置事件对ORA-8103发生错误时,dump出报错详细信息
alter system set events '8103 trace name errorstack level 3';
--报错结束之后,关闭8103事件
alter system set events '8103 trace name errorstack off';

        通过开启errorstack,在expdp再次发生报错时我们定位到了错误发生时的sql语句,从trace里面的执行sql语句里面我们提取了可能触发报错的表backupuser.backup_table_tmp

*** 2023-10-12 21:06:16.594
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0)
----- Error Stack Dump -----
ORA-08103: object no longer exists
----- Current SQL Statement for this session (sql_id=2qw01kxr5vgh0) -----
SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2('T_STAT_T', '7')), 0 ,KU$.BASE_OBJ.NAME ,KU$.BASE_OBJ.OWNER_NAME ,KU$.BASE_OBJ.TYPE_NAME ,'TABLE_STATISTICS' 
FROM SYS.KU$_TAB_STATS_VIEW KU$ 
WHERE NOT BITAND(KU$.BASE_OBJ.FLAGS,128)!=0 AND   KU$.OBJ_NUM IN (SELECT * FROM TABLE(DBMS_METADATA.FETCH_OBJNUMS(200001))) 
AND  NOT (KU$.BASE_OBJ.NAME  IN(select distinct segment_name from  backupuser.BACKUP_TABLE_TMP))
----- PL/SQL Stack -----
----- PL/SQL Call Stack -----object      line  objecthandle    number  name
0x1044c4e078      3665  package body SYS.DBMS_METADATA
0x1044c4e078      4269  package body SYS.DBMS_METADATA
0x1044c4e078      4581  package body SYS.DBMS_METADATA
0x1044c4e078      8160  package body SYS.DBMS_METADATA
0x103697dc58     11566  package body SYS.KUPW$WORKER
0x103697dc58      2808  package body SYS.KUPW$WORKER
0x103697dc58     10422  package body SYS.KUPW$WORKER
0x103697dc58      1824  package body SYS.KUPW$WORKER
0x1027151600         2  anonymous blockobject      line  object

        通过logmnr对报错时间点归档日志进行挖掘,确认表是否发生了DDL操作

--查询问题时间点涉及的归档日志1  select name,FIRST_TIME,NEXT_TIME2  from v$archived_log3  where FIRST_TIME between to_date('2023-10-12 21:00:00','yyyy-mm-dd hh24::mi:ss') and to_date('2023-10-12 21:10:00','yyyy-mm-dd hh24:mi:ss')4* order by 3
​
NAME                                                                                                 FIRST_TIME          NEXT_TIME
---------------------------------------------------------------------------------------------------- ------------------- -------------------
+DATA2/xxdb/archivelog/2023_10_12/thread_2_seq_1173870.1779.1150059883                               2023-10-12 21:01:45 2023-10-12 21:04:42
+DATA2/xxdb/archivelog/2023_10_12/thread_1_seq_1051584.3520.1150059963                               2023-10-12 21:02:39 2023-10-12 21:06:03
+DATA2/xxdb/archivelog/2023_10_12/thread_2_seq_1173871.1649.1150060057                               2023-10-12 21:04:42 2023-10-12 21:07:37
+DATA2/xxdb/archivelog/2023_10_12/thread_1_seq_1051585.1715.1150060161                               2023-10-12 21:06:03 2023-10-12 21:09:21
+DATA2/xxdb/archivelog/2023_10_12/thread_2_seq_1173872.654.1150060229                                2023-10-12 21:07:37 2023-10-12 21:10:28
+DATA2/xxdb/archivelog/2023_10_12/thread_1_seq_1051586.1560.1150060361                               2023-10-12 21:09:21 2023-10-12 21:12:40
​
--进行logmnr挖掘
SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => '+DATA2/xxdb/archivelog/2023_10_12/thread_2_seq_1173870.1779.1150059883', OPTIONS => DBMS_LOGMNR.NEW);
SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => '+DATA2/xxdb/archivelog/2023_10_12/thread_1_seq_1051584.3520.1150059963', OPTIONS => DBMS_LOGMNR.ADDFILE);
SQL> EXECUTE DBMS_LOGMNR.START_LOGMNR( OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

        在日志里面,发现了backupuser.backup_table_tmp在问题时间点确实发生了DDL:truncate table BACKUP_TABLE_TMP的操作

alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
SQL> SELECT TIMESTAMP,OPERATION,SQL_REDOFROM V$LOGMNR_CONTENTS WHERE username IN ('backupuser');
TIMESTAMP           OPERATION            SQL_REDO
------------------- -------------------- --------------------------------------------------------------------------------
2023-10-12 21:05:16 DDL                  truncate table BACKUP_TABLE_TMP;
2023-10-12 21:05:16 INSERT               insert into "backupuser"."BACKUP_TABLE_TMP"("OWNER","SEGMENT_NAME","PARTITION_NAME","BYTES") values ('TESTUSER','XXX_PT_LOG','-1','-1');

问题解决:

        跟用户进一步确认表的DDL操作逻辑,用户反馈表是备份作业任务的配置表,在备份开始后会truncate表重新插入要备份的配置信息,根据这个操作流程,想要触发ORA-08103: object no longer exists的错误,需要备份程序在同一时间执行两个expdp备份作业,一查备份的日志果然在问题时间段有两个备份作业在执行

        跟用户沟通,将两个备份作业配置在不同时间段执行,后面expdp报错不再发生,问题得以解决。

这篇关于Oracle-expdp报错ORA-08103: object no longer exists的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/274128

相关文章

Spring Boot中JSON数值溢出问题从报错到优雅解决办法

《SpringBoot中JSON数值溢出问题从报错到优雅解决办法》:本文主要介绍SpringBoot中JSON数值溢出问题从报错到优雅的解决办法,通过修改字段类型为Long、添加全局异常处理和... 目录一、问题背景:为什么我的接口突然报错了?二、为什么会发生这个错误?1. Java 数据类型的“容量”限制

SpringBoot项目中报错The field screenShot exceeds its maximum permitted size of 1048576 bytes.的问题及解决

《SpringBoot项目中报错ThefieldscreenShotexceedsitsmaximumpermittedsizeof1048576bytes.的问题及解决》这篇文章... 目录项目场景问题描述原因分析解决方案总结项目场景javascript提示:项目相关背景:项目场景:基于Spring

解决SpringBoot启动报错:Failed to load property source from location 'classpath:/application.yml'

《解决SpringBoot启动报错:Failedtoloadpropertysourcefromlocationclasspath:/application.yml问题》这篇文章主要介绍... 目录在启动SpringBoot项目时报如下错误原因可能是1.yml中语法错误2.yml文件格式是GBK总结在启动S

idea maven编译报错Java heap space的解决方法

《ideamaven编译报错Javaheapspace的解决方法》这篇文章主要为大家详细介绍了ideamaven编译报错Javaheapspace的相关解决方法,文中的示例代码讲解详细,感兴趣的... 目录1.增加 Maven 编译的堆内存2. 增加 IntelliJ IDEA 的堆内存3. 优化 Mave

如何解决mmcv无法安装或安装之后报错问题

《如何解决mmcv无法安装或安装之后报错问题》:本文主要介绍如何解决mmcv无法安装或安装之后报错问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录mmcv无法安装或安装之后报错问题1.当我们运行YOwww.chinasem.cnLO时遇到2.找到下图所示这里3.

浅谈配置MMCV环境,解决报错,版本不匹配问题

《浅谈配置MMCV环境,解决报错,版本不匹配问题》:本文主要介绍浅谈配置MMCV环境,解决报错,版本不匹配问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录配置MMCV环境,解决报错,版本不匹配错误示例正确示例总结配置MMCV环境,解决报错,版本不匹配在col

Oracle数据库常见字段类型大全以及超详细解析

《Oracle数据库常见字段类型大全以及超详细解析》在Oracle数据库中查询特定表的字段个数通常需要使用SQL语句来完成,:本文主要介绍Oracle数据库常见字段类型大全以及超详细解析,文中通过... 目录前言一、字符类型(Character)1、CHAR:定长字符数据类型2、VARCHAR2:变长字符数

SpringBoot启动报错的11个高频问题排查与解决终极指南

《SpringBoot启动报错的11个高频问题排查与解决终极指南》这篇文章主要为大家详细介绍了SpringBoot启动报错的11个高频问题的排查与解决,文中的示例代码讲解详细,感兴趣的小伙伴可以了解一... 目录1. 依赖冲突:NoSuchMethodError 的终极解法2. Bean注入失败:No qu

springboot报错Invalid bound statement (not found)的解决

《springboot报错Invalidboundstatement(notfound)的解决》本文主要介绍了springboot报错Invalidboundstatement(not... 目录一. 问题描述二.解决问题三. 添加配置项 四.其他的解决方案4.1 Mapper 接口与 XML 文件不匹配

java常见报错及解决方案总结

《java常见报错及解决方案总结》:本文主要介绍Java编程中常见错误类型及示例,包括语法错误、空指针异常、数组下标越界、类型转换异常、文件未找到异常、除以零异常、非法线程操作异常、方法未定义异常... 目录1. 语法错误 (Syntax Errors)示例 1:解决方案:2. 空指针异常 (NullPoi