There’s a problem most people who’ve had to do production datafixes have encountered at some point: you need to update a dataset. Unfortunately there’s a trigger on the target table. The trigger either prevents the update outright or just has some unwanted side effects (firing off a business process, etc.). The trigger is necessary for the application to function correctly, so you can’t just drop it.
How do you apply the changes?
You can take an outage so you can drop/disable the trigger while applying the fix. Alternatively you can modify the application so that the trigger is no longer necessary. Scheduling the outage can be difficult (particularly if the fix is urgent). Changing the application may take a long time or even be infeasible if it’s supplied by a third party.
How can you get out of this dilemma?
Fortunately in Oracle 11gR2 and higher there is another way:
create edition to_do_your_dirty_work; alter session set edition = to_do_your_dirty_work; drop trigger which_breaks_your_datafix; update the_table_with_the_trigger set the_data = 'values prevented by your trigger'; alter session set edition = back_to_your_original_edition; drop edition to_do_your_dirty_work cascade;
Using edition-based redefinition you can create a new edition and drop the trigger just in that edition. The application will still function as desired because the trigger still exists in the old edition. All you need to worry about now is concurrency issues… ;)
Warning: you must first editions enable your application before you can do this. Only some object types are “editionable” (see the comments). If you have non-editioned objects that depend upon editioned objects you’ll need to make some changes to your application before you can do this! Doing this is also a “one-way” operation – to revert it you need to recreate your user/restore from backup!
For a complete script showing this in action, click here.
For some further reading on EBR, have a look at the following: