Starting oracle database
Starting up Oracle database requires some important detail to note. Failure to follow the proper
steps would end up to failed database startup.
Remember that we need to login as a user with SYSDBA privileges to startup an Oracle database which would enable us to for example do a – SQL>connect / as sysdba.
Here is an example of a DBA connecting to his database and starting the instance:
In the above example the database was shutdown so when we logged as sysdba, we are then connected to idle instance. When we executed the startup query the database was opened after going through different startup stages as shown in example and discussed below:
* Startup (nomount)
* Mount
* Open
Let's look at these stages in a bit more detail.
The Startup (nomount) Stage
When you issue the startup command, the first thing the database will do is enter the nomount stage. During the nomount stage, Oracle first opens and reads the initialization parameter file (init.ora) to see how the database is configured. For example, the sizes of all of the memory areas in Oracle are defined within the parameter file.
After the parameter file is accessed, the memory areas associated with the database instance are allocated. Also, during the nomount stage, the Oracle background processes are started. Together, we call these processes and the associated allocated memory the Oracle instance. Once the instance has started successfully, the database is considered to be in the nomount stage. If you issue the startup command, then Oracle will automatically move onto the next stage of the startup, the mount stage.
Starting the Oracle Instance (Nomount Stage)
There are some types of Oracle recovery operations that require the database to be in
nomount stage. When this is the case, you need to issue a special startup command: startup
nomount, as seen in this example:
SQL> startup nomount
The Mount Stage
When the startup command enters the mount stage, it opens and reads the control file. The control file is a binary file that tracks important database information, such as the location of the database datafiles.
In the mount stage, Oracle determines the location of the datafiles, but does not yet open them. Once the datafile locations have been identified, the database is ready to be opened.
Mounting the Database
Some forms of recovery require that the database be opened in mount stage. To put the database in mount stage, use the startup mount command as seen here:
SQL> startup mount
If you have already started the database instance with the startup nomount command, you might change it from the nomount to mount startup stage using the alter database command:
SQL> alter database mount;
The Open Oracle startup Stage
The last startup step for an Oracle database is the open stage. When Oracle opens the database, it accesses all of the datafiles associated with the database.
Once it has accessed the database datafiles, Oracle makes sure that all of the database datafiles are consistent.
Opening the Oracle Database
To open the database, you can just use the startup command as seen in this example
SQL> startup
If the database is mounted, you can open it with the alter database open command as seen in
this example:
SQL> alter database open;
Opening the Database in Restricted Mode
You can also start the database in restricted mode. Restricted mode will only allow users with special privileges (we will discuss user privileges in a later chapter) to access the database (typically DBA's), even though the database is technically open. We use the startup restrict command to open the database in restricted mode as seen in this example.
SQL> startup restrict
You can take the database in and out of restricted mode with the alter database command as seen in this example:
-- Put the database in restricted session mode.
SQL> alter system enable restricted session;
-- Take the database out of restricted session mode.
SQL> alter system disable restricted session;
Note: Any users connected to the Oracle instance when going into restricted mode will remain connected; they must be manually disconnected from the database by exiting gracefully or by the DBA with the "alter system kill session 'sid,serial#'" command.
0 comments:
Post a Comment