Forum Stats

  • 3,814,410 Users
  • 2,258,870 Discussions
  • 7,892,703 Comments

Discussions

Upgraded database with left-over Discoverer EUL tables - how to cleanly remove?

TeresaS
TeresaS Member Posts: 28
edited Mar 23, 2018 10:38AM in Discoverer

I have inherited an upgraded 12cR2 database with DIS_, EUL_, EUL4_, and EUL5_ tables.  We previously used Discoverer, but no longer; we've moved to APEX.  Does anyone know of any documentation regarding legacy Discoverer tables (indices, etc.) that can be dropped safely to cleanup this database?  We no longer have a machine available with the Discoverer Administrator.

Best Answer

  • sbeck-Oracle
    sbeck-Oracle Member Posts: 116 Employee
    edited Mar 23, 2018 7:30AM Answer ✓

    Sounds like your end user layers were created in the EBS schema.  This has never been recommended. 
    Anyway, the DIS_ should be from a 3.1 end user layer.  The EUL_ are usually just prior to the 4i end user layer (3.x ).  EUL4_ are from the 4i end user layer.  EUL5_ are from the 10g / 11g end user layer.  I cannot provide a "list" of items as the eul tables are not documented. 


    If my memory serves (3.x was a very long time ago) there should be only views, DIS_DOCS, DIS_ALL_DOCS, DIS_GRANTS.  The remaining would be EUL_, which are mostly tables and a couple of functions.
    The naming convention for eul tables is EUL_, EUL4_, EUL5_...  so removal of these objects should have no impact.  I do suggest taking a backup prior to dropping them.

    If you were using Workbook Scheduling, there may be other objects.  You will see Views named like EUL_B070312143115Q1V1, Tables named like EUL_B070312143115Q1R1, Packages named like EUL5_BATCH_PACKAGE070312143115 and Jobs named like EUL_BATCH_PACKAGE070312143115.RUN.

    These can also be removed.

    Best regards,
    Sharon

Answers

  • sbeck-Oracle
    sbeck-Oracle Member Posts: 116 Employee
    edited Mar 22, 2018 4:04PM

    These table are not needed by any other Oracle product.
    If you are no longer using Discoverer you simply drop the items.  If they are in their Own Schema, drop the schema.

    Regards,
    Sharon

  • TeresaS
    TeresaS Member Posts: 28
    edited Mar 22, 2018 4:19PM

    Thank you!  Is there a more comprehensive list of database objects that can be dropped as well?  I'm sure the DIS_ tables are also discoverer, but not sure what else may be left-overs.  Does Oracle have an (as yet undiscovered by me) instruction sheet for manual cleanup that you know of?

  • TeresaS
    TeresaS Member Posts: 28
    edited Mar 22, 2018 4:21PM

    If they were in their own schema, that would be really clean.  Unfortunately not - they're intertwined with our main database application.

  • sbeck-Oracle
    sbeck-Oracle Member Posts: 116 Employee
    edited Mar 23, 2018 7:30AM Answer ✓

    Sounds like your end user layers were created in the EBS schema.  This has never been recommended. 
    Anyway, the DIS_ should be from a 3.1 end user layer.  The EUL_ are usually just prior to the 4i end user layer (3.x ).  EUL4_ are from the 4i end user layer.  EUL5_ are from the 10g / 11g end user layer.  I cannot provide a "list" of items as the eul tables are not documented. 


    If my memory serves (3.x was a very long time ago) there should be only views, DIS_DOCS, DIS_ALL_DOCS, DIS_GRANTS.  The remaining would be EUL_, which are mostly tables and a couple of functions.
    The naming convention for eul tables is EUL_, EUL4_, EUL5_...  so removal of these objects should have no impact.  I do suggest taking a backup prior to dropping them.

    If you were using Workbook Scheduling, there may be other objects.  You will see Views named like EUL_B070312143115Q1V1, Tables named like EUL_B070312143115Q1R1, Packages named like EUL5_BATCH_PACKAGE070312143115 and Jobs named like EUL_BATCH_PACKAGE070312143115.RUN.

    These can also be removed.

    Best regards,
    Sharon

  • TeresaS
    TeresaS Member Posts: 28
    edited Mar 23, 2018 10:38AM

    Thanks again!  If it's just the DIS_ and EUL%_ tables, we can do that easily.  I will try this on my test bed and go from there -- with backups.  Even if we do have a couple of "left-overs" (objects not labeled as above) our database will be quite a bit cleaner.

This discussion has been closed.