Oracle starts in three stages: NOMOUNT, MOUNT, and OPEN. Each stage needs different files. The stage Oracle reached is why the database can still be unavailable.
Oracle DBA Lesson 22A — Where Did Startup Stop?
The examples are Oracle Database 19c, one instance, one container database.
Instance and database
An instance is the memory and the processes. The shared memory is the SGA. Background processes write data and redo. The database is the files that instance manages. A CDB holds the root and its PDBs. Memory and files are different things, so the instance can be running while the database is still closed.
| Stage | What Oracle has done | V$INSTANCE.STATUS |
|---|---|---|
| NOMOUNT | Read the parameters, allocated the SGA, started the background processes. No database data access. | STARTED |
| MOUNT | Opened the control file and identified the database and its recorded files. No general data access. | MOUNTED |
| OPEN | Opened the required data files and online redo logs. Ran instance recovery if it was needed. Data access still depends on open mode and the PDB. | OPEN |
The stages stack. OPEN already has an instance and a mounted database. A plain STARTUP in SQL*Plus goes through to OPEN. You can stop at an earlier stage on purpose. OPEN can be read/write or read-only, and the session can be restricted. OPEN by itself does not mean the application is ready.
NOMOUNT
Oracle reads an initialization parameter file: a server parameter file (SPFILE), or a text parameter file (PFILE). Those parameters include memory settings and the control-file paths. Oracle then allocates the SGA and starts the background processes. The control file is not mounted, so Oracle does not yet have that file's inventory. If the parameter source cannot be read, startup can fail before NOMOUNT.
V$INSTANCE is available at NOMOUNT. STARTED means NOMOUNT. It does not mean users can work.
MOUNT
The control file records the database name and the physical structure: data-file names and online redo logs. At MOUNT, Oracle opens the control files named in the parameters. It knows which database this is and which files belong to it. Users still cannot work with the data. If a required control file cannot be opened, startup does not reach MOUNT.
V$DATABASE and V$DATAFILE read the control file, so they are useful after MOUNT. V$INSTANCE already answered at NOMOUNT. A row in V$DATAFILE means the control file records that data file. It does not mean Oracle can read the file, and it does not mean the file is healthy.
OPEN
Oracle opens the required data files and online redo logs. Data files hold the data. Online redo logs hold the changes recovery needs. If the previous instance stopped uncleanly, Oracle can apply that redo while opening. That is instance recovery. It is not a restore of a missing file from backup.
A missing required data file or online redo log can stop OPEN. Some data files can be taken offline. A required SYSTEM file cannot be handled that way. The error and the file decide whether the database can open. Taking files offline is not the first step.
Read the state
These queries only read. Run each one after that stage has been reached. V$DATABASE and V$DATAFILE do not work at NOMOUNT.
At NOMOUNT or later, read the instance:
SELECT instance_name, status
FROM v$instance;STATUS is STARTED at NOMOUNT, MOUNTED at MOUNT, or OPEN after open. This is the first check when you can connect and startup did not finish.
At MOUNT or OPEN, read the database and the recorded data files:
SELECT name, open_mode
FROM v$database;
SELECT file#, name
FROM v$datafile
ORDER BY file#;V$DATABASE.NAME is the database. OPEN_MODE is MOUNTED while the database is closed, and READ WRITE or READ ONLY when it is open. V$INSTANCE.STATUS = 'OPEN' describes the instance. V$DATABASE.OPEN_MODE = 'READ WRITE' describes how the database is open. V$DATAFILE lists the data files known to the control file. That list is not a check that the file on disk is healthy.
When the CDB is OPEN, read each PDB from the root:
SELECT name, open_mode
FROM v$pdbs
ORDER BY name;One PDB can be MOUNTED while another is READ WRITE. An OPEN CDB does not mean every application PDB is usable. Check the PDB the application uses. ALTER DATABASE OPEN opens the CDB. It does not open every PDB.
Move one stage at a time
A plain STARTUP runs all three stages. To check between them, issue each change yourself. These commands change the database. Use a stopped lab instance. If Oracle Restart or Clusterware owns it, use that tooling instead.
| Command | What changes | Check |
|---|---|---|
STARTUP NOMOUNT |
Reads the parameter file and creates the instance. The control file is not mounted. | V$INSTANCE.STATUS is STARTED. |
ALTER DATABASE MOUNT; |
Opens the control file on that same instance. General data access is still closed. | STATUS is MOUNTED. V$DATABASE.OPEN_MODE is MOUNTED. |
ALTER DATABASE OPEN; |
Opens the required data files and online redo logs. Instance recovery runs if it is needed. | STATUS is OPEN. OPEN_MODE is READ WRITE or READ ONLY. |
STARTUP NOMOUNT is a SQL*Plus command. Do not put a semicolon after it. The two ALTER DATABASE statements are SQL, so they take one. ALTER DATABASE MOUNT mounts the instance you just started. It does not create a second instance. If a command fails, or the check is not the state in the table, stop. Do not run the next block.
Create the instance:
STARTUP NOMOUNT
SELECT instance_name, status
FROM v$instance;STARTED means the instance exists. If STARTUP NOMOUNT fails, read the error. The parameter file or the instance startup is the first place to look.
Mount that instance:
ALTER DATABASE MOUNT;
SELECT status
FROM v$instance;
SELECT name, open_mode
FROM v$database;Expect MOUNTED from both. A failure here usually means a configured control file could not be opened. The error text says which one.
Open the CDB:
ALTER DATABASE OPEN;
SELECT status
FROM v$instance;
SELECT name, open_mode
FROM v$database;Expect instance status OPEN. A writable CDB reports READ WRITE. A read-only open reports READ ONLY. Then run the V$PDBS query above and open the PDB the application needs. A PDB that must accept writes has to be READ WRITE.
If startup stops
The last stage narrows the dependency. It does not name the cause.
| Last stage | First question | Keep |
|---|---|---|
| Not even NOMOUNT | Could Oracle read a valid parameter file and create the instance? | The exact error, the parameter-file path, and the alert log if one was created |
| NOMOUNT, not MOUNT | Could Oracle open the configured control files? | The exact error, the control-file path, and the alert log |
| MOUNT, not OPEN | Which required data file, redo log, or recovery condition blocked OPEN? | The exact error, the file number or path, the alert log, and the control-file file list |
| CDB OPEN, application still down | Is the PDB the application needs open, and is access restricted? | V$PDBS.OPEN_MODE for that PDB, and the connection error |
The alert log records the startup errors. Read that error before you repair anything. STARTUP FORCE aborts an instance that is already running, then starts it again. It hides the first failure, and it does not get past a missing control file or data file. If Oracle Restart or Clusterware manages the database, use that tooling. Do not issue a competing manual start or stop.
Order of the dependencies: parameters, then NOMOUNT; control files, then MOUNT; required data files and redo, then OPEN. Check the PDB separately.
Oracle's own pages for this: starting up and shutting down, V$INSTANCE, V$DATABASE, V$DATAFILE, V$PDBS.
No comments:
Post a Comment