Installing, Configuring, and Migrating Oracle AI Database 26ai

Preparing an Oracle database involves several related operations. You install software into an Oracle home, create or provision a database, configure its storage and services, and verify that applications can use it. When an existing database is involved, you also need to decide whether the work is a patch, an upgrade, a move to another host, or a logical migration of data. These choices determine the tools, prerequisites, testing, and maintenance window.

Oracle AI Database 26ai supports modern deployment workflows built around software images, configuration assistants, automation, and managed services. Several of these approaches existed before 26ai; their importance here is how they fit the current release. This lesson explains how to choose among them and identifies changes that matter when updating an older installation. The examples describe planning and verification rather than a complete production installation procedure.

1. Identify the operation before selecting a tool

An Oracle home contains installed software. A database contains persistent data and metadata; an instance supplies the processes and memory used to access it. Installing another home does not automatically move an existing database into it. Similarly, completing a software installation does not prove that an application database exists or that clients can connect.

These operations can be combined in a project. For example, moving a 19c application to a new server might involve installing a 26ai home, preparing a target CDB, converting or migrating the application database, and changing its connection service. Document the complete sequence before treating any single completed step as the finish line.

2. Choose the deployment model

For a self-managed installation, the team must prepare the operating system, accounts, storage, networking, software, and database configuration. This remains true for software installed on a cloud virtual machine when the team manages that machine itself. A managed database service provides a different boundary: the service provisions and operates designated components, while administrators configure the options available through its interfaces.

Before downloading software or requesting a service, record the target edition, platform, Release Update, expected workload, and recovery requirements. Check the applicable installation guide and certification information. Operating system support, package names, available services, and patch procedures can vary. A Linux example should not be applied unchanged to Windows, another processor architecture, or a managed service.

Also identify who owns each decision. Someone must approve maintenance windows, control administrative credentials, monitor capacity, and accept the result of application testing. A service may automate particular tasks, but the project still needs clear acceptance criteria: which application functions must work, which users require access, and what evidence establishes readiness?

3. Install software using the supported packaging route

Image-based installation

Oracle's Linux installation guide describes extracting a database home image into the intended Oracle home and starting the Setup Wizard with that home's runInstaller. Prepare the software owner, groups, directories, storage, and operating system prerequisites first. Follow the prompts for privileged scripts and inspect the installation results. The installer under $ORACLE_HOME/oui/bin/ is not the entry point for this installation workflow.

The Setup Wizard supports applying an RU through -applyRU. Choose the installation image and patch combination according to its documentation. A software-only installation can be followed by database creation, while supported creation options combine those stages. Keep the chosen home path and installation logs in the environment record so subsequent maintenance uses the intended software.

RPM installation on supported Linux systems

Oracle also documents an RPM route for supported single-instance installations. The preinstallation RPM prepares operating system requirements; the database RPM installs the database software. These are distinct packages with distinct purposes. The documented database configuration script can then create a database with default settings. Review those defaults before accepting them for an application.

Select one documented packaging workflow for the environment. Mixing instructions from different editions, Linux releases, or image and RPM procedures can produce an installation that is difficult to maintain. Record which route was used and retain the relevant package or image details.

Repeatable installation and configuration

Silent mode and response files make repeated deployments more consistent. DBCA can obtain its inputs from a response file or supported command options. Build the automation from the templates and command reference supplied for the target release. Protect any credentials used by that process and keep secrets out of ordinary source control.

For example, a team creating development and test environments can store a reviewed set of nonsecret configuration choices, vary only the environment-specific values, and compare completion logs. Automation should fail visibly when prerequisites or configuration steps fail. A process that runs unattended still needs validation of its result.

4. Create a CDB and configure application PDBs

Oracle 26ai uses multitenant architecture. A container database, or CDB, provides the container structure; application schemas normally reside in pluggable databases, or PDBs. New non-CDB installations are no longer supported. Database Configuration Assistant, usually called DBCA, provides supported creation and configuration workflows for this architecture.

Decide the following before completing database creation:

• Identity: Database and PDB names should match the environment plan and avoid confusion with production or other test systems.
• Storage: Choose supported file locations or storage management, initial capacity, and growth arrangements for the anticipated workload.
• Character set: Confirm the requirements of the application and any data to be imported.
• Resources: Establish memory and CPU expectations that account for other workloads sharing the host or service.
• Access: Plan administrative accounts, application users, privileges, and the services clients will use.
• Operations: Assign responsibility for backups, monitoring, maintenance, and incident response.

These decisions deserve review even when a wizard supplies defaults. A default can create a usable demonstration database without meeting an application's capacity or recovery needs. Keep the initial configuration understandable; additional features should have a defined purpose and a corresponding verification step.

After creation, verify both the CDB and the intended application PDB. Administrative access to the root does not prove that the application can connect to its PDB, find its schema, or execute its workload.

5. Verify connectivity and the administrative context

Applications use connection details that identify a service and how to reach it. Review the listener, service registration, network controls, and client configuration together. A listener process being available is only one part of a successful connection. Test from an actual application host or an equivalent environment, using the service and credentials the application will use.

In an authorized SQL*Plus session, these commands provide a simple starting point for inspecting the connection context and compatibility setting:

SHOW CON_NAME
SHOW PARAMETER compatible

The commands display information; they do not create a database or change its settings. Compare their output with the intended environment. If a query or command requires a higher privilege, use an appropriately authorized account and record why that access is needed.

Choose a management interface separately from the database installation. Enterprise Manager Cloud Control is a management platform with its own deployment requirements. Oracle Enterprise Manager Database Express, or EM Express, is desupported in 26ai. Oracle lists alternatives including OCI Database Management, Cloud Control, and SQL Developer products. Select the interface that supports the required task and deployment.

6. Plan upgrades from the actual source release

Oracle documents direct upgrades to 26ai from 19c and 21c. Earlier sources need a supported intermediate upgrade path or another supported migration approach. Check the precise source version, architecture, installed components, and target requirements before choosing the procedure. A database described only as “an older Oracle database” does not provide enough information to plan the work.

For a non-CDB source, include conversion into a PDB in the target design. Plan the destination CDB, storage, services, and recovery approach for that conversion. It is a structural change that requires its own rehearsal and validation.

The 23ai transition is different. Oracle states that applying the October 2025 release update transitions 23ai to 26ai without a full database upgrade. Use the applicable patch instructions for the exact environment and target RU. Continue to test application behavior and operational procedures as part of the maintenance process.

AutoUpgrade and Replay Upgrade

Oracle recommends the current AutoUpgrade utility for preparing and deploying supported upgrades. It performs checks and coordinates stages of the process. Review analysis results, resolve prerequisites, and rehearse the procedure with a representative copy before production. Configuration details depend on whether the source is a CDB, a PDB, or a non-CDB being converted.

Replay Upgrade uses previously captured upgrade statements to update database metadata in supported multitenant upgrade workflows. It is not an application load test. Oracle's 26ai documentation identifies AutoUpgrade and Replay Upgrade as supported upgrade methods; DBUA and manual upgrade scripts are desupported for this target. DBCA retains its database creation role and documented maintenance capabilities.

7. Consider Data Pump when moving data

Data Pump provides a logical export/import migration route into a prepared target database. This can be useful when reorganizing schemas, selecting application data, or moving to an environment where another method is unsuitable. Its support requirements differ from those of a direct database upgrade, so check source and target compatibility for the chosen export/import method.

A migration plan must account for ongoing changes at the source. An initial copy alone cannot keep the target synchronized while users continue to update the original database. Decide how a consistent data set will be obtained, when writes will stop or be synchronized through a supported mechanism, and how the application will switch to the target.

Inventory dependencies beyond tables: users and grants, scheduled jobs, database links, external files, and application connection settings can all affect the result. Measure export, transfer, import, and validation times during rehearsal. A small sample import can identify syntax or privilege problems, but it does not establish the duration of the full migration.

8. Treat patching and compatibility as explicit decisions

Oracle documents out-of-place patching by preparing a new RU home and using supported tooling to move the database to that home. DBCA has a documented command-line role in that procedure; AutoUpgrade also provides patching capabilities. Select the procedure for the deployment and follow its prerequisites. A successful software extraction alone does not establish that database patching is complete.

Keeping the old home can help with maintenance planning, but it is not a complete rollback strategy. Define how database changes, application writes, and configuration changes would be handled if validation fails. Rehearse the applicable recovery path and identify the point after which returning to the previous environment requires additional work.

The COMPATIBLE parameter controls compatibility-dependent behavior. Oracle requires at least 19.0.0 for upgrade to 26ai, while defaults for newly created databases vary by RU. The documentation describes 23.6.0 for new installations in that RU range and 23.9.0 from RU 23.9 onward. Inspect the actual setting instead of deriving it from the product name.

Increasing COMPATIBLE is not a routine cosmetic update: it cannot simply be lowered again and affects downgrade options. Oracle recommends completing upgrade testing first. Check the target CDB's compatibility when plugging in a PDB, because the container's setting also affects that operation.

9. Rehearse, cut over, and verify

A useful rehearsal follows the planned production sequence closely enough to reveal missing dependencies and timing problems. Record the starting state, tool versions, configuration inputs, analysis results, duration of each stage, and validation outcomes. Resolve failures and repeat the affected steps until the plan is reproducible.

1. Prepare: Confirm the source inventory, target requirements, access, free space, and backup or recovery arrangements.
2. Analyze: Run applicable prechecks and review desupported features, application dependencies, and unresolved errors.
3. Practice: Exercise the procedure and its failure response using a suitable nonproduction environment.
4. Cut over: Coordinate application activity, complete the selected upgrade or migration, and change connections at the agreed point.
5. Validate: Check database and PDB state, logs, services, users, application transactions, scheduled work, and representative performance.
6. Handover: Confirm monitoring and backups for the new environment, update the operating record, and assign follow-up issues.

For a business application, validation might include opening a customer record, entering and reversing a test transaction, generating a report, and confirming the next scheduled batch. Choose checks that exercise the application's actual dependencies. Capture enough evidence to distinguish “the database started” from “the service is ready for users.”

Summary and next lesson

Start with the operation and deployment model, then choose its supported tools. Installation prepares software, DBCA helps create and configure databases, upgrade tools handle supported release transitions, and migration methods move data into a target environment. Verify the precise source and target releases, CDB/PDB architecture, compatibility setting, and application behavior before declaring the work complete.

Once the database is established, its storage and workload need ongoing management.

Oracle documentation

• Database Setup Wizard and image-based installation
• RPM-based database installation
• Supported direct upgrade paths
• Upgrade and data migration methods
• Database compatibility and COMPATIBLE
• Out-of-place database patching