Discussions
Categories
- 17.9K All Categories
- 3.4K Industry Applications
- 3.4K Intelligent Advisor
- 75 Insurance
- 537.7K On-Premises Infrastructure
- 138.7K Analytics Software
- 38.6K Application Development Software
- 6.1K Cloud Platform
- 109.6K Database Software
- 17.6K Enterprise Manager
- 8.8K Hardware
- 71.3K Infrastructure Software
- 105.4K Integration
- 41.6K Security Software
use edition based redefinition to upgrade without downtime

At the moment for every Database upgrade a downtime is needed. a startup RESTRICT or MIGRATE is required to update objects belonging to SYS.
But Oracle introduced a feature which should overcome this limitation:
With Edition Based Redefinition 2 different versions of Views and Packages can exist at the same time supporting different setups during a migration.
In a RAC environment, the new edition could be loaded before the first instance is moved from the old to the new version. Then every instance with higher binaries uses the new edition, whereas the old instances are using the old views and packages.
After the last instance is upgraded, a post-script makes the new edition default and removes the old one.
It's not easy, but HA rarely is.
Comments
-
We, Oracle are working on our internal process as to how to evaluate and prioritize the IDEAS submitted. But the more votes obviously the more priority we will put on the request. However votes/popularity alone will not determine the priority.
As we move through the process the IDEA will change stages: (not in flow order)
- Active
- Already Offered
- Archived
- Coming Soon
- For Future Consideration
- in Progress
- Partially Implemented
- Under Review
-
evidently useful
-
with this one you can reduce the downtime but cant avoid the downtime.
-
How does Edition Based Redefinition "overcome this limitation" of downtime? Even with EBR, there is still a small window (can be very small) where the schema is unavailable when switching to the new edition. At this point, all database activity must cease because all database activity performed by end users will require recursive SQL which will be impossible while SYS is being moved to the new edition.
Also, an upgrade or a patch can involve more than just SYS-owned objects. It can be any other objects that support database features as well. APEX, CTXSYS, MDSYS, etc.
I don't remember, but isn't EBR an EE feature? If so, then this wouldn't apply to non-EE databases.
All that being said, I do like the idea of Oracle using their own feature to significantly shorten the downtime window.
Cheers,
Brian -
How does Edition Based Redefinition "overcome this limitation" of downtime? Even with EBR, there is still a small window (can be very small) where the schema is unavailable when switching to the new edition. At this point, all database activity must cease because all database activity performed by end users will require recursive SQL which will be impossible while SYS is being moved to the new edition.
Also, an upgrade or a patch can involve more than just SYS-owned objects. It can be any other objects that support database features as well. APEX, CTXSYS, MDSYS, etc.
I don't remember, but isn't EBR an EE feature? If so, then this wouldn't apply to non-EE databases.
All that being said, I do like the idea of Oracle using their own feature to significantly shorten the downtime window.
Cheers,
BrianEBR is for all editions.
In theory you can do an downtimeless application upgrade with that. But it is pretty complex to do that. Sessions continue to work in the old edition. Only after a reconnect you will be switch to the new edition. The complex part is how to handle data that is entered in the old and in the new edition (can be technically done with cross edition triggers, but might not always be logically done). I also doubt it would be possible for sys-objects or things like v$views . However that would be task of oracle to evaluate.