During Startup, the instance is started first (nomount stage) which then mounts the database by accessing the control files specified in the CONTROL_FILES parameter. The next step will be to open the database which includes opening the datafiles and redo log files. Applying the redo (rollforward) and the rollback of uncommitted data (rollback) also happens if the previous shutdown was not a clean one (shutdown normal or immediate).
Similarly the database and instance undergoes multiple phases during shutdown. First the database is closed ie, the datafiles and the redolog files are closed. Then the database will be dismounted to disassociate it from the instance. After a database is unmounted, Oracle Database closes the control files of the database. The next step will be to shutdown the instance by removing the SGA from the memory and terminating the background processes.
There are various shutdown modes such are normal, immediate,transactional and abort. When a database is closed as part of a SHUTDOWN with any option other than ABORT, Oracle Database writes data in the SGA to the data files and online redo log files. If a SHUTDOWN ABORT or abnormal termination occurs, then the instance of an open database closes and shuts down the database instantaneously. Oracle Database does not write data in the buffers of the SGA to the data files and redo log files. The subsequent reopening of the database requires instance recovery, which Oracle Database performs automatically.
Database startup and shutdown are powerful administrative options that are restricted to users with administrator privileges.
For details you can refer Note 1505155.1 - Master Note: Overview of Database Startup and Shutdown
This Section list out the common issues encountered during startup. The error can be reported in any of the above mentioned phases like nomount,mount or open. Since transaction recovery continues even after opening the database, you may observe issues like hang, high CPU usage etc, even after the database is open. The documents mentioned in the below section can be specific to platform or database versions.
Startup and shutdown of the container database is the same as it has always been for regular instances.
ORA-27102 errors normally occurs due to memory issues.The Common causes could be due to Semaphore Kernel misconfigurations,Memory related Ulimit settings,RAM or swap configurations.
These errors are generally reported when the Operating System called for error or when there was a connection killed or a network interconnection failures or an OS configuration issue.The error ORA-27300 will also be accompanied by ora-27301 and ora-27302
Note 579365.1 Troubleshooting ORA-27300 ORA-27301 ORA-27302 errors
This error could occur when the database init.ora parameter calling for more resources than the Operating System is configured to provide.The parameters could be PROCESSES,DB_BLOCK_SIZE,SGA and more.
This error could occur when we try to startup an instance that is already running or if the shared segments/semaphores already exist.
There could be slowness in the database during the open phase when the database is busy performing transaction recovery.
This is a general error reported at startup when there is some problem during processing of bootstrap information.There should be an accompanying error/s. Plug the ORA=704 and the other errors it reports into the Oracle Support search engine for a solution.
There are some client shadow processes hanging. Although the lk< SID> file is deleted the hanging processes still have a lock on the open file handle. This prevents the database to startup although a new lk<SID> file can be created successfully. An oracle process (background or shadow process) that exists while the instance is not started (crashed or not cleanly stopped) can have a lock on a file while this file is actually removed from the system. This is because on UNIX there is still a lock on the open file handle.
The error ORA-12547 indicates that the communication channel has been broken. It's most often thrown because the other end of the process went away unexpectedly.
The background process was not able to find one of the datafiles.The database will prohibit access to this file but other files will be unaffected.However, the first instance to open the database will need to access all online datafiles.Accompanying messages from the operating system will describe why the file was not found.
The most common issue observed while bringing down the database is shutdown immediate hang. The main reasons for Shutdown immediate hang is:
- processes still continue to be connected to the database and do not terminate.
- SMON is cleaning temp segments or performing delayed block cleanouts.
- Uncommitted transactions are being rolled back.
The below section provides the consolidated list of known issues during shutdown. The documents mentioned in the below section can be specific to platform or database versions.
Issues specific to automatic shutdown and startup
This section is specific to the automatic shutdown and startup that can be configured with the dbora / dbshut / dbstart scripts.
The key to diagnosing automatic startup failures is to determine where startup fails. This can be done via the following steps:
As with automatic startup, the key to diagnosing automatic shutdown failures is to determine where shutdown fails. This can be done via following steps:
If you were not able to resolve the issue with the details provided in this document, please raise a Service Request for further assistance from Oracle Support. The diagnostic information required to troubleshoot the issue is listed in the below document:
Troubleshooting Database Startup/Shutdown Problems (Doc ID 851057.1).