HomeФильмы и анимацияRelated VideosMore From: Redgate Videos

Oracle Edition Based Redefiinition

6 ratings | 2038 views
Upgrading critical applications can be very hard and one of the biggest problems organizations face is the availability of the application during the update. Because of the global nature of applications nowadays we want to achieve 99.99% uptime. Since Oracle Database 11g Release 2 Edition Based Redefinition is available to solve this issue. In this session, Patrick Barel will introduce the ideas behind Edition Based Redefinition and how it can be used. He will look at tables, editioning views, cross edition triggers, and how PL/SQL Code can be changed in the different editions. After this session you will have a basic idea on how Edition Based Redefinition works and how it might help you in your situation. You can view our complete archive at http://www.red-gate.com/oracle-webinars
Html code for embedding videos on your blog
Text Comments (3)
Susan Tremayne (2 years ago)
Terrible sound.
GOURI DATTA M (2 years ago)
Hi Patrick, Its really very well explained, it was my privilage to hear your Session Regards Maharana Gouri
Victor Feinstein (4 years ago)
Hi Patrick, 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!

Would you like to comment?

Join YouTube for a free account, or sign in if you are already a member.