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

相关文章

Oracle type (自定义类型的使用)

oracle - type   type定义: oracle中自定义数据类型 oracle中有基本的数据类型,如number,varchar2,date,numeric,float....但有时候我们需要特殊的格式, 如将name定义为(firstname,lastname)的形式,我们想把这个作为一个表的一列看待,这时候就要我们自己定义一个数据类型 格式 :create or repla

ORACLE 11g 创建数据库时 Enterprise Manager配置失败的解决办法 无法打开OEM的解决办法

在win7 64位系统下安装oracle11g,在使用Database configuration Assistant创建数据库时,在创建到85%的时候报错,错误如下: 解决办法: 在listener.ora中增加对BlueAeri-PC或ip地址的侦听,具体步骤如下: 1.启动Net Manager,在“监听程序”--Listener下添加一个地址,主机名写计

Oracle Start With关键字

Oracle Start With关键字 前言 旨在记录一些Oracle使用中遇到的各种各样的问题. 同时希望能帮到和我遇到同样问题的人. Start With (树查询) 问题描述: 在数据库中, 有一种比较常见得 设计模式, 层级结构 设计模式, 具体到 Oracle table中, 字段特点如下: ID, DSC, PID; 三个字段, 分别表示 当前标识的 ID(主键), DSC 当

Jenkins 插件 地址证书报错问题解决思路

问题提示摘要: SunCertPathBuilderException: unable to find valid certification path to requested target...... 网上很多的解决方式是更新站点的地址,我这里修改了一个日本的地址(清华镜像也好),其实发现是解决不了上述的报错问题的,其实,最终拉去插件的时候,会提示证书的问题,几经周折找到了其中一遍博文

oracle分页和mysql分页

mysql 分页 --查前5 数据select * from table_name limit 0,5 select * from table_name limit 5 --limit关键字的用法:LIMIT [offset,] rows--offset指定要返回的第一行的偏移量,rows第二个指定返回行的最大数目。初始行的偏移量是0(不是1)。   oracle 分页 --查前1-9

【Python报错已解决】AttributeError: ‘list‘ object has no attribute ‘text‘

🎬 鸽芷咕:个人主页  🔥 个人专栏: 《C++干货基地》《粉丝福利》 ⛺️生活的理想,就是为了理想的生活! 文章目录 前言一、问题描述1.1 报错示例1.2 报错分析1.3 解决思路 二、解决方法2.1 方法一:检查属性名2.2 步骤二:访问列表元素的属性 三、其他解决方法四、总结 前言 在Python编程中,属性错误(At

DBeaver 连接 MySQL 报错 Public Key Retrieval is not allowed

DBeaver 连接 MySQL 报错 Public Key Retrieval is not allowed 文章目录 DBeaver 连接 MySQL 报错 Public Key Retrieval is not allowed问题解决办法 问题 使用 DBeaver 连接 MySQL 数据库的时候, 一直报错下面的错误 Public Key Retrieval is

vue 父组件调用子组件的方法报错,“TypeError: Cannot read property ‘subDialogRef‘ of undefined“

vue 父组件调用子组件的方法报错,“TypeError: Cannot read property ‘subDialogRef’ of undefined” 最近用vue做的一个界面,引入了一个子组件,在父组件中调用子组件的方法时,报错提示: [Vue warn]: Error in v-on handler: “TypeError: Cannot read property ‘methods

ora-01017 ora-02063 database link,oracle11.2g通过dblink连接oracle11.2g

错误图示: 问题解决 All database links, whether public or private, need username/password of the remote/target database. Public db links are accessible by all accounts on the local database, while private

ORACLE语法-包(package)、存储过程(procedure)、游标(cursor)以及java对Result结果集的处理

陈科肇 示例: 包规范 CREATE OR REPLACE PACKAGE PACK_WMS_YX IS-- Author : CKZ-- Created : 2015/8/28 9:52:29-- Purpose : 同步数据-- Public type declarations,游标 退休订单TYPE retCursor IS REF CURSOR;-- RETURN vi_co_co