STARTUP/SHUTDOWN States, Mount/Open Modes, Restricted Sessions, and Recovery Context

Learning outcomes

Maintenance begins on the ServiceHub Free database. One operator uses STARTUP and SHUTDOWN as opaque commands; another understands that Oracle transitions through states that require progressively more persistent metadata. The second operator can diagnose a missing parameter file, missing control file, recovery requirement, or closed PDB without guessing.

1. NOMOUNT: instance exists before the database is mounted

STARTUP NOMOUNT reads the initialization parameter file, allocates the SGA, and starts background processes. At this point the instance exists, but Oracle has not yet opened the database control files. This state is required for selected administrative/recovery operations such as creating a database or recreating a control file.

-- Run from a dedicated local SYSDBA connection.SHUTDOWN IMMEDIATESTARTUP NOMOUNTSELECT instance_name, status, database_status, startup_timeFROM   v$instance;-- Intentionally test the boundary: database metadata is not mounted yet.SELECT name, open_mode FROM v$database;

The second query should fail because the database is not mounted. That error is useful evidence: the instance started successfully, so parameter-file/SGA/background-process initialization progressed far enough; database control-file access has not.

2. MOUNT: control-file metadata is available, datafiles are not open for normal use

ALTER DATABASE MOUNT causes the instance to open the control files and associate with the database. Oracle can now reason about datafile/redo metadata and perform many recovery/maintenance operations, but ordinary application data access is not available.

ALTER DATABASE MOUNT;SELECT instance_name, status, database_statusFROM   v$instance;SELECT name, open_mode, database_role, log_modeFROM   v$database;SELECT name, status FROM v$controlfile ORDER BY name;

The exact V$INSTANCE.STATUS and V$DATABASE.OPEN_MODE values give stronger evidence than “startup printed no error.” If mounting fails with a control-file-related ORA error, do not jump to datafile repair before reading the alert log and parameter/control-file configuration.

3. OPEN: normal database access begins, but PDB state remains separate

ALTER DATABASE OPEN opens the CDB database for the selected access mode after required consistency/recovery checks. In a multitenant database, individual pluggable databases (PDBs) still have their own open modes. ServiceHub lives in FREEPDB1, so “the CDB is open” does not prove the application PDB is open.

ALTER DATABASE OPEN;SELECT name, open_mode, database_roleFROM   v$database;SHOW PDBSSELECT con_id, name, open_mode, restrictedFROM   v$pdbsORDER  BY con_id;

If FREEPDB1 is not READ WRITE, open it explicitly in the disposable lab:

ALTER PLUGGABLE DATABASE FREEPDB1 OPEN;SELECT con_id, name, open_mode, restrictedFROM   v$pdbsWHERE  name = 'FREEPDB1';

Whether a PDB automatically reopens after a future CDB restart depends on saved state/management behavior. Do not hard-code an expectation; verify it after every controlled restart.

4. Shutdown modes encode different promises

SHUTDOWN IMMEDIATE is a practical planned-maintenance mode; it is not the same as killing the database process. ABORT is for cases where normal shutdown methods cannot complete or for deliberate failure testing. In Data Guard/RAC/automatic-failover environments, an abort can have additional topology consequences, so never generalize a single-instance lab procedure.

5. Restricted session and read-only are different controls

Restricted session limits new database logins to appropriately privileged users while the database can remain open. It is useful during selected maintenance operations, but existing sessions and service behavior require careful handling. READ ONLY is an open mode that restricts database changes; it is not an authentication mode and does not mean “only DBAs can connect.”

SELECT logins, status, database_statusFROM   v$instance;ALTER SYSTEM ENABLE RESTRICTED SESSION;SELECT logins FROM v$instance;-- Test from a separate unprivileged session only if the lab is disposable.ALTER SYSTEM DISABLE RESTRICTED SESSION;SELECT logins FROM v$instance;

A user with RESTRICTED SESSION can still connect during restriction. Therefore, a successful privileged login is not proof that restriction is disabled. Verify V$INSTANCE.LOGINS and the actual user privilege model.

6. Failure case: ABORT and the meaning of instance recovery

A power loss or SHUTDOWN ABORT can stop the instance without a clean close. Oracle then performs instance recovery during the next startup: redo is applied as needed to bring datafiles to a consistent state, and uncommitted work is rolled back according to transaction/recovery mechanisms. The database should not require a human to “repair every table” after an ordinary crash if media is intact.

For safety, the mandatory lab does not issue ABORT. If you deliberately practice it, do so only after confirming the environment is disposable and preserve the alert log before/after so you can see recovery evidence. Chapter 14 teaches redo/checkpoint/instance recovery in detail.

7. Hands-on lab: clean restart with state verification

Use a dedicated local SYSDBA connection from the Free host/container. This drill uses SHUTDOWN IMMEDIATE, then normal STARTUP. Keep another terminal available for listener checks.

SHOW CON_NAMESELECT instance_name, status, startup_time FROM v$instance;SHOW PDBSSHUTDOWN IMMEDIATESTARTUPSELECT instance_name, status, database_status, startup_timeFROM   v$instance;SELECT name, open_mode, database_role FROM v$database;SHOW PDBS

lsnrctl statuslsnrctl services

If the PDB is closed, open FREEPDB1 before application verification. Then reconnect as SERVICEHUB_APP using its PDB service and run a simple read from SERVICEHUB_OWNER.WORK_ORDERS. Do not “verify” the restart only with SYSDBA.

SELECT COUNT(*) AS work_ordersFROM servicehub_owner.work_orders;SELECT SYS_CONTEXT('USERENV','CON_NAME') AS con_name,       SYS_CONTEXT('USERENV','SERVICE_NAME') AS service_nameFROM dual;

Acceptance criteria: clean shutdown completes; startup reaches OPEN; FREEPDB1 is opened as intended; listener reports the service; the least-privilege runtime user reconnects; deterministic seed data remains queryable.

8. Production judgment

Startup/shutdown is orchestration, not command memorization. Record who owns the control plane: SQL*Plus/SQLcl on a standalone host, Oracle Restart, RAC Clusterware, Data Guard broker, or a managed cloud service. Use the topology-aware control plane where required. Before maintenance, establish drain/transaction policy, backup/recovery posture, PDB/service dependencies, and post-start validation. After startup, verify application-level service health—not only V$INSTANCE.

When startup fails, resist repeated STARTUP FORCE or file editing. Identify the last successful state: did the instance allocate memory, did control files open, did the database mount, did recovery/open complete, did PDBs/services register? Lesson 5 turns that sequence into an ADR/alert-log troubleshooting workflow.

9. Summary and next step

NOMOUNT proves parameter/memory/process startup; MOUNT adds control-file/database association; OPEN enables normal database access after consistency checks; PDB open state is a further boundary. Shutdown modes differ in what they wait for and whether crash recovery is needed. Restricted session and read-only are separate controls. A safe operator verifies state at every layer and uses a topology-aware control plane.

Authoritative references

• Oracle AI Database Administrator’s Guide — startup/shutdown and instance administration
• Oracle Multitenant Administrator’s Guide — Administering a CDB — CDB startup and force/recovery context
• Oracle Multitenant Administrator’s Guide — Administering PDBs — PDB open/close and saved state
• Oracle AI Database Concepts — instance/database/recovery mental model
• Oracle Net Services Administrator’s Guide — post-start listener/service verification