The Oracle Startup Command

You start the Oracle database with the startup command.

You must first be logged into an account that has sysdba or
Sysoper privileges such as the SYS account
Here then is an example of a DBA connecting to his database
and starting the instance:

C:\Documents and Settings>set oracle_sid=db_name

C:\Documents and Settings>sqlplus "sys as sysdba"

SQL*Plus: Release 10.1.0.2.0 - Production on Mon Feb 21

12:35:48

Enter password: xxxx

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 251658240 bytes

Fixed Size 788368 bytes
Variable Size 145750128 bytes
Database Buffers 104857600 bytes
Redo Buffers 262144 bytes
Database mounted.
Database opened.

In this example from a Windows XP server, we set the

ORACLE_SID to the name of the database and we log into
SQL*Plus using the “sys as sysdba” login.
This gives us the privileges we need to be able to startup the
database.
Finally, after we enter our password, we issue the startup
command to startup the database.
Oracle displays its progress as it opens the database, and then
returns us to the SQL*Plus prompt once the startup has been
completed.

When Oracle is trying to open your database, it goes through

three distinct stages, and each of these is listed in the startup
output listed previously. These stages are:

* Startup (nomount)

* Mount

* Open

1) 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 if you issue the startup
command, then Oracle will automatically move onto the next
stage of the startup, the mount stage.
2) 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

3) 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 data files.

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.

4) 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;

5) 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 data files, Oracle makes sure
that all of the database
Data files are consistent.

6) 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;

7) Opening the Database in Restricted Mode

You can also start the database in restricted mode.
Restricted mode will only allow users with special privileges
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” command.

8) 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.
---------------------Creating Tables----------------------------

Before tables can be used, they have to be created and this is

generally the job of the DBA.
Creating tables is done with the create table command.
The create table command does the following:

* Defines the table name

* Defines the columns in the table and the data types of those
columns

* Defines what tablespace the table resides in (optional)

* Defines other characteristics of the table (optional)

Let’s look at the create table command in action:

Connect scott/tiger

CREATE TABLE books

(book_id NUMBER PRIMARY KEY,
book_name VARCHAR2 (30),
author_name VARCHAR2 (40),
book_isbn VARCHAR2 (20) )
TABLESPACE users;

Once you create a table, you can use the SQL*Plus desc
command to see its structure as seen in this example:

SQL>desc books
Name Null? Type
----------------------------------------- -------- ------------
BOOK_ID NOT NULL NUMBER
BOOK_ID_SEQ NOT NULL NUMBER
BOOK_NAME VARCHAR2 (30)
AUTHOR_NAME VARCHAR2 (40)
BOOK_ISBN VARCHAR2 (20)
TABLESPACE users;

------------------------------Altering Tables--------------------------

Having created tables, you will find there are times that you will
want to alter them in some respect. This is done with the alter
table command.
Some things you might find you need to do with the alter table
command include:

* Moving a table to another tablespace

* Adding a column to the table

* Dropping a column from the table

* Changing a column name

* Modify existing constraints or add new constraints

For example, we might want to move the BOOKS table to

another tablespace.

The alter table command allows us to do this easily:

SQL>ALTER TABLE books MOVE TABLESPACE

new_users;
You can add a column to a table with the alter table command.
In this case, we are adding a column called BOOK_PRICE to
the BOOKS table.
This column is a number data type:

SQL>ALTER TABLE books ADD book_price NUMBER;

You can add multiple columns too as seen in this example

where we add a column called BOOK_PUB_NO and
* BOOK_ALT_TITLE to the BOOKS table:

SQL>ALTER TABLE
books
ADD
(
book_pub_no NUMBER,
book_alt_title VARCHAR2 (50)
);
It used to be in Oracle that renaming or removing a column from
a table was a big deal.
You actually had to save the data, drop and re-create the table
which can have a horrible impact if it’s a big table in a
production environment. Now, you can rename or drop columns
from a table with the alter table command.

We demonstrate renaming and dropping a column in the

following example.
First we rename the BOOK_ISBN column to ISBN_NUMBER.
In the second example we drop the BOOK_PUB_NO column:

SQL>ALTER TABLE books RENAME COLUMN book_isbn

TO isbn_number;

SQL>ALTER TABLE books DROP COLUMN book_pub_no;

We discussed primary key constraints earlier in this section.

Oracle actually has a number of different constraint types that
we will cover in more detail later in this section. However, we
should take a moment to see how you can rename a constraint
with the alter table command:

SQL>ALTER TABLE books RENAME CONSTRAINT

pk_books TO pk_book;

-----------------------------Dropping Tables----------------------------
The drop table command allows you to drop tables from your
Oracle database.

SQL>DROP TABLE books;

Oracle 10g has a recycle bin, kind of an old tables retirement

home.
You can recover a table that you have dropped from the recycle
bin using the flashback table command as seen here:

SQL> DROP TABLE books;

SQL> FLASHBACK TABLE books TO BEFORE DROP;

Dropped a table by accident????? In Oracle Database 10g the

flashback table command will recover the table and many of the
objects associated with the table.
Some things are not recovered like bitmap join indexes and
foreign key constraints.
--------------------Table and tablespace location---------------------

Finding out who owns a table and what tablespace it is in is a

pretty common need of the DBA.
In this query, we use the dba_tables view to find the owner and
tablespace name of the EMP table.

SQL> select owner, table_name, tablespace_name

2 from dba_tables
3 where table_name='EMP';

OWNER TABLE_NAME TABLESPACE_NAME

-------------- -------------------- --------------------------
SCOTT EMP USERS
POLL EMP USERS
As we can see from this query, we have two tables called EMP,
Owned by two different users (Scott and Poll). Both tables are
contained in the USERS tablespace.

A good exercise for you might be to try to join this query with a
view like DBA_EXTENTS and figure out just how big these
tables are allocated.

---------------------------See the indexes for a table------------------

It is not unusual to wonder what indexes a specific table might

have, and what columns in the table are assigned to those
indexes.
The following query will provide this information to you.
It draws on the information in the dba_ind_columns data
dictionary view:

SQL> column table_owner format a15

SQL> column table_name format a20
SQL> column index_name format a20
SQL> column column_name format a20
SQL> Select owner, table_name, index_name, column_name
2 FROM dba_ind_columns
3 Order by owner, table_name, column_position
4 Where owner=’SCOTT’
5 AND table_name=’EMP’;

TABLE_OWNER TABLE_NAME INDEX_NAME COLUMN_NAME

--------------- -------------------- -------------- ----------------
SCOTT EMP PK_EMP EMPNO

--------------------------Grant user privileges-------------------------

Once we have created a user, we probably want that user to be

able to do something in our database.
A created user has no privileges; they can not even connect to
the database.
In this section we will address this problem by learning how to
give users the privileges they need to actually get some work
done. First we will look at system privileges, followed by object
privileges. We will then look at how you can use roles to make
user administration much easier.

* Oracle System Privileges:

System privileges allow the user to perform system level
activities.
This might include such things as being able to actually connect
to the system, or it might include the ability to do things like
create objects in schemas other than your own schema. In the
next sections we will discuss the grant command, which you use
to grant system privileges.
Also the revoke command is used to revoke privileges from
users.

* Granting Oracle System Level Privileges:

The grant command is used to grant system level privileges.
System level privileges are those privileges that you need to
actually do something on the system.

For example you grant system level privileges to a user so that

they can:

* Connect to the database (create session)

* Create objects (create table, create index)

* Perform DBA activities, like backup the database (SYSDBA,

SYSOPER)

* Alter session related parameters (alter session)

Basically, even if you create a user account,

it will not be able to do anything until you have granted it a
basic set of privileges.
Typically you would always grant the create session privilege so
that the user can connect to the database.

The grant command is pretty simple to use, you just need to

know what privilege you want to grant and who you want to
grant that privilege to.
------------------Oracle shutdown command Concepts-------------
You might take the database down to make configuration
changes, for a backup or to upgrade Oracle software. When it’s
time to bring your database down, we use the shutdown
command.

As you might guess, the shutdown command comes in many

forms.
Oracle has three shutdown modes:

* Normal (default) - waits for in-flight work to complete

* Immediate - terminates all sessions and does a rollback on all

uncommitted transactions

* Abort - aborts all sessions, leaving current DML in need of

rollback, de-allocates the SGA and terminates the background
processes.

The "normal" and "immediate" modes can take a long time in

you have in-flight transactions, and many Oracle DBA's ensure
a swift clean shutdown this way, aborting the sessions, re-
starting to allow warm start rollback of the aborted transactions,
and a shutdown immediate to close cleanly:

SQL> shutdown abort

SQL> startup

SQL> shutdown immediate

 Oracle Normal Shutdown:

A normal shutdown of an Oracle database is actually rarely
used.
This is because the normal shutdown waits for everyone to
complete their work and then logoff in an orderly fashion. When
a normal shutdown occurs, the database is closed in a normal
manner, and all changes made in the database are flushed to the
database data files. This is known as a “clean shutdown”.

Most of the time this is not practical… there always seems to be

someone who has left for vacation and who forgot to log out, or
there are times that Oracle processes become “zombied” (this is
where Oracle thinks someone is connected to the database but
they really are not).
In these cases, the database will never come down.
It will simply wait forever until you manually kill those
sessions. Because of this, we often recommend the shutdown
immediate or shutdown abort commands, which we will discuss
in the next sections. Here is an example of the use of the normal
shutdown command.

SQL> shutdown

When you execute a shutdown, Oracle will flush all the changes
in memory out to the database data files. This makes database
startup quicker because the database is in a consistent state.

Think of it this way: if you jump into the air and land on your
feet, you have landed in a way that prepares you to make
another jump. If, instead, you jump and land on your back, you
are in no position to make another jump; instead, you must
perform a recovery by taking the actions required to stand again.
A clean shutdown is one that is prepared to come back up
without delay.
A dirty shutdown is one that lands on its back; it can not come
back up without first recovering itself.

 Oracle Shutdown Immediate:

Perhaps the best way to initially shutdown the database is the
shutdown immediate command.
This command will prevent any new logins, then rollback any
uncommitted transactions, and then bring down the database. In
the process of bringing down the database,
Oracle will flush all the changes in memory out to the database
data files too, just like a regular shutdown does. This makes
database startup quicker.
Here is an example of shutting down a database with the
shutdown immediate command:

SQL> shutdown immediate

The shutdown immediate command will work most of the time,

but there are times when it can hang and fail to shutdown the
database. In these cases, the shutdown abort command is called
for.

 Oracle Shutdown Abort Command:

The shutdown abort command is pretty much a guaranteed way
to get your database to shutdown.
It’s a “hard crash” of the database, and this can result in a longer
time to start the database back up. Still, you can’t really hurt the
database using the shutdown abort command, and during your
DBA years you will find more than a few occasions to use the
shutdown abort command.

A shutdown abort should not be your first shutdown method of

choice, there may be times when you must force the database
down. Here is an example using the shutdown abort command:

SQL> shutdown abort

----------------------Oracle Database Files Concepts----------------

The final components of the Oracle architecture are the physical

files where our information resided on disk. Oracle has several
types for data files, each for a different purpose:
* Database data files

* Control files

* Online redo logs

* Parameter files

* Other database related files

*****************Database data file*******************

Database data files are physical files stored on disk. These files
are used to store data on disk. Database data files are only
written to by the DBWR processes that we introduced you to
earlier
(There is an exception or two to this statement, but for now,
assume that this point this true).

These database data files are associated with Oracle

“tablespaces”, which are “logical” containers for tables and
indexes.
*******************Control files********************

The Control File of the database is a binary file that contains a

great deal of database information. The control file contains the
database name, data about the database log files.
Oracle cannot function without valid control files.

Because the control file is so important, Oracle allows you to

maintain duplicate copies of the control file. When you have
more than one control file, then you are said to be multiplexing
your control files.
It is a good practice to put these multiple copies on different
disks to protect the control file.
Later in this book, we will demonstrate how to do this.

***************Online redo logs concepts**************

Think of the online redo logs like a tape recorder that records
every change in the Oracle database. As changes occur, they are
regularly recorded in the online redo logs, just like you might
record a movie on your VCR.

In the event that a disk crashes, you may have to replace the disk
and restore the disk data from a backup tape. If this backup tape
was several days ago, you have lost a lot of data.

Fortunately, Oracle can “replay” the saved transactions in the

online redo logs, and re-apply lost transactions back into the
database. Many times, this means that Oracle can recover from a
crash without the DBA having to do anything other than just
telling the database to startup. We will cover the topic of online
redo log files and how they relate to database recovery in later
chapters of this book.

At a minimum, Oracle requires that you have two online redo

logs assigned to the database. Oracle will write redo to the first
log, and when the first log is full, Oracle will switch to the
second log and write the same redo. Each of these individual
online redo logs is known as an online redo log group.

The reason we call them groups is that there can be mirrored

copies of the online redo log files in each group. Like control
files, it’s a good idea to have multiplexed copies of the Online
redo logs. Oracle allows you to define multiple copies of these
files. Each copy is called a member. Each redo log group can
have one or more members.

*************Oracle Parameter file Concepts************

The parameter file (sometimes called init.ora) contains

configuration information for the database to use at startup time.
The parameter file you configure how much RAM the database
is going to use, where to find the control files, where to write
trace files, and a whole host of other information. In most cases
the database will not start without a parameter file. Oracle
allows you to have a manual parameter file
(Called a PFILE) or a server-side parameter file (called a
SPFILE).
***********Other Database Related Files*************

When working with the Oracle database you will be introduced

to a number of different kinds of files. The following table is a
list of the most common files and their general purpose.
* Oracle Trace Files - Created by Oracle in a number of
different situations. These can be created as a result of a
database crash, a session failure, an unexpected but non-fatal
database failure, or based on specific user operational
commands.

* Alert log - This is the general log file for each Oracle
database.

Networking configuration files - These files are used to

configure the different network components of the Oracle
database. These include files such as tnsnames.ora and
listener.ora.

* Oracle Database Software Binaries - The Oracle Database

software includes the basic programs that allow the database to
function.
*********Oracle Database Required Processes**********

Here are some of the most important Oracle background

processes:

* SMON - System Monitor process recovers after instance

failure and monitors temporary segments and extents. SMON in
a non-failed instance can also perform failed instance recovery
for other failed RAC instance.

* PMON - Process Monitor process recovers failed process

resources.
If MTS (also called Shared Server Architecture) is being
utilized,
PMON monitors and restarts any failed dispatcher or server
processes.
In RAC, PMON’s role as service registration agent is
particularly important.

* DBWR - Database Writer or Dirty Buffer Writer process is

responsible for writing dirty buffers from the database block
cache to the database data files. Generally, DBWR only writes
blocks back to the data files on commit, or when the cache is
full and space has to be made for more blocks. The possible
multiple DBWR processes in RAC must be coordinated through
the locking and global cache processes to ensure efficient
processing is accomplished.

* LGWR - Log Writer process is responsible for writing the log

buffers out to the redo logs.In RAC, each RAC instance has its
own LGWR process that maintains that instance’s thread of redo
logs.
* ARCH – The optional Archive process writes filled redo logs
to the archive log location(s).
In RAC, the various ARCH processes can be utilized to ensure
that copies of the archived redo logs for each instance are
available to the other instances in the RAC setup should they be
needed for recovery.