當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

oracle 31693,ORACLE expdp备份与ORA-31693、ORA-02354、ORA-01555

發(fā)布時間：2025/3/11 编程问答 26 豆豆

生活随笔收集整理的這篇文章主要介紹了 oracle 31693,ORACLE expdp备份与ORA-31693、ORA-02354、ORA-01555 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

近期，某綜合網(wǎng)管系統(tǒng)expdp備份出現(xiàn)異常，報錯信息如下：

Export: Release 10.2.0.4.0 - 64bit Production on 星期二, 12 4月, 2016 11:30:00

;;;

連接到: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

啟動 "SYSTEM"."SYS_EXPORT_SCHEMA_07": ?system/******** schemas=ultra directory=backup_expdp dumpfile=expnms_201604121.dmp,expnms_201604122.dmp,expnms_201604123.dmp,exp_nms201604124.dmp filesize=40g VERSION=10.2.0.2 exclude=statistics logfile=exp_20160412.log

正在使用 BLOCKS 方法進(jìn)行估計...

處理對象類型 SCHEMA_EXPORT/TABLE/TABLE_DATA

使用 BLOCKS 方法的總估計: 197.1 GB

處理對象類型 SCHEMA_EXPORT/USER

處理對象類型 SCHEMA_EXPORT/SYSTEM_GRANT

處理對象類型 SCHEMA_EXPORT/ROLE_GRANT

處理對象類型 SCHEMA_EXPORT/DEFAULT_ROLE

處理對象類型 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA

處理對象類型 SCHEMA_EXPORT/TYPE/TYPE_SPEC

處理對象類型 SCHEMA_EXPORT/DB_LINK

處理對象類型 SCHEMA_EXPORT/SEQUENCE/SEQUENCE

處理對象類型 SCHEMA_EXPORT/TABLE/TABLE

處理對象類型 SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT

處理對象類型 SCHEMA_EXPORT/TABLE/INDEX/INDEX

處理對象類型 SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

處理對象類型 SCHEMA_EXPORT/TABLE/COMMENT

處理對象類型 SCHEMA_EXPORT/PACKAGE/PACKAGE_SPEC

處理對象類型 SCHEMA_EXPORT/FUNCTION/FUNCTION

處理對象類型 SCHEMA_EXPORT/PROCEDURE/PROCEDURE

處理對象類型 SCHEMA_EXPORT/PACKAGE/COMPILE_PACKAGE/PACKAGE_SPEC/ALTER_PACKAGE_SPEC

處理對象類型 SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION

處理對象類型 SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE

處理對象類型 SCHEMA_EXPORT/VIEW/VIEW

處理對象類型 SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY

處理對象類型 SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

處理對象類型 SCHEMA_EXPORT/TABLE/TRIGGER

處理對象類型 SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_AND_BITMAP/INDEX

處理對象類型 SCHEMA_EXPORT/JOB

處理對象類型 SCHEMA_EXPORT/POST_SCHEMA/PROCOBJ

ORA-31693: 表數(shù)據(jù)對象 "ULTRA"."DAY_META_TASK_RESULT_B" 無法加載/卸載并且被跳過, 錯誤如下:

ORA-02354: 導(dǎo)出/導(dǎo)入數(shù)據(jù)時出錯

ORA-01555: 快照過舊: 回退段號 24 (名稱為 "_SYSSMU24$") 過小

. . 導(dǎo)出了 "ULTRA"."ZXMG_UDPATE_BACKUP" ? ? ? ? ? ? 18.36 GB 536021168 行

接下來是問題的處理過程，看到Ora-01555，首先想到的是查看及調(diào)整undo_retention參數(shù)

SQL> show parameter undo_r

NAME ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE ? ? ? ?VALUE

------------------------------------ ----------- ------------------------------

undo_retention ? ? ? ? ? ? ? ? ? ?integer ? ? 3600

SQL> select tablespace_name,sum(bytes)/1024/1024/1024 gb from dba_data_files where tablespace_name like '%UNDO%' group by tablespace_name;

TABLESPACE_NAME ? ? ? ? ? ? ? ? ? ? ? ?GB

------------------------------ ? ? ? ???----------

UNDOTBS1 ? ? ? ? ? ? ? ? ? ? ? 106.992172

然后查看了undo表空間的使用率，其使用率只有1%，因此考慮調(diào)整undo_retention參數(shù)到5400，調(diào)整后問題依舊，后來又調(diào)整到7200，問題依然存在，但是undo表空間的使用率最高到30%。現(xiàn)在，可以判斷不是單純的undo表空間參數(shù)undo_retention的問題了，需要具體問題具體分析一下。查看問題表的結(jié)構(gòu)發(fā)現(xiàn)，該表有2個大字段：

SQL> desc "ULTRA"."DAY_META_TASK_RESULT_B"

名稱 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?是否為空? 類型

----------------------------------------- -------- ? ? ? ?----------------------------

META_TASK_RESULT_ID ? ? ? ? NOT NULL ?VARCHAR2(50)

SCHEDULER_ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? VARCHAR2(50)

META_TASK_ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? VARCHAR2(50)

TIME ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??NUMBER(20)

ALARM ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??NUMBER(5)

META_TASK_STATE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? NUMBER(5)

INSTANCE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?VARCHAR2(200)

UNIT ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??VARCHAR2(10)

VALUE_CHECK ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?VARCHAR2(5)

SHELL_RESULTCLOB

ADVICE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?VARCHAR2(4000)

OPINION ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?VARCHAR2(100)

ALARM_INFO ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?VARCHAR2(200)

VALUECLOB

VTABLE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? VARCHAR2(30)

REFLAG ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??VARCHAR2(50)

通過查詢oracle官網(wǎng)，oracle的lob大字段有自己的retention參數(shù)，如果只調(diào)整undo_retention，而沒有同步到lob大字段，該參數(shù)還是默認(rèn)的900s，確認(rèn)查詢結(jié)果如下：

SQL>select table_name,column_name,pctversion,retention from dba_lobs where table_name='DAY_META_TASK_RESULT_B'

TABLE_NAME ? ? ? ? ? ? ? ? ? ? ? ??COLUMN_NAME ? ? ? ? ? ? ? ? ? ?PCTVERSION ?RETENTION

------------------------------ ? ? ? ? ??------------------------------ ? ? ? ? ? ? ? ? ?? ---------- ?----------

DAY_META_TASK_RESULT_B ? ? ? ? SHELL_RESULT ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 900

DAY_META_TASK_RESULT_B ? ? ? ? VALUE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?900

明確了問題原因，接下來就是修改表含有l(wèi)ob大字段的retention設(shè)置

SQL>ALTER TABLE DAY_META_TASK_RESULT_B MODIFY LOB(SHELL_RESULT)(retention);

table altered.

SQL>ALTER TABLE DAY_META_TASK_RESULT_B MODIFY LOB(VALUE)(retention);

table altered.

SQL>select table_name,column_name,pctversion,retention from dba_lobs where table_name='DAY_META_TASK_RESULT_B'

TABLE_NAMECOLUMN_NAME ? ? ? ? ? ? ? ? ? ?PCTVERSION ?RETENTION

--------------------------------------------------------------------------------

DAY_META_TASK_RESULT_B ? ? ? ? SHELL_RESULT7200

DAY_META_TASK_RESULT_B ? ? ? ? VALUE7200

調(diào)整完畢后，該平臺的expdp恢復(fù)正常：

Export: Release 10.2.0.4.0 - 64bit Production on 星期四, 21 4月, 2016 11:30:00

;;;

連接到: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

啟動 "SYSTEM"."SYS_EXPORT_SCHEMA_02": ?system/******** schemas=ultra directory=backup_expdp dumpfile=expnms_201604211.dmp,expnms_201604212.dmp,expnms_201604213.dmp,exp_nms201604214.dmp filesize=40g VERSION=10.2.0.2 exclude=statistics logfile=exp_20160421.log

正在使用 BLOCKS 方法進(jìn)行估計...

處理對象類型 SCHEMA_EXPORT/TABLE/TABLE_DATA

使用 BLOCKS 方法的總估計: 199.8 GB

處理對象類型 SCHEMA_EXPORT/USER

處理對象類型 SCHEMA_EXPORT/SYSTEM_GRANT

處理對象類型 SCHEMA_EXPORT/ROLE_GRANT

處理對象類型 SCHEMA_EXPORT/DEFAULT_ROLE

處理對象類型 SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA

處理對象類型 SCHEMA_EXPORT/TYPE/TYPE_SPEC

處理對象類型 SCHEMA_EXPORT/DB_LINK

處理對象類型 SCHEMA_EXPORT/SEQUENCE/SEQUENCE

處理對象類型 SCHEMA_EXPORT/TABLE/TABLE

處理對象類型 SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT

處理對象類型 SCHEMA_EXPORT/TABLE/INDEX/INDEX

處理對象類型 SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT

處理對象類型 SCHEMA_EXPORT/TABLE/COMMENT

處理對象類型 SCHEMA_EXPORT/PACKAGE/PACKAGE_SPEC

處理對象類型 SCHEMA_EXPORT/FUNCTION/FUNCTION

處理對象類型 SCHEMA_EXPORT/PROCEDURE/PROCEDURE

處理對象類型 SCHEMA_EXPORT/PACKAGE/COMPILE_PACKAGE/PACKAGE_SPEC/ALTER_PACKAGE_SPEC

處理對象類型 SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION

處理對象類型 SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE

處理對象類型 SCHEMA_EXPORT/VIEW/VIEW

處理對象類型 SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY

處理對象類型 SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT

處理對象類型 SCHEMA_EXPORT/TABLE/TRIGGER

處理對象類型 SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_AND_BITMAP/INDEX

處理對象類型 SCHEMA_EXPORT/JOB

處理對象類型 SCHEMA_EXPORT/POST_SCHEMA/PROCOBJ

. . 導(dǎo)出了 "ULTRA"."DAY_META_TASK_RESULT_B" ? ? ? ? 39.40 GB 20009768 行

. . 導(dǎo)出了 "ULTRA"."ZXMG_UDPATE_BACKUP" ? ? ? ? ? ? 18.87 GB 550823549 行

. . 導(dǎo)出了 "ULTRA"."WLANUPDATESCHEDULE" ? ? ? ? ? ? ? ? 0 KB ? ? ? 0 行

. . 導(dǎo)出了 "ULTRA"."WORKFLOW_STAT" ? ? ? ? ? ? ? ? ? ? ?0 KB ? ? ? 0 行

已成功加載/卸載了主表 "SYSTEM"."SYS_EXPORT_SCHEMA_02"

******************************************************************************

SYSTEM.SYS_EXPORT_SCHEMA_02 的轉(zhuǎn)儲文件集為:

/opt/backup/expnms_201604211.dmp

/opt/backup/expnms_201604212.dmp

/opt/backup/expnms_201604213.dmp

/opt/backup/exp_nms201604214.dmp

作業(yè) "SYSTEM"."SYS_EXPORT_SCHEMA_02" 已于 18:12:35 成功完成

至此，故障處理完畢！

來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/29357786/viewspace-2086101/，如需轉(zhuǎn)載，請注明出處，否則將追究法律責(zé)任。

總結(jié)

以上是生活随笔為你收集整理的oracle 31693,ORACLE expdp备份与ORA-31693、ORA-02354、ORA-01555的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇： count数据库优化oracle,迷惑性
下一篇： c语言error ld returned