Chapter 6: Basics of the Oracle Database Architecture

Oracle Architectural Components

Structures That Connect Users to Oracle Servers

Stages in Processing Queries

Stages in Processing DML Statements

Stages in Processing COMMIT Statements

Using Administration Tools

Using Server Manager Line Mode

Identifying Admin Apps in Oracle Enterprise Manager

Using Oracle Enterprise Manager Components

Managing an Oracle Instance

Setting Up OS and Password File Authentication

Creating Your Parameter File

Starting an Instance and Opening the Database

Closing a Database and Shutting Down the Instance

Getting and Setting Parameter Values

Managing Sessions

Monitoring ALERT and Trace Files

Creating an Oracle Database

Preparing the Operating System

Preparing the Parameter File

Creating a Database in Oracle

Chapter Summary

Two-Minute Drill

Chapter Questions

Answers to Chapter Questions

In this chapter, you will learn about and demonstrate knowledge in the
following areas:

 Oracle architectural components

 Using administration tools

 Managing an Oracle instance

 Creating an Oracle database

To be a successful Oracle DBA and to pass OCP Exam 2, you must understand
the Oracle database architecture. About 16 percent of OCP Exam 2 is on this
area. An Oracle database in action consists of several elements, including
memory structures, special processes that make things run faster, and
recovery mechanisms that allow the DBA to restore systems after seemingly
unrecoverable problems. Whatever the Oracle feature, it’s all here. Review
this chapter carefully, as these concepts form the foundation for material
covered in the rest of unit and book, the OCP exam, and your work as a
DBA.

Oracle Architectural Components

In this section, you will cover the following topics related to the Oracle
architecture:

 Structures that connect users to Oracle servers

 Stages in processing queries

 Stages in processing DML statements

 Stages in processing commit statements

The Oracle database server consists of many different components. Some of

these components are memory structures, while others are processes that
execute certain tasks behind the scenes. There are also disk resources that
store the data that applications use to track data for an entire organization,
and special resources designed to allow for recovering data from problems
ranging from incorrect entry to disk failure. All these structures of the
Oracle database server, running together to allow users to read and modify
data, are referred to as an Oracle instance. This section will explain what
each component of the Oracle instance is, as well as what Oracle is doing
when users issue queries, data change or DML statements, and save their
work to Oracle by issuing commit commands.

Structures That Connect Users to Oracle Servers

Figure 6-1 demonstrates the various disk, memory, and process components
of the Oracle instance. Every Oracle database, from the smallest Oracle
application running on a handheld device to terabyte data warehouses that
run on mainframes and supercomputers, has these features working
together to manage data. They allow for applications, ranging from online
transaction processing (OLTP) apps to N-tier apps to data marts to data
warehouses, to process their data efficiently and effectively.

Figure 1: The Oracle database architecture

The SGA: Oracle’s Primary Memory Component

Focus first on the memory components of the Oracle instance. There are
two basic memory structures in Oracle. The first and most important is the
System Global Area, or SGA. When DBAs talk about most things related to
memory, they usually mean the SGA. The SGA consists of several different
items: the buffer cache, shared pool, and redo log buffer, as well as a few
other items that will be discussed later in the unit. The following subtopics
explain the primary components of the Oracle SGA.

Buffer Cache

This memory structure consists of buffers the size of database blocks that
store data needed by SQL statements issued in user processes. A database
block is the most granular unit of information storage in Oracle, in which
Oracle can place several rows of table data. The buffer cache has two
purposes: to improve performance for subsequent
repeated select statements on the same data, and to allow Oracle users to
make data changes quickly in memory. Oracle writes those data changes to
disk later.

Shared Pool

There are two mandatory structures and one optional structure in the Oracle
shared pool. The first required component is the library cache, used for
storing parsed SQL statement text and the statement’s execution plan for
reuse. The second is the dictionary cache, sometimes also referred to as
the row cache, which is used for storing recently accessed information from
the Oracle data dictionary, such as table and column definitions, usernames,
passwords, and privileges. (If you don’t know what the data dictionary is,
you’ll find more out about it later in this chapter.) These two components
are designed to improve overall Oracle performance in multiuser
environments. The optional shared pool structure contains session
information about user processes connected to Oracle. When will Oracle
include this optional component in the SGA? You’ll find out shortly.

Redo Log Buffer

This SGA component temporarily stores in memory the redo entry

information generated by DML statements run in user sessions until Oracle
writes the information to disk. DML statements include update, delete,
and insert statements run by users. What is a redo entry? It is a small
amount of information produced and saved by Oracle to reconstruct, or
redo, changes made to the database
by insert, update, delete, create, alter, and drop statements. If
some sort of failure occurred, the DBA can use redo information to recover
the Oracle database to the point of database failure.

The PGA: The Oracle User’s Memory Area

The other memory structure in the Oracle instance is called the Program
Global Area, or PGA. The PGA helps user processes execute by storing
information like bind variable values, sort areas, and other aspects of cursor
handling. Why do users need their own area to execute? Even though the
parse information for SQL or PL/SQL may already be available in the library
cache of the shared pool, the values upon which the user wants to execute
the select or update statement cannot be shared. The PGA is used to
store real values in place of bind variables for executing SQL statements.

Reading Data from Disk for Users: The Server Process

Let’s move on to quickly cover Oracle background processes. There are

several types of processes running all the time in Oracle. These types
are background, server, and network processes. The most important one
from your users’ perspectives is the server process. This process acts on the
user’s behalf to pull Oracle data from disk into the buffer cache, where the
user can manipulate it. There are two ways DBAs can set up Oracle to run
server processes: shared servers and dedicated servers. The following
subtopics identify the primary differences between these two
configurations.

TIP: Think of the Oracle server process as a genie—the magical being from
the story of Aladdin—because your wish for Oracle data is the server
process’s command!

Dedicated Servers: One Genie, One Master

In this setup, every single user connecting to Oracle will have a personal
genie handling data retrieval from disk into the buffer cache. If there are
150 users connected to Oracle, there will also be 150 genies out there
grabbing data from disk and putting it in the buffer cache for those users.
The architectural setup means that every user gets their data retrieval
requests acted upon immediately. It also means there will be additional
memory and CPU overhead on the machine running the Oracle database, and
that each dedicated server process will, depending on the workload and the
access method, sit idle most of the time. Still, this is the setup chosen by
many DBAs for overall performance reasons when hardware resources are
readily available.

Shared Servers: One Genie, Many Masters

In this setup, there is a small pool of server processes running in Oracle that
support data retrieval requests for a large number of users. Several users
are served by one server process. Oracle manages this utilization by means
of a network process called the dispatcher. User processes are assigned to a
dispatcher, and the dispatcher puts the user requests for data into one
queue, and the shared server process fulfills all the requests, one at a time.
This configuration can reduce memory and CPU burden on the machine that
hosts Oracle, as well as limiting server process idle time, but during periods
of high database use, the user processes may have to wait for attention
from the genie with many masters.

Locating User Session Info: Shared Pool or PGA?

Let’s return to the point raised earlier about the optional component of the
shared pool, where user session information is stored in Oracle. Oracle will
store session information in the shared pool only if the DBA configures
Oracle to use shared servers to handle user data retrieval requests. This
option is known as the multithreaded server, or MTS, architecture.
Otherwise, if dedicated servers are used, user session information is housed
in the PGA.

And Finally, How Users Connect to the Server Process

Before answering this final question, let’s spend just another quick moment
covering a few other important Oracle network processes. The first is called
the listener process. The Oracle listener process does just that—it listens for
users trying to connect to the Oracle database via the network. When a user
connects to the machine hosting the Oracle database, the listener process
will do one of two things. If dedicated server processes are being used, the
listener tells Oracle to generate a new dedicated server and then assigns the
user process to that dedicated server. If MTS is being used, the listener
sends the user process to another process called the dispatcher process,
which has already been mentioned.

A request from a user is a single program-interface call that is part of the

user’s SQL statement. When a user makes a call, its dispatcher places the
request on the request queue, where it is picked up by the next available
shared server process. The request queue is in the SGA and is common to all
dispatcher processes of an instance. The shared server processes check the
common request queue for new requests, picking up new requests on a first-
in-first-out basis. One shared server process picks up one request in the
queue and makes all necessary calls to the database to complete that
request. When the server completes the request, it places the response on
the calling dispatcher’s response queue. Each dispatcher has its own
response queue in the SGA. The dispatcher then returns the completed
request to the appropriate user process. And that is the magic of how users
are connected to an Oracle server.
TIP: Here’s a quick summary of server, background, and network processes.
The server process handles user requests for data. Background processes are
Oracle processes that handle certain aspects of database operation behind
the scenes. Network processes are used for network connectivity between
user processes running on other machines to server processes running on the
machine hosting the Oracle database.

Exercises

1. What is the name of the main memory structure in Oracle, and what are
its components? What is the function of the PGA?

2. Where is user session information stored in memory on the Oracle

instance? How is its location determined?

3. How do user processes get connected to a server when dedicated servers

are used? When MTS is used? What are the performance implications of
using shared versus dedicated servers?

Stages in Processing Queries

Now that you know how Oracle connects a user process with a server
process, it’s time for you to learn how Oracle behaves when the user wants
to do something with the server, such as selecting Oracle data. You already
know most of the main players, including the server process, user process,
buffer cache, and library cache of the shared pool. You know all players,
that is, except one—the Oracle RDBMS, or relational database management
system. Recall from Unit I that SQL is a functional programming language, as
opposed to a procedural language like COBOL or C. You write your code in
terms of your desired outcome, not the process by which Oracle should get
there. The relational database management system translates the outcome
defined in your SQL statement into a process by which Oracle will obtain it.

With all components established in the world of processing Oracle queries,

let’s look now at how Oracle processes queries. There are several for
processing an Oracle select statement. The operations involved in
executing both select statements and DML statements fall into a general
pattern shown in Figure 6-2. The specific flow of operation in processing
a select statement is as follows:
1. Parse statementThe RDBMS creates a  parse tree, or execution plan,
for the statement, and places it in the library cache. This is a list of
operations the RDBMS uses to obtain data. If a parse tree already exists
for this statement, the RDBMS can omit this step.

2.  Execute statementThe RDBMS performs all processing to execute

the select statement. At this point, the server process will retrieve
data from disk into the buffer cache.

3. Fetch values from cursorOnce the  select statement has been

executed, all data returned from Oracle is stored in the cursor. That data
is then placed into bind variables, row by row, and returned to the user
process.

Figure 2: Steps in Oracle SQL statement processing

When complete, both the statement execution plan and the data in blocks
retrieved from disk stick around in the library cache and buffer cache,
respectively, for a variable length of time, just in case that user or another
one wants to execute the same select statement. In multiuser application
environments, a performance gain is achieved every time user processes
execute the same select statement because the RDBMS spends less time
parsing the statement, and the server process spends less time retrieving
data.

Exercises

1. Does SQL allow the user to define procedures or desired data for
information retrieval? Explain.

2. What are the general tasks Oracle accomplishes to

process select statements? At what point in processing does the server
process actually retrieve data into the buffer cache?

Stages in Processing DML Statements

At this point, meet yet another “behind-the-scenes” player in Oracle
transaction processing—the rollback segment. The rollback segment is a
database object in Oracle that stores old versions of data being changed by
DML statements issued by the user process. Rollback segments only store the
old values, not the new values—the new values are stored in the object
itself.

With this in mind, return to the processing of DML statements. There are
several differences between how Oracle processes select statements and
how it processes DML statements such as update, insert, and delete.
Though the operations involved in executing DML statements fall into the
same general pattern as those for selectstatements shown in Figure 6-2,
the specific flow of operation in processing DML statements is as follows:

1. Parse statementThe RDBMS creates a  parse tree, or execution plan,

for the statement and places it in the library cache. This is a list of
operations the RDBMS uses to process the data change. If a parse tree
already exists for this statement, the RDBMS can omit this step.

2.  Execute statementThe RDBMS performs all processing to execute the

DML statement. For update or delete statements, the server process
will retrieve the data from disk into the buffer cache, implicitly acquire a
lock on the data to be changed, and then make the specified data change
in the buffer cache. A lock is an Oracle internal resource that one user
process acquires before updating or deleting existing data to prevent
other users from doing the same thing. For insert statements, the
server process will retrieve a block from disk that has enough space
available to house the new row of data, and will place that new row into
the block. Also, part of executing the DML statement is writing the old
and new versions of the data to the rollback segment acquired for that
transaction. A lock must be acquired on the rollback segment to write
changes to a rollback segment as well.

3.  Generate redo informationRecall from the prior lesson that the redo
log buffer stores redo or data change information produced as the result
of DML operations running in user sessions. After issuing DML statements,
the user process must write a redo entry to the redo log buffer. In this
way, Oracle can recover a data change if damage is later done to the disk
files containing Oracle data.

TIP: Acquiring a lock is how one Oracle user says to the other users “Hey!
Hands off this data! I’m changing it now, so that means you can’t have it
until I let go of my lock!” Locks can be acquired at the row level implicitly
as part of update or delete statements, or at the table level through
explicit methods described later in the book.
Moving Data Changes from Memory to Disk

Once the DML statement has been executed, there is no further need to
fetch values, as there was for select statements. However, as
with select statements, the execution plan for the DML statement sticks
around in the library cache for a variable period of time in case another user
tries to execute the same statement. The changed blocks in the buffer
cache are now considered “dirty” because the version in the buffer cache
and on disk are no longer identical. Those dirty buffers stick around in the
buffer cache as well, but they will need to be copied to disk eventually in
order for Oracle not to lose the data change made. Also, new information
appears in the redo log buffer as the result of the data changes made by the
DML statement. By having all the data changes happening in memory, Oracle
is in a position to relieve user processes from having to wait for the data
changes to be written to disk. Oracle does this by running two other
background processes called DBWR and LGWR that write the data changes
from buffer cache and redo log buffer to disk; these processes are
asynchronous, meaning that they occur sometime after the user actually
made the change. The following subtopics explain the role of each
background process.

Role of DBWR

Called the database writer process, the DBWR background process writes
dirty data blocks from buffer cache to disk. The writes are done when the
server process needs to make room in the buffer cache to read more data in
for user processes, when DBWR is told to write data to disk by the LGWR
process, or every three seconds due to a timeout. The event that causes
LGWR to tell DBWR to write to disk is called a checkpoint. You will learn
more about checkpoints in Chapter 7. Because Oracle8 allows multiple
database writers to run on the host machine, the DBWR process is
sometimes referred to as DBW0, where 0 can be any digit between 0 and 9,
representing one of several DBWR processes running in Oracle.

Role of LGWR

Called the log writer process, the LGWR background process writes redo log
entries from the redo log buffer to online redo log files on disk. LGWR has
some other specialized functions related to the management of redo
information that you will learn about in Chapter 7. LGWR also tells DBWR to
write dirty buffers to disk at checkpoints, as mentioned earlier.
Exercises

1. How does the processing of DML statements differ from processing

queries?

2. What are rollback segments? What are locks? How are these objects
involved in DML processing?

3. How is changed data moved from memory to disk? What background

processes and memory structures are involved?

Stages in Processing COMMIT Statements

As discussed in Unit I, issuing a commit statement ends the current
transaction by making permanent any data change the user process may
have issued to the Oracle database. A rollback statement discards the
data change in favor of how the data appeared before the change was
made. The rollback segment is how Oracle manages to offer this
functionality. By keeping a copy of the old data in the rollback segment for
the duration of the transaction, Oracle is able to discard any change made
by the transaction until the commit statement is issued.

Before proceeding any further, make sure you understand the following
important point—issuing commit has no effect on when Oracle copies that
data change in the buffer cache to disk. Thus, a commit statement does not
somehow trigger DBWR activity. Only a checkpoint, a timeout, or a need for
room in the buffer cache for blocks requested by users will make DBWR
write dirty blocks to disk. With that fact in mind, what exactly does
processing a commit statement consist of? The following list tells all:

  Release table/row locks acquired by transactionAll row locks (or even

table locks, if any were acquired) are released by
issuing commit statements. Other users can then modify the rows (or
tables) previously locked by this user.

  Release rollback segment locks acquired by transactionChanges to

rollback segments are subject to the same locking mechanisms as other
objects. Once the change is committed, the space to hold both old and
new versions of data for that transaction in the rollback segment is
available for another user’s transaction.
  Generate redo for committed transactionOnce the commit takes
place, a redo entry is generated by the user process stating that all the
changes associated with that transaction have now been committed by
the user.

Note that Oracle takes no special action related to redo information as the
result of that commit, other than to indicate that the transaction has been
committed. How does Oracle know which DML statement redo entries to
associate with each transaction? The answer is the system change
numbers (SCNs). An SCN is an ID that Oracle generates for each and every
transaction that a user process engages. Every redo entry for every data
change lists the change made and the SCN the change is associated with.
The redo entry for the commit also identifies the SCN and simply notes that
this SCN has been committed. Thus, Oracle can keep easy track of the status
of every transaction via the SCN.

Exercises

1. What events occur as part of a commit statement?

2. What does a redo entry for commit statements consist of? What is an
SCN?

Using Administration Tools

In this section, you will cover the following topics related to using
administration tools:

 Using Server Manager line mode

 Identifying administration applications in Oracle Enterprise Manager

 Using Oracle Enterprise Manager components

In the past few years, there has been an explosion in the use of
administrative tools for Oracle databases. These tools are designed to
simplify many aspects of Oracle database administration, including
tablespace, instance, storage, object, and backup and recovery
management. However, OCP certification on Oracle7 did not focus on using
administrative tools. Instead, it focused on the importance of understanding
server internals, such as V$ views and issuing commands from the command
line. Though the importance of these Oracle components can hardly be
diminished, administrative tools such as Oracle Enterprise Manager matured
and expanded their functionality, and these areas have risen to take similar
levels of importance in the repertoire of every DBA. Plus, they make your
job a heck of a lot easier.

Using Server Manager Line Mode

The workhorse database administrative tool on Oracle is Server Manager.
This tool has been around in one form or another for the last few releases of
Oracle, and it rendered SQL*DBA obsolete as of Oracle 7.3. Many functions
in Oracle are accomplished easily with Server Manager, including database
startup and shutdown, database creation, and management of key aspects
of the database, such as redo log creation and control file backup.

Server Manager is usually started from the command line on the machine
hosting the Oracle database. In UNIX, the executable is called svrmgrl.
You can access the host machine command line either via Telnet or an X
terminal. You can execute Server Manager from any place in your file system
if the $ORACLE_HOME/bin directory is part of your path environment
setting. If this directory is not part of your path, you should add it. The
following code block demonstrates the execution of Server Manager in line
mode from the UNIX command line.

[ oracle80 : orgdbux01 ] > svrmgrl

Oracle Server Manager Release 3.0.5.0.0 - Production
(c)Copyright 1997, Oracle Corporation. All Rights Reserved.
Oracle8 Enterprise Edition Release 8.0.5 - Production
With the Partitioning and Objects options
PL/SQL Release 8.0.5 - Production
SVRMGR> connect internal
Connected.
SVRMGR>

Running Server Manager line mode in Windows environments is slightly

different, since most people don’t work directly from the DOS prompt as
they do with the UNIX command prompt. Again, however, you must
somehow access the DOS prompt on the machine hosting Oracle. One
method for starting Server Manager line mode in Windows can be
accomplished by choosing Start | Programs | DOS Prompt, and issuing the
following commands from within DOS, as shown in the following code block:
D:\>cd orant/bin
D:\>svrmgr30
Oracle Server Manager Release 3.0.5 - Production
(c) Copyright 1997, Oracle Corporation. All Rights Reserved.
Oracle8 Enterprise Edition Release 8.0.5.0.0 - Production
With the Partitioning and Objects options
PL/SQL Release 8.0.5 - Production
SVRMGR>

Unfortunately, the Oracle installation on Windows does not add Server

Manager to the list of menu options available under the Start | Programs |
Oracle Enterprise Manager menu. Another way to execute Server Manager in
Windows is to double-click My Computer on your desktop, double-click the
drive containing the Oracle software home directory, double-click
the bin subdirectory, and double-click the executable called svrmgr30.
Figure 6-3 shows Server Manager in action. Shortly, you will explore the use
of Server Manager for startup and shutdown of the Oracle database, in the
“Managing an Oracle Instance” section.

Figure 3: Server Manager line mode

Exercises

1. What is Server Manager? Where is its executable found? What

functionality does it offer?

2. How is Server Manager accessed in UNIX environments? In Windows

environments?

Identifying Admin Apps in Oracle Enterprise Manager

Fortunately, your administrative capabilities for Oracle don’t end at Server
Manager line mode. Oracle Enterprise Manager (OEM) is a suite of
applications that allow you to manage your Oracle database in a graphical
user interface. Anything you can do from Server Manager, you can do from
Oracle Enterprise Manager—provided you have set up a password file for
remote database administration. More about how to do this appears in the
next section. If you do not have a password file set up for administering your
Oracle database remotely, then you cannot start up and shut down the
Oracle database using OEM, but you can do most anything else.
There is no such thing as easy database administration, but using the
administrative tools available in Oracle Enterprise Manager can simplify
many areas of managing your database. Oracle Enterprise Manager is usually
run from your desktop. Assuming you use Windows, you can identify the
tools at your disposal as part of OEM either by looking under Start |
Programs | Oracle Enterprise Manager, or under the Tools | Applications
menu within the Enterprise Manager application itself. Figure 6-4 illustrates
Enterprise Manager and both the Tools | Applications menu and the
Applications button bar, both of which can be used to access any of the
administrative applications available in OEM. The following list identifies the
applications available for Oracle Enterprise Manager, along with a brief
description of their use:

  Backup ManagerHandles automation of backup operations

  Data ManagerManages import, export, and loading of data into tables

of an Oracle database

  Instance ManagerHandles management of an Oracle instance,

including session, in-doubt transaction, and initialization parameter
information

  Replication ManagerManages configuration, scheduling, and

administrative functions of replication between nodes on a network
running Oracle databases

  Schema ManagerManages table, index, cluster, and other object

creation and management in an Oracle database

  Security ManagerHandles user access privileges and role

administration

  SQL WorksheetUsed to execute SQL statements from scripts in a

graphical interface more advanced than SQL*Plus

  Storage ManagerHandles configuration and management of logical and

physical disk resources for the Oracle database

  Software ManagerUsed as part of an enterprise-wide management of

Oracle software application design, distribution, and asset management
 Repository ManagerUsed to create, validate, and drop OEM
repositories 

Figure 4: Oracle Enterprise Manager administrative applications

TIP: In addition to the administrator tools listed above, other applications

are available for different cartridges you may have installed on your Oracle
database, such as ConText Cartridge System Administrator. Administrative
tools accompany add-ins like the Diagnostic Pack as well, including Lock
Manager, Performance Manager, and others.

Exercises

1. Identify the functionality provided by the Storage, Instance, and Schema

Manager administrative tools that are part of OEM.

2. What are some other administrative tools that OEM might use, and
where/how might the DBA get them?

Using Oracle Enterprise Manager Components

To show you everything that each of the manager tools are capable of would
take quite a bit of space in this book—as it is, you will cover some serious
territory! Instead, we will look at how one of the manager tools works in
OEM, and from there we will extrapolate some general rules that all the
manager tools abide by. Because so much of your effort in this chapter will
focus on managing the Oracle instance and opening and closing the Oracle
database, the tool we will focus on here is Instance Manager.

The basic purpose of Instance Manager is—you guessed it—managing the

Oracle instance. You can start and stop the instance with this tool (provided
you’ve set up your password file—more information on how to do it in a
moment), view and modify initsid.ora parameters, view current
sessions, in-doubt transactions, and apply database configuration
information you have available on your desktop. Figure 6-5 displays the
Instance Manager login prompt. To open this tool, either click on the Tools |
Applications | Instance Manager menu item from OEM, or click on Start |
Programs | Oracle Enterprise Manager | Instance Manager from the Windows
console. After providing appropriate username, password, and TNS connect
information, notice the fourth text box, where the tool prompts you to
choose how you want to connect. The options are Normal, sysdba,
and sysoper. The first option allows you to connect as the username you
provided, but gives you no administrative abilities on the database. Thus,
you can view database initialization parameters, but cannot start up or shut
down the database. Use of the other two options is for administrative
authentication, and both will be explained in the next section.

Figure 5: Instance Manager tool in OEM

TIP: Instance Manager will not prompt you for login information if you run it
from OEM. It will instead use the login info you provided when you started
OEM.

After login, you will see the Instance Manager interface. The left-hand
window is the navigator window. On it, there are several nodes you can drill
down into to find information. You drill into each node by clicking on the
plus sign (+) to the left of the node. The names of each node are self-
explanatory. For example, if you drill into the Sessions node as shown in
Figure 6-6, you will see all the sessions currently happening in Oracle listed
below the node. On the right side is the work interface. If you click on the
name of the node or the file folder icon to the left of that name, the
relevant information will be displayed in the work window. As another
example, if you click on the name of one of the connected sessions in the
navigator window, you will see some additional information about that
session appearing in the work window.

Figure 6: Instance Manager interface

Along the top of the interface is a set of several menus. From left to right,
they are File, View, Database, Sessions, Transactions, Configuration, and
Help. The options under the File menu allow you to change database
connection, enable roles, or exit the application. The options under the
View menu allow you to modify the tools available in Instance Manager and
expand or collapse nodes in the left window. The Database menu permits
startup and shutdown operations, archiving, and other things. The Sessions
menu permits management of sessions, including the ability to disconnect a
session, restrict access to the database to only those users
with restricted session privileges, or allow all users to access the
database. The Transactions menu allows the DBA to
force commit and rollback operations to happen in the database. The
Configuration menu allows you to change or remove database configurations
from the database to the desktop. Finally, the Help menu gives you access
to online help.

Extrapolating General Usage

After using Instance Manager, as well as some of the other manager tools,
you should be able to see some general patters of use. All the manager tools
have both a navigator window with several nodes allowing you to access
various things, and a work window where you will actually execute the tasks
that the manager tool allows you to do. For each, you can login with
Normal, sysdba, or sysoper privileges. Though the actual menus and
options for each manager tool are different, they all basically mirror the
functionality you have through the navigator and work windows. Finally,
each of these tools can be run alone or as part of OEM.

Exercises

1. Describe the functionality and general use of the Instance Manager tool.
What three connect options do you have when logging into Oracle via the
tool?

2. What general use guidelines can you extract from using Instance Manager
that apply to using all of the manager tools?

Managing an Oracle Instance

In this section, you will cover the following topics related to starting and
stopping the instance:

 Setting up OS and password file authentication

 Creating your parameter file

 Starting an instance and opening the database

 Closing a database and shutting down the instance

 Getting and setting parameter values

 Managing sessions
 Monitoring ALERT and trace files

After installing the Oracle software, the DBA should master the management
of an Oracle instance. There are several important things that should be
done to manage the Oracle instance before even thinking about setting up
the Oracle database. Important questions about authentication must be
answered, and the parameter file must be developed and managed. This
parameter file is generically referred to as initsid.ora by many DBAs.
Starting up and shutting down the instance, and opening and closing the
database are key areas both before and after the database is created.
Finally, the management of sessions and places to look for information
about the Oracle instance in action are covered in this section.

Setting Up OS and Password File Authentication

How you plan to support the Oracle database you create determines to a
large extent how you will set up Oracle to handle administrative
authentication. Authentication requires the DBA to provide a password in
order to gain entry for administrative tasks onto the machine hosting
Oracle, the database itself, or both. There are two methods of providing
administrative authentication, and they are operating system and password
file authentication. If the DBA will administer the database directly from the
machine hosting the Oracle database by means of Telnet and Server
Manager line mode, operating system authentication should suffice. But, if
the DBA plans to manage the site from software running on a desktop
computer, such as OEM, then the DBA should set up a password file. Another
nice feature about a password file is that it allows many DBAs to manage
databases, each with varying levels of control. For example, the
organization might want the junior DBA to handle backups and user
creation, but not startup and shutdown of the instance. Password files work
well to support organizations wanting a team of DBAs to have a range of
capabilities on the machine.

More Introductions: SYS, SYSTEM, and the Data Dictionary

Another round of introductions is in order. SYS and SYSTEM are two users
Oracle creates when you install your database. Each has their own default
password. The default password for SYS is CHANGE_ON_INSTALL, and for
SYSTEM it is MANAGER. Be careful to protect the passwords for both these
users by changing them after installing Oracle. These two privileged users
have the power to administer most any feature of the Oracle database. SYS
is more important than SYSTEM because SYS will wind up owning all Oracle
system tables from which the data dictionary is derived.

The Oracle data dictionary is the system resource you will turn to in order to
find out just about anything about your database, from which users own
what objects, to the initialization parameter settings, to performance
monitoring, and more. There are two basic categories for Oracle database
views: those that show information about database objects and those that
show dynamic performance. The views showing information about objects
are the data dictionary views. The views showing information about
performance are dynamic performance views.

Using OS Authentication

Operating system authentication offers the comfort of a familiar face to old-

school UNIX folks, in the same way as using the VI text editor and Kornshell.
Because of this, the discussion of OS authentication will focus primarily on
its implementation in UNIX. However, OS authentication has few real
advantages and many disadvantages compared to the password file method
of authentication. The main benefit OS authentication offers is easy login to
Oracle via the slash (/) character, as shown here:

UNIX® SYSTEM V TTYP01 (23.45.67.98)

Login: bobcat
Password:
User connected. Today is 12/17/99 14:15:34
[companyx] /home/bobcat/> sqlplus /
SQL*PLUS Version 8.0.5.0.0
(c) 1979,1998 Oracle Corporation(c) All rights reserved.
Connected to Oracle8 Enterprise Edition 8.0.5 - Production
PL/SQL Version 8.0.5 - Production
SQL>

The disadvantages to OS authentication are many. For one thing, no one

who doesn’t have a machine login can use Oracle. When might this pose a
problem? For example, you may not want to make the host machine’s
command prompt accessible to your 10,000+ user base for a production
system. For development and test environments, however, OS
authentication may be fine.
To use OS authentication, a special group must be created on the operating
system before you even install your Oracle software, called dba. Later,
when Oracle is installed and configured, you can log into the OS via Telnet
as a user belonging to the dba group (such as the Oracle software owner)
run Server Manager in line mode, and perform startup and shutdown
operations after issuing the connect internal command. This command
has been around for several versions of Oracle and continues to be provided
for backward compatibility. The DBA can connect to the database by using
the connect name as sysdba command and then providing the
appropriate password, as well. The sysdba keyword denotes a collection of
privileges that are akin to those privileges granted to internal. The
following block illustrates simple usage:

SVRMGR> connect internal

Connected.

Or,

SVRMGR> connect sys as sysdba

Password:
Connected.

Oracle creates some other OS roles as part of its UNIX installation that must
be granted to the DBA, such as osoper and osdba. These OS roles are given
to the Oracle software owner, and must be granted to other OS users who
would be DBAs via operating system commands. These roles cannot be
revoked or granted from within Oracle. However, there are two equivalent
Oracle privileges used when you authenticate with a password file—
sysoper and sysdba, respectively.

There are some small differences between the osoper and sysoper,
and osdba and sysdba, which you may use to your advantage for breaking
out DBA roles and responsibilities. The osoper role and sysoper privilege
allow you to start and stop the instance, mount or open the database, back
up the database, initiate archiving redo logs, initiate database recovery, and
change database access to restricted session mode.
The sysoper and sysdba roles offer the same privileges
as osoperand sysoper, and add the ability to execute and administer all
Oracle system privileges, the create database privilege, and all privileges
required for time-based incomplete database recovery.
Obviously, osoper or sysoper is given to the DBA ultimately responsible
for the operation of the database.

TIP: The implementation of operating system authentication in Oracle

depends heavily on the operating system you use. Since operating system–
specific issues are not part of OCP Exam 2, they will not be covered here. If
you need more information on operating system authentication, consult the
appropriate operating system–specific Oracle administrative manual.

Authentication with the Password File

Oracle’s other method of authenticating DBAs is the password file. The DBA
creates the password file, and passwords for all others permitted to
administer Oracle are stored in the file. The password file is created with
the ORAPWD utility. The name of this executable varies by operating
system. For example, it is orapwd on UNIX, but orapwd80 on Windows.

When executing ORAPWD, you will pass three

parameters: FILE, PASSWORD, and ENTRIES. To determine what to specify
for FILE, you usually place the password file in $ORACLE_HOME/dbs, and
name it orapwsid.pwd, substituting the name of your database for sid.
For PASSWORD, be aware that as you define the password for your password
file, you are also simultaneously assigning the password for logging into
Oracle as internal and SYS. Later, if the DBA connects as internal or
SYS and issues the alter user name identified
by password command, the passwords for internal, SYS, and the
password file are all changed. The final parameter is ENTRIES, specifying
the number of user entries allowed for the password file. Be careful,
because you can’t add more later without deleting and re-creating the
password file, which is risky. The actual execution of ORAPWD in Windows
may look something like this, from the command line:

D:\orant\bin\>orapwd80 FILE=D:\orant\dbs\orapworgdb01.pwd
PASSWORD=jason ENTRIES=5

In UNIX, it may look something like this:

/home/oracle80> orapwd \
FILE=app/oracle/product/8.0.5/dbs/orapwdorgdb01.pwd \
PASSWORD=jason ENTRIES=5
After creating the password file, you must do a few other things to allow
administrative access to the database while simultaneously preventing use
of internal. First, set the value for
the REMOTE_LOGIN_PASSWORDFILE parameter in
the initsid.ora parameter file. This parameter accepts none, shared,
and exclusive as its values. The none setting means the database won’t
allow privileged sessions over unsecured connections. When OS
authentication is used, the REMOTE_LOGIN_PASSWORDFILE is set
to none to disallow remote database administration.
Setting REMOTE_LOGIN_PASSWORDFILE to shared means that only SYS
and internal can log into Oracle to perform administrative functions
remotely. Finally,
setting REMOTE_LOGIN_PASSWORDFILE to exclusive means that a
password file exists and any user/password combination in the password file
can log in to Oracle remotely and administer that instance. If this setting is
used, the DBA should use the create user command in Oracle to create
the users that are added to the password file, and
grant sysoper and/or sysdba system privileges to those users. After that,
users can log into the database as themselves with all administrator
privileges.

After creating the password file with the ORAPWD utility and setting
the REMOTE_LOGIN_PASSWORDFILE parameter to exclusive in order to
administer a database remotely, the DBA can then connect to the database
as a user with sysdba privileges as shown here:

SVRMGR> CONNECT sys AS SYSDBA;

Password:
Connected.

TIP: Remember two important points about password files. First, to find out
which users are in the database password file, use the V$PWFILE_USERS
dynamic performance view. (More on the data dictionary will be presented
in Chapter 7.) Second, any object created by anyone logging in
as sysdba or sysoper will be owned by SYS.

Exercises

1. What two methods of user authentication are available in Oracle? Explain

some advantages and disadvantages for each.
2. What is the name of the utility used to create a password file? Describe
its use, parameters, and the related parameter that must be set
in initsid.ora in order to use a password file for authentication.

3. What are the two Oracle roles granted to DBAs in order to perform
database administration?

4. Who is SYS, and how is it used? Who is SYSTEM?

Creating Your Parameter File

How well or poorly your database performs is determined to a great extent
by how you configure your Oracle instance. You configure your instance
dynamically when you start it, using a parameter file. This parameter file is
commonly referred to by DBAs as the initsid.ora file. The real name of
the parameter file for your database is arbitrary and completely up to you;
however, when you install Oracle and create your first database, Oracle will
generate a parameter file for you named after the database. Thus, if your
database is named ORGDB01, your default name for the initsid.ora file
will be initORGDB01.ora.

You can create your parameter file from scratch, but why bother when
Oracle creates one for you? The parameter file Oracle creates for you will
contain several different options for the most essential initialization
parameters you need to include when creating a new database. However,
Oracle has literally hundreds of initialization parameters, documented and
undocumented. The following code block shows a sample parameter file in
use on a small Oracle database running under Windows. The pound sign (#)
is used to denote comments in the parameter file.

db_name = ORGDB01
db_files = 1020
control_files = (D:\orant\DATABASE\ctl1orgdb01.ora,
D:\orant\DATABASE\ctl2orgdb01.ora)
db_file_multiblock_read_count = 16
db_block_buffers = 1000
shared_pool_size = 1048576
log_checkpoint_interval = 8000
processes = 100
dml_locks = 200
log_buffer = 32768
sequence_cache_entries = 30
sequence_cache_hash_buckets = 23
#audit_trail = true
#timed_statistics = true
background_dump_dest = D:\orant\RDBMS80\trace
user_dump_dest = D:\orant\RDBMS80\trace
core_dump_dest = D:\orant\RDBMS80\trace
db_block_size =2048
sort_area_size = 65536
log_checkpoint_timeout = 0
remote_login_passwordfile = shared
max_dump_file_size = 10240
rollback_segments = (RB0_ORGDB01, RB1_ORGDB02)
global_names=false
open_cursors=400

In general, when working with parameter files, it is best not to start from
scratch. Use the Oracle default, or borrow one from another DBA. But be
sure that you alter the parameters in the file to reflect your own database,
including DB_NAME, DB_BLOCK_SIZE, CONTROL_FILES, and others. You
should remember where you store your parameter file on the machine
hosting the Oracle database. Do not leave multiple copies in different
directories. This could lead you to make a change to one but not the other.
Then if you start your instance with the old parameter file later, you could
have problems. However, it can be useful to have a few different copies of a
parameter file for various administrative purposes, such as one for
production environments, and one for running the database is restricted
mode for DBA maintenance operations.

Exercises

1. What is the typical name for the parameter file in Oracle? By what name
do most DBAs refer to their parameter file?

2. Is it wise to create parameter files from scratch? Why or why not?

Starting an Instance and Opening the Database

There is an important distinction between an Oracle instance and an Oracle
database. The Oracle database is a set of tables, indexes, procedures, and
other objects used for storing data. More precisely, an Oracle
database, identified by the database name (DB_NAME), represents the
physical structures and is composed of operating system files. Although it is
possible to use a database name that is different from the name of the
instance, you should use the same name for ease of administration. The
Oracle instance is the memory structures, background processes, and disk
resources, all working together to fulfill user data requests and changes.

With that distinction made, let’s consider starting the Oracle instance. You
must do this before creating a new database, or before allowing access to
an existing database. To start the instance, follow these steps:

1. From the command line on the host machine, start Server Manager and
log in either as sysdba or internal:

[ oracle80 : orgdbux01 ] > svrmgrl

Oracle Server Manager Release 3.0.5.0.0 - Production
(c)Copyright 1998, Oracle Corporation. All Rights Reserved.
Oracle8 Enterprise Edition Release 8.0.5 - Production
With the Partitioning and Objects options
PL/SQL Release 8.0.5 - Production
SVRMGR> connect internal
Connected.
SVRMGR>

2. From within Server Manager, use

the startup start_option dbname pfile=init.ora command to
start the instance. Several options exist for start_option,
including nomount, mount, open, and open force.
The PFILE parameter should be used to identify the
exact initsid.ora file you want to use. An example
of startup nomount is shown in the following code block:

SVRMGR> startup nomount pfile=initORGDB01.ora

ORACLE instance started.
Total System Global Area 227174560 bytes
Fixed Size 42764 bytes
Variable Size 93999104 bytes
Database Buffers 81920000 bytes
Redo Buffers 51208192 bytes
SVRMGR>
Options for Starting Oracle

You can also start a database with OEM Instance Manager. All the options
discussed for Server Manager are available via Instance Manager, except
through a graphical user interface. You may also want to note that starting
Oracle databases in Windows is not necessarily handled with Server Manager
or even OEM, but instead may be handled as a service. A service in Windows
is similar to a daemon in UNIX. Both of these operating system functions
allow Oracle to start automatically when the machine boots. (We’re getting
a little off the topic here, but if you’re interested in more information,
consult the Oracle8 Installation Guide for Windows NT, which comes with
that distribution of Oracle.) There are several different options for starting
Oracle instances, with or without opening the database.

STARTUP NOMOUNT

This option starts the instance without mounting the database. That means
all the memory structures and background processes are in place, but no
database is attached to the instance. You will use this option later, for
creating the Oracle database. You can specify this option with or without
specifying an initsid.ora file for the PFILEparameter. If you do not
specify PFILE, Oracle uses its own built-in default settings for initialization
parameters specific to each operating system.

STARTUP MOUNT

This option starts the instance and attaches the database, but does not open
it. You can’t mount a database you haven’t created yet. This option is
useful in situations where you have to move physical database files around
on the machine hosting Oracle, or when database recovery is required. You
should specify an initsid.ora file for the PFILE parameter when using
this option; otherwise, Oracle will not use values you may have specified in
your initsid.ora file. If the instance is already started but the database
is not mounted, use alter database mount instead.

STARTUP OPEN

This option starts your instance, attaches the database, and opens it. This is
the default option for starting Oracle. It is used when you want to make
your database available to users. You can’t open a database you haven’t
created yet. The file you specify for the PFILE parameter must be
an initsid.ora file. If the instance is started and the database is
mounted, use alter database open instead.

STARTUP FORCE

This option forces the instance to start and the database to open. It is used
in situations where other startup options are met with errors from Oracle,
and no shutdownoptions seem to work either. This is an option of last
resort, and there is no reason to use it generally unless you cannot start the
database with any other option.

TIP: Two other cases for database startup include startup recover for
handling database recovery, and startup restrict to open the database
while simultaneously preventing all users but the DBA from accessing
database objects. You’ll learn about using startup restrict when we
talk about the EXPORT utility in Chapters 10 and 15, and about database
recovery in Unit III.

Exercises

1. What tools can be used for starting Oracle instances and databases? What
connection must be used for the task?

2. What are some options for database startup?

Closing a Database and Shutting Down the Instance

Shutdown of the Oracle instance works in much the same way as starting the
instance. You must either be logged onto Oracle as internal or as a user
with sysdbaprivileges. The task can be accomplished from Server Manager
or OEM Instance Manager, or as a Windows service. The steps for shutting
down an Oracle database from Server Manager are as follows:

1. From the command line on the host machine, start Server Manager, and
log in either as sysdba or internal:

[ oracle80 : orgdbux01 ] > svrmgrl

Oracle Server Manager Release 3.0.5.0.0 - Production
(c)Copyright 1998, Oracle Corporation. All Rights Reserved.
Oracle8 Enterprise Edition Release 8.0.5 - Production
With the Partitioning and Objects options
PL/SQL Release 8.0.5 - Production
SVRMGR> connect internal
Connected.
SVRMGR>

2. From within Server Manager, use

the shutdown start_option command to start the instance. Several
options exist for start_option, including immediate,normal,
or abort. An example of shutdown immediate is shown in the
following code block:

SVRMGR> shutdown immediate

ORA-01507: database not mounted
ORACLE instance shut down.
SVRMGR>

Options for Stopping Oracle

There are four priorities that can be specified by the DBA for shutting down
the database. They
include shutdown normal, shutdown immediate, shutdown abort,
and shutdown transactional. The next four subtopics will explain each
of these options and give cases where their use might be appropriate.

SHUTDOWN NORMAL

This is the lowest priority shutdown. When shutdown normal is issued,

Oracle will wait for users to log out before actually shutting down the
instance and closing the database. There are three rules Oracle follows
during shutdown normal. First, Oracle will not let new users access the
database. Second, Oracle will not force users already logged on to the
system to log off in order to complete the shutdown. Third, under normal
shutdown situations, there is no need for instance recovery.

SHUTDOWN IMMEDIATE

This is a higher-priority shutdown that the DBA can use

when shutdown normal would take too long.
The shutdown immediate command shuts down a database as follows. No
new users will be able to connect to the database once
the shutdown command is issued. Oracle will not wait for a user to log off
as it does for shutdownnormal, instead terminating user connections
immediately and rolling back uncommitted transactions. Immediate
database shutdown, though more drastic than shutdownnormal, does not
require any instance recovery.

SHUTDOWN ABORT

This is the highest priority database shutdown command. In all cases where
this priority is used, the database will shut down immediately. All users are
immediately disconnected, no transactions are rolled back, and media
recovery will be required when the database starts up again. You will use
this option only when media or disk failure has taken place on the machine
hosting Oracle.

SHUTDOWN TRANSACTIONAL

A transactional shutdown prevents clients from losing work. A transactional

database shutdown proceeds with the following conditions: no client can
start a new transaction on this particular instance, a client is disconnected
when the client ends the transaction that is in progress, and a shutdown
immediate occurs when all transactions have finished. The next startup
will not require an instance recovery.

Exercises

1. What connection must be used for the task of database shutdown?

2. What are the four options for database shutdown?

Getting and Setting Parameter Values

Once your instance is started, several different ways exist for obtaining the
values set for the instance on initialization. The first and least effective way
to view parameter values in your database is to look at
the initsid.ora file. This choice does not give you all parameters, and
what’s more, the parameters in your parameter file may have changed since
the last time you started Oracle. A much better way to obtain parameter
values is to select them from a special view in Oracle called
V$PARAMETER. Still another effective way for obtaining parameter values in
Oracle is to use Server Manager. The show parameter command will list all
parameters for the instance. Finally, you can use the OEM Instance Manager
to display instance parameters, as shown in Figure 6-7. Can you guess where
Instance Manager and Server Manager draw their initialization parameter
information from? If you said V$PARAMETER, you were right!

Figure 7: Instance parameters in Instance Manager

Setting parameters is done in one of two ways. By far, the most effective
way to set a database parameter is to add the name of the parameter and
the value to the initsid.ora file for your instance. After that, shut down
and start up your instance using the initsid.ora file. Unfortunately, in
the world of multiuser database environments, DBAs do not always have the
luxury of bouncing the database whenever they want. You can always try to
schedule this sort of thing, or if the need is not critical, wait until the
weekend. Another method for setting parameters is with
the alter system command. However, this is not an effective method for
changing parameters, because not all initialization parameters can be
changed using this command. The ones that can be changed
include RESOURCE_LIMIT, GLOBAL_NAMES,AUDIT_TRAIL, TIMED_STATI
STICS, some of the MTS parameters, and some of the licensing parameters.

Exercises

1. Identify some ways you can obtain instance parameters. Which of these
ways is least effective? Which are most effective?

2. What methods are available for changing instance parameters before the
instance is started? What about after the instance is started?

Managing Sessions
Each user process that connects to Oracle maintains a session with the
Oracle database. The user has the ability to do whatever they have been
granted privileges to do within their session. User sessions are managed with
the alter session statement. Several things can be changed about a user
session, including national language settings
like NLS_LANGUAGE, NLS_DATE_FORMAT, and so on, in the form alter
session set NLS_DATE_FORMAT = 'date_format'. In addition, if the
user wants to enable tracing on the session to determine performance
statistics for the SQL they execute, the alter session set
SQL_TRACE = TRUE command can be used.
In order to connect to the database, the user must be granted
the create session privilege. Note that this privilege only allows the user
to connect to Oracle—that user must be granted further privileges to
actually see anything once connected! Although privileges will be covered in
more detail in Chapter 10, this privilege is mentioned because it is useful in
managing sessions to know how to continue and discontinue a user’s ability
to create sessions with Oracle.

There are a few basic ways the DBA can manage sessions. One is to
disconnect a session, another is to restrict access to an open database to
only those users with a special privilege called restricted session. You
have already seen how to open the database from Server Manager in
restricted mode with the startup restrict command. (You also already
know that there is more information about startup restrict in Chapter
10.) You can restrict database access with
the alter system enablerestricted session command after the
database is open. To disconnect a session, you must issue
the alter system kill session 'sid, serial#' command. The
values for sid and serial# come from the V$SESSION data dictionary view
columns of the same name.

TIP: The V$SESSION dictionary view contains information about every session
currently connected to Oracle. It forms the basis of information displayed in
the Instance Manager tool.

Exercises

1. What command is used to manage a user session? What tasks can actually
be accomplished with that command?

2. What privileges must be granted in order for a user to connect to Oracle?

3. How do you restrict access to an open Oracle database to only those

users with the restricted session privilege? What two pieces of
information are required to disconnect a session from Oracle with
the alter system kill session command?

Monitoring ALERT and Trace Files

The background processes of the Oracle database each maintain a log file of
their execution if an error occurs in the background process during the life
of the instance. This log file is called a trace file. If something goes wrong,
the background process will write error information to the trace file,
enabling you to figure out what happened. The types of things that get
written to trace files include abnormal errors and process termination
messages. A special trace file called the ALERT log is maintained by the
Oracle instance. This file gets written in several situations. Oracle writes to
the ALERT log whenever the database is started or shut down, whenever the
control file is modified (for example, by creating a new tablespace),
whenever a severe error occurs or an Oracle internal error occurs, and when
Oracle starts writing to a new redo log file.

There are other times in Oracle execution when the ALERT log is written to,
as well. The ALERT log can grow quite large, so it makes sense to clear it
out once in a while and allow Oracle to start generating a new one,
particularly if nothing eventful has happened on your database in a long
time. Sometimes, when the ALERT log is written, the message must be
addressed. As such, it is important for you as the DBA to check the ALERT
log regularly for things like internal errors or other anomalies in database
behavior. If you have some kind of problem with your Oracle software and
need to open a trouble ticket with Oracle Support, you may be requested to
supply them with a copy of your ALERT log, as well.

The location of your ALERT log and background trace files depends on the
directory specified for the BACKGROUND_DUMP_DEST parameter for your
instance. Both the background process trace files and the ALERT log will be
found in this directory. If you are unsure of the location of your ALERT log,
simply use the methods defined for getting parameter values, and look up
the value for BACKGROUND_DUMP_DEST.

TIP: If you start getting really weird errors in your database, and your ALERT
log contains ORA-00600 errors, you should call Oracle Support ASAP!

Exercises

1. What is the ALERT log? What is a trace file? What is the difference
between the two?

2. Where are ALERT logs and trace files stored in Oracle?

Creating an Oracle Database

In this section, you will cover the following topics related to creating an
Oracle database:

 Preparing the operating system

 Preparing the parameter file

 Creating the database

Once the DBA has set up some necessary preliminary items for running the
Oracle instance, such as password authentication, the DBA can then create
the database that users will soon utilize for data management. Creating a
database involves three activities that will be discussed in this section. The
first activity for creating a database is mapping a logical entity-relationship
diagram that details a model for a process to the data model upon which the
creation of database objects like indexes and tables will be based. Second
the DBA will create physical data storage resources in the Oracle
architecture, such as datafiles and redo log files. The final (and perhaps the
most important) aspect of creating a database is creating the structures that
comprise the Oracle data dictionary. Each element in the database creation
process will be discussed in detail.

Preparing the Operating System

There are a few things you should do at the OS level before creating your
database. Since every operating system is different, you’ll be introduced to
the general concepts here for the purpose of preparing for OCP. If you have
further questions, refer to the operating system–specific Oracle installation
guide that came with your software distribution. Some of these steps are
things you should be aware of at the time you install the Oracle software on
your host machine, while others can wait until the time you are ready to
issue create database statement. In general, the things you must do to
prepare the operating system include: making sure your machine has the
capacity to handle Oracle, ensuring you have at least three separately
controlled disk resources, ensuring asynchronous I/O is possible for your
operating system, configuring certain environment settings, shutting down
and backing up any other Oracle databases running on the host, and making
sure any appropriate operating system patches recommended by Oracle are
installed on the machine. More details about each of these items follows:
  Make sure your machine has the capacity to handle OracleAlmost
any machine made these days has the capacity to install Oracle
successfully. However, not every machine has the guts to run a full-scale
Oracle enterprise database application. Before creating an Oracle
environment, be sure to assess whether your host machine has the CPU
power, memory, and disk space it takes to run an Oracle database in a
multiuser environment.

  Ensure you have at least three separately controlled disk resourcesA

running Oracle database has many moving parts. Often, these parts are
also moving at the same time. Putting every Oracle resource on the same
hard drive is a recipe for slow performance on all but the smallest single-
user database setups. Oracle recommends three separately controlled
disk resources. An enterprise production installation of Oracle can
require 20 or more. Again, think before you create.

  Configure certain environment settingsYou may need to configure a

few environment variables before creating your database, such as
ORACLE_BASE, ORACLE_HOME, ORACLE_SID, ORACLE_LD_LIBRARY_PATH,
and others. These are items that you will set up in your machine
configuration files or user configuration files. Where possible, you should
try to follow the optimal flexible architecture (OFA). This is Oracle’s
recommended guideline for file-system directory paths, and following it
will help Oracle Support find files for you when you call in the inevitable
emergency production-support issue.

  Shut down and back up other Oracle databases running on the

hostUnless you like long hours spent in a computer room handling
recovery, don’t care about your data, or both, you should never install an
Oracle database on a machine already hosting Oracle without shutting
down and backing up that other database first. The reuse keyword in
the create database command, as well as
the CONTROL_FILES parameter in your initsid.ora file, make it
possible for one Oracle database to overwrite the files of another
database on the same machine. Avoid problems by taking the extra time
to back up your data, and put different Oracle database files in different
directories.

  Install Oracle-recommended operating system patches on the

machineThis final point is as much an Oracle software installation issue
as it is a database creation issue. Since the exact OS version and required
 patches vary from operating system to operating system, you should
consult the Oracle installation guide that came with your software for
specifics, while being mindful for OCP that OS patches may need to be
applied for Oracle to work properly.

Exercise

What are some items you may need to tend to at the OS level before
creating your database?

Preparing the Parameter File

You’ve already learned about the parameter file, so now focus on the values
that must be set in order to create a new Oracle database. As mentioned,
Oracle provides a generic copy of that parameter file, initsid.ora, in the
software distribution used to install Oracle server on the machine hosting
Oracle. Generally, the DBA will take this generic parameter file and alter
certain parameters according to his or her needs. Several
parameters must be changed as part of setting up a new database. The
following subtopics identify and describe the parameters you need to
change.

DB_NAME

The local name of the database on the machine hosting Oracle, and one
component of a database’s unique name within the network. If the value for
this parameter is the same as another Oracle database running on the host,
permanent damage may result in the event that a database is created. Try
to limit this name to approximately eight characters. Do not leave the name
as DEFAULT. There is a name for the database and a name for the instance,
and they should be the same. DB_NAME is required for the creation of the
database, and it should be unique among all Oracle databases running in
your organization.

DB_DOMAIN

Identifies the domain location of the database name within a network. It is

the second component of a database’s unique name within the network.
This is usually set either to WORLD or to the domain name appearing in your
e-mail address at your organization, such as EXAMPILOT.COM.
DB_BLOCK_SIZE

The size in bytes of data blocks within the system. Data blocks are unit
components of datafiles into which Oracle places the row data from indexes
and tables. This parameter cannot be changed for the life of the database.

CONTROL_FILES

A name or list of names for the control files of the database. The control
files document the location of all disk files used by the Oracle. If the
name(s) specified for this parameter do not match filenames that exist
currently, then Oracle will create a new control file for the database at
startup only when you create a new database. Otherwise, Oracle simply tells
you it won’t start because it can’t find the control files it needs to open
your existing database. Only during creation of a new database will Oracle
overwrite the contents of a file of the same name as the control file you
specified in initsid.ora with the physical layout of the database being
created. Beware of this feature, as it can cause a control file on an existing
database to be overwritten if you are creating a second database to run on
the same machine.

DB_BLOCK_BUFFERS

The maximum number of data blocks that will be stored in the database
buffer cache of the Oracle SGA. The size of the buffer cache in bytes is a
derived value of DB_BLOCK_SIZE multiplied by DB_BLOCK_BUFFERS.

LOG_BUFFER

The size of the redo log buffer in bytes. As stated earlier, the redo log
buffer stores redo log entries in memory until LGWR can write the entries to
online redo logs on disk. There will be more about this in Chapter 7.

ROLLBACK_SEGMENTS

A list of named rollback segments that the Oracle instance will have to
acquire at database startup. If there are particular segments the DBA wants
Oracle to acquire, these can be named here.

PROCESSES
The number of processes that can connect to Oracle at any given time. This
value includes background processes (of which there are at least five) and
server processes. This value should be set high in order to avoid errors that
prevent users from connecting.

LICENSE_MAX_SESSIONS

Used for license management. This number determines the number of

sessions that users can establish with the Oracle database at any given time.

LICENSE_MAX_WARNING

Used for license management. Set to less than LICENSE_MAX_SESSIONS,

Oracle will issue warnings to users as they connect if the number of users
connecting has exceeded LICENCE_MAX_WARNING.

LICENSE_MAX_USERS

Used for license management. As an alternative to licensing by concurrent

sessions, the DBA can limit the number of usernames created on the
database by setting a numeric value for this parameter.

Exercises

1. Identify some parameters that should be unique in

the initsid.ora file for your new database.

2. What happens if you have two databases on one machine, you borrow
the parameter file from one database to create the other, and then
forget to change the value set for CONTROL_FILES?

Creating a Database in Oracle

Creation of the Oracle database is accomplished with
the create database statement. Oracle recommends a series of steps for
creating new databases. They are as follows:

1. Back up the existing databases on the machine hosting the new database
you want to create.

2. Create or edit the initsid.ora parameter file for your new instance.
3. Verify the instance name in any database creation script you have, as
well as in the initsid.ora file.

4. Start Server Manager.

5. Start the instance, but do not mount any database.

6. Issue the create database statement manually, or run a script

containing the create database statement.

7. Shut down your instance.

8. Back up your new database.

9. Open your new database again to make the database available to the
users.

Following the creation of the appropriate initialization parameter file, the

DBA will need to start the instance from Server Manager connected
as sysdba or internal. The task of connecting to the database
as sysdba has already been discussed. To start the instance, use
the startup nomount command in order to run the instance without
mounting a previously existing database. After starting the instance without
mounting a database, the DBA can create the database with
the create database command. In order to create a database, the user
must have the sysdba privilege granted to them and enabled. The following
code block contains a sample script for creating a new database in UNIX:

CONNECT INTERNAL;

CREATE DATABASE orgdb01

CONTROLFILE REUSE
LOGFILE
GROUP 1 ('/oracle/disk_01/redo1a.log',
'/oracle/disk_02/redo1b.log') SIZE 5M,
GROUP 2 ('/oracle/disk_03/redo2a.log',
'/oracle/disk_04/redo2b.log') SIZE 5M
MAXLOGFILES 40
DATAFILE '/oracle/disk_05/sys01.dbf' SIZE 30M,
'/oracle/disk_05/sys02.dbf' SIZE 50M
AUTOEXTEND ON NEXT 30M MAXSIZE 150M
MAXDATAFILES 240
CHARACTERSET US7ASCII;

EXIT;

The Datafiles of the SYSTEM Tablespace

The files created as part of the datafile clause of

the create database command are SYSTEM tablespace datafiles.
A tablespace is a logical collection of disk files collectively used to store
data. The SYSTEM tablespace can be compared to the root directory of a
machine’s file system. The SYSTEM tablespace houses the tables comprising
the basis for the Oracle data dictionary, as well as the system rollback
segments. The tables of the data dictionary and system rollback segment
will all be owned by user SYS. Oracle creates one system rollback segment in
the SYSTEM tablespace at database creation for Oracle to acquire at
database startup. Without this system rollback segment, the database won’t
start. In the interests of preserving the integrity of the Oracle database, the
DBA should ensure that only the data dictionary and system rollback
segments are placed in the SYSTEM tablespace. No data objects owned by
any user other than SYS should be placed in the SYSTEM tablespace. Instead,
you will create other tablespaces to store those database objects. You will
learn more about tablespaces and datafiles in Chapter 7.

Minimum Two Online Redo Log Groups

Redo logs are created with the logfile clause. Redo logs are entries for
data changes made to the database. You must create at least two redo log
groups for your new database, each with at least one member. In the
database created with the preceding code block, redo log group 1 consists
of two members, called log1a.dbf and log1b.dbf, respectively. If any
file specified in the create database statement currently exists on the
system, and the reuse keyword is used, Oracle will overwrite the file. Be
careful when reusing files to prevent accidentally overwriting the files in
your existing database on the host machine. You will learn more about redo
logs in Chapter 7, also.

Other Items in CREATE DATABASE Statements

Other options set when the database is created

include maxdatafiles and maxlogfiles. The maxdatafiles option
specifies the initial sizing of the data files section of the control file
at create database or create controlfile time. An attempt to add a
file whose number is greater than maxdatafiles, but less than or equal
to DB_FILES, causes control file to expand automatically so that the data
files section can accommodate more files. This clause can limit database
size later, when new datafiles are added, if the maxdatafiles value would
be exceeded. To work around this problem, use the autoextend option
when defining datafiles. When autoextend is used, the datafiles will
automatically allocate more space when the datafile fills, up to a total size
specified by the maxsize keyword. However, you’ll want to take care to
ensure that Oracle does not try to extend the datafile to more space than
the file system has available.

The final item in the create database statement was characterset,

which is used to identify the character set used in the Oracle database for
information storage. More information about character sets appears in
Chapter 10.

Another option you can use in create database commands

is archivelog. When archivelog is used, Oracle archives the redo logs
generated. More about archiving redo information will be presented in Unit
III. Finally, the create database command uses several initialization
parameters set in the initsid.ora file in database creation. These
include DB_BLOCK_SIZE, and certain NLS environment settings.

Exercises

1. Name some of the steps in creating a new Oracle database. What

resources are created as part of the creation of a database?

2. What is the SYSTEM tablespace? What is its significance?

3. What is a parameter file? What are some of the parameters a DBA must
set uniquely for any database via the parameter file?

Chapter Summary
This chapter introduced you to Oracle database administration. It covered
several topics, including an overview of the Oracle architecture, using
administrative tools such as Server Manager and OEM, managing the Oracle
instance, starting and stopping the instance, and creating an Oracle
database. The material in this chapter comprises about 16 percent of the
questions asked on OCP Exam 2.

The first area of discussion in this chapter was an overview of the various
components of the Oracle database. Figure 6-1 gave an idea of the
background processes, memory structures, and disk resources that comprise
the Oracle instance, and how they act together to allow users to access
information. Several memory structures exist on the Oracle database to
improve performance on various areas of the database. They include the
System Global Area (SGA) and the Program Global Area (PGA). The SGA, in
turn, consists of several components: the buffer cache, the shared pool, and
the redo log buffer. Behind the scenes, there are several memory processes
that move data between disk and memory or handle activities on Oracle’s
behalf. The core background processes covered in this chapter were the
database writer (DBWR or DBW0) for writing blocks to disk, the log writer
(LGWR) for writing redo entries to disk, and the server for reading data from
disk into the buffer cache for users.

You were introduced to the Oracle Relational Database Management System

(RDBMS), and learned how select and DML statements are processed. The
RDBMS translates SQL code, which defines results, into a step-by-step
procedure for Oracle to use in obtaining that data. You also learned about
how users are connected to server processes, the differences and tradeoffs
involved in the dedicated server and the MTS architecture, and how listener
processes and dispatchers are used to route user processes to servers.
Finally, you learned how commit statements are processed and that
a commit being issued does not automatically make Oracle run right out and
copy changed data back to disk.

The next section covered using administrative tools. The Server Manager
application was demonstrated in its line mode operation for various
environments. You also learned about the administrative tools that are part
of Oracle Enterprise Manager, or OEM for short. The tools described were
the Instance Manager, Data Manager, Schema Manager, Backup Manager,
Software Manager, Storage Manager, as well as many others. A
demonstration of using some of these tools was presented, as well, so that
you could better grasp how Oracle allows you to perform the same functions
in a graphical user interface that it allows you to execute using line mode
commands in Server Manager.
The next area covered was managing the Oracle instance. Setting up
operating system authentication for management of Oracle from the
command line of the machine that hosts the database was demonstrated.
The use of password file administrative authentication and the value of
setting this up was also demonstrated. If you want to use OEM for things like
starting up and shutting down your database from the client desktop, you
must set up a password file. This is handled with the ORAPWD utility. An
explanation of the various ways to connect to Oracle administratively, such
as connect internal, connect as sysdba, and the differences
between sysdba and osdbaand sysoper and osoper were all covered, as
well.

Creating a parameter file, also known as the initsid.ora file, was also
covered. Oracle provides a generic parameter file with every software
release, so it is easiest to reuse an initialization parameter file rather than
creating one from scratch yourself. The various parameters that can be set
were explained in some detail, along with how to find out what the current
parameter values are using the V$PARAMETER dynamic performance view,
the show parameter command in Server Manager, and from within the OEM
Instance Manager. The requirement for changing parameter values by
modifying the initsid.ora file and stopping and restarting the instance in
most cases, as well as the special cases for changing parameter values with
the alter system command, were shown in this discussion, too.

Starting up the instance and opening the database is described in this

chapter. The use of Server Manager and the need for connecting
as internal or sysdba was explained. The use of the startup command
and its several different options for opening the database, such
as nomount, mount, open, restrict, recover, and force, were all
explained, too, along with their appropriate usage. Situations in which you
shouldn’t use each option for opening the database were also covered in
some detail.

The shutdown of an instance and closing of the database was explained, as

well. The DBA must again connect to the database
as internal or sysdba using the Server Manager tool. The three options
for closing the Oracle database are normal, immediate, transactional,
and abort. When the DBA shuts down the database with
the normal option, the database refuses new connections to the database
by users and waits for existing connections to terminate. Once the last user
has logged off the system, then the shutdown normal will complete. The
DBA issuing a shutdown immediate causes Oracle to prevent new
connections while also terminating current ones, rolling back whatever
transactions were taking place in the sessions just terminated. The third
option for shutting down a database is shutdown abort, which disconnects
current sessions without rolling back their transactions and prevents new
connections to the database as well. The last option is shutdown
transactional, which disconnects current sessions after they complete
their current transaction, but otherwise acts like shutdown immediate.

You learned about the management of sessions with

the alter session command, and the create session privilege
required for connecting to Oracle was also presented. Oracle’s maintenance
of special trace files for logging each background process’s execution was
also described. The location of these files is identified in
the initsid.ora file by the BACKGROUND_DUMP_DEST parameter. The
special trace file for the instance called the ALERT log was described in
some detail, along with the events that cause the ALERT log to be written
and the need for regular monitoring and cleanup of this file.

The final area covered in this chapter was creating a database. The steps
required for preparing the OS were described, such as making sure the
hardware capacity, such as CPU, memory, and disk space, were up to the
task of managing the Oracle database you want to run. The required
changes to be made to the parameter file were also described. The
importance of
changing DB_NAME, DB_DOMAIN, DB_BLOCK_SIZE, DB_BLOCK_BUFFERS, P
ROCESSES, ROLLBACK_SEGMENTS, LICENSE_MAX_SESSIONS,LICENSE_M
AX_WARNING, and the LICENSE_MAX_USERS parameters to reflect the
uniqueness of this database from others on the host machine or on the
network in your organization was addressed.

Finally, the steps of database creation were also discussed. First, the DBA
should back up existing databases associated with the instance, if any, in
order to prevent data loss or accidental deletion of a disk file resource. The
next thing that should happen is that the DBA should create a parameter file
that is unique to the database being created. Several initialization
parameters were identified as needing to be set to create a database. After
the parameter file is created, the DBA can execute
the createdatabase command, which creates disk files for a special
resource called the SYSTEM tablespace, and other disk files for online redo
logs. Oracle also uses the settings in the initsid.ora file to make
appropriate changes to control files, database block size, and other things.
The SYSTEM tablespace will contain at least one system rollback segment,
which must be allocated in order for Oracle to start, and all the tables and
views that comprise the Oracle data dictionary. After creating the database,
the DBA should back up the new database to avoid needing to create it from
scratch in the event of a problem later.

Two-Minute Drill
 Several structures are used to connect users to an Oracle server. They
include memory structures like the System Global Area (SGA) and
Program Global Area (PGA), network processes like listeners and
dispatchers, shared or dedicated server processes, and background
processes like DBW0 and LGWR.

 The SGA consists of the buffer cache for storing recently accessed data
blocks, the redo log buffer for storing redo entries until they can be
written to disk, and the shared pool for storing parsed information about
recently executed SQL for code sharing.

 The fundamental unit of storage in Oracle is the data block.

 SQL select statements are processed in the following way: a cursor or

address in memory is opened, the statement is parsed, bind variables are
created, the statement is executed, and values are fetched.

 SQL DML statements such as update, delete, and insert are

processed in the following way: a cursor or address in memory is opened,
the statement is parsed, and the statement is executed.

 Several background processes manage Oracle’s ability to write data from

the buffer cache and redo log buffer to appropriate areas on disk. They
are DBW0 for writing data between disk and buffer cache, and LGWR for
writing redo log entries between the redo log buffer and the online redo
log on disk.

 DBW0 writes data to disk in three cases. They are every 3 seconds (when
a timeout occurs), when LGWR tells it to (during a checkpoint), and when
 the buffer cache is full and a server process needs to make room for
buffers required by user processes.

 Server processes are like genies from the story of Aladdin because they
retrieve data from disk into the buffer cache according to the user’s
command.

 There are two configurations for server processes: shared servers and
dedicated servers. In dedicated servers, a listener process listens for
users connecting to Oracle. When a listener hears a user, the listener
tells Oracle to spawn a dedicated server. Each user process has its own
server process available for retrieving data from disk.

 In shared server configurations (also called multithreaded server or MTS),

a user process attempts to connect to Oracle. The listener hears the
connection and passes the user process to a dispatcher process. A limited
number of server processes, each handling multiple user requests, are
monitored by a dispatcher, which assigns user processes to a shared
server based on which has the lightest load at the time of user
connection.

 The commit statement may trigger Oracle to write changed data in the
buffer cache to disk, but not necessarily. It only makes a redo log buffer
entry that says all data changes associated with a particular transaction
are now committed.

 Two user authentication methods exist in Oracle: operating system

authentication and Oracle authentication.

 There are two privileges DBAs require to perform their function on the
database. In Oracle authentication environments, they are
called sysdba and sysoper.

 To use Oracle authentication, the DBA must create a password file using
the ORAPWD utility.

 To start and stop a database, the DBA must connect

as internal or sysdba.

 The tool used to start and stop the database is called Server Manager.
This tool is usually run in line mode.
 Another tool for managing database administration activity is Oracle
Enterprise Manager (OEM). OEM has many administrative tools available,
including Backup Manager, Data Manager, Daemon Manager, Instance
Manager, Replication Manager, Schema Manager, Security Manager, SQL
Worksheet, Storage Manager, Net8 Assistant, Software Manager.

 There are several options for starting a database:

 startup nomountStarts the instance and does not mount a

database. 

 startup mountStarts the instance and mounts but does not open the
database. 

 startup openStarts the instance and mounts and opens the

database. 

 startup restrictStarts the instance, mounts and opens the

database, but restricts access to those users
with  restricted session privilege granted to them.

 startup recoverStarts the instance, leaves the database closed, and

begins recovery for disk failure scenario. 

 startup open forceMakes an instance start that is having

problems either starting or stopping. 

 When a database is open, any user with a username and password and
the create session privilege can log into the Oracle database.

 Closing or shutting down a database must be done by the DBA while

running Server Manager and while the DBA is connected to the database
as internal or sysdba.

 There are three options for closing a database:

 shutdown normalNo new existing connections are allowed, but

existing sessions may take as long as they want to wrap up. 

 shutdown immediateNo new connections are allowed, existing

sessions are terminated, and their transactions are rolled back. 
  shutdown abortNo new connections are allowed, existing sessions
are terminated, and transactions are not rolled back. 

 Instance recovery is required after shutdown abort is used.

 You can obtain values for initialization parameters from several sources:

 V$PARAMETER dynamic performance view

 show parameter command in Server Manager

 OEM Instance Manager administrative tool.

 Several important runtime logging files exist on the machine hosting

Oracle. Each background process, such as LGWR and DBWR, will have a
trace file if some error occurs in their execution, and the instance has a
special trace file called the ALERT log. Trace files are written whenever
the background process has a problem executing. The ALERT log is
written whenever the instance is started or stopped, whenever the
database structure is altered, or whenever an error occurs in database.

 Trace files and ALERT logs are found in the directory identified by
the BACKGROUND_DUMP_DEST parameter in the initsid.ora file.

 Before creating the database, assess whether several things on the OS

level:

 Are there enough individual disk resources to run Oracle without I/O
bottlenecks?

 Is there enough CPU, memory, and disk space for Oracle processing?

 Are disk resources for different Oracle databases on the same host in
separate directories?

 Are environment settings correct for the database creation?

 The first step in creating a database is back up any existing databases

already on the host machine.
 The second step in creating a database is for the DBA to create a
parameter file with unique values for several parameters, including the
following:

 DB_NAMEThe local name for the database 

 DB_DOMAINThe network-wide location for the database 

 DB_BLOCK_SIZEThe size of each block in the database 

 DB_BLOCK_BUFFERSThe number of blocks stored in the buffer

cache 

 PROCESSESThe maximum number of processes available on the

database 

 ROLLBACK_SEGMENTSNamed rollback segments the database acquires

at startup 

 LICENSE_MAX_SESSIONSThe maximum number of sessions that can

connect to the database 

 LICENSE_MAX_WARNINGThe sessions trying to connect above the

number specified by this parameter will receive a warning message 

 LICENSE_MAX_USERSThe maximum number of users that can be

created in the Oracle instance 

 LICENSE_MAX_SESSIONS and LICENSE_MAX_WARNING are used for

license tracking or LICENSE_MAX_USERS is used, but not both, usually.

 After creating the parameter file, the DBA executes

the create database command, which creates the datafiles for the
SYSTEM tablespace, an initial rollback segment, SYS and SYSTEM users,
and redo log files. On conclusion of the create database statement,
the database is created and open.

 The default password for SYS is CHANGE_ON_INSTALL.

 The default password for SYSTEM is MANAGER.

 The number of datafiles and redo log files created for the life of the
database can be limited with
the maxdatafiles and maxlogfiles options of
the createdatabase statement.

 The size of a datafile is fixed at its creation, unless

the autoextend option is used.

 The size of a control file is directly related to the number of datafiles

and redo logs for the database.

Chapter Questions
1. The user is trying to execute a select statement. Which of the
following background processes will obtain data from disk for the
user?

A. DBW0

B. LGWR

C. SERVER

D. USER

E. DISPATCHER

2. In order to perform administrative tasks on the database using

Oracle password authentication, the DBA should have the following
two privileges granted to them:

A. sysdba or sysoper

B. CONNECT or RESOURCE

C. restricted session or create session

3. Which component of the SGA stores parsed SQL statements used

for process sharing?

A. Buffer cache
 B. Private SQL area

C. Redo log buffer

D. Library cache

E. Row cache

4. Which of the following choices does not identify an aspect of

shared server processing architecture?

A. Each user gets their own server process for data retrieval

B. A dispatcher process is involved

C. A listener process is involved

D. The server process sits idle infrequently

5. The initsid.ora parameter that indicates the size of each buffer

in the buffer cache is the

A. DB_BLOCK_BUFFERS

B. BUFFER_SIZE

C. DB_BLOCK_SIZE

D. ROLLBACK_SEGMENTS

6. The datafiles named in a create database statement are used as

storage for which of the following database components?

A. SYSTEM tablespace

B. initsid.ora file

C. Redo log member

D. ALERT log

7. Changing the password used to manage the password file changes

the password for which of the following?
 A. SYSTEM

B. RPT_BATCH

C. CONNECT

D. internal

E. audit

8. The default password for the SYS user is

A. CHANGE_ON_INSTALL

B. NO_PASSWORD

C. MANAGER

D. ORACLE

E. NULL

9. DBAs who are planning to administer a database remotely should

use all of the following choices, except:

A. ORAPWD

B. REMOTE_LOGIN_PASSWORDFILE set to shared

C. OS_AUTHENT_PREFIX set to OPS$

D. A password file

10. Power will disconnect on the machine running Oracle in two

minutes, but user JASON has left for the day while still connected
to Oracle. His workstation is locked, so he cannot be logged out
from his desktop. How should the DBA shut down the instance?

A. shutdown normal

B. shutdown immediate

C. shutdown abort
 D. shutdown force

E. shutdown recover

11. Which of the following administrative tools in OEM can be used to

view the initialization parameter settings for Oracle?

A. Schema Manager

B. Instance Manager

C. Security Manager

D. Data Manager

E. Software Manager

12. Which two of the following items are required for killing a user
session?

A. Username

B. SID

C. Serial number

D. Password

Answers to Chapter Questions

1. SERVER C.

ExplanationThe server process handles data access and retrieval from disk
for all user processes connected to Oracle. Choice A, DBW0, moves data
blocks between disk and the buffer cache, and therefore is not correct.
Choice B, LGWR, copies redo entries from the redo log buffer to online redo
logs on disk, and therefore is not correct. Choice D, USER, is the process for
which the server process acts in support of. Choice E, DISPATCHER, i s used
in Oracle MTS architecture and routes user processes to a server, but does
not handle reading data from disk on behalf of the user process.

2.  A.sysdba or sysoper
ExplanationChoices B and C are incorrect. Each privilege listed has some
bearing on access, but none of them give any administrative ability. Refer to
the discussion of choosing an authentication method. 

3. Library cache D.

ExplanationChoice A is incorrect because the buffer cache is where data

blocks are stored for recently executed queries. Choice B is incorrect
because the private SQL area is in the PGA where the actual values returned
from a query are stored, not the parse information for the query. Choice C
is incorrect because the redo log buffer stores redo entries temporarily until
LGWR can write them to disk. Choice E is incorrect because the row cache
stores data dictionary row information for fast access by users and Oracle.
Refer to the discussion of Oracle architecture. 

4. Each user gets their own server process for data retrieval A.

ExplanationThe shared server or MTS architecture uses several elements

that correspond to the choices. A dispatcher process assigns users to a
shared server, while the listener process routes user processes either
directly to a server in the case of dedicated server processing or to a
dispatcher in MTS. The final choice, D, indicates a benefit of the MTS
architecture. Since many users utilize the same server process, that server
process will sit idle less frequently than in the dedicated server
architecture. Choice A indicates the dedicated server architecture only, and
is therefore the correct answer to the question. 

5.  C.DB_BLOCK_SIZE

ExplanationSince each buffer in the buffer cache is designed to fit one data
block, the size of buffers in the database block buffer cache will be the
same size as the blocks they store. The size of blocks in the database is
determined by  DB_BLOCK_BUFFERS. Refer to the discussion of
initialization parameters to be changed during database creation.

6. SYSTEM tablespace A.

ExplanationSince datafiles can only be a part of tablespaces (more on this

in Chapter 7), all other choices must be eliminated immediately. Another
reason to eliminate at least choices B and D is that neither
the  initsid.ora file nor the ALERT log are created in
the create database statement. So, as long as you know that redo logs
are composed of online redo log members, and tablespaces like SYSTEM are
composed of datafiles, you should have no problem getting a question like
this one right.

7.  D.internal

ExplanationChoice A is incorrect because the SYSTEM password has no

affiliation with the password for the password file. SYS and  internal do.
Choice B is incorrect because RPT_BATCH is not a password created by
Oracle in a create database statement. Choice C is incorrect because
CONNECT is a role, not a user. Choice E is incorrect because audit is a
command, not a user. Refer to the discussion of creating the password file
as part of choosing user authentication.

8. CHANGE_ON_INSTALL A.

ExplanationThis is a classic piece of Oracle trivia. Memorize it, along with

the SYSTEM password, which incidentally is MANAGER. This is all fine for
OCP, but beware of others who may also have memorized these facts. Don’t
let a hacker use this information against you. Make sure you change the
default passwords for SYS and SYSTEM after creating your database. 

9. OS_AUTHENT_PREFIX set to OPS$ C.

ExplanationA DBA should use password file authentication when planning to

administer a database remotely. This action consists of a password file, the
ORAPWD utility, and setting
the  REMOTE_LOGIN_PASSWORDFILE parameter to shared.
The OS_AUTHENT_PREFIX parameter is used to alter the prefix Oracle
requires on Oracle users when operating system authentication is being
used. This one, obviously, is not required for Oracle password
authentication.

10.  B.shutdown immediate

ExplanationA power outage can cause da mage to an Oracle instance if it

is running when the power goes out. But choice C is just too drastic, given
that you are basically treating the situation as if it required media recovery.
After all, you know that JASON is not executing a transaction, so no
additional time to finish the rollback will be required before shutdown.
Choice A will not do it either, though, because shutdown normal will wait
all night for JASON to come in and log off. Choice B is the logical choice.
Choices D and E are not valid options for shutting down a database instance.

11. Instance Manager B.

ExplanationThe Instance Manager tool handles all instance-related tasks,

including display and modification of initialization parameters set in
the  initsid.ora file. Schema Manager handles tasks involving database
object creation and modification, eliminating choice A. Security Manager
handles user privilege and role management, which eliminates choice C.
Data Manager handles the loading and unloading of data from EXPORT binary
or flat file format, eliminating choice D. Finally, Software Manager handles
enterprise deployment of Oracle software, eliminating choice E.

12. SID B. and C. and serial number.

ExplanationTo disconnect a database user with

the  alter system kill session statement, you must have the SID and serial number.
Both these pieces of information for the session you want to kill can be found in the
V$SESSION dictionary view. You only need username and password information to establish the
connection, not eliminate it, which in turn eliminates choices A and D.