We know that EBS Forward Cross edition triggers are used for replication the changes that are done in the run edition, to the patch edition during the online patching cycle.
These triggers are used in dml operations and by the nature of being trigger, they are fired when a new insert or update take place.
So what about the data stored in the table before creating these trigger? In other words; how is the initial loading of data is done.
There are 2 answer for these questions.
So if the patch is designed to update the seed data, then the seed data is copied from run edition to
patch edition using insert - select method.
You can see this if you execute adop phase=prepare and look at the adzdshowlog.out
"ad.plsql.ad_zd_seed.create_sync EVENT Copy Seed Data using insert-select: SOMETABLE"
But if , the patch is designed to update an application table definition, then the data in the application table is copied from run edition to patch edition by using a fake update operation that trigger the
Forward Cross edition trigger, which has the transformation logic.
It is actually exactly the same as I have explained in the earlier blog post.
http://ermanarslan.blogspot.com.tr/2015/07/ebs-122-and-ebr-lets-make-demo.html
An example for the fake update is also there.. "update olderman set dummy=dummy;"
Why insert-select for copying/initially loading the seed data from run to patch edition, and forward cross edition triggers for copying/initally loading the application table data from run to patch edition?
The answer is simple, patches update the seed data itself, so no transformation is needed, thus a simple insert-select is enough for the initial load.
On the other hand, patches dont change the data in the application tables, they change the the application table structure itself(a change in column type for example), so transformation is needed and forward cross edition triggers which have the transformation logic for that patch are our friends and that's why they are used for initial loading of data from run to patch edition during an online patching session.
These triggers are used in dml operations and by the nature of being trigger, they are fired when a new insert or update take place.
So what about the data stored in the table before creating these trigger? In other words; how is the initial loading of data is done.
There are 2 answer for these questions.
So if the patch is designed to update the seed data, then the seed data is copied from run edition to
patch edition using insert - select method.
You can see this if you execute adop phase=prepare and look at the adzdshowlog.out
"ad.plsql.ad_zd_seed.create_sync EVENT Copy Seed Data using insert-select: SOMETABLE"
But if , the patch is designed to update an application table definition, then the data in the application table is copied from run edition to patch edition by using a fake update operation that trigger the
Forward Cross edition trigger, which has the transformation logic.
It is actually exactly the same as I have explained in the earlier blog post.
http://ermanarslan.blogspot.com.tr/2015/07/ebs-122-and-ebr-lets-make-demo.html
An example for the fake update is also there.. "update olderman set dummy=dummy;"
Why insert-select for copying/initially loading the seed data from run to patch edition, and forward cross edition triggers for copying/initally loading the application table data from run to patch edition?
The answer is simple, patches update the seed data itself, so no transformation is needed, thus a simple insert-select is enough for the initial load.
On the other hand, patches dont change the data in the application tables, they change the the application table structure itself(a change in column type for example), so transformation is needed and forward cross edition triggers which have the transformation logic for that patch are our friends and that's why they are used for initial loading of data from run to patch edition during an online patching session.
Hi Erman,
ReplyDeleteI've been fighting this weird,abnormal incident for about 3-4 months already. I had an SR open for this issue since the begining but it's not going anywhere. Maybe be one of you can shed some light on why this is happening.
One of the tables (applsys.FND_CONCURRENT_QUEUES) during patch for 12.2.5 RUP did the following (per adzdshowlog)
ad.plsql.ad_zd_seed.create_sync - insert-select of (select *, 'SET1','SYNCED' from applsys.fnd_concurrent_queues where condition zd_edition_name=' ').
Essentially copying/updating everything with the exception of last two columns (ZD_EDITION_NAME, ZD_SYNC).
The only issue is since the select statement is set to null, no rows were return, because all the rows in applsys.FND_CONCURRENT_QUEUES table has 'ORA$BASE' as a zd_edition_name.
Then all the rows in applsys.FND_CONCURRENT_QUEUES table with zd_edition_name='ORA$BASE' get deleted during ADOP cleanup.
281860240 09:03:14 00:00:00 ad.plsql.ad_zd_seed.cleanup_table
Cleanup seed data table: APPLSYS.FND_CONCURRENT_QUEUES_TL, Run filter: ZD_EDITION_NAME = 'SET1'
SQL: delete from APPLSYS.FND_CONCURRENT_QUEUES_TL where not (ZD_EDITION_NAME = 'SET1') and (zd_edition_name not in ('SET1', 'SET2'))
Did i miss something? Is applsys.FND_CONCURRENT_QUEUES tabe ZD_EDITION_NAME column supposed to set to null?
I see. it took the zd_edition_name wrongly, so that the problem appeared at the end.
ReplyDeleteWe need to see the full log of problematic phase where "ad.plsql.ad_zd_seed.create_sync" was running.
Let's do it this way;
please create an issue into my forum.
Forum Link: http://ermanarslan.blogspot.com.tr/p/forum.html
Register and create an issue in the related category.
Tell me the story briefly again, and attach the log.
I will support you from there.