Oracle Data Base

http://www.dba-oracle.com/concepts/starting_database.htm

When Oracle is trying to open your database, it goes through three distinct stages .
These stages are:

* Startup (no mount)

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 confi gured. 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 Oracl e 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 comma nd, then
Oracle will automatically move onto the next stage of the startup, the mount stage

* Mount
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 inf ormation, such
as the location of the database datafiles.

In the mount stage, Oracle determines the location of the data files, but does not yet
open them. Once the data file locations have been identified, the database is ready to
be opened

* Open
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.
Problems during Oracle Startup
The most typical reason for a database not starting up is a prior database crash, a
data corruption, disk failure or some other catastrophic event from which the
database cannot recover. In these cases, you have to go into database recovery mode
to start your instance. There is a chapter on recovery later in this book and we will
discuss what to do when Oracle will not startup

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

http://www.dbasupport.com/forums/showthread.php?21922-Database-MOUNT-and-START-What-
exactly-they-mean

What is?

1) Instance Started
2) Database Mounted
3) Database Opened
4) Database Started.

Instance started: memory allocated.

Database mounted: data files available for "maintenance" purposes (very restricted
access, local server access only ).

Database opened: users can connect, all data files are available for use.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

1) Instance Started
2) Database Mounted
3) Database Opened
4) Database Started.

*When the instance is started, the init.ora file is read by the system and SGA is
allocated as per the initialization parameters . No database is associated with this
instance.

@Once you mount the database, it is associated with the instance. The control file of
the DB is read and db files, redo log files and rollback segments, all are associated
with the instance. (These files are not yet 'open' ) That is why this state is used for
moving around the db files.
#when the database is started or opened, all these files are open and available for use
to the users.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Startup No mount: -Read the parameter file and start the instance.
Instance name identified by ORACLE_SID env parameter.
The parameter file controls such things as SGA size, database name that can connect
to this instance.
Database not associated with instance yet.
As an example, you may need to do this if you will mount a standby database .

Mount: -

Associates database with the instance.

Open and read control files
Establish physical files associated with database. i.e. location, size, amount of redo
log files. Physical database file names and locations.

DBA may need to be in mount state for all kinds of DBA activity.
Examples:
rename/move system data file.
Put database in archive log mode .

Database not yet available for user connections.

Opened/started:

Ensure physical files exist.

Make available for normal operations.
Open online data files, redo logs.
Acquire rollback segments.

These states are useful in many situations to a DBA, main areas where these are
useful are;

Architecture/Admin
Backup/Recovery.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

https://juniororacledba.wordpress.com/2011/07/30/oracle-startup-phases/
Shutdown

The database is shut down and cannot be connected to by anyone but SYS.

Startup no mount:

During this phase the database reads the initialization parameters from the spfile or
pfile. If you get an error at this stage, it’s best to check this file exists, is accessible
and contains no errors.
This phase does not allow access to the database and is usually only done for database
creation, or recreation of control files

Startup mount:

During this phase the database checks the control file, this is a small binary file that
records the physical structure of the database.
If you receive errors during the mount phase, then it is best to check the control file
exists.
This phase allows for certain DBA activities to take place, but does not allow general
access to the database.

Startup open:
During this phase the database tries to start in open mo de, ready for all users to
access. It checks the data files exist and any errors at this stage you should check the
data files.
This phase can be run in restricted or unrestricted mode, depending on whether you
want all users to have access or not.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

http://markstutpnt.blogspot.in/2013/06/what-are-various-stages-of-database.html

What are the various stages of database startup and shutdown

Starting Up an Oracle Database

STARTUP NOMOUNT:

This starts the instance without mounting the database. When a database is started in
this mode, the parameter file is read, and the background processes and memory
structures are initiated, but they are not attached or communicating with the disk
structures of the database. When the instance is in this state, the database is not
available for use.

If a database is started in NOMOUNT mode, only the background processes and

instance are started. The instance is not associated with any database. This state i s
used to create a database or to create a database control file.

At times, a database may not be able to go to the next mode (called MOUNT mode)
and remains in NOMOUNT mode. For example, this can occur if Oracle has a problem
accessing the control file st ructures, which contain important information to continue
with the startup process. If these structures are damaged or not available, the
database startup process cannot continue until the problem is resolved.

If STARTUP NOMOUNT fails, the most likely cau se is that the parameter file cannot be
read or is not in the default location. Other causes include OS resource limits that
prevent memory or process allocation.

STARTUP MOUNT:

This performs all the work of the STARTUP NOMOUNT option but also attaches an d
interacts with the database structures. At this point, Oracle obtains information from
the control files that it uses to locate and attach to the main database structures. The
control file contains the name of the database, all the data file names, and t he redo
log files associated with the database.

Certain administrative tasks can be performed while the database is in this mode,
including renaming data files, enabling or disabling archive logging, renaming and
adding redo log files, and recovering the database.

STARTUP OPEN:

This is the default startup mode if no mode is specified on the STARTUP command
line. STARTUP OPEN performs all the steps of the STARTUP NOMOUNT and STARTUP
MOUNT options. This option makes the database available to all users.

When opening the database, you can use a couple of options. STARTUP OPEN READ
ONLY opens the database in read -only mode. STARTUP OPEN RECOVER opens the
database and performs a database recovery.

Although you typically use the STARTUP NOMOUNT, STARTUP MOUNT, a nd STARTUP
OPEN options, a few other startup options are available that you can use in certain
situations: STARTUP FORCE and STARTUP RESTRICT. These are discussed next.
STARTUP FORCE:

You can use the STARTUP FORCE startup option if you are experiencing difficulty
starting the database in a normal fashion. For example, if a database server lost
power and the database stopped abruptly, it can leave the database in a state in
which a STARTUP FORCE startup is necessary. This type of startup should not normal ly
be required but can be used if a normal startup does not work. What is also different
about STARTUP FORCE is that it can be issued no matter what mode the database is in.
STARTUP FORCE does a shutdown abort and then restarts the database.

STARTUP RESTRICT:

The STARTUP RESTRICT option starts up the database and places it in OPEN mode but
gives access only to users who have the RESTRICTED SESSION privilege. You might
want to open a database using the RESTRICTED option when you want to perform
maintenance on the database while it is open but ensure that users cannot connect
and perform work on the database. You might also want to open the database using
the RESTRICTED option to perform database exports or imports and guarantee that no
users are accessing the system during these activities. After you are done with your
work, you can disable the restricted session, ALTER SYSTEM DISABLE RESTRICTED
SESSION, so everyone can connect to the database.

Shutting Down an Oracle Database

SHUTDOWN NORMAL:

SHUTDOWN TRANSACTIONAL:

SHUTDOWN IMMEDIATE:

SHUTDOWN ABORT:

SHUTDOWN NORMAL:

A normal shutdown is the default type of shutdown that Oracle performs if no

shutdown options are provided. You need to be aware of the following when doing a
normal shutdown:

1. No new Oracle connections are allowed from the time the SHUTDOWN NORMAL
command is issued.

2. The database will wait until all users are disconnected to proceed with the
shutdown process.

Because Oracle waits until all users are disconnected before shutting dow n, you can
find yourself waiting indefinitely for a client who may be connected but is no longer
doing any work or may have left for the day. This can require extra work, identifying
which connections are still active and either notifying the users to disc onnect or
forcing the client disconnections by killing their session. This type of shutdown is also
known as a clean shutdown because when you start Oracle again, no recovery is
necessary.

SHUTDOWN TRANSACTIONAL:

A transactional shutdown of the database is a bit more aggressive than a normal

shutdown. The characteristics of the transactional shutdown are as follows:

1. No new Oracle connections a NN re allowed from the time the SHUTDOWN

TRANSACTIONAL command is issued.

2. No new transactions are allowed to start from the time the SHUTDOWN
TRANSACTIONAL command is issued.

3. Once all active transactions on the database have completed, all client connections
are disconnected.

A transactional shutdown does allow client processes to complete prior to the

disconnection. This can prevent a client from losing work and can be valuable
especially if the database has long -running transactions that need to be completed
prior to shut down. This type of shutdown is also a clean shutdown and does not
require any recovery on a subsequent startup.

SHUTDOWN IMMEDIATE:

The immediate shutdown method is the next most aggressive option. An immediate
shutdown is characterized as follows:

1. No new Oracle connections are allowed from the time the SHUTDOWN IMMEDIATE
command is issued.

2. Any uncommitted transactions are rolled back. Thus, a user in the middle of a
transaction will lose all the uncommitted work.

3. Oracle does not wait for clients to disconnect. Any unfinished transactions are
rolled back, and their database connections are terminated.

This type of shutdown works well if you want to perform unattended or scripted
shutdowns of the database and you need to ensure that the database will shut down
without getting hung up during the process by clients who are con nected. Even though
Oracle is forcing transactions to roll back and disconnecting users, an immediate
shutdown is still a clean shutdown. No recovery activity takes place when Oracle is
subsequently restarted.
SHUTDOWN ABORT:

A shutdown abort is the most aggressive type of shutdown and has the following
characteristics:

1. No new Oracle connections are allowed from the time the SHUTDOWN ABORT
command is issued.

2. Any SQL statements currently in progress are terminated, regardless of their state.

3. Uncommitted work is not rolled back.

4. Oracle disconnects all client connections immediately upon the issuance of the
SHUTDOWN ABORT command.

Do not use SHUTDOWN ABORT regularly. Use it only if the other options for database
shutdown fail or if you are ex periencing some type of database problem that is
preventing Oracle from performing a clean shutdown. This type of shutdown is not a
clean shutdown and requires instance recovery when the database is subsequently
started. Instance recovery is performed auto matically when you do the startup —no
manual intervention required. During instance recovery the uncommitted changes are
rolled back from the database, and committed changes are written to the data files.
Oracle uses the redo log files and undo segments to construct the instance recovery
information.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

What is the meaning of database version in Oracle

What is the meaning of database version in Oracle?

When I say that I have installed Oracle database 11.2.0.2.0, what actually is this
11.2.0.2.0

Let’s see what all this is about:

Oracle database software has a version number. Say our database version is 11.2.0.2.0

11.2.0.2.0: The first digit is the major release number. When we say 9i, 10g or 11g
we mean the major release number.
11.2.0.2.0: This second digit is the maintenance release number. This is usually called
only "release". For example when you say 11g Release 1 or 11g Release 2 in fact you
are mentioning maintenance release number. Maintenance releases are full
installations. It means that all files are replaced during upgrade. Maintenance
releases contain bug fixes and new features for database .

11.2.0.2.0: This third digit is the release number for Oracle application servers . For
database software, it should be 0.

11.2.0.2.0: The fourth digit is called component specific release number . It shows the
patch set version that has been applied to database . As of 11g, the patch sets are
now full installations. They contain bug fixes and add new features to database.
However the number of new features is not as high as maintenance releases. Its scope
is limited. The bugs fixed by patch sets are not listed in patch inventory.

11.2.0.2.0: The last digit is called platform specific release number . Patch set updates
use this fifth number. A patch set update (PSU) is a collection of patches distributed 4
times a year by Oracle (every 3 months). They contain patches for most common bugs
and security holes. They don't add a new feature to database. They are not full
installations. Only faulty files on your database are replaced. Oracle recommends
installing patch sets even if you haven't hit any of the bugs fixed in those patch sets.