A patch rehearsal establishes that the selected change can complete, that its results meet the required checks, and that the fallback can return service within the available window. It should test the actual procedure, including its failure branches.
Oracle DBA Lesson 82 Part 2 — Rehearse a Patch with a Timed Fallback
Start from a reconciled baseline
Use the database-to-home mapping, binary inventory, per-container SQL patch history, and component state collected in Part 1. Resolve outstanding discrepancies before rehearsing the next change. Investigate and resolve an existing unresolved patch failure before the rehearsal.
A representative clone should match the material characteristics of the proposed deployment: database version and edition, installed fixes and components, container coverage, encryption, operating system, and relevant application workload. Isolate it from production services, outbound jobs, and customer activity. Protect the recovery copies and keys outside the failure domain being tested.
Write down the specific goal, such as addressing a known defect or moving to a selected supported patch baseline. Resolve the exact package and its README. Record the required OPatch or orchestration-tool version, the supported source and target, dependencies, conflicts, shutdown and open-mode requirements, and the supported rollback procedure. Obtain certification and package-specific support information through the appropriate Oracle support entitlement. Exact patch commands depend on the patch package, Release Update, platform, topology, and chosen maintenance tool.
See Oracle Database patch maintenance for the selected README, conflict checks, and maintenance methods. Distinguish later-release guidance on that evolving page from the 19c material.
Complete the rehearsal record before applying a patch
PATCH REHEARSAL RECORD
1. Patch ID; source/target RU; README revision; certification evidence
2. Homes, databases and containers in scope; service routing and outage ownership
3. Prerequisite/conflict commands from that procedure; captured results
4. Tested backup/recovery route; required software, keys and rollback material
5. Binary phase; required SQL phase; expected log and result locations
6. Abort conditions; supported fallback steps; decision deadline; operator
7. Postchecks: home inventory, container SQL state, components, applicationPopulate every line for the selected target. Keep actual execution times and outputs beside the documented expectations. A check without evidence stays open. Before starting, confirm that backup recoverability, required encryption keys, and the fallback media are available. A restore point is suitable only when its requirements, feature eligibility, storage retention, and limitations have been verified. Naming a restore point alone does not establish recoverability.
Plan required service draining, shutdowns, and background-job handling according to the procedure. Oracle's patch-maintenance guidance includes stopping Data Pump activity during maintenance. Account for relevant data-movement jobs in the change plan.
A failed prerequisite is a stop before mutation
An unresolved conflict with an already installed fix stops the rehearsal before the binary phase.
| Rehearsal prerequisite | Result | Decision |
|---|---|---|
| Conflict check for the selected patch | Unresolved conflict | Stop before the binary phase |
| Supported conflict resolution | Pending | Obtain the documented resolution or required merge/replacement |
| Repeated prerequisite checks | Pending | Continue only after required checks pass |
Record the conflicting patches, affected fixes, and exact diagnostic output. Do not suppress the conflict with an arbitrary force option. Resolve it using the selected package's instructions and Oracle support guidance as required. A prevented apply is a useful result: it exposes a prerequisite problem before software or database state changes.
Understand what each phase changes
| Phase | State changed | Evidence to retain |
|---|---|---|
| Binary phase | Programs, libraries, and other software in the selected Oracle home on disk | Maintenance-tool logs and the resulting home inventory |
| SQL phase, when required | Objects inside the database, in the required container scope | Datapatch logs and SQL patch attempt records |
The binary phase follows the exact README. An out-of-place strategy prepares a separate patched home and later runs the database from that home through the supported switching procedure. Retain the original home and its needed configuration while the fallback remains required. In-place procedures and orchestration tools have their own requirements. There is no universal apply command.
A patch containing SQL changes also needs its SQL work completed. Datapatch performs those actions and records attempts in DBA_REGISTRY_SQLPATCH. The database must be in the required state for those actions. Include every container required by the procedure, and account explicitly for closed or skipped PDBs whose SQL work is deferred. Handle the root, seed, and application PDBs through the documented tooling and prerequisites. Do not improvise manual seed modifications.
Whether a maintenance tool runs datapatch automatically is tool- and procedure-specific. Record that behavior and verify its results. Running a second invocation blindly can obscure the cause of an earlier problem.
See DBA_REGISTRY_SQLPATCH for SQL attempt actions, statuses, and log locations, and datapatch and container prerequisites.
Collect and interpret acceptance evidence
From the verified target Oracle home, the inventory command is:
"$ORACLE_HOME/OPatch/opatch" lsinventoryCheck the reported home and the expected patch set, including relevant one-offs. Retain the complete output and tool logs.
In SQL*Plus, for each required container:
SHOW CON_NAME
SELECT patch_id, action, status, action_time, logfile
FROM dba_registry_sqlpatch
ORDER BY action_time;
SELECT comp_id, version, status
FROM dba_registry
ORDER BY comp_id;SHOW CON_NAME is a SQL*Plus command identifying the current container. The queries need the dictionary privileges required in that scope. Use a connection for each container, or a correctly scoped collection whose container visibility has been verified.
Interpret the latest relevant action for each intended patch alongside its history, binary state, and logs. APPLY and ROLLBACK identify the attempted SQL operation. SUCCESS records an attempt completed without errors. WITH ERRORS requires investigation. LOGFILE locates that attempt's log. An earlier success may have been followed by a rollback or another attempt.
Compare component status with the recorded baseline and the required acceptance criteria. Follow the applicable post-patch procedure for compilation and unresolved component errors. A blanket requirement that every pre-existing application object be VALID can misstate the intended baseline. Determine the actual criteria before the rehearsal.
Acceptance also includes application behavior. Use representative connection and transaction tests with known expected results, application ownership, and a cleanup plan. Include the defect being fixed when a reproducible test exists. Keep service under maintenance control until the required results have been accepted.
| Required check | Required result | Actual result before testing |
|---|---|---|
| Home inventory | Intended home and patch set | Pending |
| Binary/SQL logs and container actions | Required phases complete without unresolved failures | Pending |
| Component state | Meets baseline and patch acceptance criteria | Pending |
| Application connection and transaction | Correct expected behavior | Pending |
These rows are acceptance requirements. They are not observed passes.
See OPatch syntax and commands for tool command roles. That page is not a patch-specific execution sequence. See required post-upgrade tasks for applicable component recompilation. This part is patch rehearsal, not a release-upgrade procedure.
Failure after the binary phase
A rehearsal can reach this state:
| Check | Result |
|---|---|
| Binary phase | Completed |
| SQL APPLY in one required container | WITH ERRORS |
| Application acceptance | Pending |
| Service release | Held |
Retain the failed invocation's log, its affected container, and the relevant registry entry. Determine the cause and the supported correction. A further attempt must still fit within the available forward-work budget and leave time for fallback and verification. A completed software phase alone does not resolve this SQL failure.
This state is a decision. It does not prescribe a universal retry, rollback, or recovery command. Actual failure handling depends on the selected patch and the state reached.
Test the complete fallback route
Switching to an earlier Oracle home selects earlier executable software. Database SQL changes affect database objects, so the supported fallback may also require SQL rollback or database recovery. The retained old home is one part of that route.
Oracle's 19c AutoUpgrade patching documentation provides an example of this distinction: its restoration choices include a datapatch-based reversal or a qualifying guaranteed-restore-point/Flashback route. Those features have tool, edition, and preparation requirements. Do not transplant that command sequence into a manual OPatch procedure.
Before the change window, demonstrate the chosen route in the clone, including the resulting binary/SQL consistency, required container availability, and application checks. Record elapsed time and any prerequisites. Recovering database state can discard changes after the recovery point. Isolate the clone and prevent unintended application writes. The recovery design must address the corresponding data-loss boundary for the real operation.
See AutoUpgrade patching for the out-of-place workflow and database-state restoration choices, and applying software updates for representative testing, backups, and a proven rollback. Apply tool-specific recommendations only where that tool supports them.
Work backward from the end of the window
Measure minutes from the start of the maintenance window. For this plan the figures are:
- Total window: 60 minutes.
- Allowance for the tested fallback route: 20 minutes.
- Allowance to verify restored service after fallback: 10 minutes.
Take the real allowances from rehearsal evidence, with a realistic contingency margin.
Latest fallback decision = window − fallback allowance − restored-service checks
= 60 − 20 − 10
= minute 30| Elapsed interval | Reserved use if the forward change fails |
|---|---|
| 0–30 minutes | Forward change and its acceptance decision |
| 30–50 minutes | Execute the tested fallback |
| 50–60 minutes | Verify restored service |
If required acceptance remains unresolved at minute 30, begin the tested fallback. Start earlier when a stop condition, an unsafe state, or an updated estimate requires it. The deadline is the latest decision boundary. A known stop condition starts fallback at once, ahead of that boundary. If the fallback or verification estimate grows, move the deadline earlier. An insufficient window requires a revised plan before applying the patch.
This allocation is a planning calculation of the reserved minutes. It is separate from the elapsed time of an actual patch. The final acceptance test remains essential after fallback.
Recap
Rehearse the selected procedure, including its failure branches, and show that the chosen fallback can return service inside the window. Stop before the binary phase when a prerequisite conflict is unresolved. Keep the home inventory and the SQL patch results as separate evidence, and include every required container. When acceptance is still open at the latest decision point, start the tested fallback and leave time to verify restored service.
No comments:
Post a Comment