Seed table preparation ad/txk delta 8

[satish]

Dear erman,

In advanced seed data preparation

Oracle says,this is the feature of 'editioning' in 12.2 Apps.

There will be 2 SETS SET1 and SET2 for seed data. This table holds seed data, so when the table is prepared the second set is created. Going forward these 2 sets will be flipped whenever a patch that prepares this seed table is applied.

Which means at any point of time,we will have both the sets?
Will cleanup doesn't delete the other set?can you pls clarify.

Thanks,
Satiah

[ErmanArslansOracleBlog]

I guess you don't have my book? :)

In the case of the tables that store the seed data, the method is different. The table data is actually
copied during a patch application, and EBS uses the virtual private database (VPD ) feature to create views  of data according to the edition that queries the data. The copying of data is done in the table. That is, seed tables have an additional column named ZD_EDITION_NAME to store the edition type of a row. So, the seed data (the rows residing on the seed table, which is in the target of the patch) is copied into the same table, and the values of the ZD_EDITION_NAME columns for these copied rows are set to the patch edition’s name. Thus, with the VPD based on the ZD_EDITION_NAME column, the online patching mechanism makes the patch edition see and operate on the copy of the data without touching any of the actual data that  is used by the running EBS applications.
 There must be sufficient space in the EBS 12.2 database to hold the duplicate copy of the seed data.
This is also required for the patches that are changing the columns of the application tables. In this manner, the System tablespace should have at least 25GB of free space available, and the APPS_TS_SEED tablespace should have a minimum of 5GB of free space available before starting an online patching cycle. We also recommend you have at least 10 percent free space available in all other standard EBS tablespaces.
 Later, within the cutover phase, the modified data becomes the actual data, and the former actual
data becomes the old data, which is removed in the cleanup phase. Oracle calls this method editioned data storage , which allows an online patch to modify the seed data online.
Using this approach, what happens basically is that the data in seed data tables is replicated into the
same tables where it resides, and the patch operates on the private copy of the data. Thus, any change in the seed data won’t affect the running application.
Oracle must have chosen this approach for the seed data, because the seed data is the data used by
the code itself, and unlike the application data stored in the application tables, the seed data is created and patched by Oracle.