What to do (and not do) when TuneVault shows the red ADOP banner.
*_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.
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.
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 |
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. |
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:
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.
The ADOP banner clears automatically when:
*_ebs_patch services are no longer registered in V$ACTIVE_SERVICES (post-cleanup phase).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.