Creating an Oracle AI Database 26ai: Conclusion

Creating an Oracle database is a dependency chain, not one successful SQL statement. The platform must be prepared, the instance must start with a valid parameter configuration, the CREATE DATABASE statement must build a multitenant container database, Oracle-supplied components must be installed, administrative credentials and authorization must be secured, and storage and undo must be verified in the correct containers. Only then is the environment ready for application PDBs and users.

This module used the COIN database to expose that chain. The manual path is valuable because it reveals the boundary between an operating-system service, an Oracle instance, a CDB, its root and seed containers, its physical files, and its data dictionary. In routine deployments, Database Configuration Assistant, Oracle Managed Files, ASM, Oracle Restart, or cloud automation may perform much of the work. Understanding the underlying steps remains important when reviewing generated scripts, diagnosing a partial creation, or building repeatable provisioning.

The governing architectural fact is that Oracle AI Database 26ai uses the multitenant architecture. A new database is a CDB containing CDB$ROOT and PDB$SEED. Application data normally belongs in one or more PDBs created from the seed. A PDB owns datafiles and container-local metadata, but it shares the CDB's control files, online redo logs, background processes, and instance memory. Every later decision about users, grants, dictionary views, tablespaces, undo, services, and backup must therefore include container scope.

Stage	Principal action	Evidence of completion
Plan	Choose the database name, character sets, storage, redo, undo mode, file strategy, and PDB layout	An approved parameter file and creation script
Prepare the platform	Create the required Windows service with ORADIM when using the manual Windows path	The correct service, Oracle home, SID, account, and ORADIM log
Start the instance	Connect with administrative authority and use STARTUP NOMOUNT	Memory and background processes exist, but no database is mounted
Create the CDB	Execute the reviewed CREATE DATABASE statement	Control files, redo, core tablespaces, root, and seed are created and opened
Complete components	Install the dictionary views and PL/SQL components required by the manual procedure	Successful script logs and valid registry components
Secure	Protect credentials and apply least privilege, roles, and appropriate policy controls	Reviewed account, role, grant, audit, and SQL Firewall state
Allocate storage	Confirm SYSTEM, SYSAUX, TEMP, UNDO, and application tablespaces in each intended container	Correct datafiles or tempfiles, capacity limits, and container placement
Validate and protect	Verify configuration, patch state, connectivity, recovery mode, and backup	A signed runbook with logs, query results, and a tested recovery baseline

The order is significant. Starting a Windows service does not create a database. Starting an instance in NOMOUNT does not mount files that do not exist. A successful CREATE DATABASE does not prove that every catalog component, PDB service, grant, tablespace, or backup requirement is correct. Each stage consumes the output of the previous one and produces evidence needed by the next.

DBCA is normally the safest path for a new database because it validates choices, applies supported defaults, creates a locally managed SYSTEM tablespace, configures the CDB and seed, runs required Oracle scripts, and records its work. It can also generate scripts for review. Oracle Managed Files reduces errors by deriving file names and destinations from initialization parameters. ASM or cloud storage adds another managed layer.

A manual script remains useful for education, controlled laboratory work, and reviewed automation where every choice must be explicit. That path transfers responsibility to the operator. File destinations must be empty or deliberately reusable, the database name must match DB_NAME, the character set must be chosen before data is stored, and the root and seed files must be generated correctly. The script must also specify EXTENT MANAGEMENT LOCAL; otherwise a manually created SYSTEM tablespace can use deprecated dictionary management.

On Windows, ORADIM creates and administers the Oracle service used by a manually managed instance. The service associates the SID with an Oracle home and operating-system service account. Always inspect oradim.log and the Windows service configuration. On other operating systems, this Windows service step does not apply; Oracle Restart or another supported service manager may own instance startup.

STARTUP NOMOUNT reads the PFILE or SPFILE, allocates the SGA, and starts background processes. At this point the instance exists, but the control files and datafiles of the new database do not. This is the correct state for issuing CREATE DATABASE. A failure here usually belongs to environment variables, parameter syntax, memory, directories, permissions, or the selected Oracle home—not to tables inside a database that has not yet been created.

STARTUP NOMOUNT;
SELECT instance_name, status, database_status
FROM v$instance;

Keep the alert log and creation spool open during the operation. An error reported near one clause can reflect an earlier mismatch, existing file, unwritable directory, or insufficient resource. Do not repeatedly rerun a destructive creation script until the exact file state and failure point have been understood.

The statement binds the instance to a new database identity and creates its initial physical and logical structures. Its major decisions include control-file destinations, online redo log groups and members, initial control-file capacity, database and national character sets, SYSTEM and SYSAUX, the default permanent and temporary tablespaces, the undo tablespace, and the CDB root and seed.

ENABLE PLUGGABLE DATABASE creates the root and PDB$SEED. Seed file names must come from Oracle Managed Files, PDB_FILE_NAME_CONVERT, or an appropriate FILE_NAME_CONVERT clause. The seed is a protected template, not an application container. New application PDBs are created after the CDB is open and receive their own system tablespaces and services.

Use AL32UTF8 for a new general-purpose Unicode database unless a documented application requirement dictates otherwise. Character-set selection is a data architecture decision, not a display preference. Redo groups should be sized and multiplexed according to workload and failure domains. CONTROLFILE REUSE and file-level REUSE are destructive exceptions for deliberate recreation, not convenient defaults for a first creation.

Local undo is the preferred CDB design and is the DBCA default. A manual statement should select it deliberately when required:

CREATE DATABASE coin
  EXTENT MANAGEMENT LOCAL
  CHARACTER SET AL32UTF8
  NATIONAL CHARACTER SET AL16UTF16
  ENABLE PLUGGABLE DATABASE
  LOCAL UNDO ON;

This is only a structural summary, not a runnable production script. A real statement must provide a complete and internally consistent file or Oracle Managed Files design, administrative credential handling, redo configuration, tablespace clauses, seed placement, and capacity plan. Never place reusable passwords in a checked-in script or command history.

Completing the CDB does not complete the application environment. Create an application PDB from PDB$SEED with an approved file-placement method, local administrator, service strategy, and credential procedure. Oracle Managed Files can remove explicit file conversion from the statement; explicit storage requires a reviewed conversion or file-name plan. Do not use the root as the ordinary home for application schemas.

Opening a new PDB for the current instance is not the same as preserving its behavior across restarts. After creation, open the PDB, save its desired state, and verify the service through which applications will connect:

ALTER PLUGGABLE DATABASE coin_pdb1 OPEN;
ALTER PLUGGABLE DATABASE coin_pdb1 SAVE STATE;

SELECT name, open_mode, restricted
FROM   v$pdbs
ORDER  BY con_id;

Confirm service registration with the listener or service-management layer and test a connection that names the PDB service. A connection to the CDB root can succeed while the application PDB is closed, restricted, or unregistered. That is why the acceptance test must identify the service, current container, application schema, and expected transaction—not merely show that an administrative connection reached the instance.

Apply PDB-local defaults after changing to the intended container: permanent and temporary tablespaces, quotas, application roles, audit policies, SQL Firewall configuration, and local parameters where supported. Record whether each item is common or local. This prevents a root-level grant or configuration from being mistaken for PDB readiness and makes future cloning, unplugging, patching, and recovery decisions easier to reproduce.

DBCA creates the data dictionary and Oracle-supplied components automatically. A manually created CDB requires the documented post-creation script procedure. In the workflow studied here, catcdb.sql orchestrates installation for the root and seed, including work historically associated with catalog.sql and catproc.sql. Follow the instructions for the installed Oracle home rather than mixing scripts from another release.

catalog.sql creates dictionary views and many public synonyms. catproc.sql installs PL/SQL packages and supporting objects. They are installation and maintenance scripts, not routine startup commands. Run them only for the documented creation, upgrade, repair, or component procedure, with the required administrative identity and container scope. Preserve the complete logs and investigate errors before continuing.

Verify the resulting components rather than assuming that the final script line proves success:

SELECT comp_id, comp_name, version, status
FROM   dba_registry
ORDER  BY comp_id;

SELECT object_type, status, COUNT(*) AS object_count
FROM   dba_objects
WHERE  oracle_maintained = 'Y'
GROUP  BY object_type, status
ORDER  BY object_type, status;

Invalid objects require diagnosis before recompilation. Confirm the applicable patch level and run Datapatch according to the software installation procedure. A database whose binary home and SQL registry disagree is not a completed deployment.

The SYS and SYSTEM accounts are common administrative users. Protect their credentials during creation, rotate any exposed or temporary values, and reserve them for appropriate administrative work. Applications should not connect as either account. Prefer task-specific administrative privileges and named accounts so auditing can distinguish responsibility.

The desupported SQL*Plus Product User Profile does not belong in a 26ai creation checklist. It was a client-dependent control and cannot provide consistent protection across current applications and tools. Begin with least-privilege object, schema, and system grants grouped through reviewed roles. Then select an additional feature only when its control model matches the requirement.

Security requirement	Appropriate control
Authorize an account to use objects or system capabilities	Privileges and roles with correct common or local scope
Restrict a stable account to learned SQL and connection paths	Oracle SQL Firewall with reviewed capture and allow-list lifecycle
Protect sensitive data or commands from broadly privileged accounts	Database Vault realms, factors, and command rules where available
Filter rows according to trusted session context	Virtual Private Database or another documented data-security policy
Record security-relevant actions and policy violations	Unified Auditing and, where required, fine-grained auditing

Profiles and Resource Manager govern password, session, and resource behavior; they do not replace authorization. Secure application roles enable privileges through an authorized invoker-rights PL/SQL unit after checks succeed. SQL Firewall enforcement should begin in observe-only mode and move to blocking only after a representative workload and release process have been validated.

Tablespaces connect logical allocation to physical storage. SYSTEM stores the core dictionary, SYSAUX supports Oracle components, TEMP serves temporary operations, UNDO stores automatically managed undo, and application tablespaces separate business data from system structures. In a CDB, the inventory is container-sensitive: the root, seed, and application PDBs do not share one flat set of permanent tablespaces.

Use locally managed tablespaces and automatic segment-space management for ordinary permanent application storage. Choose smallfile or bigfile tablespaces deliberately. With explicit files, define locations, initial sizes, growth increments, and maximum sizes. With Oracle Managed Files or ASM, let Oracle generate names while still monitoring capacity and failure-domain design. MAXSIZE UNLIMITED means the database can grow until a platform or storage limit is reached; it is not a substitute for alerts and capacity planning.

Verify both the logical definition and its files in the current container:

SHOW CON_NAME

SELECT tablespace_name, contents, status, bigfile
FROM   dba_tablespaces
ORDER  BY tablespace_name;

SELECT tablespace_name, file_name,
       autoextensible, bytes, maxbytes
FROM   dba_data_files
ORDER  BY tablespace_name, file_name;

Temporary files appear in DBA_TEMP_FILES, not DBA_DATA_FILES. Repeat the checks in each application PDB and confirm defaults, quotas, encryption requirements, and recovery implications before assigning application schemas.

Manual rollback-segment creation is historical material. A CDB requires UNDO_MANAGEMENT=AUTO, so Oracle manages undo segments inside undo tablespaces. Undo supports transaction rollback, statement and transaction read consistency, and Flashback features. The administrator manages tablespace capacity and retention policy rather than creating individual rollback segments.

Local undo gives each container its own undo and is preferred for most CDBs because it supports important PDB operations and recovery workflows. UNDO_RETENTION is a retention target, not a promise that ignores capacity. Oracle can tune retention upward when space permits and may need to reuse unexpired undo under pressure. Investigate workload duration, retention, and tablespace size together when diagnosing snapshot-too-old errors.

SHOW PARAMETER undo

SELECT end_time,
       tuned_undoretention,
       maxquerylen,
       ssolderrcnt
FROM   v$undostat
ORDER  BY end_time DESC
FETCH FIRST 6 ROWS ONLY;

Evaluate these results in the intended container. Do not convert an obsolete rollback-segment exercise into production syntax. Replace it with monitoring, capacity planning, and a controlled retention test.

A creation runbook should end with evidence, not “command completed.” Verify the instance, database, root, seed, application PDBs, services, files, components, accounts, grants, storage, undo, and patch state. Confirm that applications connect to the intended PDB service rather than the root.

SELECT instance_name, status, database_status
FROM   v$instance;

SELECT name, cdb, open_mode, log_mode
FROM   v$database;

SELECT con_id, name, open_mode, restricted
FROM   v$containers
ORDER  BY con_id;

Review the alert log, ORADIM or service logs where applicable, creation spool, catalog logs, Datapatch output, invalid objects, and listener service registration. Confirm that PDB$SEED is read only, application PDBs have the intended saved open state, and backup software can discover all files. Test a controlled restart so the service and parameter configuration are not merely correct for the original terminal session.

Finally, establish a physical recovery baseline. Configure the intended archiving and recovery strategy, then take and validate the first RMAN backup through the organization's approved runbook. Preserve the parameter file, password file, network configuration, wallet or keystore material, creation scripts, logs, configuration inventory, and backup metadata according to their security classifications. A database is not production-ready until the team can restore and recover it.

The module's lasting lesson is the separation of concerns. The operating system hosts services and files. The Oracle instance supplies memory and processes. The CDB supplies shared control, redo, root metadata, and the seed. PDBs supply application isolation and local scope. Catalog scripts install Oracle-maintained metadata and program units. Privileges and policies control use. Tablespaces allocate storage, and automatic undo preserves transactional consistency.

Automation can combine these actions, but it does not erase their boundaries. When a deployment fails, locate the failed layer before changing the next one. When a deployment succeeds, verify every layer independently. That approach turns database creation from a fragile sequence of commands into a repeatable architectural process.

Now, click the Quiz link below to test what you've learned. Create Database - Quiz