Oracle AI Database 26ai Administration Conclusion

This module introduced the decisions that make an Oracle database usable, maintainable, and secure. You examined installation and migration, tablespace storage, workload resources, data loading, table maintenance, cloud connections, and security management. These topics belong together because a change in one area can affect several others: importing data consumes storage, a reporting workload competes for resources, and a new application connection requires both network access and appropriate privileges.

The central administrative habit is to define the intended result, identify the correct environment and scope, select a supported procedure, and verify the outcome. A completed command is one piece of evidence. The stronger test is whether the application can perform its required work, unwanted access is restricted, and the system remains recoverable and supportable.

Oracle AI Database 26ai combines established administration techniques with newer and release-specific capabilities. Avoid assuming that every feature discussed is new to 26ai or available in every deployment. The installed release update, service model, client software, configuration, and applicable entitlement all influence the procedures you can use.

What You Should Now Be Able to Explain

• Distinguish software installation, database creation, patching, upgrading, and data migration.
• Explain the relationship between a container database, application PDBs, tablespaces, and database services.
• Separate storage allocation and growth limits from workload resource controls.
• Describe tablespace transport and read-only access without confusing them with continuous replication or backup requirements.
• Select appropriate approaches to loading data, moving tables, storing temporary work, and retiring obsolete columns.
• Separate public web traffic, database client sessions, and database-initiated outbound calls.
• Explain how identity, privileges, workload policies, encryption, and auditing address different security requirements.
• Define meaningful checks before declaring an administrative change complete.

1. Begin with Responsibilities, Scope, and Evidence

The module overview established that database administration extends across the system's lifecycle. It includes preparing an environment, monitoring its operation, managing access and capacity, maintaining software, and planning recovery. Choosing a management console is only one part of that work.

In a self-managed deployment, the team controls the host, Oracle software, storage, and database configuration. A managed service takes responsibility for specified components, while customers continue to make decisions about their application data and access. Record that division of responsibility rather than assuming that a cloud label settles every operational question.

Identify the database and container before inspecting or changing configuration. The container database (CDB) and its pluggable databases (PDBs) have different administrative scopes. An application connection normally needs the intended PDB service; a successful administrative connection to the root does not prove that the application environment is ready.

Use tools according to the task. DBCA supports database creation and configuration workflows, SQL*Plus provides a direct administrative interface, and management platforms can collect monitoring information across supported targets. A dashboard alert tells you where to investigate. Its color or headline value does not establish the cause of an incident.

2. Distinguish Installation, Configuration, and Migration

The installation, configuration, and migration lesson separated operations that are often grouped under “installing Oracle.” An Oracle home contains software. Database creation establishes the database structure. Configuration prepares services, storage, accounts, and operating settings. An upgrade changes an existing database to a supported target release, while a logical migration moves selected data and metadata into a target environment.

These distinctions determine which tools and checks apply. Installing a new home does not automatically migrate a database. Importing application tables does not necessarily recreate every external dependency. A successful database startup does not verify scheduled jobs, client connections, application permissions, or representative performance.

For a migration, inventory the source release, architecture, components, data volume, character requirements, and application dependencies. Select a supported path for the actual source and destination. Rehearse the process with representative data, including the time needed for validation and the point at which application connections change.

Also decide how source writes are handled during the transition. An initial data copy does not keep itself synchronized. The plan must explain when writes stop or how an appropriate synchronization method maintains consistency, who approves cutover, and what happens if the target fails its acceptance checks.

Treat compatibility settings and rollback assumptions as explicit decisions. Keeping an old software home is not a complete recovery plan for a database that has accepted new writes. Before maintenance begins, document which changes can be reversed directly and which require a tested recovery or migration procedure.

3. Separate Storage Management from Resource Allocation

The tablespace and resource management lesson distinguished several mechanisms that solve different problems. Tablespaces organize storage. Datafiles supply permanent storage. Quotas limit allocation by a schema, file growth settings govern expansion, and the underlying storage system limits the capacity actually available.

When a segment cannot grow, determine which limit has been reached. Raising a quota cannot create disk space. Increasing a file's permitted maximum does not guarantee that physical storage is available. Adding CPU resources does not resolve either condition. Inspect the relevant settings and usage in the intended container before selecting a remedy.

Local extent management and automatic segment space management (ASSM) operate at different levels. Local bitmaps track extent allocation, while ASSM tracks free space within segments. Neither mechanism eliminates the data dictionary or removes the need for capacity monitoring. Temporary and undo requirements also need attention alongside permanent application data.

Resource Manager addresses workload competition rather than file capacity. Consumer groups classify sessions, plans define policies, and directives apply the supported resource controls. Creating a plan does not prove that it is active or that the expected sessions enter the intended groups. Verify configuration, activation, classification, and measured effects.

For a reporting workload competing with transaction processing, compare both workloads under representative concurrency. A change that improves interactive response but prevents the required report from completing may not meet the business objective. Resource allocation is a balancing decision supported by measurements, not simply a preference for the most visible workload.

Transport and Read-Only Access Have Specific Purposes

Conventional transportable tablespaces combine copied datafiles with exported and imported metadata. The selected set must satisfy containment and other eligibility requirements. Check source and target compatibility, encryption, platform considerations, and dependencies. A successful containment check addresses one prerequisite rather than certifying the entire migration.

For the conventional transport workflow, the source tablespaces are made read-only during the required stage. Queries can continue, while ordinary changes to those tablespaces are prevented after the transition completes. Work in other read/write tablespaces can continue where application dependencies permit. This is different from taking a tablespace offline or opening an entire PDB read-only.

A transported copy does not continuously receive later source changes. Define which copy will accept future writes and verify the destination before handing it to the application. Also remember that ordinary RMAN online backups in ARCHIVELOG mode do not require application tablespaces to be read-only; the transport procedure's requirements should not be generalized to unrelated backup operations.

4. Plan Data Loading and Table Maintenance as Complete Operations

The data loading and table management lesson treated scale as an operational problem. Row count is only one factor. Data width, large objects, concurrency, maintenance windows, and validation time can make a task difficult even when storage capacity appears comfortable.

SQL*Loader maps external records to database structures. A robust loading process defines formats, conversions, document associations, and error handling before importing data. Review rejected and deliberately excluded records separately, compare accepted values with their sources, and establish how a partially completed run can be resumed without duplicating valid data.

Moving an eligible table online can preserve concurrent DML during much of the operation, subject to restrictions. It is not a promise of zero waits or unlimited capacity. Check destination space, privileges, quotas, indexes, LOB storage, and application impact. Maintaining indexes does not necessarily move them to the table's destination tablespace.

Temporary tables require clear lifetime rules. A global temporary table has a shared persistent definition but session-private rows. A private temporary table also has a private definition. Commit behavior and session termination affect the two forms differently, so the chosen option must match the application's transaction boundaries.

This distinction matters with connection pools. The end of a web request may not end its database session. Test temporary-data cleanup and user context across repeated requests using the same pooled connection. Logical separation of rows does not remove the shared demand for temporary space and other execution resources.

Removing a column requires dependency review and a recovery decision. Marking a column unused makes it unavailable while deferring physical cleanup; it does not immediately reclaim its storage or provide a matching command to make it used again. Review reports, integrations, views, and maintenance code before either logical or physical removal.

5. Design Each Connection Path Deliberately

The cloud connection lesson began with a useful design principle: a public website can use a private database. Browser requests reach an HTTPS application or API, and a server-side component makes the separate database connection. Database credentials belong with the component that needs them, not in browser-delivered code.

Distinguish three flows: a visitor's web request, a SQL client's database session, and a database operation calling an external service. Each flow has its own endpoint, identity, and access controls. Allowing incoming database connections does not authorize outbound calls, and successfully reaching an API does not prove that a user may retrieve its protected data.

For Autonomous AI Database, choose public or private access according to the application's needs and restrict allowed sources appropriately. Private access still requires working name resolution, routes, and network security rules. Optional public access adds a separate connection path that should have a documented purpose.

TLS protects communication and validates the expected peer; mutual TLS adds client-certificate authentication. Use the instance's connection information and a supported client rather than assuming that a familiar port number proves encryption. Network reachability, transport security, database login, and SQL privileges are separate checks.

Outbound HTTPS may additionally require database host authorization, network egress, certificate trust, and destination credentials. Service-specific routing matters, particularly for managed database services. Do not copy a self-managed networking procedure into a managed deployment without checking how that service handles the corresponding operation.

6. Combine Security Controls and Verify Their Behavior

The security management lesson connected identity, authorization, SQL workload restrictions, encryption, auditing, and ongoing operations. These controls reinforce one another, but they are not interchangeable. Encryption does not remove excessive privileges, and auditing does not itself block an unwanted operation.

Separate object owners, application accounts, reporting users, security administrators, and audit reviewers. Grant access according to the actual task. A schema privilege can simplify access throughout one schema, including applicable future objects, but object-specific grants or selected views may be more appropriate when the required access is narrower.

SQL Firewall restricts configured SQL workloads and connection contexts. Capture representative legitimate activity, review the baseline, monitor exceptions, and introduce enforcement under change control. An unexpected statement needs investigation: it may represent an attack, an incomplete baseline, or approved new application functionality.

Data-access policies answer a different question: which rows or fields should a particular user receive? Established controls and RU-specific capabilities such as Deep Data Security require correct identity context and tested policies. Applications and AI agents do not gain correct end-user restrictions automatically just because the database version supports those features.

Oracle 26ai uses Unified Auditing, with traditional auditing desupported. Define the required policy, enable it, generate a controlled test event, and inspect the evidence. Assign responsibility for reviewing records and managing retention. Protect encryption keys and test recovery dependencies as carefully as the data they protect.

Apply the Module to One Application Change

Imagine a learning application moving to a prepared Oracle 26ai environment. It imports course documents, processes student transactions, and produces a nightly report. The migration also retires an old integration column. This example combines the module's decisions without turning them into a single unreviewed maintenance script.

First, establish the target service, PDB, software level, application connection, and recovery requirements. Rehearse data movement and verify the application's dependencies. Decide when the source stops accepting changes and what evidence is needed before users connect to the destination.

Next, estimate the space required for imported documents, indexes, temporary report work, and maintenance. Check quotas and file growth against actual capacity. Validate source-to-target document associations and rejected inputs. Measure the nightly report alongside interactive activity before deciding whether a Resource Manager plan is needed.

Then verify the access design. Keep the database connection on the application side, restrict its privileges, and test two users with different data entitlements. Confirm that temporary rows and identity context do not carry over incorrectly between pooled requests. Check the intended audit events after representative operations.

Finally, retire the old column only after dependent code and reports have been checked. Schedule physical cleanup according to its impact. Capture migration results, application checks, capacity measurements, security tests, and recovery readiness in the handover record. The project is complete when its agreed outcomes are demonstrated, not when the last command finishes.

Match the Change to Its Acceptance Evidence

Choose checks before making the change, while the objective is still clear. Include the actual application path rather than relying exclusively on an administrator's session. Preserve enough evidence for another DBA to understand what was tested, what remains uncertain, and who accepted the result.

Review Your Understanding

Before proceeding, explain why each statement below is incomplete. Use the linked lesson when you need to revisit a distinction:

• “The software installer completed, so the application database is ready.” Database creation, services, permissions, and application behavior still need verification.
• “The file can autoextend, so the database cannot run out of space.” File limits, quotas, and physical capacity remain relevant.
• “The table is temporary, so every web request starts with an empty working set.” Commit rules and pooled-session lifetime determine cleanup.
• “The endpoint is private, so every connected user has appropriate access.” Network isolation does not define database or end-user authorization.
• “The audit policy exists, so the required activity is recorded.” Enablement, scope, test events, and review must be checked.

Oracle Enhancements - Quiz

Continue to Installation and Configuration

The next module develops installation, provisioning, and configuration topics in more detail. Carry forward the habit of identifying the deployment, supported procedure, administrative scope, and verification criteria before making a change.

Continue to the next module's installation and configuration overview. Use the current lesson text and release-specific documentation to evaluate the procedure for your environment.