What you will learn
The supplied plans target Oracle 11.2.0.3 and old Exadata generations. They are historical notes, not a current destination. This tutorial preserves their useful sequencing while requiring an explicit source-to-target compatibility decision. The commands assess readiness; upgrade execution must follow the selected target guide.
Before you begin
Use an isolated Oracle Database 19c Linux lab with a certified patch level. Names host1.sample.com and host2.sample.com identify distinct lab hosts; replace them consistently with your own addresses. Use oracle for database software and grid for Grid Infrastructure where ownership is separated. Connect through local operating-system authentication or a configured wallet; no example includes a password. Preserve a tested backup and record the database identity before changes. Assess a restored source copy using commands supported by its release. Inventory database and Grid versions separately and prepare representative application tests, a target guide, and a recovery-time budget.
1. Inventory the actual source
SELECT banner FROM v$version;
SELECT name,dbid,database_role,open_mode FROM v$database;
SELECT comp_id,version,status FROM dba_registry ORDER BY comp_id;
SELECT name,value FROM v$parameter WHERE name IN
('compatible','cluster_database','db_block_size');
Also record character sets, timezone-file version, installed options, size, invalid objects, external dependencies, encryption, and non-CDB/CDB architecture. Old filenames are not reliable version evidence.
2. Select and analyze the path
Check direct-upgrade source eligibility, platform restrictions, intermediate releases, and multitenant requirements. Some sources need an intermediate upgrade or logical migration. Confirm the supported AutoUpgrade build and Java requirements, then analyze a reviewed configuration:
java -jar /u02/tools/autoupgrade.jar -config /u02/upgrade/demo.cfg -mode analyze
The configuration must identify the actual source SID and home, target home, logging, and destination settings. Analysis does not promise that every old source is eligible.
3. Rehearse the entire change
Restore a copy, resolve precheck findings, and time backup, restore, upgrade, validation, and recovery decisions separately. Test components, statistics, privileges, jobs, listeners, services, and backups. Do not inherit hidden parameters unless still justified for the exact issue and release.
4. Define acceptance and recovery boundaries
Compare representative transactions and query behavior before and after. Distinguish binary installation, dictionary upgrade, and COMPATIBLE changes. Advancing compatibility can restrict downgrade options. Verify monitoring and backups before releasing writes and retain measured recovery timings.
5. Read the example output
The following is illustrative, normalized output, not a transcript from a customer system. Values depend on your release and lab state.
Supported path: checked
Analysis blockers: resolved
Restore duration: measured
Application regression tests: passed
Recovery decision point: documented
Fill this worksheet from the rehearsal; no timings are inherited from the historical environment.
Verify the result
Prove both the target application workload and the chosen recovery path. Compare component status, invalid objects, jobs, and a fresh backup. Utility completion alone is insufficient.
Troubleshooting
Unsupported sources require another path, not skipped checks. Investigate changed optimizer behavior using affected SQL and data rather than resetting every parameter.
Recovery and next steps
Keep source backups and the recovery environment through acceptance and retention. Determine from the guide whether downgrade, flashback, or restore is valid at the point reached. Do not retire the old home prematurely.