Patch a live ERP without taking it down? Nearly.
Online patching is the headline feature of EBS 12.2, and the most misunderstood. It does not mean zero downtime. It means the downtime shrinks to one phase — cutover — and everything else happens while users carry on working. Understanding why that works is what stops a patch cycle turning into a weekend.
The idea in one sentence
EBS 12.2 keeps two copies of itself. Users run on one. You patch the other. Then you swap them.
That is the whole concept. Everything below is detail about how Oracle makes the swap safe.
The mechanism: two file systems and two editions
The trick has two halves, because an EBS instance is two things — code on disk, and objects in a database.
- A dual file system (fs1 and fs2) handles the code. One file system is the run edition, serving users. The other is the patch edition, where patch work happens. Their roles swap at cutover, so the labels are not fixed to fs1 or fs2 — whichever is running is the run edition.
- Edition-Based Redefinition (EBR), an Oracle Database feature, does the same job inside the database. A patch edition of database objects exists alongside the run edition, so schema changes can be staged while the run edition keeps serving live queries.
This pairing is the point. Plenty of people know about the dual file system and stop there — then wonder why a patch that changes a package still needs the editioning machinery. Code on disk and objects in the database both have to be versioned, or the swap is not atomic.
The cycle
| Phase | What happens | Users |
|---|---|---|
prepare | A patch edition is created — a copy of the run file system, and a patch edition in the database. It persists until cutover or abort. | Online |
apply | Patches are applied to the patch edition of the file system and database. Nobody is on it. | Online |
finalize | Remaining processing is done up front so cutover can be as short as possible. Runs with the application still up. | Online |
cutover | The patch edition becomes the new run edition and the application restarts on it. | Down |
cleanup | Obsolete code and data from old editions are dropped. | Online |
Read the “Users” column again. Four of the five phases are online. That is the entire value proposition, and it is why finalize exists at all — it is pure preparation, moving work out of the downtime window into the online window.
The other phases nobody mentions
ADOP has more than the standard five. The ones worth knowing:
abort— bail out of a patch cycle before cutover. The single most reassuring command in EBS. Ifapplygoes wrong, you are not committed; nothing has touched the run edition.fs_clone— resynchronise the patch file system from the run file system. The usual repair when the two have drifted apart.actualize_all— housekeeping across editions.
abort deserves emphasis. Online patching is often sold on uptime, but the underrated benefit is that most of a patch cycle is reversible. Everything before cutover happens on a copy. That changes the risk profile of patching more than the downtime number does.
Where cycles actually go wrong
The mechanism is sound. The failures are almost always operational:
- Leaving a cycle open. A
preparethat is never cut over or aborted leaves the patch edition hanging around. Storage grows, the next cycle inherits the mess, and someone eventually runsfs_cloneat the worst possible moment. - Skipping cleanup. Old editions accumulate. Cleanup exists for a reason and it is the phase people drop when they are in a hurry.
- Custom code that ignores editioning. Customisations that were not developed against 12.2's editioning rules are where cutovers break. Oracle documents how to develop and deploy customisations for 12.2 precisely because this is the sharp edge.
- Treating cutover as instant. It is short, not free. Services restart. Plan a window, tell the business, and measure how long yours actually takes — it is a property of your estate, not of the product.
- Storage planning. Two full file systems is not a rounding error. If nobody sized for it, you will find out during
prepare.
What good looks like
- Cycles are opened and closed deliberately — never left hanging between maintenance windows.
cleanupruns every time, not when disk alerts fire.- Your actual cutover duration is a measured number, not a guess.
- Customisations follow 12.2 editioning rules, and someone owns that.
- The team has aborted a cycle at least once on purpose, so nobody is afraid to when it matters.
The summary
Online patching does not remove downtime; it relocates it. Four phases run with users online, one does not, and almost everything before cutover can be thrown away without consequence. That combination — a short window plus a genuine undo — is what makes 12.2 patchable at a cadence that keeps you inside Premier Support rather than years behind it.
The technology mostly works. The discipline around it is what decides whether patching is routine or an event.
This article is part of the ROSTAN Oracle Knowledge Hub — our engineering guidance on Oracle EBS, Fusion Cloud, APEX, Database 23ai and OCI, organised by topic.
