Database listening suddenly experienced a problem. After reconfiguration, restart the database. It is found that both shutdown and immediate have the same effect. After more than 10 minutes, no response has been made.
After checking the information, I checked the usage of each parameter and found that the connection request is still connected to the database, so I have to wait. The SSH was forcibly disabled, and the result was a cup of cake.
When starting, we will say:
The shutdown and startup parameters are described as follows:
Shutdown has four parameters: Normal, transactional, immediate, and abort. If no parameter is specified by default, the value is normal.
Shutdown normal: do not allow new connections, wait for the session to end, wait for the transaction to end, make a checkpoint, and close the data file. No instance recovery is required at startup.
Shutdown transactional: do not allow new connections, do not wait for the session to end, wait for the transaction to end, make a checkpoint, and close the data file. No instance recovery is required at startup.
Shutdown immediate: do not allow new connections, do not wait for the session to end, do not wait for the transaction to end, make a checkpoint and close the data file. Transactions that are not finished are automatically rolled back. No instance recovery is required at startup.
Shutdown ABORT: does not allow new connections, does not wait for the session to end, does not wait for the transaction to end, does not do the checkpoint and does not close the data file. The instance is automatically restored at startup.
In addition, data files are written to the normal, transactional, immediate, and DB buffer cache contents. uncommitted transactions are rolled back and all resources are released, the database is "clean.
For abort, the content of the DB buffer cache is not written into the data file, and transactions that are not committed are not rolled back. The database is not dismount and closed, and the data files are not closed. When the database starts, you need to restore data through the redo log, roll back the transaction through the rollback segment, and release the resource. Startup [force] [restrict] [pfile = filename] [open [recover] [database] | Mount | nomount]
Startup open: the default startup parameter is open. Open the database and allow access to the database. All files described in the control file of the current instance have been opened.
Startup mount: mount the database. only DBA is allowed to manage the database. Only the control file of the current instance is opened and the data file is not opened.
Startup nomount: only through the initialization file, allocate the SGA area, start the database background process, did not open the control file and data file. You cannot access any database.
Startup pfile = filename: Start the database with filename as the initialization file, instead of using the default initialization file.
Startup force: Stop the running of the current database and restart the database.
Startup restrict: only users with restricted session permission can access the database.
Startup RECOVER: starts the database and starts media recovery.
When shutdown is used, normal and immediate may both be unable to restart the database because the connection is not released.
The following two solutions can be used:
Code
SQL > Shutdown Abort; -- This method directly closes the database without waiting for the end of the session. It is generally not recommended. If it cannot be closed, there is generally no problem. Similar to the direct kill process.
SQL > Startup -- After shutdown abort, start the database.
SQL>Startup force;--This method is to directly shut down the database and then restart the database. This method can also be used to close the database. I can use either method when I use it.