Академический Документы
Профессиональный Документы
Культура Документы
Since managing the database is such an important and responsible task, being an
administrator is not always easy. The individual in addition to being able to administer
the database should have certain personal strengths such as being proactive, organized
and being able to handle well under stressful situations. A DBA should also be able to
communicate well. To effectively manage enterprise databases, a DBA must understand
business reasons for storing the data in the database and the technical details of how the
data is structured and stored.
Given below is a list of tasks which the administrator may need to do:
• Install, Upgrade and configure the Oracle Database server based on the
organizational requirements.
• Since systems are not static, the DBA must be able predict growth based on
application and data usage patterns.
• Understand the logical and physical structure of the particular database.
• Ensuring the database is available to the users with minimum or no downtime, by
taking backups regularly and creating well-tested recovery strategies.
• Helping and creating primary objects such as tables, views and indexes based on
the needs of the application developments.
• The DBA must be able to design a database that holds accurate and valid data at
all times.
• Managing users and ensuring the database is accessible to only valid users.
Granting the users the privileges they need to perform various actions in the
database.
• Monitoring and optimizing the performance of the database.
• The DBA must be able to design, debug, implement and maintain stored
procedures, triggers and user defined functions that are stored.
• Security is becoming increasing important with the need for data to be available
across the internet. The DBA should ensure that the data is secure and implement
rigorous security schemes for the databases to ensure that only authorized users
have access to the data.
The list above broadly covers various aspects of the administrators work responsibilities.
By now you should have gathered that the responsibilities of an administrator are not
easy. However, companies like Oracle Corporation are making this job easier with each
new release. Oracle Database 10g is particularly popular for its introduction of new
automated and intelligent features that remove and simplify some the burden on the
DBA.
The Oracle Architecture
An analogy could be a service technician trying to fix a car that is having a problem. The
technician wouldn't know where to start unless he knows very clearly what the various
components of the car are, what they do, how they function and how they interact with
each other. This is absolutely essential before he can start to find a solution to the
problem. The same goes for a database. If a user comes to an administrator with a certain
problem, the DBA cannot come up with the right solution unless he knows everything he
possibly can about the database.
The Oracle server consists of physical files and memory components. The Oracle 10g
Database product is made up three main components namely:
• The Oracle Server – This is the Oracle database management system that is able to
store, manage and manipulate data. It consists of all the files, structures, processes
that form Oracle Database 10g. The Oracle server is made up of an Oracle instance
and an Oracle database.
• The Oracle Instance –Consists of the memory components of Oracle and various
background processes.
• The Oracle database – This is the centralized repository where the data is stored. It
has a physical structure that is visible to the Operating system made up of operating
system files and a logical structure that is recognized only the Oracle Server.
The figure 3.1 displays the architecture of the Oracle Database 10g. It is broadly divided
into the memory components which form the Oracle instance and the physical database
components where different kinds of data are stored.
Fig 3.1: Oracle Architecture
Java Pool
Data
Redo Database Server
Dictionary
Log Buffer Cache Process
Cache Streams Pool
Buffer
Shared Pool
The instance and its components are configured using a file known as the Parameter file.
In Oracle 10g there are two types of initialization files namely the 'Server Parameter file'
(spfile) and 'The Parameter file' (pfile). The parameter files hold parameters that can set
the sizes of the various buffers and pools of the SGA. You can also specify the name of
the instance, the name of the database and other size-related parameters needed by the
Oracle instance.
Redo Log Buffer – A circular buffer that stores all changes made in the database. It
contains are transferred periodically from memory to the online redo log files on disk by
the Log Writer (LGWR) background process. The contents of the redo log buffer are
essential for instance recovery purposes. The size of the redo log buffer is determined by
the LOG_BUFFER initialization parameter.
The Database Buffer Cache – An area in memory that holds all the blocks read in from
disk for query or modification. Blocks that need to be modified, are modified in memory
and are written back to disk periodically. Modified blocks that have not yet been written
to disk are known as dirty blocks. This buffer is managed in a manner that free blocks are
always made available for new blocks being read into memory. The contents of the
database buffer cache are shared by multiple user processes. The contents of the database
buffer cache are written to datafiles on disk by the Database Writer (DBWR) background
process. The size of the default database buffer cache is sized by the DB_CACHE_SIZE
initialization parameter. The blocks that are part of the Database buffer cache are sized by
the DB_BLOCK_SIZE initialization parameter. This is the default buffer cache.
Other caches that can be created in addition to the default database buffer cache. They are
the Keep and Recycle cycle buffers. Oracle uses the technique known as LRU algorithm,
to create space for new in-coming blocks that need room in buffer cache. The oldest
blocks are the first ones to leave. There maybe certain blocks that should be retained in
memory for a longer period of time, since they are frequently accessed. The Keep cache
is used to hold such. Though they are also subject to the LRU algorithm, blocks are not
released as quickly as they would have in the default cache. Blocks from standard and
frequently accessed packages should be placed in the keep cache. The size of the Keep
cache can be specified by the DB_KEEP_CACHE_SIZE initialization parameter. The
Recycle cache on the otherhand is used to hold blocks of objects that should be released
as soon as they are used if it is unlikely that they will be reused. You can specify which
cache will be used by an object when the object is created.
The Shared Pool – The contents of this memory area are shared by multiple users and
hence the name shared pool. Two specific caches form the shared pool. The sizes of the
two caches are not set individually and are automatically determined by the Oracle
Server. However it is possible to set the overall size of the Shared pool by using the
SHARED_POOL_SIZE initialization parameter.
• Library Cache –It is responsible for storing and reusing frequently used SQL
statements, their execution plans and stored procedures. This cache prevents SQL
statements from being repeatedly parsed thus improving performance during
execution of SQL statements. When a statement is executed, Oracle looks for an
identical statement / execution plan in the library cache. If one is found it is reused, if
not a new parse tree and execution plan are created. The library cache also holds
frequently accessed PL/SQL blocks.
• The Data Dictionary Cache – Sometimes referred to as the Row Cache. The cache
consists of blocks that hold data dictionary information read in from the datafiles.
Reads that are made to the data dictionary information in the datafiles are also called
recursive reads. Typical information stored in this cache is user account information,
table, index and other object definitions, privileges and other relevant information
that is frequently accessed. This cache is also managed using the Least Recently Used
(LRU) Algorithm, which is on a first-in first-out basis.
The Large Pool – This is an optional pool. The size of this memory area is determined
by the LARGE_POOL_SIZE initialization parameter. It is used for handling large I/O
requests of server processes. Its main functions are to provide memory for session
memory (UGA) for the shared server environment, parallel execution message buffers
(when PARALLEL_AUTOMATIC_TUNING is set to TRUE). It is also used by the
Recovery Manager (RMAN) for its functioning when the BACKUP_DISK_IO =n and
BACKUP_TAPE_IO_SLAVE=TRUE initialization parameters have been set. This pool
does not use the LRU algorithm.
The Java Pool – This memory area is used by all session-specific Java code and data
within the Java Virtual Machine (JVM). Its size is determined by the
JAVA_POOL_SIZE initialization parameter.
The Streams Pool – This memory area is used by the Oracle Streams Product for its
functioning.
Background Processes
The background processes of the Oracle instance are responsible for performing
asynchronous I/O functions between the Oracle Instance and the physical files of the
Oracle database that exist on disk. There are 5 mandatory background processes in Oracle
10g. These are the Database Writer (DBWR), the Log Writer (LGWR), the Checkpoint
process (CKPT), the System Monitor (SMON) and the Process Monitor (PMON). Other
background processes can be started based on certain additional functionality required in
the database. Given below is a list of the most commonly started background process and
the actions they are responsible for in the database.
User Processes
A user trying to access data in the database needs to make a connection with the database
using an appropriate tool such as SQL*Plus, iSQL*Plus and a front-end database
interface tool. A connection is a communication pathway created between a user process
and the Oracle Server. The user has to first supply proper authentication credentials.
Once the user's credentials are validated a user session is established and a user process is
created on the client-side to act on behalf of the user. This process remains active till the
user completes the session. In the event that a user process is terminated abnormally the
PMON background process cleans up the resources that were held by the user process.
Server Processes
Server processes are created in Oracle to handle requests made by user processes. Server
processes are always started on the Server side. They are responsible for responding to
the user process with appropriate results. Based on the mode in which a database operates
either a 1:1 ratio or m:n exists between user and server processes. In Oracle, the instance
can operate in one of two modes:
• Dedicated server mode: Once a user process is started, a server process is created on
behalf of the user process. A one-to-one ratio is maintained between user and server
processes. The server process remains attached to the user process as long as the user
process is active. The server process remains idle during periods of inactivity. The
server process is responsible for satisfying all requests made by the user process and
responding with appropriate results. The server process communicates with the
Oracle server using the Oracle Program Interface (OPI). The disadvantage of this is
that in an OLTP environment where there can be many thousands of users accessing
the database simultaneously, a large number of server processes would need to be
active.
• Shared Server Mode: In this environment a pool of shared server processes satisfy the
required of user processes. A one-to-one ratio is not maintained as in the dedicated
server mode. A user process can be serviced by any available server process. This
mode of operating is particularly useful in large multi-user online transaction
processing (OLTP) environments, where many users concurrently access the database
using short transactions. The shared server environment is discussed as a separate
chapter in this book.
• Datafiles – These files contain the data of the database. All objects created in the
database by users have their data physically stored in the datafiles. Datafiles
contain the data dictionary and user created data. In order to access the data that is
physically stored in the datafiles and reduce the overhead of disk I/O, blocks from
the datafiles are read into the database buffer cache in memory. Once they are
modified or are no longer needed they are written back to the datafiles.
• Control Files – This is a very important file that is required for the Oracle
database to function. If any one of the control files is unavailable the database is
shutdown. Hence it recommended that multiple copies of the control file are
maintained in the database on separate disks. The control file keeps a record of
the names, size and locations different physical files of the database. It also hold
other control information necessary to keep the database functioning. The
following is a list of the entries maintained in the control file.
o The database identifier and name
o Timestamp of database creation
o Tablespace names
o Names and locations of data files and online redo log files
o Current online redo log file sequence number
o Checkpoint information as and when checkpoints are made
o Begin and end of undo segments
o Redo log archive information
o Backup information generated by the recovery manager utility.
This file is size by the values specified for a number of parameters during
database creation, namely MAXLOGMEMBERS, MAXLOGFILES,
MAXLOGHISTORY, MAXDATAFILES and MAXINSTANCES.
• Redo Log Files – These files contain a record of all the changes made in the
database. These changes are referred to as redo entries. Redo entries can be used
to recover the database in the event of an instance failure. Instance failure can
occur when the contents of the SGA are lost such as in the event of a power
outage or an abnormal shutdown of the database. Any change made in the
database is first recorded in the online redo log buffer before it is actually
implemented. Hence even if modified blocks were not written in the event of an
instance failure, the changes can be recovered by using the online redo log files.
In Oracle 10g, a minimum of two redo logs should be available. These redo logs
files are known as redo groups.
Since the redo log files are very important for recovery purposes, Oracle
recommends that redo logs be multiplexed. Multiplexing is maintaining multiple
copies or additional members. In other words, each group should have more than
one member. Members of the redo log files should be off the same size and placed
on separate disks. This will prevent loss of redo data in the event of the loss of a
disk.
DISK1
Rlog1a Rlog2a
LGWR
GROUP1 GROUP2
DISK2
Rlog1b Rlog2b
Redo log groups are used in a circular fashion. Consider the figure. There are two
disks DISK1 and DISK2. There are two redo log groups GROUP1 and GROUP2.
GROUP1 has two members Rlog1 and Rlog1b. GROUP2 has two members
Rlog2a and Rlog2b. When the LGWR performs a write, it first writes
simultaneously to Rlog1a and Rlog1b. When the group becomes filled, it starts
writing simultaneously to Rlog2a and Rlog2b. The contents of the members are
identical. Now, if one of the disks is lost as a result of failure, the data is still
available in a member on another disk.
Since the contents of the redo log files are very important for recovery purposes,
you can transfer the redo entries to another media before overwriting them. This
process is known as archiving. Archiving can be done automatically every-time a
redo log file becomes full and LGWR starts writing to another file. The event
when LGWR stops writing to one file and starts writing to another is called a Log
Switch. Archiving helps achieve complete recovery in the event of media failures.
The parameter file – The parameter file is a file which contains a number of parameters
that can be used to configure the Oracle 10g instance. There are two kinds of parameter
files available. The first one is called the Server parameter file (spfile) introduced in
Oracle 9i, which allows you to specify the values to parameters that can be enforced
without bouncing the database as well as after re-starting the database. These are called
persistent parameters. The second kind of file is called Parameter file (pfile) which has
been around for a while now. It holds parameters and their values however any change to
a parameter's values requires you to bounce or restart the database.
The archive files – These are files that can be created by a process known as archiving.
When a database operates in archivelog mode, the contents of the redo log file are
transferred to an offline file known as the archive file. This file is very useful in the event
of a failure and is used for recovery purposes. Usually complete recovery up to the point
of failure is possible if all archive files are available. Archive files can be created on disk
and transferred to tape to create space for new archive files.
Parameter Files in Oracle
The Oracle 10g server is made up of the Oracle Instance and the Oracle database. The
Oracle instance is created in real memory. Most actions are first performed in memory
and then transferred to disk. It is therefore very important the Oracle instance be
configured properly. When a database administrator starts the Oracle database, the first
step involves creating the instance in memory. Various memory structures and
background processes are started.
To create the instance the Oracle server uses a file known as the Initialization Parameter
File. There are two types of initialization parameter files,
• The Static parameter file, PFILE, known as the initSID.ora file
• Persistent parameter file, SPFILE, known as the spfileSID.ora file
The initialization parameter file consists of a list of parameters. Each parameter has a
name and a value. Most parameters have default values. Explicit values can also be
assigned to the parameters. The initialization parameter file specifies information such as
the values for various memory structures of the instance, the database name, the number
of processes the can concurrently access the instance, parameters associated with
archiving and so on. A comprehensive list of initialization parameters has been displayed
along with a brief description.
In Oracle 10g, the number of initialization parameters to be configured has been greatly
reduced compared to previous versions of Oracle. Parameters have been categorized into
basic and advanced parameters. The basic parameters are a list of parameters that are
sufficient for day-to-day interaction.
Select Database Control Home Page -> Instance Section -> All
Initialization Parameters link.
The PFILE can be created when a database is creating using the Database Configuration
Assistant and manually. This file is a text file which can be read and modified. Each entry
in the PFILE shows the values
parameter_name = parameter_value
Where
parameter_value can consist of a single value or a list of values separated by commas and
enclosed in single quotes. Parameters can be specified in any order. A parameter can be
commented in the parameter file by using the #.
This change will affect only the current instance. When the database is restarted, the
previous value present in the parameter file will be used.
Any permanent change you make to a parameter requires that the database be restarted.
By default the parameter file is located in the %ORACLE_HOME%\dbs directory. It has a
name like initSID.ora where SID is the system identifier of the database. It can be
quite difficult to remember the names of all the parameters and set them properly. There
is a sample file created in the Oracle database, which can be copied and modified based
on your requirements. It is possible to create multiple initialization parameters files
however only one will be active at any time.
The persistent parameter file often called the spfile was introduced in Oracle 9i. It is
located at the server-side. The spfile cannot be modified by the user and any manual
change to the file will render it useless. It is also located in the %ORACLE_HOME%\dbs
directory. When using the Database Configuration Assistant, you are given the option of
creating an SPFILE for the database. This option is not available when you create a
database manually using the CREATE DATABASE command. The CREATE
DATABASE command has not been discussed in the book and more information about it
can be retrieved from the Oracle Documentation. If you are using the SPFILE file, it can
be backed up using Recovery Manager, since it is located on the server side.
In the case of the static parameter file any permanent change to a parameter would
require a bounce of the database. Using the spfile you can modify parameters such that
the change will not only affect the current instance but also affect future instances of the
database. Hence the term persistent.
When changing a parameter dynamically, you can set the SCOPE option. The values
taken by the SCOPE option are MEMORY, SPFILE or BOTH. The value BOTH is the
default. When you set SCOPE=MEMORY, the change you are making will only affect the
current instance. If you set SCOPE=SPFILE the change will be made in the parameter
file and will come into effect when the database is restarted. If you set SCOPE=BOTH
then the change will affect both the current instance and will affect future instances for
the database. An example of a dynamic change only affecting the spfile is displayed
below.
The ALTER SYTEM SET command is used to modify the values of instance parameters
after the instance has been created. The complete syntax of its usage is displayed below:
Example of dynamic changes the may or may not affect the changes:
1. Modify the size of the default database buffer cache to 20M, both for the current
and future instances.
ALTER SYSTEM SET DB_CACHE_SIZE=20M SCOPE=BOTH;
CREATE SPFILE [= 'location of the spfile'] FROM PFILE [= 'location of the pfile'] ;
If you do not specify the location, which is optional it will be created in the default
location %ORACLE_HOME%\dbs directory.
It is possible to create the PFILE from the SPFILE by using the command:
An editable parameter file will be created in its default location if a path is not
specified.
1) Instance Creation – This is the first step in starting the database. The initialization
parameter file is read, (spfile or pfile depending on the options used in the STARTUP
command) and the System Global Area (SGA) is configured. The parameter file
identifies the name of the database, and various sizes for the memory pools, the
optional background processes and so on. During instance creation, the mandatory
and optional background processes are started. The alert log file and other trace files
are also started.
2) Mounting the Database – After instance creation, the database is mounted. When a
database is mounted a database administrator can perform certain maintenance or
administrative tasks. For e.g. putting a database in archivelog mode, renaming
datafiles or performing a full database recovery requires the database to be mounted.
During mounting, a database is associated with its previously started instance. The
control files of the database are opened and read. The control file contains
information about the other files of the database, their status, location and
synchronizing information. This information is needed for the next stage of startup
which is opening of the database.
3) Opening the database – This is the last stage in starting a database. This phase has to
be performed so that users of the database can access the data in the database. Once
the control file has been read and the location of the physical files of the database
identified after mounting, the files are opened and made available to the users. The
files that are opened are the online datafiles and the online redo log files. If any of the
files are unavailable, an error will be reported and the database will not be opened. It
is at this point that the Oracle server verifies the consistency of the database. In case
the database was shutdown improperly the last time, it will be detected at this point
and the SMON background process will perform instance recovery.
STARTUP command
The syntax of the STARTUP command with its important options has been displayed:
RESTRICT: This option is used when you want only users who possess the
RESTRICTED SESSION privilege to access the database. This option can be used is you
wish to perform some kind of maintenance on the database such as an export and import.
PFILE=filename: this option starts up the database using the static non-default parameter
file to startup the database.
OPEN [database_name]: The instance will be created; database will be mounted and then
opened for all the users. You can optionally specify the database name. This is the default
option.
MOUNT: The instance will be created and the database mounted. The option can be used
for performing certain maintenance tasks.
NOMOUNT: Only the instance is created. The SGA will be created in memory and the
background processes will be started. You may have to use this option for certain
operations such as when creating a database manually.
READ ONLY: used to open the database for queries only. DML statements are not
allowed in the database.
If you have started the database using the NOMOUNT option, only the instance is
created. In order to then mount / open the database you can use the following ALTER
DATABASE command. It is not possible to re-issue the STARTUP command with the
MOUNT or OPEN options.
It is possible to open a database in a read only or read write mode using the ALTER
DATABASE command. To startup the database in a read only or read write mode from a
NOMOUNT or MOUNT stage you can issue;
ALTER DATABASE OPEN [READ ONLY | READ WRITE];
Where:
READ ONLY – only queries are allowed on the database.
READ WRITE – the database is opened for normal read and writes.
NORMAL: This is the default mode for shutting down the database. The Oracle server
waits for all currently connected users to disconnect their sessions. No new connections
are permitted. A checkpoint is performed on all the databases and the files are closed.
When a database is shutdown is this mode, an instance recovery will not need to be done
during the subsequent startup.
TRANSACTIONAL – When the database is shutdown using this option, all currently
active transactions will be allowed to complete. As soon as a user's transaction completes
the user is automatically disconnected. No new user connections will be allowed. The
database is then closed, dismounted and the instance released. No instance recovery will
be performed during subsequent startup.
ABORT – When the database is shutdown using this option, the instance is shutdown
down. This is a case of an improper shutdown. No checkpointing is done. All user
connections are abnormally terminated. The database is not closed or dismounted.
However, the next startup will require an instance recovery to be performed by the
SMON background process.
SQL> STARTUP;
If the database has an spfile, by default the spfileSID.ora will be used to configure the
instance. If the spfileSID.ora file does not exist, Oracle will look for a default SPFILE on
the server side. If one cannot be found the initSID.ora file on the server side will be used.
There may be times when you wish to startup the database using the PFILE. To do so,
you issue the STARTUP command with the PFILE='filename' option as shown:
A database administrator can initiate SQL tracing in a particular session by using the
DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION packaged procedure.
To initiate SQL tracing at an instance level, you can issue set the SQL_TRACE
initialization parameter to TRUE. In this case all user sessions will be traced.
Lesson 6: Enterprise Manager Database Control
Enterprise manager provides two configurations with which to monitor your database:
Database Control and Grid Control.
The Oracle Enterprise Manager 10g Database Control is one of the main functional areas
of the entire Enterprise Manager framework. It is a web-based application for managing
the Oracle 10g database. The database control is installed and available with every Oracle
Database 10g installation. Using the Database Control, you can monitor a single Oracle
Database instance or a clustered database.
You can configure Database Control from the database configuration assistant (DBCA)
when a new database is being created or reconfigure and existing database.
To start the database control on Windows you would need to start a service in the
following manner.
1. Select Services from the Start -> Settings -> Administration Tools menu
2. Locate the Database Control service, OracleDBConsoleDatabase_name
3. Start the service
OR
To stop the database control on Windows you would need to start a service in the
following manner.
1. Select Services from the Start -> Settings -> Administration Tools menu
2. Locate the Database Control service, OracleDBConsoleDatabase_name
3. Stop the Service
OR
The Enterprise Manager console has become a database administrator's most useful and
resourceful companion in Oracle 10g. Its web-based interface has greatly simplified
database administration. Using the interface
The Oracle Enterprise Manager Database Control, is used to perform administrative tasks
such as creating schema objects (tables, tablespaces, users), managing user accounts,
backup and recovering the database, performance tuning, proactive maintenance, cloning
a database and so on. The SYS or SYSTEM user accounts are administrative accounts
that can be used when trying to logon to the EM console.
After successful logon into the EM console, you will be displayed the Database Home
page.
The various sections of the Database Home page, and its related links provide a DBA
with a wealth of information about the database's environment and health.
Property pages exist on each home page. These are categorized based on management
tasks. For e.g. the maintenance tab can be accessed to perform backups of the database.