Tài liệu OCA: Oracle Database 11g Administrator Certified Associate- P14 pptx

Using DBCA to Create Oracle 11g Databases

481
When the creation process is complete, connect to the database with one of the tools
such as SQL*Plus or Enterprise Manager to ensure that all the database options and
components were installed properly. Logging into Enterprise Manager will give you an
overview of the new database. By using the URL specified in Figure 9.31, you can invoke
the Database Control home page. Log in using the
SYSMAN
account with the password you
supplied in Figure 9.7. Figure 9.33 shows the home screen of Enterprise Manager Database
Control.
FIGURE 9.33 Enterprise Manager Database Control home page
Configuring an Oracle Database Using the DBCA
The DBCA lets you change various aspects of an existing database. To change the database
configuration, select Configure Database Options on the DBCA Operations screen (shown
earlier in this chapter in Figure 9.2). If the database is not started, the DBCA starts it for
you automatically. You must connect to the database as a user who has DBA authority.
95127c09.indd 481 2/18/09 6:43:54 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
482

Chapter 9
N
Creating an Oracle 11g Database
Once you have selected and started the database, you can add options that may not
have been previously included in the database. Using DBCA you can perform the following
changes to database configuration:
Add database components (refer to Figure 9.13).
ÛN
Change database security settings from pre-11

ÛN
g default security setting to 11g
enhanced security settings, or vice versa (refer Figure 9.24).
Change the default connection mode for the database. You can change from dedicated
ÛN
server mode to shared server mode, or vice versa (refer Figure 9.22).
Deleting an Oracle Database Using the DBCA
You can also delete a database using the DBCA. On the Operations screen (Figure 9.2),
choose Delete a Database, and click Next to open the Database screen. The DBCA lists all
the databases available for deletion. Choose the database you want to delete.
If you click Finish, the DBCA removes all files on the disk associated with the database
you have chosen. If you are using Windows, the DBCA also removes the service associated
with the database.
Exercise 9.1 shows you how to delete a database manually using SQL*Plus.
EXERCISE 9.1
Delete or Remove an Oracle Database Manually
Some DBAs prefer to use a command-line interface to perform their tasks. You can delete
a database using the command-line tool SQL*Plus.
To do so, first connect to SQL*Plus as an administrator who has the ability to start up the
database; that is, an administrator with either the
SYSOPER
or
SYSDBA
privilege.
Here’s an example:
/u01/app/oracle>sqlplus sys/**** as sysdba
Once you are connected, you need to put the database in
MOUNT
mode. Issue the following
command if the database is not running:

Startup mount;
Next, issue the following command:
Drop database;
This command deletes all the files associated with the database. If you are using raw disk
devices, the special files created for these devices are not deleted. Also, you may have to
remove any archived logs from the database archive area using the appropriate operating-
system command.
95127c09.indd 482 2/18/09 6:43:54 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Using DBCA to Create Oracle 11g Databases

483
Managing Database Templates Using the DBCA
As I explained earlier in this chapter, the DBCA can store and use XML-based templates to
create your Oracle Database. As the DBA, you can manage these database-definition tem-
plates. Saving a definition of your database in a template format makes it easier to perform
various tasks. For example, you can copy a preexisting template to modify new database
definitions. The template definition is normally stored in the
$ORACLE_HOME/assistants/
dbca/templates
directory on Unix and in the
%ORACLE_HOME%\assistants\dbca\templates

directory on Windows systems.
The DBCA can use two types of templates: seed and nonseed. Seed templates are tem-
plate definitions that contain database-definition information and the actual data files and
redo log files. The advantage of a seed template is that the DBCA makes a copy of the data
files and redo logs included in the definition file. These prebuilt data files include all schema
information, which makes for a faster database-creation process. The seed templates carry
a

.dbc
extension. The associated predefined data files are stored as files having a
.dfb
exten-
sion. When you use a seed template, you can change the database name, the data-file locations,
the number of control files and redo log groups, and the initialization parameters.
Nonseed templates contain custom-defined database definitions. Unlike seed templates,
they do not come with preconfigured data files and redo logs. Nonseed templates carry a
.dbt
extension.
Now I’ll cover the various options you have to manage templates.
Creating Template Definitions Using the DBCA
You can use the DBCA interface to create new database templates. When you connect to
the DBCA, select Manage Templates on the Operations screen (see Figure 9.2, shown ear-
lier in this chapter), and click Next to open the Template Management screen, as shown in
Figure 9.34.
FIGURE 9.34 The DBCA Template Management screen
95127c09.indd 483 2/18/09 6:43:54 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
484

Chapter 9
N
Creating an Oracle 11g Database
You have three choices for creating templates. Table 9.4 summarizes your options.
TABLE 9.4 Template-Creation Options
Selection Description
From an Existing Template Creates a new template definition from a preexisting tem-
plate. This allows you to modify a variety of template settings,
including parameters and data file storage characteristics.

From an Existing Database
(Structure Only)
Creates a new template based on the structural characteris-
tics of an existing database. The data files are created from
scratch and will not include data from the original database.
Choose this option when you want a database that is struc-
turally like another database but does not contain any data.
The database you are copying from can reside anywhere in
your network.
From an Existing Database
(Structure As Well As Data)
Creates a new template based on the structural character-
istics of an existing database. The data files and all corre-
sponding user data are included in the new database. Choose
this option when you want an exact copy of an existing data-
base. The database you are copying must reside on the same
physical server as the new database you are creating.
Depending on the option selected, you are presented with a set of forms to save your
template definition. If you elect to create a template from an existing database, you will have
to connect to the database so that the DBCA can obtain information about the database.
You must connect to the database as a user who has DBA credentials to perform this task.
If you are copying a definition from an existing template, you can configure the template
by following a series of screens that are similar to those used to create a database. These
screens allow you to configure the various aspects of the template, including initialization
parameters and data file and redo log locations.
Deleting Template Definitions Using the DBCA
You can also delete an existing template definition. On the Operations screen (see Figure 9.2,
shown earlier in this chapter), click Manage Templates. You will be presented with the
Template Management screen (see Figure 9.34). Select the option Delete a Database Tem-
plate. You can then choose the template to delete. When you remove the template, the

DBCA removes the XML file from the system.
95127c09.indd 484 2/18/09 6:43:54 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Working with Oracle 11g Metadata

485
Working with Oracle 11g Metadata
In addition to tables such as
DEPARTMENTS
and
EMPLOYEES
that store important business
data, Oracle Databases also contain system tables that store data about the database.
Examples of the type of information in these system tables include the names of all the
tables in the database, the column names and datatypes of those tables, the number of rows
those tables contain, and security information about which users are allowed to access
those tables. This “data about the database” is referred to as metadata. As a DBA, you will
frequently use this metadata when performing your administration tasks.
An Oracle 11g database contains two types of metadata views:
Data dictionary views
ÛN
Dynamic performance views
ÛN
The
SYS
user owns the data dictionary and dynamic performance views in the Oracle
11g database, and they are stored in the
SYSTEM
tablespace. During normal database opera-
tion, Oracle uses the data dictionary frequently and updates the dictionary with the current

status of the database components. The dictionary is also immediately updated when a
DDL statement is executed.
Data dictionary views and dynamic performance views are described in the next section.
Data Dictionary Views
Data dictionary views provide information about the database and its objects. Depending
on which features are installed and configured, an Oracle 11g database can contain more
than 1,600 data dictionary views. Data dictionary views have names that begin with
DBA_
,
ALL_
, and
USER_
. Oracle creates public synonyms on many data dictionary views so users
can access the views conveniently.
The difference between the
DBA_
,
ALL_
, and
USER_
views can be illustrated using the
DBA_TABLES
data dictionary view as an example. The
DBA_TABLES
view shows information
on all the tables in the database. The corresponding
ALL_TABLES
view, despite its name,
shows only the tables that a particular database user owns or can access. For example,
if you were logged into the database as a user named

SCOTT
, the
ALL_TABLES
view would
show all the tables owned by the user
SCOTT
and the tables to which
SCOTT
has been granted
access by other users. The
USER_TABLES
view shows only those objects owned by a user. If
the user
SCOTT
were to examine the
USER_TABLES
view, only those tables he owns would
be displayed. Figure 9.35 shows a graphical representation of the relationship between the
DBA_
,
ALL_
, and
USER_
views.
Because the
DBA_
views provide the broadest metadata information, they are generally
the data dictionary views used by DBAs. Table 9.5 provides examples of
DBA_
data diction-

ary views.
95127c09.indd 485 2/18/09 6:43:55 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
486

Chapter 9
N
Creating an Oracle 11g Database
FIGURE 9.35 A comparison of data dictionary views
USER_TABLES
All tables owned by a
particular database user.
DBA_TABLES
All tables in the entire database.
Reserved for user accounts that
have DBA privileges.
ALL_TABLES
All tables owned by a
particular database user plus
all tables to which the user
has been granted access.
TABLE 9.5 Examples of Data Dictionary Views
Dictionary View Description
DBA_TABLES
Shows the names and physical storage information about all the
tables in the database
DBA_USERS
Shows information about all the users in the database
DBA_VIEWS
Shows information about all the views in the database

DBA_TAB_COLUMNS
Shows all the names and datatypes of the table columns in the
database
DATABASE_PROPERTIES
Displays database properties such as NLS parameters, default
temporary and permanent tablespace names, database time
zone, so on
GLOBAL_NAME
Shows the global database name
95127c09.indd 486 2/18/09 6:43:55 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Working with Oracle 11g Metadata

487
You can find a complete list of the Oracle 11g data dictionary views in
Part II of the “Oracle Database Reference 11g Release 1 (11.1) Part Number
B28320-01” document available at

.
Dynamic Performance Views
Throughout database operation, Oracle updates a set of virtual tables to record the cur-
rent database activity and status. These tables are called dynamic performance tables.
Views are created on top of the dynamic performance tables for better grouping of infor-
mation and to have names in a user-friendly format. The dynamic performance views are
sometimes called fixed views, because they cannot be altered or removed by the database
administrator.
The dynamic performance tables begin with
X$
. The dynamic performance view names
begin with

V_$
. Public synonyms are created on these views, and they begin with
V$
.
For example, the dynamic performance view with data file information is
v_$datafile
,
whereas the public synonym is
v$datafile
.
Depending on which features are installed and configured, an Oracle 11g database can
contain approximately 480 dynamic performance views. Most of these views have names
that begin with
V$
. Table 9.6 describes a few of these dynamic performance views.
TABLE 9.6 Examples of Dynamic Performance Views
Dynamic
Performance View
Description
V$DATABASE
Contains information about the database, such as the database name
and when the database was created
V$VERSION
Shows which software version the database is using
V$OPTION
Displays which optional components are installed in the database
V$SQL
Displays information about the SQL statements that database users
have been issuing
You can find a complete list of the Oracle 11g data dictionary views in Part

III of the “Oracle Database Reference 11g Release 1 (11.1) Part Number
B28320-01” document available at

.
95127c09.indd 487 2/18/09 6:43:55 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
488

Chapter 9
N
Creating an Oracle 11g Database
Although the contents of the
DBA_
and
V$
metadata views are similar, there are some
important differences between the two types. Table 9.7 compares these two types.
TABLE 9.7 Data Dictionary vs. Dynamic Performance Views
Data Dictionary Views Dynamic Performance Views
The
DBA_
views usually have plural names
(for example,
DBA_DATA_FILES
).
The names of the
V$
views are generally sin-
gular (for example,
V$DATAFILE

).
The
DBA_
views are available only when the
database is open and running.
Some
V$
views are available even when the
database is not fully open and running.
The data contained in the
DBA_
views is
static and is not cleared when the database
is shut down.
The
V$
views contain dynamic statistical
data that is lost each time the database is
shut down.
The data dictionary view
DICTIONARY
shows information about the data
dictionary and dynamic performance views in the database.
DICT
is a syn-
onym for the
DICTIONARY
view. The
COMMENTS
column shows the purpose

or contents of the view. The
V$FIXED_TABLE
view lists the dynamic perfor-
mance tables and views in the database.
The Oracle data dictionary and dynamic performance views are created while creating
the database. The scripts to create the metadata are stored in the
$ORACLE_HOME/rdbms/
admin
directory. Several scripts are in this directory, and the script that creates the base dic-
tionary objects is called
catalog.sql
. The
catproc.sql
script creates the PL/SQL packages
and functionality to support PL/SQL in the database.
You are not allowed to log in as
SYS
and modify the data dictionary views
or update information directly using SQL. The only
SYS
-owned table you
are allowed to delete records from is
AUD$
. This table is used to keep data-
base audit information.
Managing Initialization-Parameter Files
Oracle uses initialization-parameter files to store information about initialization parame-
ters used when an Oracle instance starts. Oracle reads the parameter file to obtain informa-
tion about how the Oracle instance should be sized and configured upon startup.
95127c09.indd 488 2/18/09 6:43:55 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Managing Initialization-Parameter Files

489
The parameter file can be a plain text file, commonly referred to as a pfile, or it can be
a binary parameter file, commonly referred to as an spfile. You can use either type of file
to configure instance and database options; however, there are some important differences
between the two types of configuration files, as shown in Table 9.8.
TABLE 9.8 Pfiles vs. Spfiles
Pfile Spfile
Text file that can be edited using a text editor. Binary file that cannot be edited directly.
When changes are made to the pfile, the
instance must be shut down and restarted
before it takes effect.
Parameter changes made to the database
using
ALTER​SYSTEM
are updated in the spfile.
Is called
initinstance_ name.ora
. Is called
spfileinstance_ name.ora
.
Oracle instance reads only from pfile. Oracle instance reads and writes to the spfile.
Can be created from an spfile using the
create​pfile​from​spfile
command.
Can be created from a pfile using the
create​spfile​from​pfile
command.

You can specify more than 285 documented configuration parameters in the pfile or
spfile. Oracle 11g divides these parameters into two categories: basic and advanced. Oracle
recommends you set only the basic initialization parameters manually. Oracle also recom-
mends you do not modify the remaining parameters unless directed to do so by Oracle
Support or to meet the specific needs of your application. Table 9.9 describes the basic ini-
tialization parameters . A “Yes” in the Static column indicates that the parameter is static
and cannot be modified dynamically without a database restart.
TABLE 9.9 Oracle 11g Basic Initialization Parameters
Parameter Name Static Description
CLUSTER_DATABASE
Yes Tells the instance whether it is part of a clustered
environment.
COMPATIBLE
Yes Specifies the release level and feature set you want to be
active in the instance.
CONTROL_FILES
Yes Designates the physical location of the database control
files.
DB_BLOCK_SIZE
Yes Specifies the default database block size. The database
block size specified at database creation cannot be
changed.
95127c09.indd 489 2/18/09 6:43:55 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
490

Chapter 9
N
Creating an Oracle 11g Database
Parameter Name Static Description

DB_CREATE_FILE_DEST
No Specifies the directory location where database data files
will be created if the Oracle-Managed Files feature is used.
DB_CREATE_ONLINE_LOG_
DEST_n
No Specifies the location(s) where the database redo log files
will be created if the Oracle-Managed Files feature is used.
DB_DOMAIN
Yes Specifies the logical location of the database on the net-
work.
DB_NAME
Yes Specifies the name of the database that is mounted by
the instance.
DB_RECOVERY_FILE_DEST
No Specifies the location where recovery files will be writ-
ten if the flash recovery feature is used.
DB_RECOVERY_FILE_
DEST_SIZE
No Specifies the amount of disk space available for storing
flash recovery files.
DB_UNIQUE_NAME
Yes Specifies a globally unique name for the database within
the enterprise.
INSTANCE_NUMBER
Yes Identifies the instance in a Real Application Clusters
(RAC) environment.
LDAP_DIRECTORY_​
SYSAUTH
Yes Enables or disables Oracle Internet directory–based
authentication for

SYSDBA
and
SYSOPER
connections to
the database.
LOG_ARCHIVE_DEST_n
No Specifies as many as nine locations where archived redo
log files are to be written.
LOG_ARCHIVE_DEST_
STATE_n
No Indicates how the specified locations should be used for
log archiving.
NLS_LANGUAGE
Yes Specifies the default language of the database.
NLS_TERRITORY
Yes Specifies the default region or territory of the database.
OPEN_CURSORS
No Sets the maximum number of cursors that an individual
session can have open at one time.
PGA_AGGREGATE_TARGET
No Establishes the overall amount of memory that all PGA
processes are allowed to consume.
PROCESSES
Yes Specifies the maximum number of operating-system
processes that can connect to the instance.
REMOTE_LISTENER
No Specifies a network name that points to the address or
list of addresses of remote Oracle Net listeners.
TABLE 9.9 Oracle 11g Basic Initialization Parameters (continued)
95127c09.indd 490 2/18/09 6:43:56 AM

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Managing Initialization-Parameter Files

491
Parameter Name Static Description
REMOTE_LOGIN_​
PASSWORDFILE
Yes Determines whether the instance uses a password file
and what type.
ROLLBACK_SEGMENTS
Yes Specifies the rollback-segment names, only if Automatic
Undo Management is not being used.
SESSIONS
Yes Determines the maximum number of sessions that can
connect to the database.
SGA_TARGET
No Establishes the maximum size of the SGA, within which
space is automatically allocated to each SGA component
when Automatic Memory Management is used.
SHARED_SERVERS
No Specifies the number of shared server processes to start
when the instance is started. See Chapter 11 for details.
STAR_TRANSFORMATION_
ENABLED
No Determines whether the optimizer will consider star trans-
formations when queries are executed. See Chapter 14 for
details on the optimizer.
UNDO_MANAGEMENT
Yes Establishes whether system undo is automatically or
manually managed. See Chapter 8, “Introducing Oracle

11g Components and Architecture,” for details on undo
segments.
UNDO_TABLESPACE
No Specifies which tablespace stores undo segments if the
Automatic Undo Management option is used. See Chap-
ter 13, “Managing Data and Undo,” for details on undo
management.
Any parameters not specified in the pfile or spfile take on their default values. The fol-
lowing is an example of the contents of a typical Oracle 11g pfile that contains both basic
and advanced parameters:
audit_file_dest=’/u01/app/oracle/admin/OCA11G/adump’
audit_trail=’db’
compatible=’11.1.0.0.0’
control_files=(‘/u01/app/oracle/oradata/OCA11G/control01.ctl’
,’/u01/app/oracle/oradata/OCA11G/control02.ctl’
,’/u01/app/oracle/oradata/OCA11G/control03.ctl’)
db_block_size=8192
db_domain=’’
db_name=’OCA11G’
db_recovery_file_dest=’/u01/app/oracle/flash_recovery_area’
TABLE 9.9 Oracle 11g Basic Initialization Parameters (continued)
95127c09.indd 491 2/18/09 6:43:56 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
492

Chapter 9
N
Creating an Oracle 11g Database
db_recovery_file_dest_size=2147483648
diagnostic_dest=’/u01/app/oracle’

dispatchers=’(PROTOCOL=TCP)​(SERVICE=OCA11GXDB)’
memory_target=1G
open_cursors=300
processes=150
remote_login_passwordfile=’EXCLUSIVE’
undo_tablespace=’UNDOTBS1’
In this sample pfile, the sizes of the shared pool, database buffer cache, large pool, and
Java pool are not individually specified. Instead, Oracle 11g’s Automatic Memory Manage-
ment features allow you to simply set one configuration parameter—
MEMORY_TARGET
—to
establish the total amount of memory allocated to the SGA and PGA. I will discuss this
parameter in Chapter 14.
On production databases, if your Oracle license is based on the number of named users,
you can enforce the license compliance by setting the
LICENSE_MAX_USERS
parameter. The
default for this parameter is 0, which means you can create any number of users in the
database and the license compliance is not enforced.
Handle with Care: Undocumented Configuration Parameters
You’ve just read a performance-tuning tip posted to the Oracle newsgroup at
comp​
.databases.oracle.server
. The person posting the tip suggests setting the undocu-
mented pfile parameter
_dyn_sel_est_num_blocks
to a value of 200 in order to boost
your database’s performance. Should you implement this suggestion?
More than 1,000 undocumented configuration parameters are available in Oracle 11g.
Undocumented configuration parameters are distinguished from their documented counter-

parts by the underscore that precedes their name, as with the parameter described in the
newsgroup posting.
I do not recommend utilizing undocumented pfile or spfile parameters on any of your
systems because knowing the appropriate reasons to use these parameters, and the
appropriate values to set these parameters to, is almost pure speculation because of their
undocumented nature. Although some undocumented parameters are relatively harmless
(such as
_trace_files_public
), using others incorrectly can cause unforeseen database
problems. What does the
_dyn_sel_est_num_blocks
parameter do, and what value should
you set it to? Only the engineers of the Oracle 11g kernel code know for sure.
One exception to this suggestion is when you are directed to use an undocumented config-
uration parameter by Oracle Support. Oracle Support occasionally uses these parameters
to enhance the generation of debug information or to work around a bug in the kernel code.
95127c09.indd 492 2/18/09 6:43:56 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Managing Initialization-Parameter Files

493
Locating the Default Parameter File
The default location that Oracle searches to find the pfile and spfile parameter files is
$ORACLE_HOME/dbs
on Unix systems and
%ORACLE_HOME%\database
on Windows systems.
Oracle uses a search hierarchy when a
startup
command is issued without specifying

either a pfile or an spfile. Oracle looks for files with the following names in the default
directory to start the instance:
spfile$ORACLE_SID.ora
ÛN
spfile.ora
ÛN
init$ORACLE_SID.ora
ÛN
Oracle first looks for a parameter file called
spfile$ORACLE_SID.ora
. If it doesn’t find
that, it searches for
spfile.ora
. Finally, it searches for a traditional text pfile with the
default name of
init$ORACLE_SID.ora
.
If the parameter files do not exist in the default location or you want to use a different
parameter file to start your database, you can specify a parameter file to use when you issue
a
startup
command to start the Oracle Database.
You will see examples of how database startup is performed later in
this chapter in the section “Starting Up and Shutting Down an Oracle
Instance.”
Modifying Initialization-Parameter Values
In some instances, you may need to change the initialization parameters. For example, you
might need to increase the number of sessions allowed to connect to the database because
you are adding users. Whatever the case, you need to know how to make these changes.
There are a few options to change the initialization-parameter value, based on the type of

parameter file used. Here they are:
If
ÛN
PFILE
is used, edit the pfile using an OS editor, and make appropriate changes.
If
ÛN
SPFILE
is used, connect to the instance, and make changes using the
ALTER​SYSTEM​
SET​parameter_name​=​value
statement.
Use EM Database Control to make changes.
ÛN
Using EM Database Control
To use the EM Database Control tool to modify existing database parameters, navigate to
the Server menu. In the Database Configuration section, you can modify your initialization
parameters. The SPFile tab shows the parameters as set in the spfile. You can also use the
filters to find the exact parameter that needs to be modified. The Category drop-down is a
very useful feature. Figure 9.36 shows the EM screen to change initialization parameters.
95127c09.indd 493 2/18/09 6:43:56 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
494

Chapter 9
N
Creating an Oracle 11g Database
The Initialization Parameters screen has two tabs:
Current tab This tab displays all the currently active settings for initialization parameters
for the database instance. If a parameter is marked Dynamic, you can modify it, and this

modification immediately affects the parameter that affects the currently running instance
without stopping the database. The changes you make on the Current tab are not perma-
nent, so the next time the database is stopped and restarted, the settings revert to their
original values.
SPFile tab If you are using a server parameter file, you will see the SPFile tab. This tab
also lets you change existing database parameters. The difference between changing param-
eters on this tab and changing parameters on the Current tab is that changes to the spfile
are persistent across database startups and shutdowns because the changes are saved to the
spfile definition. You can also apply your changes to the spfile only or to the spfile and the
currently running instance.
FIGURE 9.36 The EM Database Control Initialization Parameters screen
95127c09.indd 494 2/18/09 6:43:56 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Managing Initialization-Parameter Files

495
Using SQL*Plus
Though EM Database Control is a handy tool to modify the initialization parameters,
sometimes it is convenient to use SQL*Plus and make changes to the parameters. You
should know about two dynamic performance views:
V$PARAMETER
and
V$SPPARAMETER
.
V$PARAMETER
The
V$PARAMETER
view shows information about the initialization parameters that are cur-
rently in effect. This view has several useful columns. Table 9.10 lists some of the columns
in

V$PARAMETER
and how they can be used in queries.
TABLE 9.10
V$PARAMETER
Columns
Column Name Description
NAME
This specifies the name of the initialization parameter.
VALUE
This specifies the current value of the parameter.
DISPLAY_VALUE
This specifies the current value in a more user-friendly format.
DESCRIPTION
This gives a short description about the parameter.
ISBASIC TRUE
indicates that the parameter is categorized as a basic parameter.
ISDEFAULT FALSE
indicates that the parameter was specified in the pfile or spfile
during instance startup.
ISMODIFIED FALSE
indicates that the parameter has not been modified since the
instance started.
ISSES_MODIFIABLE TRUE
indicates that the parameter can be modified using an
ALTER​
SESSION
statement.
ISSYS_MODIFIABLE FALSE
indicates that the parameter cannot be modified using an
ALTER​SYSTEM

statement. Such parameters can be changed only
using the
SCOPE=SPFILE
clause.
V$SPPARAMETER
The
V$SPPARAMETER
view shows the contents of the spfile used to start the instance. A
TRUE

value for the
ISSPECIFIED
column shows whether the parameter was specified in the spfile.
If a pfile was used to start the instance, all the rows will have
FALSE
for the
ISSPECIFIED

column. Sometimes, querying the
V$SPPARAMETER
can produce readable output for param-
eters that take multiple values.
95127c09.indd 495 2/18/09 6:43:56 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
496

Chapter 9
N
Creating an Oracle 11g Database
V$PARAMETER vs. V$SPPARAMETER

The following SQL example shows the difference in the result from the
V$PARAMETER
and
V$SPPARAMETER
views:
SQL>​SELECT​name,​value
​​2​​FROM​v$parameter
​​3​​WHERE​name​LIKE​‘control%’
​​4​​AND​isdefault​=​‘FALSE’;
NAME​​​​​​​​​​​​​​​​​VALUE
--------------------​------------------------------------------------
control_files​​​​​​​​/u01/app/oracle/oradata/OCA11G/control01.ctl,​/u
​​​​​​​​​​​​​​​​​​​​​01/app/oracle/oradata/OCA11G/control02.ctl,/u01/
​​​​​​​​​​​​​​​​​​​​​app/oracle/oradata/OCA11G/control03.ctl
SQL>​SELECT​name,​value
​​2​​FROM​v$spparameter
​​3​​WHERE​name​LIKE​‘control%’
​​4​​AND​isspecified​=​‘TRUE’;
NAME​​​​​​​​​​​​​​​​​VALUE
--------------------​------------------------------------------------
control_files​​​​​​​​/u01/app/oracle/oradata/OCA11G/control01.ctl
control_files​​​​​​​​/u01/app/oracle/oradata/OCA11G/control02.ctl
control_files​​​​​​​​/u01/app/oracle/oradata/OCA11G/control03.ctl
SQL>
You can use the
ALTER​SESSION
statement to change the value of a parameter in the cur-
rent session. For example, if you want to change the default date-display format for the ses-
sion only, use the following statement:
SQL>​ALTER​SESSION​SET​NLS_DATE_FORMAT​=​‘DD-MON-YYYY​HH24:MI:SS’;

Session​altered.
SQL>
You can use the
ALTER​SYSTEM
statement to change the value of a parameter system-wide
or in the spfile, or both. You use the
SCOPE
clause to define where you want to change the
parameter value:
MEMORY
,
SPFILE
, and
BOTH
are the valid values for the
SCOPE
clause.
95127c09.indd 496 2/18/09 6:43:57 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Managing Initialization-Parameter Files

497
A value of
DEFERRED
or
IMMEDIATE
in the
ISSYS_MODIFIABLE
column shows that the
parameter can be dynamically changed using

ALTER​SYSTEM
. The
DEFERRED
value indicates
that the change you make does not take effect until a new session is started; the existing
sessions will use the current value.
IMMEDIATE
indicates that as soon as you change the value
of the parameter, it is available to all sessions in the instance. A session is a job or task that
Oracle manages. When you log in to the database using SQL*Plus or any other tool, you
start a session.
If you want to change a parameter value for the current instance but do not want the
change to persist across database shutdowns, you can specify
SCOPE=MEMORY
, as in the fol-
lowing example:
SQL>​ALTER​SYSTEM​SET​UNDO_RETENTION​=​3600​SCOPE=MEMORY;
System​altered.
SQL>
Some parameters values can be set only at instance startup; they are not modifiable
when the instance is running. Such parameter changes can be made with the
SCOPE=SPFILE

clause. Oracle will make the change only to the spfile, which takes effect after you restart
the database:
SQL>​ALTER​SYSTEM​SET​UNDO_MANAGEMENT​=​MANUAL;
ALTER​SYSTEM​SET​UNDO_MANAGEMENT​=​MANUAL
​​​​​​​​​​​​​​​​​*
ERROR​at​line​1:
ORA-02095:​specified​initialization​parameter​cannot​be​modified

SQL>​ALTER​SYSTEM​SET​UNDO_MANAGEMENT​=​MANUAL​SCOPE=SPFILE;
System​altered.
SQL>
Most of the times when you make a parameter change, you want it to take effect imme-
diately in memory as well as persist the change across database shutdowns. You can use the
SCOPE=BOTH
clause, which is the default, for this purpose. So if you omit the
SCOPE
clause,
Oracle will make changes to the memory and to the spfile. If a pfile is used to start the
instance, the change will be in memory only for the current running instance.
SQL>​ALTER​SYSTEM​SET​SGA_TARGET=500M​SCOPE=BOTH;
System​altered.
SQL>
95127c09.indd 497 2/18/09 6:43:57 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
498

Chapter 9
N
Creating an Oracle 11g Database
You can use the SQL*Plus command
SHOW​PARAMETER
to view the current value of an
initialization parameter. You can specify the full parameter name or part of the name. For
example, to view all parameters related to undo, you can do this:
SQL>​SHOW​PARAMETER​undo
NAME​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​TYPE​​​​​​​​VALUE
------------------------------------​-----------​-----------
undo_management​​​​​​​​​​​​​​​​​​​​​​string​​​​​​AUTO

undo_retention​​​​​​​​​​​​​​​​​​​​​​​integer​​​​​3600
undo_tablespace​​​​​​​​​​​​​​​​​​​​​​string​​​​​​UNDOTBS1
SQL>
In the next section, I will discuss the options to start up and shut down a database.
Starting Up and Shutting Down an
Oracle Instance
As a DBA, you are responsible for the startup and shutdown of the Oracle instance. Oracle
gives authorized administrators the ability to perform this task using a variety of interfaces.
It is important to understand the options that are available to you to start up and shut
down the Oracle instance and when the various options can or should be used. The stages
of instance startup and the startup options appear frequently on OCA certification exams.
To start up or shut down an Oracle instance, you need to be connected to the data-
base with the appropriate privileges. Two special connection account authorizations are
available for startup and shutdown:
SYSDBA
and
SYSOPER
. The
SYSDBA
authorization is an
all-empowering authorization that allows you to perform any database task. The
SYSOPER

authorization is a less powerful authorization that allows startup and shutdown abilities
but restricts other administrative tasks, such as access to nonadministrative schema objects.
These authorizations are managed either through a passwords file or via operating-system
control.
When a database is initially installed, only the
SYS
schema can connect to the database

with the
SYSDBA
authorization. You can grant this authorization and the
SYSOPER
authoriza-
tion to give others the ability to perform these tasks without connecting as the
SYS
user.
Now I will discuss how to perform a database startup.
Starting Up an Oracle 11g Database
As described in Chapter 8, the Oracle instance is composed of a set of logical memory struc-
tures and background processes that users interact with to communicate with the Oracle
Database. When Oracle is started, these memory structures and background processes are
initialized and started so that users can communicate with the Oracle Database.
95127c09.indd 498 2/18/09 6:43:57 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Starting Up and Shutting Down an Oracle Instance

499
Whenever an Oracle Database is started, it goes through a series of steps to ensure
database consistency. When it starts up, a database passes through three modes:
NOMOUNT
,
MOUNT
, and
OPEN
. I will review each of these startup modes and other special startup options
such as
FORCE
and

RESTRICT
and discuss when you need to use these options. I’ll then dis-
cuss how to use the available interfaces to start up an Oracle instance.
STARTUP NOMOUNT    
This starts the instance without mounting the database. When a data-
base is started in this mode, the parameter file is read, and the background processes and
memory structures are initiated, but they are not attached or communicating with the disk
structures of the database. When the instance is in this state, the database is not available
for use.
If a database is started in
NOMOUNT
mode, only the background processes and instance are
started. The instance is not associated with any database. This state is used to create a
database or to create a database control file.
At times, a database may not be able to go to the next mode (called
MOUNT
mode) and remains
in
NOMOUNT
mode. For example, this can occur if Oracle has a problem accessing the control
file structures, which contain important information to continue with the startup process. If
these structures are damaged or not available, the database startup process cannot continue
until the problem is resolved.
If
STARTUP​NOMOUNT
fails, the most likely cause is that the parameter file
cannot be read or is not in the default location. Other causes include OS
resource limits that prevent memory or process allocation.
STARTUP MOUNT   
This performs all the work of the

STARTUP​NOMOUNT
option but also attaches
and interacts with the database structures. At this point, Oracle obtains information from
the control files that it uses to locate and attach to the main database structures. The con-
trol file contains the name of the database, all the data file names, and the redo log files
associated with the database.
Certain administrative tasks can be performed while the database is in this mode, including
renaming data files, enabling or disabling archive logging, renaming and adding redo log
files, and recovering the database.
STARTUP OPEN    
This is the default startup mode if no mode is specified on the
STARTUP
com-
mand line.
STARTUP​OPEN
performs all the steps of the
STARTUP​NOMOUNT
and
STARTUP​MOUNT

options. This option makes the database available to all users.
When opening the database, you can use a couple of options.
STARTUP​OPEN​READ​ONLY
opens
the database in read-only mode.
STARTUP​OPEN​RECOVER
opens the database and performs a
database recovery.
Although you typically use the
STARTUP​NOMOUNT

,
STARTUP​MOUNT
, and
STARTUP​OPEN
options,
a few other startup options are available that you can use in certain situations:
STARTUP​FORCE

and
STARTUP​RESTRICT
. These are discussed next.
95127c09.indd 499 2/18/09 6:43:57 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
500

Chapter 9
N
Creating an Oracle 11g Database
STARTUP FORCE    
You can use the
STARTUP​FORCE
startup option if you are experiencing
difficulty starting the database in a normal fashion. For example, if a database server lost
power and the database stopped abruptly, it can leave the database in a state in which a
STARTUP​FORCE
startup is necessary. This type of startup should not normally be required
but can be used if a normal startup does not work. What is also different about
STARTUP​
FORCE
is that it can be issued no matter what mode the database is in.

STARTUP​FORCE
does
a shutdown abort and then restarts the database.
STARTUP RESTRICT    
The
STARTUP​RESTRICT
option starts up the database and places it in
OPEN
mode but gives access only to users who have the
RESTRICTED​SESSION
privilege. You
might want to open a database using the
RESTRICTED
option when you want to perform
maintenance on the database while it is open but ensure that users cannot connect and per-
form work on the database. You might also want to open the database using the
RESTRICTED

option to perform database exports or imports and guarantee that no users are accessing
the system during these activities. After you are done with your work, you can disable the
restricted session,
ALTER​SYSTEM​DISABLE​RESTRICTED​SESSION
, so everyone can connect to
the database.
Starting Up Oracle Using EM Database Control
Now that you understand the various startup options, let’s look at how to use the EM
Database Control to start up the Oracle instance.
When you invoke the Enterprise Manager console, you are notified that the database
instance is down (see Figure 9.37).
FIGURE 9.37 The EM Database Control database status screen

95127c09.indd 500 2/18/09 6:43:57 AM
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.