College of Computer and Information Sciences

Information systems Department

IS337 - Database Lab

Instructor: Najmuddin Malik

Academic Year: 2010-2011

Total Pages 188

Page | 1
Course reference book:
OCA Oracle Database 11g Administration I
ISBN 978-0-07-159104-1
Published by Oracle Press

Title Page No

Ch 2: Exploring Database Architecture 5

Ch 4: Creating an Oracle Database 37
Ch 5: Managing Oracle Instance 37
Ch 6: Configuring the Oracle Net Environment 47
Ch 7: Managing Database Storage Structure 72
Ch 8: Administering User Security 102
Ch 15: Backup and recovery Concepts 118
Ch 16: Performing Database Backups 118
Ch 17: Performing Database Recovery 175

Page | 2
Metadata Views
An Oracle 10g database contains two types of meta data views.

1. Data dictionary views: Oracle 10g contains over 1,300 dictionary views. Their names
begin with dba_, all_, and user_.

2. Dynamic performance views: Oracle 10g contains over 350 dynamic performance views.
Most of these views have names that begin with v$.

>select TABLE_NAME, BLOCKS, EMPTY_BLOCKS from user_tables;

>select owner, TABLE_NAME, BLOCKS, EMPTY_BLOCKS from all_tables;

>select owner,TABLE_NAME,BLOCKS,EMPTY_BLOCKS from dba_tables;

>select FILE_ID, FILE_NAME, STATUS, BYTES, BLOCKS from dba_data_files;

>select FILE#, NAME, STATUS, BYTES, BLOCKS from v$datafile;

Comparison of Data dictionary and dynamic performance views

Dictionary Views Dynamic Performance Views

Views usually have plural names. Views generally have singular names.

Available only when database is OPEN. Some are available when database is
NOT OPEN.

Data is generally UPPERCASE. The data is generally lowercase.

Data is static, not change when db is shutdown. Data lost when database shutdown.

Page | 3
Some Useful Views
dba_clu_columns v$dbfile
dba_clusters v$dblink
dba_constraints v$instance
dba_data_files v$librarycache
dba_db_links v$log
dba_extents v$log_history
dba_free_space v$logfile
dba_ind_columns v$parameter
dba_ind_partitions v$rollname
dba_ind_subpartitions v$rollstat
dba_locks v$session
dba_objects v$session_wait
dba_outstanding_alerts v$sga
dba_part_key_columns v$sgastat
dba_part_tables v$sort_segment
dba_password_limits v$sql
dba_profiles v$sqlarea
dba_resourse_limits v$sqltext
dba_role_privs v$sysstat
dba_roles v$system_parameter
dba_rollback_segs v$tempfile
dba_segments v$transaction
dba_subpart_columns v$recovery_file_dest
dba_sys_privs v$flash_recovery_area_usage
dba_tab_partitions
dba_tab_privs rc_archived_log
dba_tab_subpartitions rc_backup_controlfile
dba_tables rc_backup_piece
dba_tablespaces rc_backup_redolog
dba_temp_files rc_backup_set
dba_ts_quotas rc_controlfile_copy
dba_users rc_database
v$archive rc_database_block_corruption
v$archive_dest rc_datafile
v$archived_log rc_datafile_copy
v$backup_datafile rc_rman_configuration
v$backup_device rc_rman_status
v$backup_piece rc_stored_script
v$backup_redolog rc_stored_script_line
v$backup_set rc_tablespace
v$controlfile rc_unusable_backupfile_detail
v$controlfile_record_section
v$database role_role_privs
v$datafile role_tab_privs
v$datafile_header role_sys_privs
v$db_object_cache

Page | 4
CH 2: Exploring the Oracle Database Architecture

Topic Page No

1. Oracle Architecture 6
2. Memory Structures 7
3. Background Threads of an Instance 8
4. Least Recently Used (LRU) algorithm 17
5. Calculating size of SGA and it’s Components 18
6. Oracle Physical structures 21
a. Initialization file 22
b. Control file 24
c. Data files 24
d. Redo Log files 26
e. Alert Log files 27
f. Trace files 28
g. Password files 31
7. User Session 32
8. Checkpoint 33
9. Connection Request Failure reasons 34
10. SQL Statement Execution Steps 35
11. Instance recovery at instance startup (SMON) 35

Page | 5
Oracle Architecture

As a DBA, you take care of each of each tasks, as well as others.

1. Selecting server hardware on which database software will run.
2. Install and configuring the Oracle 10g software on the server.
3. Creating database itself.
4. Creating and managing the tables and other objects.
5. Creating and managing database users.
6. Establish reliable backups and recovery process for the database.
7. Monitoring and Tuning database performance

To work as a DBA, you need to completely understand Oracle’s underlying architecture and
its mechanism. Understand the relationship between Oracle’s memory structures,
background process, and I/O activities on physical structure. Oracle server architecture can
be broken into two main categories

Following are Oracle structures and together we call them Oracle Database Server.
 Oracle Instance
1. Memory structures
2. Processes
 Physical structures / Oracle database (group of 3 type of physical structures)

Oracle Server instance is a collection of server side processed and memory areas that
Oracle used for managing access to database. Oracle Server instance main memory
structure called System Global Area (SGA), and Oracle background processes. The SGA, at
a minimum, is made up of four components: The Shared Pool, The Database Buffer Cache,
The java Pool, and Redo Log Buffer. Other components of the SGA, like Large Pool may also
exist on the Oracle system depending on which optional features you chose to use.
The Oracle background processes are System Monitor (SMON), Process Monitor (PMON),
Database Writer (DBW0), Log Writer (LGWR), and Checkpoint (CKPT). Several other Oracle
processes may also be running on the system, depending on which optional features you
have decided to implement.

The SGA and the required background processes acquire space in the server’s memory
immediately upon startup of the Oracle server. Four initialization parameters are the primary
determinant of the SGA memory requirements.

The Oracle database is made up of a set of physical files that reside on the host server disk
drives. These files are called control files, data files, and redo logs. Additional physical files
that are associated with the Oracle database, but are not technically part of the database, are
password file, the PFILE/SPFILE and archived redo log files.

Page | 6
Memory Structures

1. System Global Area (SGA)

2. Program Global Areas (PGA)

System Global Area (SGA)

Database Buffer Cache store data needed for SQL statements issued in user processes. It
improves performance for subsequent statements on same data. SGA allows users to make
data changes quickly in memory.

Shared Pool Caches the most recently used SQL statements that have been issued by
database users.
 Library Cache (mandatory): Used for storing parsed SQL statement text and statement
execution plan for reuse.
 Dictionary cache / Row cache (mandatory): Used for storing recently accessed
information (table, column definition, user name, PWD and privileges)

Redo Log Buffer temporarily stores in memory the redo log information generated by DML in
user sessions until Oracle writes information to disk. Redo log is small amount of information
produced and saved to redo changes made to database by insert, update, alter, drop
statements.

Large Pool buffers Caches data for large I/O operations such as RMAN backup and restore
activities and shared server components.

Java Pool Caches the most recently used Java objects and application code when Oracle
JVM option is used.

Streams Pool Caches the data associated with queued message requests when
Oracle Advance Queuing (OAQ) option is used.

Program Global Areas (PGA)

PGA is created for each user and it stores user-specific session information.
1. Bind variables
2. Session variables. (uid, ip address of client machine, time connect, program, status, ..)

Page | 7
Background Threads of an Instance.

At the user level two processes allow a user to interact with instance and, ultimately with the
database. They are User process and Server process. The user process exists either on the
user’s own pc or on the middle-tier application server. Once the connection is made, the user
establishes a session in the instance. After establishing a session, each user then starts a
Server process on the host server. It is the server process that is responsible for performing
the tasks that actually allow the user to interact with the database.
In a Dedicated Server configuration each end user has his/her own Server Process. When
Shared Server option is used, several end-users share one or more Server Processes.
Server process management is an important aspect of overall database performance.

Oracle Background Processes

Five Oracle background processes are required and several background processes are
optional.

Required Oracle Background Processes.

Data base Writer (DBWn): Writes modified data block from data buffer cache back to data
files on disk. At least one DBWn may have more DBW0, DBW1, DBW3 ….DBW9
DBWR writes dirty data blocks from buffer cache to disk.
1. Writes when need room in buffer cache.
2. When DBWr is told to write data to disk by LGWR at checkpoint.

Log Writer (LGWR): Write Redo Log entries from redo log buffer to online redo log files on
disk.

Checkpoint (CKPT): Periodically database performs checkpoints. During checkpoints DBWn

writes all modified data blocks in memory back to data files. CKPT updates the data files
header following a checkpoint event.

System Monitor (SMON): performs internal operation.

1. Periodically coalesces the free space. It works during times of low activity.
2. Instance recovery handled after database starts up if necessary.
3. De-allocates space in temporary segments no longer in use.

Process Monitor (PMON) Cleans up messes left by dedicated server with no user session
attached to it. Roll back changes and kills the dedicated server memory and CPU usage.

Page | 8
Optional Oracle Background Processes
Archive (ARCn) automatically back ups transactions log files. After LGWR fills them with redo
log entries.

Recoverer (RECO): Distributed database is a collection of individual database that appear to

an application and user as a single database. A distributed transaction is a transaction that
updates data in multiple databases. To protect integrity of data through out a distributed
database, Oracle used mechanism. The transaction might be completed at some servers,
while left in doubt at other. RECO is used in such instances. RECO automatically wakes up
to resolve all in-doubt distributed transactions as they happen.

Dispatcher (Dnnn): Assigns user’s request to request queue in Oracle Shared Server mode.

Shared Server (Snnn): Server processes that are shared among several users when Oracle
Shared Server feature is used.

Job Queue Monitor (CJQn): Assigns jobs to Job Queue processes when using oracle job
scheduling feature.

Job Queue (Jnnn): Executes database jobs that have been schedules using Oracle Job
scheduling feature.

Queue Monitor (QMNn): Monitors the messages in the message queue when Oracle
Advanced Queuing feature is used.

Parallel Query Slave (Qnnn): Used to carry out portions of a large overall query when Oracle
Parallel Query feature is used.

Memory Manager (MMAN): Manages the size of each individual SGA component when
Oracle Automatic Shared Memory Management feature is used.

Memory Monitor (MMON): Gathers and analyzes statistic used by the Automatic Workload
Repository featured.

Memory Monitor Light (MMNL): Gathers and analyzes statistic used by the Automatic
Workload Repository featured.

Recovery Writer (RVWR): Writes recovery information to disk when Oracle Flashback
Database Recovery feature is used.

Change Tracking Writer (CTWR): keeps track of which database blocks have changed when
Oracle Incremental Recovery Manager feature is used.

Page | 9
User and Server Processes relationship

Page | 10
The basic Oracle Architecture Components

Oracle Instance
Physical
Structures
Memory Structures

SGA PGA

Processes

DBWn ARCn Dnnn Initialization file (spfile)

LGWR RECO Snnn Control files
PMON CJQn MMAN Data files
SMON Jnnn MMON Log files
CKPT QMNn MMNL Alert file
Qnnn RVWR Trace files
Password file
CTWR

Page | 11
Some Important Memory Areas and Processes

Page | 12
Page | 13
Subdivision of SGA Areas

Page | 14
Some of Oracle memory areas and processes description

Page | 15
Oracle SGA, background processes and some physical structures

Page | 16
Least Recently Used (LRU) algorithm

Oracle used a Least Recently Used (LRU) algorithm to manage the contents of the Shared
Pool and Database Buffer Cache. Oracle keeps frequently accessed SQL statements and
database buffers in memory longer, improving the overall performance of the server by
minimizing parsing and physical I/O.

The size of the SGA can be managed by manually or automatically. In automatic mode, the
instance itself will monitor the utilization of each SGA component and adjust their size
accordingly, relative to a predefined maximum allowable aggregate SGA size. Oracle
allocates SGA memory into chunks called granules. These granules of memory are
dynamically allocated or de-allocated from the buffer cache, shared pool, large pool, and
java pool as needed according to the demand placed on these areas by application users.
SGA granules can be 4mb, 8mb, or 16mb in size, depending on the server OS and size of
SGA.

Whether the instance operates in manual or automatic mode is determined by settings in a

configuration file called parameter initialization file. There are two type of parameter
initialization files Parameter File (PFiles), and Server Parameter Files (SPFiles). You can use
either type of file to configure instance and database operations. You can specify more than
250 documented configuration parameters in Pfile/Spfile. Oracle recommends that you
set only about 30 basic initialization parameters manually.

Cache STATUS
Cache Hit/Cache Get:
Cache hit happens when an application request data that is already in memory cache.

Cache Miss:
Cache miss happens when an application request data that is not in the cache, so a disk read
is necessary.

Cache reload:
Cache reload happens when application request data that was in the cache, but aged from
cache (written back to disk), so data must be read from disk into memory. A memory cache is
a fixed chunk of memory that does not grow or shrink. Most Recently Used (MRU)/Least
Recently Used (LRU) caching algorithm is used to keep the most frequently used data blocks
in memory and minimize number of cache miss or reload.

Cache hit ratio is calculated to find out the performance of different memory areas of Oracle
server running Modes.

Page | 17
Calculating size of SGA and it’s Components

> select sum(value/(1024*1024)) SGA_mb from v$sga;

SGA_MB
164
Total size of SGA is 164 mb.

> show parameter sga_max_size

NAME TYPE VALUE

sga_max_size big integer 164M

> show parameter log_buffer;

NAME TYPE VALUE

log_buffer integer 1048576

> select name, value size_kb, to_char(value/(1024*1024),999.99) size_mb

from v$sga;

NAME SIZE_KB SIZE_MB

Fixed Size 787988 .75 -- instance background processes
Variable Size 144964076 138.25 -- shared pool, large pool, and java pool
Database Buffers 25165824 24.00 -- data
Redo Buffers 1048576 1.00 -- transactions

Variable space (144964076) is composed of shared pool, large pool, and java pool,
database buffer cache is 25165824, the redo log 1048576 and additional space (787988) that
stores information used by the instance background processes.

Command to know the current size of different SGA Areas

> select component, current_size/(1024*1024) curr_size_mb
from v$sga_dynamic_components where current_size <> 0;

COMPONENT CURR_SIZE_MB
shared pool 80
large pool 8
java pool 48
DEFAULT buffer cache 24

Page | 18
> select name, value
from v$parameter
where name in ('java_pool_size', 'sga_max_size', 'large_pool_size',
'log_buffer', 'shared_pool_size', 'sort_area_size');

NAME VALUE
sga_max_size 171966464
shared_pool_size 83886080
large_pool_size 8388608
java_pool_size 50331648
log_buffer 1048576
sort_area_size 65536

> select pool, sum(bytes) "size"

from v$sgastat where pool = 'shared pool' group by pool;

POOL size
shared pool 83886080

> select name, to_char(bytes/(1024*1024),999.99) size_MB

from v$sgastat
where name in ('buffer_cache', 'library cache', 'log_buffer', 'sql area');

NAME SIZE_MB
buffer_cache 24.00
log_buffer 1.00
sql area 8.56
library cache 10.65

Page | 19
> select pool Name, sum(bytes)/(1024*1024) Size_MB
from v$sgastat
where pool in ('java pool','large pool','shared pool') group by pool
union
select name, value/(1024*1024) size_MB
from v$sga where name in ('Database Buffers','Redo Buffers');

NAME SIZE_MB
Database Buffers 24
Redo Buffers 1
java pool 48
large pool 8
shared pool 80

> select substr(name,1,25) Name, value/(1024*1024) size_MB

from v$parameter
where name in
('java_pool_size', 'large_pool_size','log_buffer', shared_pool_size', 'db_cache_size' );

NAME SIZE_MB
shared_pool_size 80
large_pool_size 8
java_pool_size 48
db_cache_size 24
log_buffer 1

Page | 20
Oracle Physical Structures

The physical files are made up of control files, datafiles, and redo log files. Additional files
that are associated with the Oracle database are initialization file, trace file, alert log files,
password file and any archived log files.

File Name Information contained

Initialization Listing of configuration parameters for the instance and the database.

Control Location of other physical files, database name, database block size,
database character set, and optionally recovery information

Datafile Data blocks from all database segments. (data and metadata)

Redo Log Record of all changes made to the database and used for recovery.

Archived Log Copy of the contents of previous online Redo Los.

Password Users information who have been granted SYSDBA or SYSOPER

privileges.

Alert Log Informational and error messages generated by database activity.

Trace Informational and error messages generated by users or background

processes.

Oracle Database

An instance is a temporary structure, but the Oracle database is made up of a set of physical
files that reside on the host server’s disk drives. These files are called:
1. control file
2. data files
3. redo logs

Additional physical files that are associated with the Oracle database, but are not technically
part of the database are pfile/spfile, any archive log files and password file.

Page | 21
Initialization file (pfile / spfile)
When we start server, PFILE.ORA file is read and initializes parameters and the
memory areas. This is a text file and can be read in any standard text editor. This file
is known as PFILE. There are 280+ different documented parameters in Oracle.
Oracle recommends that you set only about 30 basic initialization parameters
manually.
From Oracle9 version, Oracle introduces Server Parameter (SP) files also known as
SPFile (server parameter file) located in same directory as pfile.
SPFile can not be edited by standard text editor. It is created from standard PFILE
and modified by ALTER SYSTEM command. Command can change the value of a
parameter for the life of instance, or across a shutdown and start or both. The SP files
are named like spfile_SID.ora. The SP file will automatically incorporate any changes
made dynamically via ALTER SYSTEM commands.
A pfile.ora file will not reflect any dynamic system changes unless they are manually
added to the file. Unless the instance is specially started using the STARTUP PFILE
option with an existing pfile.ora, the values contained in the spfile.ora , not the pfile.ora
will be used to determine the instance parameters. Basic information in initialization
file is:

 Different Buffer size

 Control file location
 Archive mode option
 Different dump file destination
 Rollback segment management option
 No of users can connect

Parameter / Default Description

DB_CACHE_SIZE Caches segment data from tables, indexes etc.
SHARED_POOL_SIZE Caches SQL and PL/SQL statements and data dictionary
LOG_BUFFER Caches transaction information
LARGE_POOL_SIZE Buffers I/O server processes and backup and recovery
JAVA_POOL_SIZE Buffer Java state information b/w database calls java comp.

Comparision of Pfiles and Spfiles

PFile SPFile
 Text file Binary file
 Called initinstance_name.ora Called spfileinstance_name.ora
 Can be created from an SPFile Can be created from PFile
>create pfile from spfile; >create spfile from pfile;
 After changes in pfile, instance must be Most changes to spfile can be dynamic.
Shut down and restarted before it takes effect.

Initialization file is found in directory will be %oracle_base%\admin\SID\pfile.

For Oracle9 database on college server the file name is c:\oracle\admin\oracle\database\pfile\pfile.ora
For oracle10g database on college server the file name is $oracle_home%/database/spfileo10g.ora
Page | 22
Displays parameter values in the initialization file.
> show parameters

Show a specific parameter vale of initialization file.

> show parameters db_block_size

NAME TYPE VALUE

db_block_size integer 8192

Parameter value can also be get from v$parameter view.

Display the control_files parameter value.
> select name, value from v$parameter where name = ‘control_files’;

Displays database block parameter value.

> select name, value from v$parameter where name = 'db_block_size';

Certain parameters can be changed dynamically by ALTER SESSION / ALTER SYSTEM

command. A value of IMMEDIATE indicates that the parameter can be dynamically changed
by ALTER command. A value of DEFERRED indicate that the change does not take effect
until a new session is started. By using spfile, DBA has more flexibility as to when parameter
takes effect in the instance.
Change log buffer size to 40m
> alter system set log_buffer=40m;

Change the default date format to ‘DD-MM-YYYY’ format

> alter system set nls_date_format=’dd-mm-yyyy’;

Change the session to English output if it is not English.

> alter session set nls_language=’ENGLISH’;

Change the format of sort to Arabic during the session.

> alter session set nls_sort = ‘ARABIC’;

Sort the attribute cename to Arabic format if default is other than Arabic.
> select cno, cname, cename
from customers order by nlssort(cename,”NLS_SORT=ARABIC”);

Change the default datafile location for new datafiles.

> alter session set db_create_file_dest = ‘e:\oracle\datafiles’;

Change the max dump file size to 20000 bytes and will take effect when we restart the Oracle
Server after shutting down.
> alter system set max_dump_file_size=20000 scope=spfile
scope clause are:
memory = effect is life of current instance
spfile = new value takes effect when instance shutdown and start
both [DEFAULT] = for current instance across shutdown and restart
Page | 23
Control Files
Control files are critical components of the database because they store important
information.
 The name of database
 The name, location, and sizes of the data files and redo log files.
 Information to recover the database in the case of a failure.
 Latest SCN (System Change Number)
 Last LSN (log switch number)

The controlfiles are created when the database is created in the locations specified in the
control_files parameter in the parameter file. Oracle used CKPT process to automatically
update each of these files as needed, keeping the contents of all copies of the controlfile
synchronized. You can use the view v$controlfile to display the names and locations of all the
controlfiles.
Controlfile is used to mount the database. Minimun one controlfile is needed but for safety
oracle create three controlfile. We can create more if we want.Minimum one controlfile is
needed but default value is three.

Following command will display how many control files the database has.
> select name from v$controlfile;
> show parameter control_files;

Datafiles
Data files are the physical files that actually store the data that has been inserted into each
table in the database. Datafiles are the physical structure behind another database storage
area called tablespace. A tablespace is a logical storage unit within the database. By default
Oracle 10g must have at least three tablespaces. You can use v$tablespace and v$datafile
views to display their information.

Required Tablespaces
Tablespace Name Description
SYSTEM Stores the data dictionary tables and PL/SQL code.
SYSAUX Stores segments used for databasae options such as the Automatic
Workload Repository, Online Analytical Processing (OLAP), and Spatial.
TEMP used for performing large sort operations.

Common Tablespaces
Tablespace Name Description
TOOLS Used to store segments for nonapplication management tools.
USERS Used as default tablespace for database users.
UNDOTBS1 used to store information for read consistency and recovery purposes.

Page | 24
Beyond the six mentioned tablespaces listed above, production databases often have many
more tablespaces for storing application segments. For each of the tablespace, there must be
at least one datafile. Some tablespaces may be composed of several datafiles for
management or performance reasons.

Following command displays the name of tablespaces.

> select tablespace_name from dba_tablespaces;

Following command displays the datafiles and the corresponding tablespace they belong.
> select tablespace_name, file_name from dba_data_file order by tablespace_name;

When a user performs a SQL operation on a table, the users server process copies the
affected data from the datafile into the database buffer cache in the SGA. If the user has
performed a committed transaction that modified that data, the DBWn ultimately writes the
modified data blocks to the datafiles.

When does the Database writer (DBWn) write?

1. A server process has searched too long for a free buffer when reading a buffer into the
buffer cache.
2. The number of modified and committed but unwritten buffers in the database buffer cache
is too large.
3. At database checkpoint event.
4. The instance is shutdown using any method other than shutdown abort.
5. A tablespace is placed into backup mode.
6. A tablespace is taken offline or change to ‘read only’ mode.
7. A segment is dropped.

Page | 25
Redo Log Files
When a user performs a transaction in the database, the information needed to reproduce
this transaction in the event of a database failure is automatically recorded in the redo log
buffer. The contents of the redo log buffer are ultimately written to the redo log files by the
LGWR process. Redo logs are usually multiplexed or copied. Collectively, these sets of redo
logs are referred to as redo log groups. Each multiplexed file with in the group is called a
redo log member. Oracle writes to all members of redo log group to keep the files in sync.
Each redo log group must be composed of one or more members. Each database must have
a minimum of two redo log groups because redo logs are used in a circular fashion.

When a user performs a DML activity on the database, the recovery information for the
transaction is written to the redo log buffer by user server process. LGWR eventually writes
this recovery information to the active redo log group until that group is filled. Once the
CURRENT log fills with transaction information, LGWR switches to the next redo log until that
group fills with transaction information and so on. When the last redo log is used, LGWR
wraps around and starts using the first redo log again.

Following command displays all redo log groups information.

> select group#, members, status,bytes from v$log;

Following command displays all members name and their group#.

> select group#, member from v$logfile order by group#;

When does the Log writer (LWGr) write?

1. Every three seconds
2. A user commits a transaction.
3. The redo log buffer is one-third full.
4. The redo log buffer contains 1mb worth of redo information (changes).
5. Before the DBWn process whenever a database checkpoint occurs.

When LGWR wraps around from the last redo log back to the first redo log, any recovery
information previously stored in the first redo log group is overwritten and therefore no longer
available for recovery purpose. However, if the database is running in archive log mode, the
contents of these previously used logs are copied to a secondary location before the log is
reused. It is the job of the ARCn process to copy the contents of the redo log to the archive
location. These copies of the old redo log entries are called archive logs.

In the figure, the first redo log group has been filled, and LGWR has moved/switch to on to
redo log group 2 from redo log group 1. As soon as LGWR switches from redo log group 1 to
redo log group 2, the ARCn process starts copying the contents of the redo log group 1 to the
archive log file location as mentioned in the parameter file. Once the first redo log group is
safely archived, LGWR is free to wrap around and reuse the first redo log group once redo
log group 3 is filled.

Page | 26
The Alert Log
The Oracle alert log records information and error messages for a variety of activities that
have occurred against the database during its operation. The alert log is constantly appended
to while the database is in operation. If left unmanaged, it can grow very large. Oracle
automatically creates a new alert log if the prior was deleted or renamed. The information
helps in tuning the database.

Common alert messages related to performance and Tuning are

 Unable to extend temp segment by n in tablespace x
 Unable to extend table x by n in tablespace x
 Unable to extend Rollback segment x by string in tablespace x
 Max # extents n reached in table x
 Checkpoint not completed
 Thread n advanced to log sequence n ( not indicate a performance problem)

The alert log is found in the directory specified by the parameter

BACKGROUND_DUMP_DEST.

Page | 27
The Trace Files
Oracle trace files contain session information for the process that created them. Trace files
can be created by the oracle background process, through the use of pfile.ora trace events or
by tracing user Server Processes.

Background Trace files

Background process trace files incorporate the name of the background process that
generated them in the trace file name.
Process Name Windows System Trace File Name
Process Monitor (PMON) sidPMON.trc
System Monitor sidSMON.trc
Database Writer sidDBW0.trc
Log Writer sidLGWR.trc
Checkpoint Process sidCKPT.trc
Archive Process sidARC0.trc

Event Tracing
The database event is a specific action or activity that occurs in the database. Oracle has
special option that you can configure to enable the collection of detailed tracing information
for particular database event. By default, most database events do not cause the creation of
trace files. However, some database events can be forced to create a trace file of their
activities you wish to trace.
Tracing of these events is usually done at the instance level by adding new lines to pfile.ora.
Generally you may be asked to do event tracing by the Oracle Worldwide Support (OWS) as
part of trouble shooting.

The background process and EVENT trace files are found in the directory specified by
BACKGROUND_DUMP_DEST parameter. Systems those follow OFA model this directory
will be %oracle_base%\admin\SID\bdump on windows 2000.
Tracing of these events is usually done at the instance level by adding new lines to the
pfile.ora. If several events are being added to the pfile.ora, they should be grouped together
and commented appropriately. The spfile.ora looks like this:

EVENT=”10046 trace name context forever, level 12”

>alter system set event = "10046 trace name context forever, level 12"

The double quotes are part of the syntax of this parameter.

 The event to be traced, designated by a number.
 Te level to which tracing will be performed.

OWS personnel will provide you with these numeric values when the need for using trace
events arises.

Page | 28
User Trace files
User Process Trace files incorporate by OS process identifier in the trace file. An example
can be ora00776.trc. Query against the V$PROCESS and V$SESSION views can be
performed to identify which user generated a particular trace file.

>select s.username, p.spid

from v$session s, v$process p
where s.paddr = p.addr
and p.background is null;

USERNAME SPID
Scott 2922
Najm 3088

Use ‘SCOTT’ tracing information can be found in ora02922.trc file.

The User trace files are found in the directory specified by USER_DUMP_DEST parameter.

Page | 29
Activating Instance-Level Tracing (background processes tracing)
By setting SQL_TRACE=TRUE in pfile.ora, all processes against the instance will create their
own trace files. It creates a great deal of overhead against the system, so care must be
taken. The default value for the parameter is FALSE.

Activating User-Level Self Tracing

A user can turn SQL tracing ON or OFF in their own session by following SQL command.

Command to start the tracing process

> alter session set SQL_TRACE=TRUE

Command to end the tracing process

> alter session set SQL_TRACE=FALSE

Activating User-Level DBA Tracing

In general most applications do not provide user with a mechanism for tracing SQL
commands from within the applications. A DBA can use Oracle supplied procedures to start
and stop user tracing. To activate tracing as a DBA the procedure need user system identifier
(SID) and serial number (serial#) values from the V$SESSION view.

> select username, sid, serial#

from v$session where username = ‘NAJM’;

USERNAME SID SERIAL#

NAJM 20 2999

Execute command after logging on as SYS.

> execute sys.dbms_system.set_sql_trace_in_session (20, 2999, TRUE);

Managing Trace File Size

Once tracing is activated in a user’s session, every action the user takes against the instance
is included in the trace file output. Trace can grow if tracing is left on for an extended period
of time. The pfile.ora parameter MAX_DUMP_FILE_SIZE allows you to limit the size to which
a user trace file can grow.

Parameter specification Resulting maximum size of user trace

max_dump_file_size=10000 10000 OS blocks
max_dump_file_size=unlimited No limit on file size [DEFAULT]

Page | 30
Password file
The physical file used by Oracle to authenticate database users who are connecting with
SYSDBA or SYSOPER privileges.

Steps to create password authentication file

1. Use ORAPWD utility with SYS password
2. Set REMOTE_LOGIN_PASSWORDFILE parameter EXCLUSIVE/SHARED/NONE
3. Grant users SYSDBA / SYSOPER privileges. When these privileges are granted to any
user, he is added to file.

Values for REMOTE_LOGIN_PASSWORDFILE parameter

EXCLUSIVE = file is used for one database only. SYS or other users with SYSDBA or
SYSOPER privileges entries will be made.

SHARED = share among multiple databases. Only SYS can work.

If connected as SYSDBA connected to SYS schema
If connected as SYSOPER connected to PUBLIC schema.
NONE = Oracle ignores the password file.

Command to create passward file by ORAPWD unility

C:\> orapwd file=<FileName> password=<password> entries=<MaxUersEnteries>

File = name of password file

Password = password of SYS
Entries = max no of users entries
No space around = sign
File is stored in dbs directory of oracle home

C:\> orapwd file=’c:\oracle\pwd.ora’ entries=10 password=syspwd

Entries in the file cannot be modified. To change the entries we must delete and recreate the
password file.

Information of password file can be viewed from v$pwfile_user dynamic view.

> select username, sysdba,sysoper from v$pwfile_users;

USERNAME SYSDB SYSOP

SYS TRUE TRUE
NAJM TRUE FALSE

Page | 31
User Session
A user session is stared when database connection is made. Session is available as long as
user is connected to the database. An ID is assigned to each session. Session identifier (SID)
and serial# uniquely identifies each session. The serial# guarantees that commands are
applied to the correct session object, if the session end and another session begins with the
same SID.

Display all current sessions’ information.

> select username, sid, serial# from v$session;

Display all session but not Oracle runing sessions.

> select sid, serial#, username, status, machine
from v$session where username is not null;

Display user ‘NAJM’ session information.

> select username, sid, serial#, status, program
from v$session where username = ‘NAJM’;

USERNAME SID SERIAL#

NAJM 5 3

How to kill/disconnect a user sessions

Following command will kill username ‘NAJM’ session for which we found SID and SERIAL#
from previous command
>alter system kill session ‘5,3’;

>alter system kill session ‘5,3’ immediate;

>alter system disconnect session ‘5,3’ post_transaction;

When you kill a session, Oracle terminates the session to prevent any more SQL execution.
Statement is terminates when session is terminated and all changes are rolled back. Session
lock and other resources are released.

If inactive session is killed, Oracle terminates the session and mark the status as killed
Subsequently when user tries to use session, error is returned to user and session
information is removed from v$session

If active session is killed with IMMEDIATE option, ongoing transaction is rolled back and
release session locks.

Page | 32
Checkpoint
Periodically Oracle perform checkpoint. DBWn writes all modified data blocks in the instance
buffer cache back to Data Files that contains those blocks. Checkpoint indicates how much of
transaction log entries oracle must apply if simple server crash occurs.

1. Each log switch perform checkpoint

2. When tablespace goes offline. Checkpoints for the blocks of the tablespace.
3. Time based checkpoint
4. Manual checkpoints
>alter system switch logfile;
>alter system checkpoint;

Log_checkpoint_timeout = time between two consecutive checkpoints

Log_checkpoint_interval =
[(log file size /db_block_size)*(db_block_size/os block size)] / # of desired checkpoints b/w log switch

Commit
1. Releases the Locks
2. Rollback segment is freed
3. Trans move from log buffer to log file.

Rollback
1. Move old / rolled back information from rollback segment back to memory
2. Releases the Locks
3. Rollback segment is freed

Page | 33
Connection Request Failure reasons
A connection request may fail for many reasons. Here are a few of most common reasons for
connection failure.

Rejection due to Invalid Net Service Name

If the net service name cannot be resolves, you will receive an error. This code shows that
the user will receive an error because of this rejection.

ERROR:
ORA-12154: TNS:could not resolve service name

If Host Machine name is incorrect in Net Service

ERROR:
ORA-12545: Connect failed because target host or object does not exist

The listener process is not running

If the listener process is not available, the connection will fail. The following code shows the
result from the situation.

ERROR:
ORA-12541: TNS:no listener

The Service Name supplied is invalid

If the user supplies a service name the listener is not listening for, the listener will return an
error. The following code shows the result of connecting with an invalid service name.

ERROR:
ORA-12514 TNS:listener could not resolve SERVICE_NAME given in correct descriptor

The Oracle Instance is not running

The Oracle instance that the user wants to connect to is not available, The connection will be
rejected. Following is an example of this occurrence:

ERROR:
ORA-01034: ORACLE not available

The user supplied an Invalid User ID or Password

If the user supplied an invalid User ID or Password, the connection will be rejected. In this
case the server process on the Oracle Server is created. The server process validates the
User ID and the Password against the known users and Passwords on the database. If no
match is found, the connection fails.

ERROR:
ORA-01017: invalid username/password; logon denied

Page | 34
SQL Statement Execution Steps
When a statement is send to Oracle database server, Oracle server process
- First converts the characters in the SQL statement to ASCII equivalent numeric codes.
- Next, this string of ASCII code is passed through hashing algorithm, which in turn
produces a single hashed value.
- The User Server process then checks to see if that hashed value already exists in the
SQL Area of the Shared Pool.
- If it does, the User’s Server Process uses the cached version of the statement to execute
the statement.
- If the hashed value does not exist in the Shared Pool, The User’s Server Process goes
about the process of parsing the statement, and then executes it.

The Parse step must complete the following tasks:

1. Check the statement for syntactic corrections.
2. Names and structures of the reference objects are checked against the data
dictionary.
3. Gather statistic regarding the objects referenced from data dictionary.
4. Prepare and select an execution plan from available plans.
5. Determine the security of the referenced objects.
6. Generate a compiled version of statement (P-Code)

Instance Recovery at Instance Startup (SMON).

Whenever a commit is executed by a user the relevant transaction is assigned a SCN and
written to Redo Log file from Log Buffer and the transaction number is updated in the Control
file.

1. At Checkpoint DBWr writes dirty blocks of committed transactions from data buffer to data
files.
2. Checkpoint process CKPT, updates the header of all the data files with the last
Transaction number SCN whose data is moved from data buffer to data files.
3. At the server startup SMON compares the SCN in the Control files with the SCN of all the
data files. If any transaction is missing, SMON will run that transaction and will
synchronize the SCN of Data files with that of Control files and the database reached to
consistent state.

Page | 35