A release upgrade is accepted when the database is healthy, the application produces the required results, and the recovery choices are understood and tested. A normal database startup is an early check. The application's transactions, stored code, client connections, data interpretation, and performance still need verification.
Oracle DBA Lesson 82 Part 3 — Treat an Upgrade as an Application Change
Release update and release upgrade
| Change | Main purpose | Application work |
|---|---|---|
| Release Update within an existing release | Apply the selected release's maintenance fixes through its documented binary and SQL work | Test affected behavior and the required application workload |
| Upgrade to a different database release | Move database operation and dictionary components to the target release | Review feature changes and compatibility, then repeat database, client, functional, integration, and performance tests |
Both require change planning, backups, and verified recovery. A release upgrade adds release-specific changes that may require application or client changes. A successful tool completion must be followed by the post-upgrade work and acceptance tests for that environment.
Prepare the release path and application tests
Record the exact source and target versions, architecture, edition, platform, installed components, current COMPATIBLE, and intended upgrade method. Resolve all prerequisites for that combination. Recheck the current supported AutoUpgrade build and its Java and runtime requirements. Examples in an older guide do not guarantee that the current tool uses the same options or runtime.
Oracle's 19c Upgrade Guide lists 12.2.0.1 as a supported source for direct upgrade. Check the exact edition, platform, patch levels, features, drivers, application certification, and selected upgrade-tool version for the actual change. Use the guide for the actual target when it differs. See releases that support direct upgrade.
Use AutoUpgrade readiness analysis for the selected target and interpret its findings. Analyze mode gathers readiness information without making database updates. It does create reports, and it requires a valid configuration and appropriate access. A change mode such as Fixups or Deploy has different effects. See pre-upgrade checks using AutoUpgrade.
Before scheduling the change:
- Resolve blocking pre-upgrade findings and repeat the analysis.
- Review deprecated features and features unsupported in the target. Deprecation signals a feature's lifecycle status. It does not by itself mean the feature has already been removed. A removed dependency may require an application replacement.
- Check the actual application client, driver, and authentication combination. Record certification evidence for the exact versions.
- Include time zone sensitive dates in the tests. Follow the pre-upgrade report and the target-specific procedure for any required time zone file update.
- Include representative character data and compare its stored and displayed meaning. A database release upgrade does not automatically change its character set. Any desired conversion needs its own supported plan and tests.
- Save the application's existing expected outputs and performance under representative load. Use the same meaningful inputs and comparable conditions after the upgrade.
A useful order test checks that an application can connect through its normal service, save an order, calculate the correct total, and retrieve the saved values. Add the real integrations, scheduled work, error handling, and concurrency that the application needs. One transaction alone is only a bounded example. See how to develop an upgrade test plan.
Collect database evidence before and after
Capture the inspection before and after the upgrade. Record the time, connected container, database identity, version, and run identifier with each set of results. These commands inspect state. They do not perform an upgrade.
SHOW CON_NAME
SHOW PARAMETER compatibleThese are SQL*Plus commands. SHOW CON_NAME identifies the connected container. SHOW PARAMETER compatible displays the current compatibility setting. In a multitenant database, COMPATIBLE is controlled at the container database level and cannot be set separately in a PDB. Record it in the correct administrative scope.
SELECT comp_id, version, status
FROM dba_registry
ORDER BY comp_id;DBA_REGISTRY describes installed database components. Compare the intended target component versions and acceptable status with the saved baseline and the required postchecks. An absent or changed component needs an explanation. The registry alone does not establish correct application behavior.
SELECT owner, object_type, COUNT(*) AS invalid_count
FROM dba_objects
WHERE status = 'INVALID'
GROUP BY owner, object_type
ORDER BY owner, object_type;This query groups invalid objects by owner and object type in the current scope. It helps locate a change in invalidity. It does not identify which object changed, and a similar count can conceal different objects. Preserve the actual object identities as well.
Saved package-body counts for application owner APP_USER:
| Stage | Owner | Object type | Invalid count |
|---|---|---|---|
| Before | APP_USER | Package body | 2 |
| After | APP_USER | Package body | 3 |
STAGE is an annotation used to align two saved query results. The query does not return that column. These rows are the relevant excerpt. They are not a claim that other owners or object types are absent.
To identify the objects, collect their names and status:
SELECT owner, object_name, object_type, status
FROM dba_objects
WHERE owner = 'APP_USER'
AND status = 'INVALID'
ORDER BY object_type, object_name;APP_USER is the application owner in this example. Compare the saved object lists. Inspect a specific object's earlier status when establishing whether it became invalid.
| Package body | Before | After | Interpretation |
|---|---|---|---|
LEGACY_EXPORT | INVALID | INVALID | Pre-existing invalidity; assign ownership and a resolution decision |
LEGACY_REPORT | INVALID | INVALID | Pre-existing invalidity; assign ownership and a resolution decision |
ORDER_API | VALID | INVALID | Newly invalid in this example; investigate before accepting the order transaction |
The ORDER_API row is established by the saved identity and status comparison, not inferred from the count alone. Investigate errors, dependencies, missing or changed features, privileges, and the relevant logs. Apply the supported correction and repeat the transaction. Keep the original evidence so the correction and retest can be traced.
Oracle documents post-upgrade recompilation procedures. Select them for the actual tool and environment. Recompiling all schemas does not substitute for diagnosing an application failure. Current AutoUpgrade behavior can distinguish Oracle-maintained objects from application-owned objects. Verify the tool version and review the remaining application invalids explicitly. See required post-upgrade tasks.
From the container database root, inspect PDB state:
SELECT name, open_mode
FROM v$pdbs
ORDER BY con_id;Interpret each expected PDB according to its intended role. A seed can normally be read only. Application PDB requirements depend on their use. A container that is not read-write is not automatically a failure. A root query's component or object results do not automatically describe each application PDB. Collect the required component and object results in each relevant container, and verify that the application connects to its intended service and container. See DBA_REGISTRY, DBA_OBJECTS, ALL_OBJECTS column definitions, and V$PDBS.
Acceptance includes application results
| Area | Required evidence |
|---|---|
| Upgrade procedure | Required logs and postchecks complete for the selected method |
| Components | Intended versions and acceptable status in scope |
| Objects | Identity-based comparison; new problems diagnosed and corrected; pre-existing issues assigned |
| Containers and services | Required PDB states, correct routing, and successful actual-client authentication |
| Functional behavior | Correct saved data, order totals, dates, text, and relevant integrations |
| Performance | Comparable workload; response times and throughput meet stated limits |
| Downtime | Measured full service interruption, including required verification |
| Recovery | Supported fallback successfully rehearsed within its time and data-loss requirements |
For the order example, resolving ORDER_API invalidity is followed by another order transaction, a data comparison, and a performance check. Keep a failed acceptance item open until its required result is achieved and recorded. Some failures reveal an application dependency rather than an error in the upgrade utility.
Use existing application timing and load records, or other methods that fit the environment. Optional Oracle performance or replay features require their applicable licensing and configuration. See recommended post-upgrade practices and application tests.
Manage COMPATIBLE as a separate decision
COMPATIBLE controls release compatibility of database disk formats and structures, and therefore the availability of some release-dependent features. It is not the displayed database software version, an application compatibility score, or an RU number.
For a 12.2.0.1-to-19c upgrade:
| Item | Example value | Meaning |
|---|---|---|
| Source software | 12.2.0.1 | The earlier database release |
| Upgraded software | 19c | The new release running after the upgrade |
Retained COMPATIBLE | 12.2.0 | A supported earlier compatibility level retained while testing and preserving the documented downgrade option |
| Later proposed increase | 19.0.0 | Enables applicable newer formats and features and prevents downgrade to the earlier release |
Once raised, the parameter cannot be lowered. Raising it to the target release can permit structures on disk that the earlier release cannot process. Oracle recommends completing testing before an increase. For a Release Update within 19c, leave the compatibility level at the appropriate release value. Do not change it to the RU version.
Before deciding to increase it, establish:
- Required database and application acceptance tests are complete.
- The documented downgrade choice is understood, and the decision to relinquish it is deliberate.
- The recovery approach that remains after the increase has been checked and rehearsed for the actual configuration.
- Backups, software, keys, capacity, timing, service routing, and data handling support that recovery approach.
Keeping the earlier setting is only one prerequisite for a documented downgrade. Supported source and target releases, features, architecture, and the full procedure still matter. A downgrade, a database restore, and Flashback Database have different requirements and data consequences. Changing to the old Oracle home alone does not carry out a database downgrade.
A restore point does not automatically remain usable across a compatibility increase. Check the specific Oracle restrictions before choosing a restore or flashback route. When Flashback Database or another optional feature is part of the plan, verify its edition, licensing, prior configuration, and exact procedure.
Account for application writes after cutover. A return to an earlier backup or restore point can lose later transactions unless a supported reconciliation or synchronization approach is part of the plan. Decide when to stop new writes, what the acceptable data-loss boundary is, how the application state will be reconciled, and how restored service will be validated. Record the last point at which each fallback method is still available.
See what Oracle Database compatibility means, the COMPATIBLE parameter, and downgrading a database.
Recap
Accept a release upgrade when the database is healthy, the application produces the required results, and the recovery choices are understood and tested. Startup is an early check. Compare invalid objects by identity with the baseline, correct the objects the upgrade changed, and repeat the transaction. Raise COMPATIBLE only after that acceptance, and only when giving up the documented downgrade is a deliberate decision backed by a checked recovery approach.
No comments:
Post a Comment