Oracle DBA Lesson 22 Part 2 — Start a Database in Stages

A staged startup turns one large operation into three observable steps. Start the instance, mount the database, then open it. After each command, inspect the current state and use that result to choose the next action. Finally, check the pluggable database that the application actually uses.

Oracle DBA Lesson 22 Part 2 — Start a Database in Stages

The sequence below assumes Oracle Database 19c, a primary single-instance CDB on Linux, and SQL*Plus connected locally with the required administrative privileges. It is intended for a disposable instance that is not managed by Oracle Restart or Clusterware. The displayed results are constructed examples, not output from an executed database. APP_PDB is a replaceable name for the user-created PDB used by an application.

The commands and their results

1. Start the stopped instance without mounting

In the eligible administrative SQL*Plus session:

STARTUP NOMOUNT

STARTUP is a SQL*Plus command. Enter it on its own line. The NOMOUNT option starts the instance without mounting the database, giving you a stopping point at which to inspect it. See SQL*Plus STARTUP.

SELECT status FROM v$instance;

At this stage, the expected STATUS is STARTED. It describes the running instance before the database is mounted. Record your actual result before moving on. See V$INSTANCE.

2. Mount onto the running instance

ALTER DATABASE MOUNT;
SELECT status FROM v$instance;

ALTER DATABASE is SQL. The semicolon terminates the statement in SQL*Plus. The MOUNT clause mounts the database onto the instance that is already running. Oracle reads its configured control files, which are physical files on disk. A successful mount gives a STATUS of MOUNTED.

Keep the two observations separate:

Step	Instance status	Interpretation
STARTUP NOMOUNT	STARTED	The instance has started; the database is not mounted.
ALTER DATABASE MOUNT;	MOUNTED	The database is mounted onto that running instance.

Continue with ALTER DATABASE between stages. Issuing another ordinary STARTUP against a running instance returns an error. STARTUP FORCE would abort an existing instance before restarting it and is outside this exercise. See starting up and shutting down.

3. Open and verify

ALTER DATABASE OPEN;
SELECT status FROM v$instance;
SELECT open_mode FROM v$database;

Opening involves the required online data files and online redo log files on disk, together with the consistency work needed for opening. Oracle automatically performs instance recovery when an earlier instance failure requires it. This does not turn media recovery or repair of unavailable files into an automatic startup recipe. See instance recovery.

For the normal primary CDB in this example, successful opening is followed by V$INSTANCE.STATUS = OPEN and V$DATABASE.OPEN_MODE = READ WRITE. These fields describe different properties: the current instance stage and the database open mode. See V$DATABASE.

Review the alert log for the same startup interval. Correlate timestamps, errors, opening messages, and any instance-recovery messages through their completion. Do not manufacture recovery entries or infer that recovery ran merely because the database opened. Transaction cleanup can continue on demand after opening. This lesson does not require proving that every terminated transaction has already been rolled back. See monitoring the alert log.

If opening fails, preserve the exact error and the corresponding alert-log entries. Recheck the state rather than assuming success. It may remain MOUNTED. Investigate the reported cause before another attempt. The example does not authorize a recovery command, forced restart, file deletion, or configuration repair.

Verify the application PDB separately

From the CDB root:

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

For example, the root-level CDB check may report READ WRITE, while the row for APP_PDB reports MOUNTED. The CDB is open. Application data inside that PDB is still closed. A separate PDB opening operation is needed before its ordinary application data can be accessed.

A user-created PDB does not always remain mounted after the CDB restarts. Saved state and configured startup management can affect its mode. Query the actual PDB instead of assuming a result. PDB$SEED is the system seed and normally appears as READ ONLY. Identify the application's PDB by name. PDB opening and saved-state administration are separate topics. See V$PDBS and PDB open modes and saved state.

A suitable PDB open mode is one part of application readiness. Service availability, restricted access, and a permitted connection using the intended service must also be checked when restoring an application. The CDB open-mode query alone does not prove those conditions.

Practice and restoration

Use an explicitly designated disposable, unmanaged 19c instance with an approved outage and a restorable snapshot. Do not apply these startup commands to a production database, a shared instance, a RAC database, or an Oracle Restart or Clusterware resource. Managed databases use their applicable management procedures.

Before the exercise, an authorized administrator must confirm the intended Oracle home and instance identity, dependent storage availability, local administrative authentication, and the original CDB, PDB, and service state. The exercise begins with that instance already stopped through its approved procedure. Shutdown is not taught here. A local administrative connection is commonly established using sqlplus / as sysdba by an authorized member of the appropriate operating-system group.

1. Start at NOMOUNT, query the status, and record the result.
2. Mount, query the status again, and explain why the command changed.
3. Open, inspect the instance status and database open mode, then review that startup interval in the alert log.
4. From the root, identify the application PDB and record its actual open mode. Compare it with the CDB result.
5. If any step fails, preserve the exact error, timestamp, and alert-log evidence. Stop the sequence and follow the designated administrator's diagnosis or snapshot-restoration procedure.

Restoration is part of the exercise. Use the approved PDB and service restoration procedure to restore the originally recorded modes and services, opening only the PDBs that should be open. Verify the intended service and an authorized application connection. Do not open every PDB as a shortcut. If the original state cannot be restored, use the authorized snapshot rollback and report the unresolved condition. No database was started or changed while preparing these notes.

Recap

STARTUP NOMOUNT starts the instance without mounting the database. V$INSTANCE.STATUS is STARTED. ALTER DATABASE MOUNT; mounts that running instance onto its configured control files, and the status becomes MOUNTED. Continue with ALTER DATABASE between stages. Another ordinary STARTUP against a running instance returns an error. STARTUP FORCE aborts an existing instance before restarting it and is outside this exercise. ALTER DATABASE OPEN; opens the required online data files and online redo log files, together with the consistency work needed for opening. Oracle performs instance recovery when an earlier instance failure requires it. That does not turn media recovery or repair of unavailable files into an automatic startup recipe. For the normal primary CDB in this example, success is V$INSTANCE.STATUS = OPEN and V$DATABASE.OPEN_MODE = READ WRITE. Those fields describe the instance stage and the database open mode. Review the same interval in the alert log. Do not manufacture recovery entries or infer that recovery ran merely because the database opened. Transaction cleanup can continue after opening. This lesson does not require proof that every terminated transaction has already been rolled back. If opening fails, preserve the exact error and the alert-log entries. The state may remain MOUNTED. The example does not authorize a recovery command, forced restart, file deletion, or configuration repair. Opening the CDB does not open APP_PDB. Query V$PDBS from the root. PDB$SEED normally appears as READ ONLY. A mounted application PDB needs its own opening operation. Service availability, restricted access, and a permitted connection are separate checks. Restore the originally recorded modes and services, and open only the PDBs that should be open.

Quiz

1. What does STARTUP NOMOUNT do in this staged sequence?

Starts the instance without mounting the database. Mounts and opens every PDB. Opens the database read-only. Rebuilds the control files.

2. The instance is already at NOMOUNT. Which command advances this same instance to the mounted stage?

STARTUP FORCE ALTER DATABASE MOUNT; ALTER DATABASE OPEN; COMMIT;

3. Which result verifies the database's open mode after normal primary opening?

V$INSTANCE.INSTANCE_NAME The presence of a control-file path V$DATABASE.OPEN_MODE = READ WRITE A remembered earlier STARTED result

4. Opening returns an error. What should guide the next action?

Repeated forced startups until it opens Deleting the named database file Assuming the database is open because mounting succeeded The exact error, current state, and corresponding alert-log evidence

5. ALTER DATABASE OPEN; succeeds. Does that prove APP_PDB is open for reading and writing?

Yes. All PDBs share the CDB's mode. No. Inspect that PDB in V$PDBS. Yes. A mounted PDB permits ordinary application data access. Only the SQL*Plus version determines this.

The displayed results are constructed examples, not output from an executed database. APP_PDB is a replaceable name for the user-created PDB used by an application. Practice only on an explicitly designated disposable, unmanaged Oracle Database 19c instance with an approved outage and a restorable snapshot. Do not apply these startup commands to a production database, a shared instance, a RAC database, or an Oracle Restart or Clusterware resource. No database was started or changed while preparing these notes.

AIOps Pro

https://www.apps-dba.com/ https://x.com/AIOpsPro https://www.youtube.com/@AIOpsPro