EBS 12.2 -- Online patching , Copying the Seed data

Oracle does not want a patch to operate on the actual seed data which is stored in the seed tables.

So the seed data is copied during the patching cycles and all the patching work is done on these copied rows. As the seed data is copied in to the same table which the original seed data resides, it must be distungished from the original data somehow..

To distinguish the run edition seed data from the patch edition seed data , columns named as zd_edition_name are populated with the edition names and VPD policies are used to determine the rows to be returned according the session's database edition. So patch edition sees the copied data and Run edition sees the run edition seed data, in other words the real seed data which is in use by the application at that time.

To understand te online patching better, you can read my earlier posts about it.

http://ermanarslan.blogspot.com.tr/2014/06/122-online-patching-revolutinary.html

http://ermanarslan.blogspot.com.tr/2014/03/ebs-122-applications-dba-online.html

To build such a mechanism to support online patching of seed tables, a preparation is done in the database. The preparation is done in the prepare phase and can be seen clearly by the following example.

FND_PROFILE_OPTION_VALUES table can be considered as an example to these seed tables, as it is used to store the profile option values set for the EBS profiles and meets the requirements of being a seed tables.

Ref: (Doc ID 1577661.1). These requirements are;

• The Table contains data that is "part of the application" and is delivered and maintained via application patching.
• The Table Data affects runtime application functionality or appearance Meaning the data is used by the code, rather than simply handled by the code. The data controls how the application operates.
• The Table Data is predominately application seed data.

So this table has a zd_edition_name column and a VPD policy associated with it 

For the online patching to happen, the data in the seed tables are copied in the prepare phase.

No matter which patch will be applied and no matter if that patch will use this table or not, adop's prepare phase copies the data in this table in the prepare phase as seen in the following log;

Below is a snip taken from the log of an adop phase=prepare operation.
Here it says , it copies the seed data using and insert-select operation;

3915624 09:38:31 00:00:00 ad.plsql.ad_zd_seed.create_sync EVENT Copy Seed Data using insert-select: FND_PROFILE_OPTION_VALUES
3915624 09:38:31 00:00:00 ad.plsql.ad_zd_seed.create_sync STATEMENT SQL: insert /*+ ignore_row_on_dupkey_index("FND_PROFILE_OPTION_VALUES","FND_PROFILE_OPTION_VALUES_U1") */

...
So it is pretty clear that the copy of the seed data is done in the prepare phase and it is done no matter what. That is , it s not dependent on the patches that will be applied in the apply phase. It is done just in case..

Note that; I didnt copy/paste the whole log file, but the seed data in this table is not the only thing that is copied during the prepare phase, so we can say that these kind of operations make the cleanup phase to take a long time.