Fix adop phase=prepare Failures in EBS 12.2 Online Patching
adop phase=prepare fails in EBS 12.2 online patching
Also searched as
- 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
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.
Applies to: EBS 12.2.0 through 12.2.11 and later (Online Patching, adop utility)
How to recover from an adop prepare phase failure
- 1Run 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.
- 2Open 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.
- 3Confirm 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.
- 4If 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.
- 5Check 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.
- 6Verify 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.
- 7If 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.
- 8Once 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.
Why prepare depends on the previous cycle finishing cleanly
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
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.
adop -status
adop phase=fs_clone
Invalid objects and TNS or context mismatches
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
What is the first command to run when adop prepare fails?
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?
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?
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?
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?
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.
Related
Fix FRM-40735: WHEN-VALIDATE-RECORD Trigger Raised Unhandled Exception ORA-06508
FRM-40735 with ORA-06508 almost always means a PL/SQL package used by the form was recompiled while your session still held the old cached state, or the trigger's own exception handling does not trap a real data error. Exit the form completely and re-enter it; if the error repeats for all users, recompile invalid objects on the database and check for a bad custom trigger.
Error fixOracle EBS Concurrent Manager Will Not Start: How to Fix It
A concurrent manager that will not start in Oracle EBS is almost always one of three things: the node registered in FND_NODES no longer matches the actual hostname (common after cloning), stale OS processes are blocking a fresh start, or the database and listener the manager connects to are unreachable. Check the internal manager log, verify the node name, clear stale processes, and restart with adcmctl.sh.
Error fixFix Oracle EBS Workflow Notification Mailer Not Sending Emails
When EBS notifications stop reaching inboxes, check the mailer status in Oracle Applications Manager (OAM) Workflow Manager first - a Suspended or Error status almost always points at an SMTP or IMAP connectivity or credential problem introduced by a mail server change, not at Workflow itself. Fix the mail server configuration, restart the mailer component, and requeue the backlog.
Error fixFix ORA-01555: Snapshot Too Old in Oracle EBS Concurrent Requests
ORA-01555 in a concurrent request means the program tried to read data from undo that has already been overwritten, usually because the report or custom PL/SQL ran long enough, or committed often enough mid-cursor, that the undo tablespace could not retain the needed read-consistent image. Increase UNDO_RETENTION and undo tablespace size first, then review the program for commits inside open cursor loops.
How-toHow to Import AP Invoices in Oracle EBS with Payables Open Interface Import
Load invoice header and line data into AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE, then run the Payables Open Interface Import concurrent program to create standard invoices in Oracle Payables. Rows that fail validation land in AP_INTERFACE_REJECTIONS with a specific reject reason you can query directly, without opening the Invoice Workbench.
How-toHow to Use Forms Personalization in Oracle EBS (No CUSTOM.pll Needed)
Forms Personalization lets you change field properties, set defaults, run built-ins and show messages on any Oracle Forms screen through Help > Diagnostics > Custom Code > Personalize, with no custom library or forms compile required. Rules are stored per form and responsibility in FND_FORM_CUSTOM_RULES and apply at runtime for every user who opens that form.
AI for ERPAI for Oracle E-Business Suite, Without Leaving On-Prem
Add AI to Oracle E-Business Suite 12.2 without moving off-prem. Query concurrent programs, interface tables, and AP/PO data with a private LLM. See how.
AI for ERPAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
Stuck on Oracle E-Business Suite (EBS)?
Talk to engineers who work inside Oracle E-Business Suite (EBS) every week, and who build private AI that answers these questions from your own ERP data.