My Oracle Support Banner

Demantra TABLE_REORG Tool New Release with Multiple Updates! Partitions, Drop_temps and More! 7.3.1.3 to 12.2.x. (Doc ID 1980408.1)

Last updated on FEBRUARY 03, 2019

Applies to:

Oracle Demantra Demand Management - Version 7.3.1.4 and later
Information in this document applies to any platform.

Details

Demantra Customers, there is a new release of the table_reorg Tool.  This patch will install updates to the TABLE_REORG tool.  Demantra Version: 7.3.1.3 to 12.2.x.
The minimum 7.3.1.x version is 7.3.1.3.   You can download this patch using bug 17640575 in My Oracle Support.  The following repairs are included:

bug 17236424 - DROP_TEMPS DROPS TMP_COL_ORDER4REDEF TEMP TABLE AND CAUSES THE NEXT RUN OF TABLE
               The standard program DROP_TEMPS is actually dropping standard temp table tmp_col_order4redef.  This error can cause the function redef$_col_order to
               become invalid.  Moreover because of this, the next run of TABLE_REORG fails with the following error:

               BEGIN table_reorg.reorg(user,'MDP_MATRIX','R'); END;
               *
               ERROR at line 1:
               ORA-00900: invalid SQL statement

bug 17430356 - ORA-600 [KQLIDCHG0] WHEN RUNNING TABLE_REORG.REOG
bug 17555445 - DEMANTRA TABLE_REORG.REORG PROCEDURE ERRORS WITH ORA-14024
bug 20407821 - VCP12.2.4.1 ERROR LOG IN DEMANTRA STARTUP

Additionally, You may want to review MOS note: Excessive Object Sizes When Using Parallel (Doc ID 855472.1) if you have a ASSM tablespace, using an extent size specified as UNIFORM, with AUTOEXTEND enabled.

Processing Note:

Normally when customers do table re org, they take a backup of the table first.  Can they drop these backup tables once the re org is completed successfully?

After the completion of the next engine run, yes.  However, best practice could be considered as:

1. Create a backup of the table before first run.  Backup #1
2. Run table_reorg
3. Process as normal, allowing time to go by
4. Time for the next submission of table_reorg, create a backup.  Backup #2
5. Process as normal, until a reorg is required
6. Time for the next submission of table_reorg, create a backup.  Backup #3
7. Delete backup #1.  At this point, backup #2 becomes backup #1.  Backup #3 becomes backup #2
8. Process as normal, allowing time to go by
9. Time for the next submission of table_reorg, create a backup.  Backup #3
10. Delete backup #1.  At this point, backup #2 becomes backup #1.  Backup #3 becomes backup #2

If implementing the above, you can be assured that you will always have two backups.  Does it consume disk space, of course.  Does this approach deliver reliable, retrievable historical backup
data, yes.

Please note that when creating this note, the minimum Demantra version 7.3.1.3 was not available as a release.   This is for 7.3.1.3 to 12.2.x.

Actions

Download this patch using bug 17640575 in My Oracle Support.

Contacts

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Details
Actions
Contacts
References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.