In general, patching or upgrading the artifacts in an Oracle Database hat jointly implement an application’s back end involves changing two or more functionally dependent objects. Because each
DDL autocommits, such changes inevitably imply that the system is mutually inconsistent once the patching begins and that its integrity is regained only when patching completes. Moreover, so-called
“hot patching”—doing create or replace on even a single object, while that object is among the set of objects in ordinary concurrent use by the application, is in general unsafe. Before EBR, your only
option, therefore, was to take downtime. EBR allows you to create a semantic copy of the live system within the same database so that you can make your changes to this while the live system remains in
uninterrupted use. A copy-on-write scheme is used so that only changed objects occupy space. Of course, the quota-consuming data must be mutually synchronized, transactionally, and without
harming performance for ordinary users. EBR supports this too. This workshop explains how it all works. This seminar starts at 9am, and runs through 5pm.
Distinguished Product Manager for PL/SQL and EBR