# Fix adop phase=prepare Failures in EBS 12.2 Online Patching

> Source: https://netray.co/erp-help/ebs-adop-prepare-phase-failure-fix
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

An adop prepare phase failure in EBS 12.2 almost always means the patch edition (patch file system) and the run edition are out of sync, or a previous cutover or cleanup did not complete cleanly. Read adop.log for the specific worker error, resync the file systems with adop phase=fs_clone if needed, and never start a new patch cycle on top of an unfinished one.

## Kind

error

## System

oracle-ebs

## Erp

Oracle E-Business Suite (EBS)

## Module

System Administration / adop Online Patching

## Query

adop phase=prepare fails in EBS 12.2 online patching

## Alternate Queries

- adop prepare phase failure R12.2
- adop fs_clone failed EBS 12.2
- adop patch cycle stuck prepare phase
- AD_ZD file system sync error adop

## Applies To

EBS 12.2.0 through 12.2.11 and later (Online Patching, adop utility)

## Steps

### How to recover from an adop prepare phase failure

**Items:**

Run adop -status first to see exactly which phase and node the cycle stopped at, and whether any earlier phase (apply, finalize, cutover) is actually incomplete.

Open the session log referenced in the adop output, then drill into the worker log under $APPL_TOP/admin/CONTEXT_NAME/log/ for the specific SQL or file error that failed.

Confirm the patch edition and run edition file systems are actually in sync - a prepare failure frequently follows an interrupted previous cycle that left them mismatched.

If the file systems are out of sync and no patch session is genuinely in progress, resynchronize them with adop phase=fs_clone, which recreates the patch file system from the current run file system.

Check for invalid objects before retrying: query ad_zd_mismatches or dba_objects for status = 'INVALID' in the patch edition context - unresolved invalids from a prior cycle commonly block prepare.

Verify database connectivity and TNS entries for both the run and patch editions are correct in the context file; a stale or duplicated TNS alias after a change is a frequent, easy to miss cause.

If a worker genuinely failed mid-phase, do not just re-run adop blindly - check whether it needs adop phase=prepare force=yes, or whether abort/cleanup is the correct recovery depending on how far the cycle progressed.

Once resolved, complete the standard cycle in order: prepare, apply, finalize, cutover, cleanup - do not skip cleanup, since a lingering completed but uncleaned cycle is exactly what causes the next prepare to fail.

## Sections

### Why prepare depends on the previous cycle finishing cleanly

**Body:**

R12.2's Online Patching model keeps two full copies of the application tier - the run edition users are actively on, and the patch edition being updated in the background - and adop phase=prepare is the step that gets the patch edition ready to receive a new patch. If the last cycle's cleanup phase never ran, or cutover was interrupted, the patch edition can be in a state the next prepare does not expect, and it fails rather than risk corrupting either edition.

This is why adop -status is always the right first command before touching anything else: it tells you definitively whether you are starting a fresh cycle on a genuinely clean base, or unknowingly trying to layer a new patch on top of a cycle that never finished, which is by far the single most common self-inflicted cause of prepare failures in a busy patching schedule.

### File system sync issues

**Body:**

Because the patch edition file system is essentially a clone of the run edition file system with edition-based redefinition applied, anything that changes the run file system outside of the adop workflow - a manual file copy, an out-of-band customization deployment, or a failed prior fs_clone - can leave the two out of sync. adop phase=fs_clone exists specifically to rebuild the patch file system from the current run file system when this happens.

Plan for an fs_clone to take real, noticeable time on a multi-node install, since it copies the entire application tier file system out to every node in the farm, not just the one you are working on. Running it during a scheduled maintenance window rather than in the middle of a production incident avoids compounding an already stressful patching problem with a long, rushed file system rebuild under pressure.

**Code:**

- adop -status
- adop phase=fs_clone

### Invalid objects and TNS or context mismatches

**Body:**

A prepare phase can also fail because of invalid database objects left in the patch edition schema from an earlier interrupted cycle, or because the context file has a stale TNS entry after a network or listener change. Both produce worker-level errors that look database-related rather than adop-specific, so always read the actual worker log rather than only the top-level adop summary.

Resolve invalid objects in the patch edition schema before retrying prepare, since adop expects that schema to compile cleanly at each phase boundary as a precondition, not an afterthought. Even a small handful of leftover invalid objects from an earlier aborted cycle is enough to block the next prepare outright, so check dba_objects in the patch edition context specifically, not just the run edition.

## Pitfalls

- Re-running adop repeatedly without reading the worker-level log, which hides the real SQL or file error behind a generic phase failure message.
- Starting a new patch cycle before confirming the previous one fully completed cleanup - this is the most common cause of a mysterious prepare failure.
- Manually copying files into the run or patch file system outside the adop workflow, which desynchronizes editions in ways fs_clone is needed to fix.
- Ignoring invalid objects left over from a prior interrupted cycle instead of resolving them before the next prepare.
- Treating adop phase=abort as a routine reset without understanding what state it leaves the environment in - use it deliberately, not as a first troubleshooting step.

## Ai Angle

ERPray grounded on the EBS filesystem and the adop worker logs can scan the latest patch cycle's logs, correlate them against ad_zd_mismatches and the context file's TNS entries, and tell an EBS DBA in plain terms whether a prepare failure is a leftover unfinished cycle, a file system sync problem, or a genuine database issue - narrowing hours of log diving to the specific phase and object that needs attention.

## Faq

### What is the first command to run when adop prepare fails?

**Answer:** adop -status, always, before touching anything else in the environment. It shows exactly which phase and which node the cycle actually stopped at, and whether an earlier phase such as apply or cutover is still incomplete, which changes the correct recovery path significantly.

### When should I use adop phase=fs_clone?

**Answer:** Use it when the patch edition file system is genuinely out of sync with the run edition and no patch session is actually mid-cycle on the environment. It rebuilds the patch file system cleanly from the current run file system across every node, resolving most file-system-level prepare failures in one step.

### Is it safe to just re-run adop phase=prepare after a failure?

**Answer:** Only after reading the worker log in full and confirming the previous cycle is genuinely in a clean, resumable state rather than partially applied. Blindly re-running adop without understanding why the first attempt failed can compound the problem and make the eventual recovery considerably more involved.

### Can a TNS or listener change break adop even if the patch itself is fine?

**Answer:** Yes - the context file holds separate TNS entries for both the run and patch editions, and a stale or recently changed listener alias produces worker-level connection failures that look exactly like a patching problem but are actually a network or database configuration issue outside adop's control.

### What does adop phase=abort do and when should I use it?

**Answer:** It cancels the current online patching cycle outright and moves the environment back toward a clean, known state rather than leaving it half-patched. Use it deliberately, only when a cycle is genuinely unrecoverable, and always confirm the result with adop -status afterward before starting any new patch cycle.

## Search terms

adop prepare phase failure, adop fs_clone EBS 12.2, adop patch cycle stuck, EBS online patching error, AD_ZD mismatch adop, adop -status EBS, R12.2 adop worker log error, adop phase=abort EBS, EBS 12.2 patch edition sync, adop cutover failure

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json