Oracle AI Database 26ai Initialization File

An Oracle database instance, memory plus background processes, cannot start until it reads initialization parameters. These parameters define the instance's operating environment: memory sizing, process limits, file locations, and the multitenant configuration required to mount and open the database. During STARTUP NOMOUNT, Oracle uses the initialization parameters to allocate the SGA, set up PGA-related structures, and start background processes. Only after that can Oracle locate and read the control files to proceed to MOUNT and then OPEN.

Oracle continues to support two initialization-parameter file types:

• PFILE (parameter file), a plain-text file, typically named init<ORACLE_SID>.ora. It's human-editable and commonly used for initial configuration, troubleshooting, or as a bootstrap file when an SPFILE is unavailable.
• SPFILE (server parameter file), a binary file, typically named spfile<ORACLE_SID>.ora. This is the preferred standard, since persistent changes can be made with ALTER SYSTEM ... SCOPE=SPFILE (or SCOPE=BOTH) without manually editing a text file at all.

Operationally, most environments run day to day on an SPFILE, while keeping a known-good PFILE available for recovery scenarios, for example, to start the instance when the SPFILE itself is missing or corrupt.

The default location varies by platform and by how the Oracle home is configured, but the common patterns are:

• Linux/UNIX, standard read/write Oracle home: PFILE/SPFILE reside under $ORACLE_HOME/dbs, for example $ORACLE_HOME/dbs/initCOIN.ora or $ORACLE_HOME/dbs/spfileCOIN.ora.
• Linux/UNIX, read-only Oracle home: if the Oracle home is configured read-only, an established, version-independent capability, not something new to this release, the dbs directory moves out of $ORACLE_HOME entirely and lives under $ORACLE_BASE_CONFIG/dbs instead, alongside other writable configuration. Worth checking which mode your environment uses before assuming the standard path.
• Windows: PFILE/SPFILE commonly reside under the Oracle home's database directory, for example %ORACLE_HOME%\database\initCOIN.ora or %ORACLE_HOME%\database\spfileCOIN.ora.

Regardless of where the file actually lives, you can always start explicitly with a known file:

-- SQL*Plus
STARTUP NOMOUNT PFILE='/full/path/to/initCOIN.ora';

Once the instance is up, you can confirm exactly which parameters are in effect, and where they came from, with:

SELECT name, value, isdefault FROM V$PARAMETER WHERE name = 'db_name';

and, if you're running from an SPFILE specifically, check what's actually persisted there (which can differ from the currently running value if someone changed something with SCOPE=MEMORY only):

SELECT name, value FROM V$SPPARAMETER WHERE name = 'db_name';

Oracle AI Database is built around the multitenant architecture: a CDB (container database) holds one or more PDBs (pluggable databases), and the instance-level initialization file governs the CDB instance as a whole. When you create a database using SQL directly, rather than through DBCA, Oracle's multitenant documentation references the ENABLE_PLUGGABLE_DATABASE initialization parameter specifically for CDB creation workflows, it's a bootstrap parameter used at the moment of creating a CDB, not something you toggle back and forth afterward.
Key takeaway for this lesson: you write the initialization file for the instance, meaning the CDB instance. PDB-level settings are managed through SQL once the instance is up and the PDB is open, not through separate "PDB init.ora files," that pattern doesn't exist in normal practice.

Older init files often contained parameters such as background_dump_dest (bdump) and user_dump_dest (udump). Both are deprecated, specifically BACKGROUND_DUMP_DEST as of Oracle Database 12c Release 1 (12.1.0.1), replaced by diagnostic_dest, which points to the Automatic Diagnostic Repository (ADR). Both deprecated parameters still exist and still function today, purely for backward compatibility, they haven't been removed outright, but there's no good reason to use them in new work. Prefer diagnostic_dest and let Oracle manage trace/alert file locations under the ADR structure automatically.

This module's project database is named COIN, and the training goal here is to begin building a working PFILE named initCOIN.ora. Even if your environment ultimately runs from an SPFILE, writing a clean PFILE first teaches you exactly what Oracle needs at startup and how parameter scoping actually works, rather than skipping straight to a binary file you can't read.

If you're following an OFA-style project layout for training purposes, keep your project PFILE under an admin directory tree. Create the directories if they don't already exist.

# Linux/UNIX example
mkdir -p $ORACLE_BASE/admin/COIN/pfile

:: Windows example (Command Prompt)
mkdir C:\oracle\admin\COIN
mkdir C:\oracle\admin\COIN\pfile

Many real-world systems use the Oracle home default location instead of a custom admin tree. The important thing is consistency, and making sure the Oracle software owner account actually has read permissions on wherever you land.

Use a plain-text editor and save a new file named initCOIN.ora. In a GUI editor, this is effectively:

File->Save As

Save it into your chosen PFILE directory, for example $ORACLE_BASE/admin/COIN/pfile, or the default Oracle location if you're not using a custom layout.

These starter parameters are intentionally minimal, current for Oracle AI Database 26ai conventions, and avoid the deprecated bdump/udump settings entirely. Treat the file paths as examples, adjust for your own environment (file system vs. ASM, Oracle base locations, naming standards):

# initCOIN.ora (PFILE) - starter example

db_name='COIN'
db_unique_name='COIN'

# Memory (choose one approach appropriate for your environment)
memory_target=2G

# Control files (example filesystem paths; ASM environments will differ)
control_files=(
  '/u01/app/oracle/oradata/COIN/control01.ctl',
  '/u02/app/oracle/oradata/COIN/control02.ctl'
)

# Diagnostics (ADR root)
diagnostic_dest='/u01/app/oracle'

# Multitenant enablement is referenced in Oracle multitenant creation workflows
enable_pluggable_database=TRUE

A production build would typically include more: process limits, an undo tablespace, character set decisions made at CREATE DATABASE time, redo sizing, archive log configuration, and so on. For this lesson, the objective is narrower: write a clean file that can bootstrap an instance to NOMOUNT successfully.

Some environments separate site-wide settings from database-specific settings. Oracle supports this through the IFILE directive: the primary init file includes another parameter file entirely. This pattern is still current and still useful for standardization across many databases, just make sure the included file also avoids the deprecated bdump/udump parameters.
Example: keep initCOIN.ora small and include a COIN-specific config file.

# initCOIN.ora
ifile='/u01/app/oracle/admin/COIN/pfile/configCOIN.ora'

# configCOIN.ora
db_name='COIN'
db_unique_name='COIN'
memory_target=2G
control_files=(
  '/u01/app/oracle/oradata/COIN/control01.ctl',
  '/u02/app/oracle/oradata/COIN/control02.ctl'
)
diagnostic_dest='/u01/app/oracle'
enable_pluggable_database=TRUE

Once your PFILE is valid, the standard next step is starting the instance from the PFILE and then generating an SPFILE for ongoing administration.

-- SQL*Plus
CONNECT / AS SYSDBA;

STARTUP NOMOUNT PFILE='/u01/app/oracle/admin/COIN/pfile/initCOIN.ora';

-- After validating parameters, persist them into an SPFILE
CREATE SPFILE FROM PFILE='/u01/app/oracle/admin/COIN/pfile/initCOIN.ora';

SHUTDOWN IMMEDIATE;
STARTUP;

This sequence gives you the best of both: the transparency and editability of a PFILE during early setup, and the operational convenience of an SPFILE for long-term management, where changes can be made and persisted with a single ALTER SYSTEM statement instead of hand-editing a text file and restarting.