Demantra TABLE_REORG Tool New Release with Multiple Updates! Partitions, Drop_temps and More! 22.214.171.124 to 12.2.x.
(Doc ID 1980408.1)
Last updated on FEBRUARY 03, 2019
Applies to:Oracle Demantra Demand Management - Version 126.96.36.199 and later
Information in this document applies to any platform.
Demantra Customers, there is a new release of the table_reorg Tool. This patch will install updates to the TABLE_REORG tool. Demantra Version: 188.8.131.52 to 12.2.x.
The minimum 7.3.1.x version is 184.108.40.206. 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 - VCP220.127.116.11 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.
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
Please note that when creating this note, the minimum Demantra version 18.104.22.168 was not available as a release. This is for 22.214.171.124 to 12.2.x.
Download this patch using bug 17640575 in My Oracle Support.
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