# ADOP Patch Cycle — Safe vs. Misleading Health Checks

What to do (and not do) when TuneVault shows the red ADOP banner.

🔴 You're here because TuneVault detected active ADOP patch services (`*_ebs_patch` in `V$ACTIVE_SERVICES`). This means Oracle's online patching cycle is in progress — the RUN and PATCH filesystems are split. Health metrics captured now describe a transient state, not steady-state production.

## How ADOP Online Patching Works

ADOP (AD Online Patching) splits EBS into two filesystem editions: the RUN edition (live production) and the PATCH edition (where patching happens). Oracle signals this by registering `APPSSID_ebs_patch` and `DBSID_ebs_patch` services in the listener — exactly what TuneVault detects via `V$ACTIVE_SERVICES`.

While ADOP is active, the database itself is normal — all DB-level metrics (tablespace, sessions, wait events) reflect production accurately. But application-tier objects are in flux: Concurrent Managers may run on the RUN edition while the patch edition is being updated, Workflow Mailer state is frozen, and FNDLOAD/APEX metadata may be mid-migration.

## ADOP Phases

Each phase changes what TuneVault can reliably measure:

Phase | What's happening | Risk level
--- | --- | ---
PREPARE | Patch filesystem being set up. RUN edition fully operational. DB-level checks safe. | Low
APPLY | Patches being applied to PATCH edition. Concurrent queue depth is partially cut over. Workflow Mailer is frozen on RUN edition. | Medium
CUTOVER | Production flips from RUN to PATCH edition. This is the window of maximum flux — some sessions disconnect, new ones connect to the new edition. Avoid ALL destructive ops. | High — avoid ops
FINALIZE | Old RUN edition being cleaned up. System is on new edition. Most operations safe again. | Low
CLEANUP | Housekeeping. Old edition objects removed. Fully safe. | Safe

## Check Safety Matrix

The following table lists TuneVault's health checks and whether they are reliable during ADOP.

Check | Category | Safe during ADOP? | Why
--- | --- | --- | ---
Tablespace Usage | Storage | ✓ Safe | Reads `DBA_TABLESPACE_USAGE_METRICS` — DB-level, unaffected by ADOP filesystem split.
FRA Usage | Storage | ✓ Safe | Reads `V$RECOVERY_FILE_DEST` — pure DB metric.
Archive Log Rate | Storage | ✓ Safe | REDO generation is a DB-level metric. ADOP does not affect archive rate directly.
Undo Utilization | Storage | ✓ Safe | UNDO usage reflects live transactions — valid, though ADOP cutover briefly spikes it.
Temp Space | Storage | ✓ Safe | Temp tablespace usage is DB-level.
Top SQL by CPU/Reads | Performance | ⚠ Caution | During APPLY, patch-edition SQL may skew the top list. Values are real but context-dependent.
Wait Events Summary | Performance | ⚠ Caution | ADOP APPLY generates heavy I/O and library cache activity. Wait events are real but inflated.
Blocking Sessions | Sessions | ✓ Safe | Real blocking is still a problem. Report is accurate.
Long-Running Sessions | Sessions | ⚠ Caution | ADOP workers run as long-running sessions. They're expected — not a sign of DBA intervention needed.
Instance Parameters | Configuration | ✓ Safe | DB parameters are unaffected by ADOP.
Invalid Objects | Configuration | ✗ Misleading | ADOP intentionally invalidates objects during APPLY. Report will show hundreds of invalids — this is normal and expected.
Stale Statistics | Performance | ✗ Misleading | ADOP gathers stats on the patch edition. Stale stat alerts during APPLY are ADOP-normal, not DBA action items.
Concurrent Manager Queue Depth | EBS | ✗ Misleading | During CUTOVER, ICM re-initializes. Queue depth reflects the cut-over transition, not a stuck manager. Do not bounce CM.
Workflow Mailer State | EBS | ✗ Misleading | WF Mailer is intentionally suspended during ADOP APPLY. The "stopped" status is expected. Do not restart it.
FND Top Programs | EBS | ⚠ Caution | Patch-edition jobs (ADOP stages) show up as top programs. Not actionable during patching.
EBS System Health (APPS.DUAL probe) | EBS | ✓ Safe | Connectivity probe. Always safe — just verifies DB→APPS schema path is alive.
Patch Level / Last CPU | EBS | ✓ Safe | Reads `AD_APPLIED_PATCHES` — read-only, unaffected by in-flight ADOP.
ETCC Check Status | EBS | ⚠ Caution | ETCC results will change after the patch is applied. Run after CLEANUP for a meaningful result.

## Operations Blocked During Patching

TuneVault blocks the following operations when `patching=true`. These carry a high risk of interfering with the ADOP session or leaving the system in an inconsistent state:

- Bounce/Start/Stop Concurrent Manager — ICM re-init during cutover is ADOP-managed.
- Restart Workflow Mailer — intentionally suspended; restarting it mid-ADOP can corrupt WF state.
- Kill Sessions — ADOP workers look like long-running sessions; killing them aborts the patch.
- Rolling bounce (WLS/Apache/OHS) — app-tier bounces during cutover break the in-flight filesystem flip.
- Parameter changes (ALTER SYSTEM) — risky at any time; forbidden during active patching.

To override a block, enter the ADOP session ID (shown in the banner) in the override field. This is intentionally friction-heavy — only do this if you have confirmed with the patching DBA that the operation is safe at the current phase.

## What Is Safe During ADOP

- Running a full health check (all storage + session + configuration checks are accurate).
- Viewing tablespace growth, FRA, archive log rate.
- Reviewing blocking sessions and killing non-ADOP blockers.
- Accessing the ADDM panel (task-based analysis of pre-ADOP baseline is valid).
- Viewing patch history, EBS version levels, ETCC results (for informational context).
- Exporting PDF/XLSX reports (the data is valid, with the caveats noted above).

## After Cutover — Clearing the Banner

The ADOP banner clears automatically when:

- The `*_ebs_patch` services are no longer registered in `V$ACTIVE_SERVICES` (post-cleanup phase).
- A new health pack runs — the detector re-checks on every health-pack completion.
- You click the ↻ Refresh button on the banner (rate-limited to once per 60s).

After cutover completes, re-run the full health check to get a clean baseline on the new production edition. The "Invalid Objects" count will normalize within minutes as the background recompilation job runs.

← Back to Deep EBS Mode DBA Role Setup Guide →