Hello,
When we create the very first edition as a child of ORA$BASE, and grant some package to it or re-compile some package, this package gets assigned to our new edition as expected:
create edition v36 as child of ora$base;
alter session set edition=v36;
grant execute on P_CONF_MERCH_ETL to IHUB_ETL;
Now, what is the pro and con of running a LOGON trigger to enable v36 for all new logon to Oracle, vs. doing ALTER SYSTEM SET DEFAULT EDITION = v36 ?
and how can we 'purge' older editions, if every new edition we create always 'is a child of ' the older edition? Oracle will not let us drop those older editions, and is this a problem at all, if say we create 20 new editions per year, for 5 years?
How do we manage completely non-editionable objects such as TYPES and AQ queues, and sequences? anything special to consider as we implement EBR for all of our OWNER schema for these non-editionable types? I know function based index will raise an error because INDEX is non-editionable, and function is, so if you can re-write the function as a inline CREATE INDEX expression, it will solve the issue. but what if you cannot?
sorry, that is more than 1 question.. Purging EBR is the main question.
thanks in advance!
Hi, thank you for your forum post.
When we create the very first edition as a child of ORA$BASE, and grant some package to it or re-compile some package, this package gets assigned to our new edition as expected:
create edition v36 as child of ora$base;
alter session set edition=v36;
grant execute on P_CONF_MERCH_ETL to IHUB_ETL;
Now, what is the pro and con of running a LOGON trigger to enable v36 for all new logon to Oracle, vs. doing ALTER SYSTEM SET DEFAULT EDITION = v36 ?
and how can we 'purge' older editions, if every new edition we create always 'is a child of ' the older edition? Oracle will not let us drop those older editions, and is this a problem at all, if say we create 20 new editions per year, for 5 years?
How do we manage completely non-editionable objects such as TYPES and AQ queues, and sequences? anything special to consider as we implement EBR for all of our OWNER schema for these non-editionable types? I know function based index will raise an error because INDEX is non-editionable, and function is, so if you can re-write the function as a inline CREATE INDEX expression, it will solve the issue. but what if you cannot?
sorry, that is more than 1 question.. Purging EBR is the main question.
thanks in advance!