Thanks for the question, Neetu.
Asked: April 07, 2017 - 9:57 am UTC
Last updated: April 07, 2017 - 10:15 am UTC
Version: 12c
Viewed 1000+ times
You Asked
Hi Tom,
We are planning to implement Oracle EBR in our DB and plan to have only two editions created ED1 and ED2 apart from ORA$BASE. We would also ensure that all the 5000 objects(editionable) we have in ORA$BASE would be actualized into ED1 and ED2 as a one time activity. Subsequent release we would toggle between defaulting the edition as ED1 and ED2. AFter every successfull code release in an edition, we will synch-up the other edition with the latest changes in background, so that both editions are same.
However one particular case worries me, when ED2(child) is current default edition and then for upcoming release I will need to modify/add new objects in edition ED1 which is the parent of ED2, will i have any issues here? as my system is connected to ED2. Here i try to ensure that child ED2 do not look back to its parent ED1 as we have actualized all the 5000 objects in ED1 and ED2.
Your inputs are valuable.
Note: The reason why we want to restrict to two editions is we dont want to end up having too many editions in the DB, and over a period of time the system might lag when the child has to traverse through the editions and look back into ORA$BASE for the objects with no changes.
Thanks in advance.
Neetu
and Chris said...
This is the wrong way to use EBR! Each new release should create a new version as a child of the current active version. If you try and switch back and forth between two editions you're bound to make a mistake somewhere and end up in a mess.
There's no overhead to "traversing back through the editions". But if you aren't convinced, then you've already stated the solution to avoid this:
Actualize all the objects in the new edition!
This way all the objects exist in the latest edition, so there's no need "go back" to ora$base.
Is this answer out of date? If it is, please let us know via a Comment