A fairly common topic of discussion within the E-Business Suite DBA community is “How many editions can I have?” This was once again true at the recent Ascend conference. While there is not a simple correct answer to this question, it is a fact that the number of editions you have in your database directly impacts the size of OBJ$ and the size of OBJ$ can impact your performance. Which in a way does give us a simple answer, “As few as possible.” How do you control the number of editions in your EBS database? The answer is to make sure you at least occasionally include the actualize_all phase in your patching cycle.
Every time you run, adop phase=prepare, you create a new edition in your database. Any objects created or compiled in that edition are actualized, the rest are stubs which just point to the earlier edition when the object was actualized. Oracle gives us a useful report to look at the state of the objects by edition, $AD_TOP/sql/ADZDSHOWOBJS.sql.
=========================================================================
= Editioned Objects Per Edition
=========================================================================
EDITION_NAME A_VALID A_INVALID A_TOTAL S_VALID S_INVALID S_TOTAL TOTAL
--------------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
V_20250517_0907 111770 38764 150534 0 0 0 150534
V_20250601_1535 160 67 227 150534 0 150534 150761
V_20250614_0920 28 16 44 150726 0 150726 150770
V_20250615_1247 291785 40 291825 0 0 0 291825
Note :
(A_) - Actual Objects
(S_) - Stub Objects
This is an example output while the database is in the process of getting rid of the old editions. With 19c, the cleanup phase tells the database to get rid of the old editions in the background after doing an actualize_all phase instead of actually doing it immediately. This is why the total number of objects in the previous editions is so much smaller than the current edition. You can also confirm that the previous editions are unusable by querying DBA_EDITIONS in the database.
SQL> select * from dba_editions;
EDITION_NAME PARENT_EDITION_NAME USABLE
-------------------- -------------------- --------
V_20250517_0907 NO
V_20250614_0920 V_20250601_1535 NO
V_20250601_1535 V_20250517_0907 NO
V_20250615_1247 V_20250614_0920 YES
SQL>When the cleanup is complete, only V_20250615_1247 will be left as an edition, the unusable editions will have been dropped.
You can get an idea of the work that will be involved if you run adop phase=actualize_all by looking at the output of ADZDSHOWOBJS.sql. If a significant percentage of the total packages are already actualized, then it should not take as long to instantiate the objects in the current patch edition. Having said that, it has been my observation with AD/TXK delta 16 and 19c (19.24+) that concurrency and system load are at least as large a factor. I have had actualize_all take from as little as 10 minutes to over an hour in different environments (patching sandbox, development, test, and production). In the most recent round of patching, testing was the slowest and development was the fastest. However since I am doing my patching against a live system, as long as the longest it took in non-production is less than half the time remaining after I complete patching in production before my scheduled outage for the cutover phase, I will run actualize_all (in practical terms, this means that I will always include the actualize_all phase in my patch sessions). This also means that if I do need to skip it in one patch cycle, it is unlikely to cause me any pain either in performance or space usage.
If you would like to test this for yourself realize that in spite of our normal diagram for a patch cycle:
It is actually
In other words, when you are not in a patch cycle (after cleanup and before prepare), you can run fs_clone or prepare. After running prepare, you can run apply, actualize_all, and finalize as much as you want as long as you end with finalize before doing cutover. And, of course, you can run abort at any time prior to cutover. You must always end with cleanup. This means if you have applied your patches and run the finalize phase and then find another patch or which to actualize the objects to cleanup the old editions, you can do so and just run another finalize phase. This has been confirmed by the EBS ATG group (the development group that owns adop) at Oracle. This means that you can test the extra time needed just for actualize_all by applying all your patches and completing a finalize phase then doing an actualize_all and finalize (realize that this will be high since certain activities will be repeated in the second finalize). Of course this will not test the impacts from concurrency so it still could run longer in another environment.
The TLDR version of this post is that in any normal patching cycle, I will run actualize_all instead of keeping the extra editions.
What will you do?