Monday, June 1, 2015

How to fix error >>> DBMS_AW_EXP: BIN$DdyrY during export

During export using data pump, you see the following:

Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 7.968 GB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
>>> DBMS_AW_EXP: BIN$DdyrY/cyAMLgU5/YLVaAbg==$0 not AW$

Solution: empty the recyclebin:
purge dba_recyclebin;
and restart the export.
Posted by at
Labels: , ,

3 comments:

  1. Javier PazAugust 10, 2015 at 8:06 PM

    DBMS_AW_EXP: Ignoring APPS.ODPCODE During Schema Data Pump Export (Doc ID 1675617.1)


    Click to add to Favorites DBMS_AW_EXP: Ignoring APPS.ODPCODE During Schema Data Pump Export (Doc ID 1675617.1) To BottomTo Bottom

    In this Document
    Symptoms
    Changes
    Cause
    Solution
    References

    This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.
    APPLIES TO:

    Oracle OLAP - Version 11.2.0.4 and later
    Information in this document applies to any platform.
    SYMPTOMS

    When attempting to perform a schema level export with datapump post database upgrade to 11.2.0.4,
    the following information is logged in the export log:

    expdp userid/password schemas=AP dumpfile=ap_expdp.dmp logfile=ap_expdp.log
    -----------------------
    >>> DBMS_AW_EXP: Ignoring FPA.FPAPJP
    >>> DBMS_AW_EXP: Ignoring APPS.ODPCODE
    >>> DBMS_AW_EXP: Ignoring ZPB.ZPBCODE
    >>> DBMS_AW_EXP: Ignoring APPS.XWDEVKIT

    You will also notice the AWs are actually exported:



    Processing object type SCHEMA_EXPORT/ASSOCIATION
    . . exported "APPS"."SUB_GIR" 79.72 MB 3675245 rows
    . . exported "APPS"."AW$ODPCODE":"PTN1"."SYS_SUBP101" 38.13 MB 135 rows
    . . exported "APPS"."OE_ITEMS_MV" 31.12 MB 270575 rows
    . . exported "APPS"."AW$$TEMP_EXP_TABLE112" 14.32 MB 7197 rows
    . . exported "APPS"."AW$XWDEVKIT":"PTN1"."SYS_SUBP226" 7.930 MB 147 rows
    . . exported "APPS"."AW$ODPCODE":"PTNN"."SYS_SUBP116" 5.279 MB 199 rows
    . . exported "APPS"."AW$ODPCODE":"PTNN"."SYS_SUBP109" 4.294 MB 165 rows
    . . exported "APPS"."AW$ODPCODE":"PTNN"."SYS_SUBP110" 4.893 MB 159 rows
    . . exported "APPS"."AW$ODPCODE":"PTNN"."SYS_SUBP111" 4.441 MB 181 rows
    . . exported "APPS"."AW$ODPCODE":"PTNN"."SYS_SUBP113" 4.578 MB 153 rows
    . . exported "APPS"."AW$ODPCODE":"PTNN"."SYS_SUBP112" 4.225 MB 165 rows
    . . exported "APPS"."AW$ODPCODE":"PTNN"."SYS_SUBP114" 4.255 MB 154 rows
    . . exported "APPS"."AW$ODPCODE":"PTNN"."SYS_SUBP115" 4.279 MB 173 rows


    CHANGES

    Upgrade to 11.2.0.4

    CAUSE

    In 11.2.0.4, we provide more details than we did in11.2.0.3.

    SOLUTION

    These messages can be ignored. AWs can't be exported like regular tables since they contain binary structures on disk that are not stored in an architecture-independent manner. So the datapump product provides a way for database options like OLAP to register special callbacks so we can handle our own objects (in this case AWs) appropriately. Unfortunately even when you export a single schema, our callback gets called for each AW in the instance. So that accounts for the messages about AWs not in the schema to export. Once you import the dump file, you will notice all the AWS are there.

    ReplyDelete
  2. UnknownSeptember 30, 2015 at 1:06 AM

    purge dba_recyclebin; helped me in my case... Thanks allot...

    ReplyDelete
  3. khaterMarch 17, 2016 at 1:55 PM

    purge dba_recyclebin; helped me in my case

    ReplyDelete

Subscribe to: Post Comments (Atom)