What are the challenges you face when working across database platforms? Take the survey

edition- based redefinition

vfeinstein50vfeinstein50 Posts: 2
edited March 31, 2014 9:44AM in Source Control for Oracle

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!


  • Options
    Eddie DEddie D Posts: 1,789 Rose Gold 5
    Hi, thank you for your forum post.

    With regards to your questions, what relevance are they to our Oracle Tools and our Source Control for Oracle product?

    I have no idea regarding the pro and con of running a LOGON trigger. Likewise purging older editions and something called EBR.

    Many Thanks
    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
Sign In or Register to comment.