Skip Headers

Oracle9i Database Administrator's Guide

Release 2 (9.2)
Home Book Contents Index Master Feedback
Part Number A96521-01 List Index

1
The Oracle Database Administrator
This chapter describes your responsibilities as a database administrator (DBA) who administers
the Oracle database server.

The following topics are discussed:

 Types of Oracle Users

 Tasks of a Database Administrator
 Identifying Your Oracle Database Software Release
 Database Administrator Security and Privileges
 Database Administrator Authentication
 Creating and Maintaining a Password File
 Database Administrator Utilities

Types of Oracle Users

The types of users and their roles and responsibilities at a site can vary. A small site can have one
database administrator who administers the database for application developers and users. A very
large site can find it necessary to divide the duties of a database administrator among several
people, and among several areas of specialization.

This section contains the following topics:

 Database Administrators
 Security Officers
 Network Administrators
 Application Developers
  Application Administrators
 Database Users

Database Administrators

Each database requires at least one database administrator (DBA) to administer it. Because an
Oracle database system can be large and can have many users, often this is not a one person job.
In such cases, there is a group of DBAs who share responsibility.

A database administrator's responsibilities can include the following tasks:

 Installing and upgrading the Oracle server and application tools

 Allocating system storage and planning future storage requirements for the database
system
 Creating primary database storage structures (tablespaces) after application developers
have designed an application
 Creating primary objects (tables, views, indexes) once application developers have
designed an application
 Modifying the database structure, as necessary, from information given by application
developers
 Enrolling users and maintaining system security
 Ensuring compliance with your Oracle license agreement
 Controlling and monitoring user access to the database
 Monitoring and optimizing the performance of the database
 Planning for backup and recovery of database information
 Maintaining archived data on tape
 Backing up and restoring the database
 Contacting Oracle Corporation for technical support

Security Officers

In some cases, a site assigns one or more security officers to a database. A security officer
enrolls users, controls and monitors user access to the database, and maintains system security.
As a DBA, you might not be responsible for these duties if your site has a separate security
officer.

Network Administrators
Some sites have one or more network administrators. A network administrator can administer
Oracle networking products, such as Oracle Net Services.

See Also:

Part VI, "Distributed Database Management" for information on network

administration in a distributed environment

Application Developers

Application developers design and implement database applications. Their responsibilities

include the following tasks:

 Designing and developing the database application

 Designing the database structure for an application
 Estimating storage requirements for an application
 Specifying modifications of the database structure for an application
 Relaying the above information to a database administrator
 Tuning the application during development
 Establishing an application's security measures during development

Application developers can perform some of these tasks in collaboration with DBAs.

Application Administrators

An Oracle site can assign one or more application administrators to administrate a particular
application. Each application can have its own administrator.

Database Users

Database users interact with the database through applications or utilities. A typical user's
responsibilities include the following tasks:

 Entering, modifying, and deleting data, where permitted

 Generating reports from the data

Tasks of a Database Administrator

The following tasks present a prioritized approach for designing, implementing, and maintaining
an Oracle Database:

Task 1: Evaluate the Database Server Hardware

Task 2: Install the Oracle Software

Task 3: Plan the Database

Task 4: Create and Open the Database

Task 5: Back Up the Database

Task 6: Enroll System Users

Task 7: Implement the Database Design

Task 8: Back Up the Fully Functional Database

Task 9: Tune Database Performance

These tasks are discussed in succeeding sections.

Note:

If upgrading to a new release, back up your existing production database

before installation. For information on preserving your existing production
database, see Oracle9i Database Migration.

Task 1: Evaluate the Database Server Hardware

Evaluate how Oracle and its applications can best use the available computer resources. This
evaluation should reveal the following information:

 How many disk drives are available to Oracle and its databases
 How many, if any, dedicated tape drives are available to Oracle and its databases
 How much memory is available to the instances of Oracle you will run (see your system's
configuration documentation)

Task 2: Install the Oracle Software

As the database administrator, you install the Oracle database server software and any front-end
tools and database applications that access the database. In some distributed processing
installations, the database is controlled by a central computer (database server) and the database
tools and applications are executed on remote computers (clients). In this case, you must also
install the Oracle Net components necessary to connect the remote machines to the computer that
executes Oracle.
For more information on what software to install, see "Identifying Your Oracle Database
Software Release".

See Also:

For specific requirements and instructions for installation, refer to the

following documentation:

 Your operating system specific Oracle documentation

 Your installation guides for your front-end tools and Oracle Net
drivers.

Task 3: Plan the Database

As the database administrator, you must plan:

 The logical storage structure of the database

 The overall database design
 A backup strategy for the database

It is important to plan how the logical storage structure of the database will affect system
performance and various database management operations. For example, before creating any
tablespaces for your database, you should know how many datafiles will make up the tablespace,
what type of information will be stored in each tablespace, and on which disk drives the datafiles
will be physically stored. When planning the overall logical storage of the database structure,
take into account the effects that this structure will have when the database is actually created
and running. Such considerations include how the logical storage structure database will affect
the following:

 The performance of the computer executing Oracle

 The performance of the database during data access operations
 The efficiency of backup and recovery procedures for the database

Plan the relational design of the database objects and the storage characteristics for each of these
objects. By planning the relationship between each object and its physical storage before creating
it, you can directly affect the performance of the database as a unit. Be sure to plan for the
growth of the database.

In distributed database environments, this planning stage is extremely important. The physical
location of frequently accessed data dramatically affects application performance.
During the planning stage, develop a backup strategy for the database. You can alter the logical
storage structure or design of the database to improve backup efficiency.

It is beyond the scope of this book to discuss relational and distributed database design. If you
are not familiar with such design issues, refer to accepted industry-standard documentation.

Part II, "Oracle Server Processes and Storage Structure" and Part III, "Schema Objects" provide
specific information on creating logical storage structures, objects, and integrity constraints for
your database.

Task 4: Create and Open the Database

When you complete the database design, you can create the database and open it for normal use.
You can create a database at installation time, using the Database Configuration Assistant, or you
can supply your own scripts for creating a database.

Either way, refer to Chapter 2, "Creating an Oracle Database", for information on creating a
database and Chapter 4, "Starting Up and Shutting Down" for guidance in starting up the
database.

Task 5: Back Up the Database

After you create the database structure, carry out the backup strategy you planned for the
database. Create any additional redo log files, take the first full database backup (online or
offline), and schedule future database backups at regular intervals.

See Also:

For instructions on customizing your backup operations and performing

recovery procedures see either of the following:

 Oracle9i User-Managed Backup and Recovery Guide

 Oracle9i Recovery Manager User's Guide

Task 6: Enroll System Users

After you back up the database structure, you can enroll the users of the database in accordance
with your Oracle license agreement, create appropriate roles for these users, and grant these
roles.

The following chapters will help you in this endeavor:

 Chapter 23, "Establishing Security Policies"

 Chapter 24, "Managing Users and Resources"
  Chapter 25, "Managing User Privileges and Roles"

Task 7: Implement the Database Design

After you create and start the database, and enroll the system users, you can implement the
planned logical structure database by creating all necessary tablespaces. When you complete this,
you can create the objects for the database.

Part II, "Oracle Server Processes and Storage Structure" and Part III, "Schema Objects" contain
information which can help you create logical storage structures and objects for your database.

Task 8: Back Up the Fully Functional Database

Now that the database is fully implemented, again back up the database. In addition to regularly
scheduled backups, you should always back up your database immediately after implementing
changes to the database structure.

Task 9: Tune Database Performance

Optimizing the performance of the database is one of your ongoing responsibilities as a DBA.
Additionally, Oracle provides a database resource management feature that enables you to
control the allocation of resources to various user groups.

The database resource manager is described in Chapter 27, "Using the Database Resource
Manager".

See Also:

Oracle9i Database Performance Tuning Guide and Reference contains

information about tuning your database and applications.

Identifying Your Oracle Database Software Release

Because the Oracle database server continues to evolve and can require maintenance, Oracle
periodically produces new releases. Because only some users initially subscribe to a new release
or require specific maintenance, multiple releases of the product can exist simultaneously.

As many as five numbers may be required to fully identify a release. The significance of these
numbers is discussed below.

Release Number Format

To understand the release level nomenclature used by Oracle, examine the following example of
an Oracle database server labeled "Release 9.2.0.1.0."
Figure 1-1 Example of an Oracle Release Number

Text description of the illustration admin002.gif

Note:

Starting with release 9.2, maintenance releases of Oracle are denoted by a

change to the second digit of a release number. In previous releases, the third
digit indicated a particular maintenance release.

Major Database Release Number

This is the most general identifier. It represents a major new edition (or version) of the software
that contains significant new functionality.

Database Maintenance Release Number

This digit represents a maintenance release level. Some new features may also be included.

Application Server Release Number

This digit reflects the release level of the Oracle9i Application Server (Oracle9iAS).

Component Specific Release Number

This digit identifies a release level specific to a component. Different components can have
different numbers in this position depending upon, for example, component patch sets or interim
releases.

Platform Specific Release Number

This digit identifies a platform specific release. Usually this is a patch set. Where different
platforms require the equivalent patch set, this digit will be the same across the effected
platforms.
Checking Your Current Release Number

To identify the release of the Oracle database server that is currently installed and to see the
release levels of other Oracle components you are using, query the data dictionary view
PRODUCT_COMPONENT_VERSION. A sample query is shown below. Other product release levels
may increment independently of the database server.

COL PRODUCT FORMAT A35

COL VERSION FORMAT A15
COL STATUS FORMAT A15
SELECT * FROM PRODUCT_COMPONENT_VERSION;

PRODUCT VERSION STATUS

----------------------------------- --------------- ---------------
NLSRTL 9.2.0.1.0 Production
Oracle9i Enterprise Edition 9.2.0.1.0 Production
PL/SQL 9.2.0.1.0 Production
TNS for Solaris: 9.2.0.1.0 Production

It's important to convey to Oracle the information displayed by this query when you report
problems with the software.

Optionally, you can query the V$VERSION view to see component-level information.

Database Administrator Security and Privileges

To accomplish the administrative tasks of an Oracle DBA, you need extra privileges both within
the database and possibly in the operating system of the server on which the database runs.
Access to a database administrator's account should be tightly controlled.

This section contains the following topics:

 The Database Administrator's Operating System Account

 Database Administrator Usernames

The Database Administrator's Operating System Account

To perform many of the administrative duties for a database, you must be able to execute
operating system commands. Depending on the operating system that executes Oracle, you might
need an operating system account or ID to gain access to the operating system. If so, your
operating system account might require more operating system privileges or access rights than
many database users require (for example, to perform Oracle software installation). Although
you do not need the Oracle files to be stored in your account, you should have access to them.

See Also:
 Your operating system specific Oracle documentation. The method of
distinguishing a database administrator's account is operating system specific.

Database Administrator Usernames

Two user accounts are automatically created with the database:

 SYS (default password: CHANGE_ON_INSTALL)

 SYSTEM (default password: MANAGER)

Note:

Oracle recommends that you specify passwords for SYS and SYSTEM at
database creation time, rather that using these default passwords. This is
explained in "Protecting Your Database: Specifying Passwords for Users
SYS and SYSTEM".

If you use the default passwords, to prevent inappropriate access to the data
dictionary tables or other tampering with the database, it is important that you
change the passwords for the SYS and SYSTEM usernames immediately after
creating an Oracle database.

It is suggested that you create at least one additional administrator user, and grant that user the
DBA role, to use when performing daily administrative tasks. It is recommended that you do not
use SYS and SYSTEM for these purposes.

Note Regarding Security Enhancements:

In this release of Oracle and in subsequent releases, several enhancements are

being made to ensure the security of default database user accounts.

 During initial installation with the Database Configuration Assistant

(DCBA), all default database user accounts except SYS, SYSTEM,
SCOTT, DBSNMP, OUTLN, AURORA$JIS$UTILITY$,
AURORA$ORB$UNAUTHENTICATED and OSE$HTTP$ADMIN are locked and
expired. To activate a locked account, the DBA must manually unlock
it and reassign it a new password.
 In addition, the DBCA prompts for passwords for users SYS and
SYSTEM during initial installation of the database rather than assigning
default passwords to them. A CREATE DATABASE statement issued
 manually also lets you supply passwords for these two users.

SYS

When any database is created, the user SYS is automatically created and granted the DBA role.

All of the base tables and views for the database's data dictionary are stored in the schema SYS.
These base tables and views are critical for the operation of Oracle. To maintain the integrity of
the data dictionary, tables in the SYS schema are manipulated only by Oracle. They should never
be modified by any user or database administrator, and no one should create any tables in the
schema of user SYS. (However, you can change the storage parameters of the data dictionary
settings if necessary.)

Ensure that most database users are never able to connect using the SYS account.

SYSTEM

When a database is created, the user SYSTEM is also automatically created and granted the DBA
role.

The SYSTEM username is used to create additional tables and views that display administrative
information, and internal tables and views used by various Oracle options and tools. Never create
in the SYSTEM schema tables of interest to individual users.

The DBA Role

A predefined role, named DBA, is automatically created with every Oracle database. This role
contains most database system privileges. Therefore, it is very powerful and should be granted
only to fully functional database administrators.

Note:

The DBA role does not include the SYSDBA or SYSOPER system privileges.
These are special administrative privileges that allow an administrator to
perform basic database administration tasks, such as creating the database
and instance startup and shutdown. These system privileges are discussed in
"Administrative Privileges".

Database Administrator Authentication

As a DBA, you often perform special operations such as shutting down or starting up a database.
Because only a DBA should perform these operations, the database administrator usernames
require a secure authentication scheme.

This section contains the following topics:

 Administrative Privileges
 Selecting an Authentication Method
 Using Operating System (OS) Authentication
 Using Password File Authentication

Administrative Privileges

Administrative privileges that are required for an administrator to perform basic database
operations are granted through two special system privileges, SYSDBA and SYSOPER. You must
have one of these privileges granted to you, depending upon the level of authorization you
require.

Note:

The SYSDBA and SYSOPER system privileges allow access to a database

instance even when the database is not open. Control of these privileges is
totally outside of the database itself.

While referred to as system privileges, SYSDBA and SYSOPER, can also be

thought of as types of connections (for example, you specify: CONNECT AS
SYSDBA) that enable you to perform certain database operations for which
privileges cannot be granted in any other fashion.

SYSDBA and SYSOPER

The following are the operations that are authorized by the SYSDBA and SYSOPER system
privileges:

System
Privilege Operations Authorized
SYSDBA
 Perform STARTUP and SHUTDOWN operations
 ALTER DATABASE: open, mount, back up, or change character set
 CREATE DATABASE
System
Privilege Operations Authorized

 CREATE SPFILE

 ARCHIVELOG and RECOVERY

 Includes the RESTRICTED SESSION privilege

Effectively, this system privilege allows a user to connect as user SYS.

SYSOPER
 Perform STARTUP and SHUTDOWN operations
 CREATE SPFILE

 ALTER DATABASE OPEN/MOUNT/BACKUP

 ARCHIVELOG and RECOVERY

 Includes the RESTRICTED SESSION privilege

This privilege allows a user to perform basic operational tasks, but without the
ability to look at user data.

The manor in which you are authorized to use these privileges depends upon the method of
authentication that you choose to use.

When you connect with SYSDBA or SYSOPER privileges, you connect with a default schema, not
with the schema that is generally associated with your username. For SYSDBA this schema is SYS;
for SYSOPER the schema is PUBLIC.

Connecting with Administrative Privileges: Example

This example illustrates that a user is assigned another schema (SYS) when connecting with the
SYSDBA system privilege.

Assume that user scott has issued the following statements:

CONNECT scott/password
CREATE TABLE admin_test(name VARCHAR2(20));

Later, scott issues these statements:

CONNECT scott/password AS SYSDBA

SELECT * FROM admin_test;

User scott now receives the following error:

ORA-00942: table or view does not exist

This is because scott now references the SYS schema by default. The table was created in the
scott schema.

See Also:
 "Using Operating System (OS) Authentication"
 "Using Password File Authentication"

Selecting an Authentication Method

The following methods are available for authenticating database administrators:

 Operating system (OS) authentication

 Password files

Note:

These methods replace the CONNECT INTERNAL syntax provided with earlier
versions of Oracle. CONNECT INTERNAL is no longer allowed.

Your choice will be influenced by whether you intend to administer your database locally on the
same machine where the database resides, or whether you intend to administer many different
databases from a single remote client. Figure 1-2 illustrates the choices you have for database
administrator authentication schemes.

Figure 1-2 Database Administrator Authentication Methods

Text description of the illustration admin001.gif

If you are performing remote database administration, you should consult your Oracle Net
documentation to determine if you are using a secure connection. Most popular connection
protocols, such as TCP/IP and DECnet, are not secure.

See Also:
 Oracle9i Database Concepts for additional information about user
authentication
 "User Authentication"
 "User Authentication Methods"
 Oracle9i Net Services Administrator's Guide

Non-Secure Remote Connections

To connect to Oracle as a privileged user over a non-secure connection, you must be

authenticated by a password file. When using password file authentication, the database uses a
password file to keep track of database usernames that have been granted the SYSDBA or SYSOPER
system privilege.

This form of authentication is discussed in "Using Password File Authentication".

Local Connections and Secure Remote Connections

To connect to Oracle as a privileged user over a local connection or a secure remote connection,
you have the following options:

 You can connect and be authenticated by a password file, provided the database has a
password file and you have been granted the SYSDBA or SYSOPER system privilege.
  If the server is not using a password file, or if you have not been granted SYSDBA or
SYSOPER privileges and are therefore not in the password file, you can use OS
authentication. On most operating systems, OS authentication for database administrators
involves placing the OS username of the database administrator in a special group,
generically referred to as OSDBA.

Using Operating System (OS) Authentication

This section describes how to authenticate an administrator using the operating system.

Preparing to Use OS Authentication

To enable authentication of an administrative user using the operating system you must do the
following:

1. Create an operating system account for the user.

2. Add the user to the OSDBA or OSOPER operating system defined groups.

3. Ensure that the initialization parameter, REMOTE_LOGIN_PASSWORDFILE, is set to NONE.

This is the default value for this parameter.

Connecting Using OS Authentication

A user can be authenticated, enabled as an administrative user, and connected to a local database
by typing one of the following SQL*Plus commands:

CONNECT / AS SYSDBA
CONNECT / AS SYSOPER

For a remote database connection over a secure connection, the user must also specify the net
service name of the remote database:

CONNECT /@net_service_name AS SYSDBA

CONNECT /@net_service_name AS SYSOPER
See Also:

SQL*Plus User's Guide and Reference for syntax of the CONNECT command

OSDBA and OSOPER

Two special operating system groups control database administrator connections when using OS
authentication. These groups are generically referred to as OSDBA and OSOPER. The groups
are created and assigned specific names as part of the database installation process. The specific
names vary depending upon your operating system and are listed in the following table:
Operating System Group UNIX Windows
OSDBA dba ORA_DBA

OSOPER oper ORA_OPER

The default names assumed by the Oracle Universal Installer can be overridden. How you create
the OSDBA and OSOPER groups is operating system specific.

The following describes how membership in the OSDBA or OSOPER group affects your
connection to Oracle:

 If you are a member of the OSDBA group, and specify AS SYSDBA when you connect to
the database, you are granted the SYSDBA system privilege.
 If you are a member of the OSOPER group, and specify AS SYSOPER when you connect
to the database, you are granted the SYSOPER system privilege.
 If you are not a member of the associated operating system group for SYSDBA or SYSOPER
system privileges, the CONNECT command fails.

See Also:

Your operating system specific Oracle documentation for information about

creating the OSDBA and OSOPER groups

Using Password File Authentication

This section describes how to authenticate an administrative user using password file
authentication.

Preparing to Use Password File Authentication

To enable authentication of an administrative user using password file authentication you must
do the following:

1. Create an operating system account for the user.

2. If not already created, Create the password file using the ORAPWD utility:
3. ORAPWD FILE=filename PASSWORD=password ENTRIES=max_users
4.

3. Set the REMOTE_LOGIN_PASSWORDFILE initialization parameter to EXCLUSIVE.

4. Connect to the database as user SYS (or as another user with the administrative privilege).

5. If the user does not already exist in the database, create the user. Grant the SYSDBA or
SYSOPER system privilege to the user:
 6. GRANT SYSDBA to scott;
7.

This statement adds the user to the password file, thereby enabling connection AS
SYSDBA.

See Also:

"Creating and Maintaining a Password File" for instructions for creating and
maintaining a password file

Connecting Using Password File Authentication

Administrative users can be connected and authenticated to a local or remote database by using
the SQL*Plus CONNECT command. They must connect using their username and password and
with the AS SYSDBA or AS SYSOPER clause. For example, user scott has been granted the
SYSDBA privilege, so he can connect as follows:

CONNECT scott/tiger AS SYSDBA

However, since scott has not been granted the SYSOPER privilege, the following command will
fail:

CONNECT scott/tiger AS SYSOPER

Note:

Operating system authentication takes precedence over password file

authentication. Specifically, if you are a member of the OSDBA or OSOPER
group for the operating system, and you connect as SYSDBA or SYSOPER,
you will be connected with associated administrative privileges regardless of
the username/password that you specify.

If you are not in the OSDBA or OSOPER groups, and you are not in the
password file, then the connection will fail.

See Also:

SQL*Plus User's Guide and Reference for syntax of the CONNECT command

Creating and Maintaining a Password File

You can create a password file using the password file creation utility, ORAPWD. For some
operating systems, you can create this file as part of your standard installation.
This section contains the following topics:

 Using ORAPWD
 Setting REMOTE_LOGIN_ PASSWORDFILE
 Adding Users to a Password File
 Maintaining a Password File

See Also:

Your operating system specific Oracle documentation for information on

using the installer utility to install the password file

Using ORAPWD

When you invoke the password file creation utility without supplying any parameters, you
receive a message indicating the proper use of the command as shown in the following sample
output:

orapwd
Usage: orapwd file=<fname> password=<password> entries=<users>
where
file - name of password file (mand),
password - password for SYS (mand),
entries - maximum number of distinct DBAs and OPERs (opt),
There are no spaces around the equal-to (=) character.

The following command creates a password file named acct.pwd that allows up to 30 privileged
users with different passwords. In this example, the file is initially created with the password
secret for users connecting as SYS.

ORAPWD FILE=acct.pwd PASSWORD=secret ENTRIES=30

Following are descriptions of the parameters in the ORAPWD utility.

FILE

This parameter sets the name of the password file being created. You must specify the full path
name for the file. The contents of this file are encrypted, and the file cannot be read directly. This
parameter is mandatory.

The types of filenames allowed for the password file are operating system specific. Some
operating systems require the password file to be a specific format and located in a specific
directory. Other operating systems allow the use of environment variables to specify the name
and location of the password file. See your operating system specific Oracle documentation for
the names and locations allowed on your platform.

If you are running multiple instances of Oracle using Oracle9i Real Application Clusters, the
environment variable for each instance should point to the same password file.

Caution:

It is critically important to the security of your system that you protect your
password file and the environment variables that identify the location of the
password file. Any user with access to these could potentially compromise
the security of the connection.

PASSWORD

This parameter sets the password for user SYS. If you issue the ALTER USER statement to change
the password for SYS after connecting to the database, both the password stored in the data
dictionary and the password stored in the password file are updated. This parameter is
mandatory.

ENTRIES

This parameter specifies the number of entries that you require the password file to accept. This
number corresponds to the number of distinct users allowed to connect to the database as SYSDBA
or SYSOPER. The actual number of allowable entries can be higher than the number of users
because the ORAPWD utility continues to assign password entries until an operating system block
is filled. For example, if your operating system block size is 512 bytes, it holds four password
entries. The number of password entries allocated is always multiple of four.

Entries can be reused as users are added to and removed from the password file. If you intend to
specify REMOTE_LOGON_PASSWORDFILE=EXCLUSIVE, and to allow the granting of SYSDBA and
SYSOPER privileges to users, this parameter is required.

Caution:

When you exceed the allocated number of password entries, you must create
a new password file. To avoid this necessity, allocate a number of entries that
is larger than you think you will ever need.

Setting REMOTE_LOGIN_ PASSWORDFILE

In addition to creating the password file, you must also set the initialization parameter
REMOTE_LOGIN_PASSWORDFILE to the appropriate value. The values recognized are described as
follows:

Value Description
NONE Setting this parameter to NONE causes Oracle to behave as if the password file does
not exist. That is, no privileged connections are allowed over non-secure
connections. NONE is the default value for this parameter.
EXCLUSIVE An EXCLUSIVE password file can be used with only one database. Only an
EXCLUSIVE file can contain the names of users other than SYS. Using an EXCLUSIVE
password file allows you to grant SYSDBA and SYSOPER system privileges to
individual users and have them connect as themselves.
SHARED A SHARED password file can be used by multiple databases. However, the only user
recognized by a SHARED password file is SYS. You cannot add users to a SHARED
password file. All users needing SYSDBA or SYSOPER system privileges must
connect using the same name, SYS, and password. This option is useful if you have
a single DBA administering multiple databases.

Suggestion:

To achieve the greatest level of security, you should set the

REMOTE_LOGIN_PASSWORDFILE initialization parameter to EXCLUSIVE
immediately after creating the password file.

Adding Users to a Password File

When you grant SYSDBA or SYSOPER privileges to a user, that user's name and privilege
information are added to the password file. If the server does not have an EXCLUSIVE password
file (that is, if the initialization parameter REMOTE_LOGIN_PASSWORDFILE is NONE or SHARED) you
receive an error message if you attempt to grant these privileges.

A user's name remains in the password file only as long as that user has at least one of these two
privileges. If you revoke both of these privileges, the user is removed from the password file.

To Create a Password File and Add New Users to It

1. Follow the instructions for creating a password file as explained in "Using ORAPWD".

2. Set the REMOTE_LOGIN_PASSWORDFILE initialization parameter to EXCLUSIVE.

3. Connect with SYSDBA privileges as shown in the following example:

4. CONNECT SYS/password AS SYSDBA
 5.

4. Start up the instance and create the database if necessary, or mount and open an existing
database.

5. Create users as necessary. Grant SYSDBA or SYSOPER privileges to yourself and other
users as appropriate. See "Granting and Revoking SYSDBA and SYSOPER Privileges".

Granting the SYSDBA or SYSOPER privilege to a user causes their username to be added to the
password file. This enables the user to connect to the database as SYSDBA or SYSOPER by
specifying username and password (instead of using SYS). The use of a password file does not
prevent OS authenticated users from connecting if they meet the criteria for OS authentication.

Granting and Revoking SYSDBA and SYSOPER Privileges

If your server is using an EXCLUSIVE password file, use the GRANT statement to grant the SYSDBA
or SYSOPER system privilege to a user, as shown in the following example:

GRANT SYSDBA TO scott;

Use the REVOKE statement to revoke the SYSDBA or SYSOPER system privilege from a user, as
shown in the following example:

REVOKE SYSDBA FROM scott;

Because SYSDBA and SYSOPER are the most powerful database privileges, the ADMIN OPTION is
not used. Only a user currently connected as SYSDBA (or INTERNAL) can grant or revoke another
user's SYSDBA or SYSOPER system privileges. These privileges cannot be granted to roles, because
roles are only available after database startup. Do not confuse the SYSDBA and SYSOPER database
privileges with operating system roles, which are a completely independent feature.

See Also:

Chapter 25, "Managing User Privileges and Roles" for more information on

system privileges

Viewing Password File Members

Use the V$PWFILE_USERS view to see the users who have been granted SYSDBA or SYSOPER
system privileges for a database. The columns displayed by this view are as follows:

Column Description
USERNAME This column contains the name of the user that is recognized by the password file.
SYSDBA If the value of this column is TRUE, then the user can log on with SYSDBA system
Column Description
privileges.
SYSOPER If the value of this column is TRUE, then the user can log on with SYSOPER system
privileges.

Maintaining a Password File

This section describes how to:

 Expand the number of password file users if the password file becomes full
 Remove the password file
 Avoid changing the state of the password file

Expanding the Number of Password File Users

If you receive the file full error (ORA-1996) when you try to grant SYSDBA or SYSOPER system
privileges to a user, you must create a larger password file and re-grant the privileges to the
users.

To Replace a Password File

1. Note the users who have SYSDBA or SYSOPER privileges by querying the V$PWFILE_USERS
view.

2. Shut down the database.

3. Delete the existing password file.

4. Follow the instructions for creating a new password file using the ORAPWD utility in
"Using ORAPWD". Ensure that the ENTRIES parameter is set to a number larger than you
think you will ever need.

5. Follow the instructions in "Adding Users to a Password File".

Removing a Password File

If you determine that you no longer require a password file to authenticate users, you can delete
the password file and reset the REMOTE_LOGIN_PASSWORDFILE initialization parameter to NONE.
After you remove this file, only those users who can be authenticated by the operating system
can perform database administration operations.

Caution:
 Do not remove or modify the password file if you have a database or instance
mounted using REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE (or SHARED). If
you do, you will be unable to reconnect remotely using the password file.
Even if you replace it, you cannot use the new password file, because the
timestamps and checksums will be wrong.

Changing the Password File State

The password file state is stored in the password file. When you first create a password file, its
default state is SHARED. You can change the state of the password file by setting the initialization
parameter REMOTE_LOGIN_PASSWORDFILE. When you start up an instance, Oracle retrieves the
value of this parameter from the parameter file stored on your client machine. When you mount
the database, Oracle compares the value of this parameter to the value stored in the password
file. If the values do not match, Oracle overwrites the value stored in the file.

Caution:

Use caution to ensure that an EXCLUSIVE password file is not accidentally

changed to SHARED. If you plan to allow instance start up from multiple
clients, each of those clients must have an initialization parameter file, and
the value of the parameter REMOTE_LOGIN_PASSWORDFILE must be the same
in each of these files. Otherwise, the state of the password file could change
depending upon where the instance was started.

Database Administrator Utilities

Several utilities are available to help you maintain the data in your Oracle database. This section
introduces two of these utilities:

 SQL*Loader
 Export and Import

See Also:

Oracle9i Database Utilities

SQL*Loader
SQL*Loader is used both by database administrators and by other users of Oracle. It loads data
from standard operating system files (such as, files in text or C data format) into Oracle database
tables.

Export and Import

The Export and Import utilities enable you to move existing data in Oracle format to and from
Oracle databases. For example, export files can archive database data or move data among
different Oracle databases that run on the same or different operating systems.

Copyright © 2001, 2002 Oracle Corporation. Hom Book Conte Inde Mast Feedb
All Rights Reserved. e List nts x er ack
Inde
x

Skip Headers

Oracle9i Database Administrator's Guide

Release 2 (9.2)
Home Book Contents Index Master Feedback
Part Number A96521-01 List Index

2
Creating an Oracle Database
This chapter discusses the process of creating an Oracle database, and contains the following
topics:

 Considerations Before Creating a Database

 Using the Database Configuration Assistant
 Manually Creating an Oracle Database
 Understanding the CREATE DATABASE Statement
 Troubleshooting Database Creation
 Dropping a Database
 Considerations After Creating a Database
 Initialization Parameters and Database Creation
  Managing Initialization Parameters Using a Server Parameter File

See Also:

o Chapter 3, "Using Oracle-Managed Files" for information about

creating a database whose underlying operating system files are
automatically created and managed by the Oracle database server
o Oracle9i Real Application Clusters Setup and Configuration for
additional information specific to an Oracle Real Application Clusters
environment

Considerations Before Creating a Database

Database creation prepares several operating system files to work together as an Oracle database.
You need only create a database once, regardless of how many datafiles it has or how many
instances access it. Creating a database can also erase information in an existing database and
create a new database with the same name and physical structure.

The following topics can help prepare you for database creation.

 Planning for Database Creation

 Meeting Creation Prerequisites
 Deciding How to Create an Oracle Database

Planning for Database Creation

Prepare to create the database by research and careful planning. The following are some
recommended actions:

For more
Action information...

Part II, "Oracle Server

 Plan the database tables and indexes and estimate the amount of
Processes and Storage
space they will require.
Structure"

Part III, "Schema

Objects"
Oracle9i Database
 Plan the layout of the underlying operating system files that are to
Performance Tuning
comprise your database. Proper distribution of files can improve
Guide and Reference
database performance dramatically by distributing the I/O for
accessing the files. There are several ways to distribute I/O when you
Your Oracle operating
 For more
Action information...

install Oracle and create your database. For example, placing redo log
files on separate disks or striping; placing datafiles to reduce system specific
contention; and controlling density of data (number of rows to a data documentation
block).

Chapter 3, "Using
 Consider using the Oracle Managed Files feature to create and
Oracle-Managed
manage the operating system files that comprise your database
Files"
storage. This feature eases their administration.

"Determining the
 Select the global database name, which is the name and location of
Global Database
the database within the network structure. Create the global
Name"
database name by setting both the DB_NAME and DB_DOMAIN
initialization parameters.

"Initialization
 Familiarize yourself with the initialization parameters that comprise
Parameters and
the initialization parameter file. Become familiar with the concept and
Database Creation"
operation of a server parameter file. A server parameter file allows
you to store and manage your initialization parameters persistently in
a server-side disk file. "What is a Server
Parameter File?"

Oracle9i Database
Reference

 Select the database character set. Oracle9i Database

Globalization
All character data, including data in the data dictionary, is stored Support Guide
in the database character set. You must specify the database
character set when you create the database.

If clients using different character sets will access the database,

then choose a superset that includes all client character sets.
Otherwise, character conversions may be necessary at the cost of
increased overhead and potential data loss.

You can also specify an alternate character set.

 Consider what time zones your database must support. "Specifying the
Database Time Zone
Oracle uses a time zone file, located in the Oracle home File"
 For more
Action information...

directory, as the source of valid time zones. If you determine that Oracle9i Database
you need to use a time zone that is not in the default time zone Globalization
file (timezone.dat), but that is present in the larger time zone Support Guide
file (timezlrg.dat), then you must set the ORA_TZFILE
environment variable to point to the larger file.

 Select the standard database block size. This is specified at database "Specifying Database
creation by the DB_BLOCK_SIZE initialization parameter and cannot Block Sizes"
be changed after the database is created.

The SYSTEM tablespace and most other tablespaces use the

standard block size. Additionally, you can specify up to four
non-standard block sizes when creating tablespaces.
Chapter 13,
 Use an undo tablespace to manage your undo records, rather than
"Managing Undo
rollback segments.
Space"

Chapter 7, "Managing
 Develop a backup and recovery strategy to protect the database from
the Online Redo Log"
failure. It is important to protect the control file by multiplexing, to
choose the appropriate backup mode, and to manage the online and
archived redo logs.
Chapter 8, "Managing
Archived Redo Logs"

Chapter 6, "Managing
Control Files"

Oracle9i Backup and

Recovery Concepts
Chapter 4, "Starting
 Familiarize yourself with the principles and options of starting up and
Up and Shutting
shutting down an instance and mounting and opening a database.
Down"

Meeting Creation Prerequisites

To create a new database, the following prerequisites must be met:

 The desired Oracle software is installed. This includes setting up various environment variables
unique to your operating system and establishing the directory structure for software and
database files.
  You have the operating system privileges associated with a fully operational database
administrator. You must be specially authenticated by your operating system or through a
password file, allowing you to start up and shut down an instance before the database is created
or opened. This authentication is discussed in "Database Administrator Authentication".
 There is sufficient memory available to start the Oracle instance.
 There is sufficient disk storage space for the planned database on the computer that executes
Oracle.

All of these are discussed in the Oracle installation guide specific to your operating system.
Additionally, the Oracle Universal Installer will guide you through your installation and provide
help in setting up environment variables, directory structure, and authorizations.

Deciding How to Create an Oracle Database

Creating a database includes the following operations:

 Creating information structures, including the data dictionary, that Oracle requires to access and
use the database
 Creating and initializing the control files and redo log files for the database
 Creating new datafiles or erasing data that existed in previous datafiles

You use the CREATE DATABASE statement to perform these operations, but other actions are
necessary before you have an operational database. A few of these actions are creating users and
temporary tablespaces, building views of the data dictionary tables, and installing Oracle built-in
packages. This is why the database creation process involves executing prepared scripts. But,
you do not necessarily have to prepare this script yourself.

You have the following options for creating your new Oracle database:

 Use the Database Configuration Assistant (DBCA).

DBCA can be launched by the Oracle Universal Installer, depending upon the type of
install that you select, and provides a graphical user interface (GUI) that guides you
through the creation of a database. You can chose not to use DBCA, or you can launch it
as a standalone tool at any time in the future to create a database. See "Using the
Database Configuration Assistant".

 Create the database manually from a script.

If you already have existing scripts for creating your database, you can still create your
database manually. However, consider editing your existing script to take advantage of
new Oracle features. Oracle provides a sample database creation script and a sample
initialization parameter file with the database software files it distributes, both of which
can be edited to suit your needs. See "Manually Creating an Oracle Database".
  Upgrade an existing database.

If you are already using a previous release of Oracle, database creation is required only if
you want an entirely new database. You can upgrade your existing Oracle database and
use it with the new release of the Oracle software. Database upgrades are not discussed in
this book. The Oracle9i Database Migration manual contains information about
upgrading an existing Oracle database.

Using the Database Configuration Assistant

The Database Configuration Assistant (DBCA) an Oracle supplied tool that enables you to create
an Oracle database, configure database options for an existing Oracle database, delete an Oracle
database, or manage database templates. DBCA is launched automatically by the Oracle
Universal Installer, but it can be invoked standalone from the Windows operating system start
menu (under Configuration Assistants) or by entering the following on the UNIX command line:

dbca

DBCA can be run in three modes:

Mode Description

Interactive This is the default mode if you do not specify any parameters. This mode presents a
wizard like GUI interface and provides complete DBCA functionality. Online help
is provided.
Progress This mode is typically used by other tools to create a database. For example, it is
Only used by the Oracle Universal Installer, the Enterprise Manager Configuration
Assistant, and the Oracle Internet Directory Configuration Assistant. In this mode,
only a progress bar is displayed, and it is used when creating databases and
templates.
Silent This mode has only a command-line interface where parameters are specified.
There is no other user interaction. Informational, error, and warning message are
written to a log file. You specify the template of your choice, for customization or
for the creation of a database.

DBCA can be used to create single instance databases, or it can be used to create or add
instances in an Oracle Real Application Clusters environment.

This section primarily describes the use of DBCA in interactive mode. It contains the following
topics:

 Advantages of Using DBCA

 Creating a Database Using DBCA
  Configuring Database Options
 Deleting a Database Using DBCA
 Managing DBCA Templates
 Using DBCA Silent Mode

Advantages of Using DBCA

These are a few of the advantages of using DBCA:

 You can use its wizards to guide you through a selection of options providing an easy means of
creating and tailoring your database. It allows you to provide varying levels of detail. You can
provide a minimum of input and allow Oracle to make decisions for you, eliminating the need to
spend time deciding how best to set parameters or structure the database. Optionally, it allows
you to be very specific about parameter settings and file allocations.
 It builds efficient and effective databases that take advantage of Oracle's new features.
 It uses Optimal Flexible Architecture (OFA), whereby database files and administrative files,
including initialization files, follow standard naming and placement practices.

Creating a Database Using DBCA

DBCA enables you to create a database from predefined templates provided by Oracle or from
templates that you or others have created. A template is a description of a database. Templates
are described in more detail in "Managing DBCA Templates".

Selecting the Template

DBCA displays the templates that are available, which includes templates that Oracle ships with
the DBCA product. These templates are described in "DBCA Templates Provided by Oracle". If
you or others have created templates, those will be displayed also. You select the appropriate
template for the database that you want to create. Clicking the "Show Details..." button displays
specific information about the database defined by a template.

Including Datafiles

When you select a template, you also specify whether the database definition is to include
datafiles. This determines whether you use a seed template (includes datafiles), or a non-seed
template (does not include datafiles), to create your database.

Specifying Global Database Name and Database Features

The next page that DBCA displays enables you provide a global database name and SID.

Specifying Database Features

The "Database Features" page is presented only when you select a non-seed template. It enables
you to include optional database features.

The following is a representative list of Oracle features that you can install in your database.
Some of the listed options might already be included depending upon the database template that
you selected. Those options that are already installed are noted as such (grayed out).

 Oracle Spatial
 Oracle Ultra Search
 Oracle Label Security
 Oracle Data Mining
 Oracle OLAP Services
 Sample Schemas

You can also display a list of standard database features. These are features that Oracle
recommends you always install, but you have the option of excluding them. These include:

 Oracle JVM
 Oracle Text
 Oracle interMedia
 XDB Protocol

Specifying Mode, Initialization Parameters, and Datafiles

The next pages enable you to further define your database. You specify mode (dedicated server
of shared server), set initialization parameters, and specify datafile locations. Oracle can
determine specific values for you based upon your description of the database you are trying to
create. For example, Oracle can choose appropriate settings for SGA memory sizing parameters
depending upon whether you select a typical or custom database.

Completing Database Creation

After you have completed the specification of the parameters that define your database you can:

 Create the database now

 Save the description as a database template
 Generate database creation scripts

If you choose to generate scripts, you can use them to create the database later without using
DBCA, or you can use them as a checklist

Configuring Database Options

When you elect to configure database options, you can add Oracle options that have not
previously been configured for use with your database. This provides you the opportunity to add
options and features that you did not include when you created the database. These options are
discussed in "Specifying Database Features".

Deleting a Database Using DBCA

DBCA enables you to delete a database. When you do so, you delete the database instance and
its control file(s), redo log files, and datafiles. Any server parameter file (SPFILE) or
initialization parameter file used by the database is also deleted.

Managing DBCA Templates

DBCA templates are XML files that contain information required to create a database. Templates
are used in DBCA to create new databases and make clones of existing databases. The
information in templates includes database options, initialization parameters, and storage
attributes (for datafiles, tablespaces, control files and redo logs).

Templates can be used just like scripts, and they can be used in silent mode. But they are more
powerful than scripts, because you have the option of cloning a database. This saves time in
database creation, because copying an already created seed database's files to the correct
locations takes less time than creating them as new.

Templates are stored in the following directory:

$ORACLE_HOME/assistants/dbca/templates

Advantages of Using Templates

The following are some of the advantages of using templates:

 They save you time. If you use a template you do not have to define the database.
 By creating a template containing your database settings, you can easily create a duplicate
database without specifying parameters twice.
 They are easily edited. You can quickly change database options from the template settings.
 Templates are easy to share. They can be copied from one machine to another.

Types of Templates

There are two types of templates:

 Seed templates
 Non-seed templates

The characteristics of each are shown in the following table:

 File Include
Type Extension Datafiles? Database Structure

Seed .dbc Yes This type of template contains both the structure and the
physical datafiles of an existing (seed) database. When you
select a seed template, database creation is faster because the
physical files and schema of the database have already been
created. Your database starts as a copy of the seed database,
rather than having to be built.

You can change only the following:

 Name of the database

 Destination of the datafiles
 Number control files
 Number redo log groups
 Initialization parameters

Other changes can be made after database creation using

custom scripts that can be invoked by DBCA, command line
SQL statements, or the Oracle Enterprise Manager.

The datafiles and redo logs for the seed database are stored in
zipped format in another file with a .dfj extension. Usually
the corresponding .dfj file of a .dbc file has the same file
name, but this is not a requirement since the corresponding
.dfj file's location is stored in the .dbc file.

Non- .dbt No This type of template is used to create a new database from
seed scratch. It contains the characteristics of the database to be
created. Seed templates are more flexible than their seed
counterparts because all datafiles and redo logs are created to
your specification (not copied), and names, sizes, and other
attributes can be changed as required.

DBCA Templates Provided by Oracle

Oracle provides templates for the following environments:

Environment Description of Environment

DSS (Data Users perform numerous, complex queries that process large volumes
Warehousing) of data. Response time, accuracy, and availability are key issues.
Environment Description of Environment

These queries (typically read-only) range from a simple fetch of a few

records to numerous complex queries that sort thousands of records
from many different tables.
OLTP (Online Many concurrent users performing numerous transactions requiring
Transaction rapid access to data. Availability, speed, concurrence, and
Processing) recoverability are key issues.

Transactions consist of reading (SELECT statements), writing (INSERT

and UPDATE statements), and deleting (DELETE statements) data in
database tables.
General Purpose This template creates a database designed for general purpose usage. It
combines features of both the DSS and OLTP database templates.
New Database This template allows you maximum flexibility in defining a database.

Creating Templates Using DBCA

The "Template Management" page provides you with three options that enable you to modify
existing templates or to create your own custom templates. Your choices are:

 From an existing template

Using an existing template, you can create a new template based on the pre-defined
template settings. You can add or change any template settings such as initialization
parameters, storage parameters, or use custom scripts.

 From an existing database (structure only)

You can create a new template that contains structural information about an existing
database, including database options, tablespaces, datafiles, and initialization parameters
specified in the source database. User defined schema and their data will not be part of
the created template. The source database can be either local or remote.

 From an existing database (structure as well as data--a seed database)

You can create a new template that has both the structural information and physical
datafiles of an existing database. Databases created using such a template are identical to
the source database. User defined schema and their data will be part of the created
template. The source database must be local.

Oracle saves templates as XML files.

While creating templates from existing databases, you can optionally choose to translate file
paths into OFA (Optimal Flexible Architecture) or maintain existing file paths. OFA is
recommended if the machine on which you plan to create the database using the template has a
different directory structure. Non-OFA can be used if the target machine has a similar directory
structure.

Deleting DBCA Templates

The "Template Management" page also allows you to delete existing templates.

Using DBCA Silent Mode

Silent mode does not have any user interface (other than what you initially input on the
command line) or user interaction. It outputs all messages including information, errors, and
warnings into a log file.

From the command line enter the following command to see all of the DBCA options that are
available when using silent mode:

dbca -help

The following sections contain examples that illustrate the use of silent mode.

DBCA Silent Mode Example 1: Creating a Clone Database

To create a clone database, enter the following on the command line:

% dbca -silent -createDatabase -templateName Transaction_Processing.dbc

-gdbname ora9i -sid ora9i -datafileJarLocation
/private/oracle9i/ora9i/assistants/dbca/templates -datafileDestination
/private/oracle9i/ora9i/oradata -responseFile NO_VALUE
-characterset WE8ISO8859P1

DBCA Silent Mode Example 2: Creating a Seed Template

To create a seed template, enter the following on the command line:

% dbca -silent -createCloneTemplate -sourceDB ora9I -sysDBAUserName

sys -sysDBAPassword change_on_install -templateName copy_of_ora9i.dbc
-datafileJarLocation /private/oracle/ora9i/assistants/dbca/templates

Manually Creating an Oracle Database

This section presents the steps involved when you create a database manually. These steps
should be followed in the order presented. You will previously have created your environment
for creating your Oracle database, including most operating system dependent environmental
variables, as part of the Oracle software installation process.

Step 1: Decide on Your Instance Identifier (SID)

Step 2: Establish the Database Administrator Authentication Method

Step 3: Create the Initialization Parameter File

Step 4: Connect to the Instance

Step 5: Start the Instance.

Step 6: Issue the CREATE DATABASE Statement

Step 7: Create Additional Tablespaces

Step 8: Run Scripts to Build Data Dictionary Views

Step 9: Run Scripts to Install Additional Options (Optional)

Step 10: Create a Server Parameter File (Recommended)

Step 11: Back Up the Database.

The examples shown in these steps are to create the database mynewdb.

Note:

At this point, you may not be familiar with all of the initialization parameters
and database structures discussed in this section. These steps contain many
cross references to other parts of this book to allow you to learn about and
understand these parameters and structures.

Step 1: Decide on Your Instance Identifier (SID)

Decide on a unique Oracle system identifier (SID) for your instance and set the ORACLE_SID
environment variable accordingly. This identifier is used to avoid confusion with other Oracle
instances that you may create later and run concurrently on your system.

The following example sets the SID for the instance and database we are about to create:
% setenv ORACLE_SID mynewdb

The value of the DB_NAME initialization parameter should match the SID setting.

Step 2: Establish the Database Administrator Authentication Method

You must be authenticated and granted appropriate system privileges in order to create a
database. You can use the password file or operating system authentication method. Database
administrator authentication and authorization is discussed in the following sections of this book:

 "Database Administrator Security and Privileges"

 "Database Administrator Authentication"
 "Creating and Maintaining a Password File"

Step 3: Create the Initialization Parameter File

The instance (System Global Area and background processes) for any Oracle database is started
using an initialization parameter file. One way of getting started on your initialization parameter
file is to edit a copy of the sample initialization parameter file that Oracle provides on the
distribution media, or the sample presented in this book.

For ease of operation, store your initialization parameter file in Oracle's default location, using
the default name. That way, when you start your database, it is not necessary to specify the
PFILE parameter because Oracle automatically looks in the default location for the initialization
parameter file.

Default parameter file locations are shown in the following table:

Platform Default Name Default Location

UNIX init$ORACLE_SID.ora $ORACLE_HOME/dbs

For example, the initialization For example, the initialization parameter file for
parameter file for the mynewdb the mynewdb database is stored in the following
database is named: location:

initmynewdb.ora /vobs/oracle/dbs/initmynewdb.ora

Windows init$ORACLE_SID.ora $ORACLE_HOME\database

The following is the initialization parameter file used to create the mynewdb database.

Sample Initialization Parameter File

# Cache and I/O

DB_BLOCK_SIZE=4096
DB_CACHE_SIZE=20971520

# Cursors and Library Cache

CURSOR_SHARING=SIMILAR
OPEN_CURSORS=300

# Diagnostics and Statistics

BACKGROUND_DUMP_DEST=/vobs/oracle/admin/mynewdb/bdump
CORE_DUMP_DEST=/vobs/oracle/admin/mynewdb/cdump
TIMED_STATISTICS=TRUE
USER_DUMP_DEST=/vobs/oracle/admin/mynewdb/udump

# Control File Configuration

CONTROL_FILES=("/vobs/oracle/oradata/mynewdb/control01.ctl",
"/vobs/oracle/oradata/mynewdb/control02.ctl",
"/vobs/oracle/oradata/mynewdb/control03.ctl")

# Archive
LOG_ARCHIVE_DEST_1='LOCATION=/vobs/oracle/oradata/mynewdb/archive'
LOG_ARCHIVE_FORMAT=%t_%s.dbf
LOG_ARCHIVE_START=TRUE

# Shared Server
# Uncomment and use first DISPATCHES parameter below when your listener is
# configured for SSL
# (listener.ora and sqlnet.ora)
# DISPATCHERS = "(PROTOCOL=TCPS)(SER=MODOSE)",
# "(PROTOCOL=TCPS)(PRE=oracle.aurora.server.SGiopServer)"
DISPATCHERS="(PROTOCOL=TCP)(SER=MODOSE)",
"(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)",
(PROTOCOL=TCP)

# Miscellaneous
COMPATIBLE=9.2.0
DB_NAME=mynewdb

# Distributed, Replication and Snapshot

DB_DOMAIN=us.oracle.com
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

# Network Registration
INSTANCE_NAME=mynewdb

# Pools
JAVA_POOL_SIZE=31457280
LARGE_POOL_SIZE=1048576
SHARED_POOL_SIZE=52428800

# Processes and Sessions

PROCESSES=150

# Redo Log and Recovery

FAST_START_MTTR_TARGET=300

# Resource Manager
RESOURCE_MANAGER_PLAN=SYSTEM_PLAN
# Sort, Hash Joins, Bitmap Indexes
SORT_AREA_SIZE=524288

# Automatic Undo Management

UNDO_MANAGEMENT=AUTO
UNDO_TABLESPACE=undotbs
See Also:

 "Initialization Parameters and Database Creation" for more information on

some of these parameters and other initialization parameters that you
decide to include

Step 4: Connect to the Instance

Start SQL*Plus and connect to your Oracle instance AS SYSDBA.

$ SQLPLUS /nolog
CONNECT SYS/password AS SYSDBA

Step 5: Start the Instance.

Start an instance without mounting a database. Typically, you do this only during database
creation or while performing maintenance on the database. Use the STARTUP command with the
NOMOUNT option. In this example, because the initialization parameter file is stored in the default
location, you are not required to specify the PFILE clause:

STARTUP NOMOUNT

At this point, there is no database. Only the SGA is created and background processes are started
in preparation for the creation of a new database.

See Also:

 "Managing Initialization Parameters Using a Server Parameter File"

 Chapter 4, "Starting Up and Shutting Down" to learn how to use the
STARTUP command

Step 6: Issue the CREATE DATABASE Statement

To create the new database, use the CREATE DATABASE statement. The following statement
creates database mynewdb:

CREATE DATABASE mynewdb

USER SYS IDENTIFIED BY pz6r58
 USER SYSTEM IDENTIFIED BY y1tz5p
LOGFILE GROUP 1 ('/vobs/oracle/oradata/mynewdb/redo01.log') SIZE 100M,
GROUP 2 ('/vobs/oracle/oradata/mynewdb/redo02.log') SIZE 100M,
GROUP 3 ('/vobs/oracle/oradata/mynewdb/redo03.log') SIZE 100M
MAXLOGFILES 5
MAXLOGMEMBERS 5
MAXLOGHISTORY 1
MAXDATAFILES 100
MAXINSTANCES 1
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
DATAFILE '/vobs/oracle/oradata/mynewdb/system01.dbf' SIZE 325M REUSE
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE tempts1
DATAFILE '/vobs/oracle/oradata/mynewdb/temp01.dbf'
SIZE 20M REUSE
UNDO TABLESPACE undotbs
DATAFILE '/vobs/oracle/oradata/mynewdb/undotbs01.dbf'
SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED;

A database is created with the following characteristics:

 The database is named mynewdb. Its global database name is mynewdb.us.oracle.com. See
"DB_NAME Initialization Parameter" and "DB_DOMAIN Initialization Parameter".
 Three control files are created as specified by the CONTROL_FILES initialization parameter. See
"Specifying Control Files".
 The password for user SYS is pz6r58 and the password for SYSTEM is y1tz5p. These two
clauses that specify the passwords for SYS and SYSTEM are not mandatory in this release of
Oracle9i. However, if you specify either clause, you must specify both clauses. For further
information about the use of these clauses, see "Protecting Your Database: Specifying
Passwords for Users SYS and SYSTEM".
 The new database has three online redo log files as specified in the LOGFILE clause.
MAXLOGFILES, MAXLOGMEMBERS, and MAXLOGHISTORY define limits for the redo log. See
Chapter 7, "Managing the Online Redo Log".
 MAXDATAFILES specifies the maximum number of datafiles that can be open in the database.
This number affects the initial sizing of the control file.

Note:

You can set several limits during database creation. Some of these limits are
also subject to superseding limits of the operating system and can be affected
by them. For example, if you set MAXDATAFILES, Oracle allocates enough
space in the control file to store MAXDATAFILES filenames, even if the
database has only one datafile initially. However, because the maximum
control file size is limited and operating system dependent, you might not be
 able to set all CREATE DATABASE parameters at their theoretical maximums.

For more information about setting limits during database creation, see the
Oracle9i SQL Reference and your operating system specific Oracle
documentation.

 MAXINSTANCES specifies that only one instance can have this database mounted and open.
 The US7ASCII character set is used to store data in this database.
 The AL16UTF16 character set is specified as the NATIONAL CHARACRTER SET, used to store
data in columns specifically defined as NCHAR, NCLOB, or NVARCHAR2.
 The SYSTEM tablespace, consisting of the operating system file
/vobs/oracle/oradata/mynewdb/system01.dbf, is created as specified by the
DATAFILE clause. If the file already exists, it is overwritten.
 The SYSTEM tablespace is a locally managed tablespace. See "Creating a Locally Managed
SYSTEM Tablespace".
 The DEFAULT_TEMPORARY_TABLESPACE clause creates and names a default temporary
tablespace for this database. See "Creating a Default Temporary Tablespace".
 The UNDO_TABLESPACE clause creates and names an undo tablespace to be used to store undo
records for this database if you have specified UNDO_MANAGEMENT=AUTO in the initialization
parameter file. See "Using Automatic Undo Management: Creating an Undo Tablespace".
 Because the ARCHIVELOG clause is not specified in this CREATE DATABASE statement, redo log
files will not initially be archived. This is customary during database creation and an ALTER
DATABASE statement can be used later to switch to ARCHIVELOG mode. The initialization
parameters in the initialization parameter file for mynewdb relating to archiving are
LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_FORMAT, and LOG_ARCHIVE_START. See Chapter 8,
"Managing Archived Redo Logs".

See Also:

o "Understanding the CREATE DATABASE Statement"

o Oracle9i SQL Reference for more information about specifying the
clauses and parameter values for the CREATE DATABASE statement

Step 7: Create Additional Tablespaces

To make the database functional, you need to create additional files and tablespaces for users.
The following sample script creates some additional tablespaces:

CONNECT SYS/password AS SYSDBA

-- create a user tablespace to be assigned as the default tablespace for users
CREATE TABLESPACE users LOGGING
DATAFILE '/vobs/oracle/oradata/mynewdb/users01.dbf'
SIZE 25M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL;
-- create a tablespace for indexes, separate from user tablespace
CREATE TABLESPACE indx LOGGING
DATAFILE '/vobs/oracle/oradata/mynewdb/indx01.dbf'
SIZE 25M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL;
EXIT

For information about creating tablespaces, see Chapter 11, "Managing Tablespaces".

Step 8: Run Scripts to Build Data Dictionary Views

Run the scripts necessary to build views, synonyms, and PL/SQL packages:

CONNECT SYS/password AS SYSDBA

@/vobs/oracle/rdbms/admin/catalog.sql
@/vobs/oracle/rdbms/admin/catproc.sql
EXIT

The following table contains descriptions of the scripts:

Script Description

CATALOG.SQL Creates the views of the data dictionary tables, the dynamic performance views,
and public synonyms for many of the views. Grants PUBLIC access to the
synonyms.
CATPROC.SQL Runs all scripts required for or used with PL/SQL.

You may want to run other scripts. The scripts that you run are determined by the features and
options you choose to use or install. Many of the scripts available to you are described in the
Oracle9i Database Reference.

See your Oracle installation guide for your operating system for the location of these scripts.

Step 9: Run Scripts to Install Additional Options (Optional)

If you plan to install other Oracle products to work with this database, see the installation
instructions for those products. Some products require you to create additional data dictionary
tables. Usually, command files are provided to create and load these tables into the database's
data dictionary.
See your Oracle documentation for the specific products that you plan to install for installation
and administration instructions.

Step 10: Create a Server Parameter File (Recommended)

Oracle recommends you create a server parameter file as a dynamic means of maintaining
initialization parameters. The server parameter file is discussed in "Managing Initialization
Parameters Using a Server Parameter File".

The following script creates a server parameter file from the text initialization parameter file and
writes it to the default location. The instance is shut down, then restarted using the server
parameter file (in the default location).

CONNECT SYS/password AS SYSDBA

-- create the server parameter file
CREATE SPFILE='/vobs/oracle/dbs/spfilemynewdb.ora' FROM
PFILE='/vobs/oracle/admin/mynewdb/scripts/init.ora';
SHUTDOWN
-- this time you will start up using the server parameter file
CONNECT SYS/password AS SYSDBA
STARTUP
EXIT

Step 11: Back Up the Database.

You should make a full backup of the database to ensure that you have a complete set of files
from which to recover if a media failure occurs. For information on backing up a database, see
Oracle9i Backup and Recovery Concepts.

Understanding the CREATE DATABASE Statement

When you execute a CREATE DATABASE statement, Oracle performs (at least) the following
operations. The actual operations performed are in large part determined by the clauses that you
specify in the CREATE DATABASE statement or initialization parameters that you have set.

 Creates the datafiles for the database

 Creates the control files for the database
 Creates the redo log files for the database and establishes the ARCHIVELOG mode.
 Creates the SYSTEM tablespace and the SYSTEM rollback segment
 Creates the data dictionary
 Sets the character set that stores data in the database
 Sets the database time zone
 Mounts and opens the database for use
This section discusses several of the clauses of the CREATE DATABASE statement. It expands upon
some of the clauses discussed in "Step 6: Issue the CREATE DATABASE Statement" and
introduces additional ones.

The following topics are contained in this section:

 Protecting Your Database: Specifying Passwords for Users SYS and SYSTEM
 Clauses that Simplify Database Creation and Management
 Creating a Locally Managed SYSTEM Tablespace
 Specifying the Database Time Zone and Time Zone File
 Specifying FORCE LOGGING Mode

Protecting Your Database: Specifying Passwords for Users SYS and

SYSTEM

The clauses of the CREATE DATABASE statement used for specifying the passwords for users SYS
and SYSTEM are:

 USER SYS IDENTIFIED BY password

 USER SYSTEM IDENTIFIED BY password

If not specified, these users are assigned the default passwords change_on_install and
manager, respectively. A record is written to the alert file indicating that the default passwords
were used. To protect your database, you should change these passwords using the ALTER USER
statement after database creation.

While these clauses are optional in this Oracle release, Oracle strongly recommends that you
specify them. The default passwords are commonly known, and if you neglect to change them
later, you leave yourself vulnerable to attack by malicious users.

See Also:

"Some Security Considerations"

Clauses that Simplify Database Creation and Management

In addition to using the Database Configuration Assistant for creating your database, Oracle9i
offers you other options that can simplify the creation, operation, and management of your
database. These options, and their associated CREATE DATABASE clauses, are discussed briefly in
the following sections, and in more detail in later sections of this book:

 Using Automatic Undo Management: Creating an Undo Tablespace

 Creating a Default Temporary Tablespace
  Using Oracle-Managed Files

Using Automatic Undo Management: Creating an Undo Tablespace

Oracle recommends that instead of using rollback segments in your database, you use an undo
tablespace. This requires the use of a different set of initialization parameters, and optionally, the
inclusion of the UNDO TABLESPACE clause in your CREATE DATABASE statement.

You must include the following initialization parameter if you want to operate your database in
automatic undo management mode:

UNDO_MANAGEMENT=AUTO

In this mode, rollback information, referred to as undo, is stored in an undo tablespace rather
than rollback segments and is managed by Oracle. If you want to create and name a specific
tablespace for the undo tablespace, you can include the UNDO TABLESPACE clause at database
creation time. If you omit this clause, and automatic undo management is specified, Oracle
creates a default undo tablespace named SYS_UNDOTBS.

See Also:

 "Specifying the Method of Undo Space Management"

 Chapter 13, "Managing Undo Space" for information about the creation
and use of undo tablespaces

Creating a Default Temporary Tablespace

The DEFAULT TEMPORARY TABLESPACE clause of the CREATE DATABASE statement specifies that
a temporary tablespace is to be created at database creation time. This tablespace is used as the
default temporary tablespace for users who are not otherwise assigned a temporary tablespace.

Users can be explicitly assigned a default temporary tablespace in the CREATE USER statement.
But, if no temporary tablespace is specified, they default to using the SYSTEM tablespace. It is not
good practice to store temporary data in the SYSTEM tablespace. To avoid this problem, and to
avoid the need to assign every user a default temporary tablespace at CREATE USER time, you can
use the DEFAULT TEMPORARY TABLESPACE clause of CREATE DATABASE.

If you decide later to change the default temporary tablespace, or to create an initial one after
database creation, you can do so. You do this by creating a new temporary tablespace (CREATE
TEMPORARY TABLESPACE), then assign it as the temporary tablespace using the ALTER DATABASE
DEFAULT TEMPORARY TABLESPACE statement. Users will automatically be switched (or assigned)
to the new temporary default tablespace.

The following statement assigns a new default temporary tablespace:

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE tempts2;

The new default temporary tablespace must be an existing temporary tablespace. When using a
locally managed SYSTEM tablespace, the new default temporary tablespace must also be locally
managed.

You cannot drop a default temporary tablespace, but you can assign a new default temporary
tablespace, then drop the former one. You are not allowed to change a default temporary
tablespace to a permanent tablespace, nor can you take a default temporary tablespace offline.

Users can obtain the name of the current default temporary tablespace using the
DATABASE_PROPERTIES view. The PROPERTY_NAME column contains the value
"DEFAULT_TEMP_TABLESPACE" and the PROPERTY_VALUE column contains the default temporary
tablespace name.

See Also:

 Oracle9i SQL Reference for the syntax of the DEFAULT TEMPORARY

TABLESPACE clause of CREATE DATABASE and ALTER DATABASE

 "Temporary Tablespaces" for information about creating and using

temporary tablespaces

Using Oracle-Managed Files

You can minimize the number of clauses and parameters that you specify in your CREATE
DATABASE statement by using the Oracle Managed Files feature.

If you include the DB_CREATE_FILE_DEST or DB_CREATE_ONLINE_LOG_DEST_n initialization

parameters in your initialization parameter file, you enable Oracle to create and manage the
underlying operating system files of your database. Oracle will automatically create and manage
the operating system files for the following database structures, dependent upon the initialization
parameters you specify and how you specify clauses in your CREATE DATABASE statement:

 Tablespaces
 Temporary tablespaces
 Control files
 Online redo log files

Briefly, this is how the Oracle Managed Files feature works, using the following CREATE
DATABASE statement as an example:

CREATE DATABASE rbdb1

USER SYS IDENTIFIED BY pz6r58
 USER SYSTEM IDENTIFIED BY y1tz5p
UNDO TABLESPACE undotbs
DEFAULT TEMPORARY TABLESPACE tempts1;

 No DATAFILE clause is specified, therefore Oracle creates an Oracle-managed datafile for the
SYSTEM tablespace.
 No LOGFILE clauses are included, therefore Oracle creates two online redo log file groups that
are Oracle managed.
 No DATAFILE subclause is specified for the UNDO TABLESPACE clause, therefore Oracle creates
an Oracle-managed datafile for the undo tablespace.
 No TEMPFILE subclause is specified for the DEFAULT TEMPORARY TABLESPACE clause,
therefore Oracle creates an Oracle-managed tempfile.
 Additionally, if no CONTROL_FILES initialization parameter is specified in the initialization
parameter file, Oracle creates an Oracle-managed control file.
 If using a server parameter file (see "Managing Initialization Parameters Using a Server
Parameter File") the initialization parameters are set accordingly and automatically.

See Also:

Chapter 3, "Using Oracle-Managed Files" for a complete description of the

Oracle Managed Files feature and how to use it

Creating a Locally Managed SYSTEM Tablespace

When you specify the EXTENT MANAGEMENT LOCAL clause in the CREATE DATABASE statement,
you cause Oracle to create a locally managed SYSTEM tablespace wherein Oracle determines
extent sizes. The COMPATIBLE initialization parameter must be set to 9.2 or higher for this
statement to be successful. If you do not specify the EXTENT MANAGEMENT LOCAL clause, the
default is to create a dictionary-managed SYSTEM tablespace.

Locally managed tablespaces provide better performance and greater ease of management over
dictionary-managed tablespaces. A locally managed SYSTEM tablespace is created AUTOALLOCATE
by default, meaning that it is system managed with extent sizes determined and controlled by
Oracle. You may notice an increase in the initial size of objects created in a locally managed
SYSTEM tablespace because of the autoallocate policy. It is not possible to create a locally
managed SYSTEM tablespace and specify UNIFORM extent size.

When you create your database with a locally managed SYSTEM tablespace, ensure the following
conditions are met:

 There must be a default temporary tablespace, and that tablespace cannot be the SYSTEM
tablespace.
  You must not create rollback segments in dictionary-managed tablespaces. Attempting to create
a rollback segment in a dictionary-managed tablespace will fail if the SYSTEM tablespace is
locally managed.

To meet the first condition, you can specify the DEFAULT TEMPORARY TABLESPACE clause in the
CREATE DATABASE statement, or you cannot include the clause and allow Oracle to create the
tablespace for you using a default name and in a default location.

For fulfilling the second condition, Oracle recommends that instead of using rollback segments
to manage the database's undo records, that you use automatic undo management. You can
include the UNDO TABLESPACE clause in the CREATE DATABASE statement to create a specific
undo tablespace, or if you do not include the clause, Oracle creates a locally managed undo
tablespace for you using the default name and in a default location.

Note:

When your SYSTEM tablespace is locally managed, there are restrictions on

other tablespaces in the database. These restrictions are:

 You cannot create any dictionary-managed tablespaces in the database.

 You cannot migrate a locally managed tablespace to a dictionary-managed
tablespace.
 You can transport dictionary-managed tablespaces into the database, but
you are not allowed to alter them to read-write.
 Preexisting dictionary-managed tables