Database Mount Stage

After the database is booted from Nomount to Mount State, view the log:

wed dec 17 13:23:19 2014alter database  Mountwed dec 17 13:23:23 2014successful mount of redo thread 1,  with mount id 1394303559Database mounted in Exclusive ModeLost  write protection disabledcompleted: alter database mountwed dec 17  13:36:20 2014db_recovery_file_dest_size of 3882 mb is 0.00% used. this  is auser-specified limit on the amount of space that will  be used by thisdatabase for recovery-related files, and does  not reflect the amount ofspace available in the underlying  Filesystem or asm diskgroup. 

The log prompts for a successful load of the redo thread. and output Mount ID 1394303559 here, after several reboots, you can also dump the control files to see the changes.

View the configuration in the parameters (11g generates two control files by default, one placed in the data directory and the other in the Flash zone directory):

sql> show parameters control_files;name                TYPE                                value------------------ --------------------------------- ------------------------------ control_files      string                              /DBBK/oracle/oradata/orcl/cont                                                                           rol01.ctl, /dbbk/oracle/flash_                                                                           recovery_area/orcl/control02.c                                                                            tl 

When the database switches from Nomount to mount, the database first reads Controlfile in the path specified in SPFile:

Sql> col status for a10sql> select status,name,is_recovery_dest_file,block _size,file_size_blks from v$controlfile; status     name                                                   is_recove block_size file_size_blks---------- ------------------------------------------- -------- --------- ---------- --------------            /DBBK/oracle/oradata/orcl/control01.ctl              NO              16384            594           /dbbk/oracle/flash_recovery_area/orcl/ control02.ctl no             16384             594

The following error is reported when the database cannot find the specified controlfile:

Wed Dec 11:14:06 2014alter Database Mountora-00210:cannot Open the specified control Fileora-00202:control file: '/db BK/ORACLE/PRODUCT/11.2.0.1.0/DBS/CNTRLORCL.DBF ' ora-27037:unable to obtain file statuslinux-x86_64 Error:2: No such File or directory

To be safe, you can also customize the data to increase the database controlfile, specify the location, specify multiple control files in the pfile before the database starts, and copy the control file to the corresponding path:

sql> show parameter control_files;name                                   TYPE                                value------------------------------------ --------------------------------- ------------------ ------------control_files                         string                              /DBBK/oracle/oradata/orcl/cont                                                                           rol01.ctl, /DBBK/oracle/oradat                                                                           a/orcl/control03.ctl, /DBBK/or                                                                           acle/flash_recovery_area/orcl/                                                                           control02.ctlSQL> select  name,block_size,file_size_blks from v$controlfile;name                                                   Block_size file_size_blks--------------------------------------------------- ---------- ------- -------/dbbk/oracle/oradata/orcl/control01.ctl                   16384             594/DBBK/oracle/oradata/orcl/control03.ctl                   16384             594/DBBK/oracle/flash_recovery_area/orcl/control02.ctl       16384            594

Modify the Mount ID to see the Mount status changed once again

[[email protected] trace]$ grep-b2 ' Mount ID ' alert_orcl.log ALTER DATABASE mountwed DEC 13:23:23 2014Successful Mount of Redo thread 1, with Mount ID 1394303559--alter database mountwed Dec 14:28:10 2014Successful Mount of Redo thread 1 With Mount ID 1394319734

When booting to the Mount state as described in Gai DBA Primer, Advanced and diagnostic cases, the database also requires an important file-password file, located under $oracle_home/dbs, named: Orapw+sid

[Email protected] dbs]$ strings ORAPWORCL]\[zoracle Remote Password fileinternal59f91175308d448bab38edaf3af77681ts/c

However, by verifying the discovery of 11G, the database is loaded with the validation of the password file has been canceled, in fact, it can also explain why the SYS user password to modify the database before 11G needs to be modified by the ORAPWD command, and to 11G only through the ALTER user SYS Identified by ' NewPassword ' in such a way that you can change your password. The database parameter associated with the file remote_login_passwordfile.

With regard to the use of the ORAPWD command, the use of commands can be obtained by directly entering commands in the terminal, and subsequent use of the command is further explained:

Usage: orapwd file=<fname> entries=<users> force=<y/n> ignorecase= <y/n> nosysdba=<y/n>  where    file - name of  password file  (required),    password - password for  sys will be prompted if not specified at command line,     entries - maximum number of distinct DBA  (optional),     force - whether to overwrite existing file  ( Optional),    ignorecase - passwords are case-insensitive  ( Optional), &NBSP;&NBSP;&NBSP;&NBSP;NOSYSDBA&NBSP;-&NBSP;WHETHER&NBSP;TO&NBSP;SHUT&NBSP;OUT&NBSP;THE&NBSP;SYSDBA  logon  (optional database vault only) .      there  must be no spaces around the equal-to  (=)  character. 

In addition, there are some files in the $oracle_home/dbs directory, such as HC_ORCL.DAT,HC represents the health check, the online introduction of the file as a instance healthy status check when the reference file, the contents of the file said do not delete or modify him, However, the actual discovery is automatically created each time the instance is restarted.

There is also a file when LKORCL, from the naming method can be seen when the file instance of the lock file, LK means lock. The same file will be re-created every time the instance starts, but as mentioned in the Gai book, when the database shuts down and the lock is not released, it can cause subsequent databases to fail to start. Because no such problem has been encountered. For the moment, it is not an example.

Reference: "DBA Primer, Advanced and diagnostic case" Gai

This article is from the "linuxoracle" blog, make sure to keep this source http://onlinekof2001.blog.51cto.com/3106724/1591011

Database Mount Stage