Professional Documents
Culture Documents
HAND BOOK
BY
Y.SREENIVASA REDDY
JTO(DOTSOFT)
BASICS OF THE ORACLE DATABASE ARCHITECTURE
Topics
Oracle Instance: All above three structures of the Oracle database server running together to
allow users to read and modify data are referred to as an Oracle Instance.
This set of memory components represent a “Living” version of Oracle that is available
only when the instance is running.
Buffer Cache: The Buffer Cache consists of buffers that are the size of database blocks.
The buffers are designed to store data blocks recently used by the user SQL statements in
order to improve performance for subsequent selects and data changes.
Shared Pool: This has 2 required components and one optional component. The required
components are:
Redo Log Buffer: This stores online redo log entries in memory until they can be written to
disk.
- Oracle has hash value to search for PL/SQL statements in cache area of Library
Cache.
- There is limit for no.of statements to hash.
- The algorithm LRU (Least Recently used) is used to flush out the SQL statements
in Cache.
Benefit of Caching DD is :
- All user processes and the Oracle database internal processes use the DD, the
database as a whole benefits in terms of performance from the presence of cached
DD in memory.
(*) The size of the Library Cache and Row Cache will be internally taken care by
Oracle and user has no control over it.
(*) If there is contention for memory bet’ rib cache and row cache – the row cache is
given priority.
Usage of Database Buffer Cache: The size of this db buffer cache is controlled by the INIT.ORA
Parameter DB_BLOCK_BUFFERS = integer value.
DB_BLOCK_BUFFERS specifies the no. of database blocks that will be there in the db
buffer cache.
The size of database buffer cache is the value of DB_BLOCK_BUFFERS *
DB_BLOCK_SIZE.
Functionality:
- When a user process needs data from database Oracle first checks to see if the required
block is already in the db buffer cache. If it is, it is retrieved from the cache and a disk
I/O operation is avoided.
- Oracle maintains an LRU list of blocks in the cache, when a block is read, its identifier is
moved to the end of the list, making it the last block to be purged from the Cache.
- One exception for this rule is that blocks read as the result of full table scan are placed at
the top of the LRU list. The assumption is that they are unlikely to be requisite again
soon.
- This behavior may be overridden by using the cache clause when creating or updating
table.
(*) if the requested block is not resident in db buffer cache, then a free block must be created.
If the cache is full then the block at the top of the LRU list is removed and the requested block is
read from the disk.
- If the block at the top of the LRU is a “dirty block” – meaning that its data has been
modified – then identifier for that block is moved to dirty list to await processing by the
DBWR process.
- If a free buffer block cannot be located, the DBWR process is notified that its services
required and the dirty blocks are written to the disk.
- When a block of data is not available in the database buffer cache and must be read from
the dist, it is a cache-miss.
- When block is available in the buffer it is cache hit.
- more the db buffer cache, better the hit / miss ratio will be since memory access in orders
of magnitude faster than disk access, most Oracle databases are configured with the
largest possible database buffer cache.
.
(*) Care must be taken not to set DB_BLOCK_BUFFERS so high that paging results, since
paging degrades the performance of the database much more than Oracle I/O operation from
disk.
Redo log buffer: - these redo log buffer holds information about changes to the database, called
redo log entries. These entries are used if database recovery is necessary and they contain
information required to reconstruct changes made by INSERT, UPDATE, DELETE, CREATE,
DROP or ALTER statements.
Functionality:
- It is circular i.e., when it is full entries are written to it from the beginning.
- The LGWR process writes the contents of the redo log buffer to the active redo log file
on disk.
- The site of redo log buffer is determined by the INIT.ORA parameter LOG_BUFFER in
bytes.
(*) The default value of this is 4 times of DB_BLOCK_SIZE but it is often desirable to set
the value higher, particularly if there are many or long transactions generating high rates of redo
generation.
When a SQL statement is executed by user process, the following steps take place :
1. Oracle checks to see if the SQL statement is already in the SQL area. If so, the parsed
version is used for execution. If not, the statement is parsed and placed in the shared
SQL area.
2. A private SQL area is allocated and assigned to the user process.
The user process maintains the private SQL area. The no. of SQL statements that can be
maintained in the private SQL area is limited by the INIT.ORA parameter OPEN_CURSORS,
which has a default value of 50.
NOTE:
- If a user process is connected to the instance via a dedicated server process (i.e. MTS is
not in use), the private SQL area is allocated in the user’s PGA, not in the SGA.
- However, if the process is connected via a shared server process, the private SQL area
will be allocated in the SGA.
CONTROL STRUCTURES: The SGA contains other data required for the operation and control
of the Oracle Instance, including information about the state of database, the instance, locks and
individual process.
This information is shared across all processes for the instance. No user data is stored in
this area.
- The PGA is a memory region that contains data and controls information for single server
process or a single background process.
- It contrasts to SGA, which is shared and written to be several processes.
The PGA is also known as Process Global Areas that is used by only one process.
DBWR :
LGWR :
NOTE: The LGWR performs sequential writes to the redo log file under the following situations
SYSTEM MONITOR (SMON): The System Monitor is responsible for performing the following
operations:
The SMON process wakes up at regular basis to check whether any of these operations
are required. In addition, other background processes can wake up SMON if they require on eof
these services.
- The process recovery when a user process fails, including cache clean up and
freeing of resources the process was using.
- Rollback of uncommitted transactions
- Release of locks held by failed or terminated processes.
- Restart of failed dispatcher and shared server processes.
The PMON process wakes up on regular basis to check whether any of these operations
are required. In addition other background processes can wake up PMON if they require one of
these services.
Other Background Processes: (Optional Processes) : These other background processes may be
active, depending on the Oracle options installed and the specific configuration of the instance.
Check Point Process (CKPT): Always exists in Oracle 8 & Optional in Oracle 7
- CKPT is responsible for updating the headers of all Oracle data files at the time of
checkpoint.
In Oracle 7 this CKPT task may be performed by LGWR,
but if there are many data files in
The database then LGWR performance may be reduced. In such a case, the CKPT
Process can be enabled to perform this task through the use of the
CHECK_POINT_PROCESS Parameter in INIT.ORA.
NOTE : CKPT process does not actually write the updated header records to disk, that is still the
responsibility of DBWR process. i.e. in high activity databases, CKPT can be used to handle
writing log sequence numbers to the data file headers and control file, alleviating LGWR of that
responsibility.
- The ARCH process is us ed to copy the contents of an online log file to another location
typically a disk file, when that log file becomes full.
- When all available online log files become full, the first file is reused.
- The mode of operation whereby the contents of each file are saved prior to reuse is called
archive log mode and is controlled by the ARCHIVELOG parameter in the ALTER
DATABASE Statement.
- The ARCH Process runs only when the instance is running in Archieve log mode.
The Recoverer Process (RECO): The RECO process is used by the Oracle distributed transaction
facility to recover from failures involving distributed transactions by:
Lock Process (LCKn) – One or more lock processes (named LCK0, LCK1,………) are used by
Oracle running with the Parallel Server Option to provide inter-instance locking. For most
Oracle instances, a single process, LCK0 is sufficient.
There are two visions for the DBA to understand Storage Structures of Oracle.
1. The DBA sees the disk utilization of the Oracle Database consisting of logical data
structures. These structures include – Table spaces, segments and extents.
2. Through another vision the DBA sees the physical database files that store these
logical database structures.
Physical View
Logical View
Segments Datablocks
Extents Datafiles
tablespaces
Logical :
1. Table Space: Table Space is a logical database structure that is designed to store other
logical database structures.
2. Segment: Segment is a logical data object that stores the data of a table, index or series of
roll back entries.
3. Extent: An extent is similar to a segment in that extent stores information corresponding
to a table.
However, the difference is that an extent handles table growth when the row data for a
table exceeds the space allocated to it by the segment, the table acquires an extent to place the
additional data in.
Oracle Blocks:
When a data file is assigned to a table space, oracle formats the file into blocks for the
actual storage of data. The size of each oracle block is determined by DB_BLOCK_SIZE
parameter. The oracle block is divided into three distinct segments :
ROW 1
ROW 2
ROW3
Free space
FIXED BLOCK HEADER
The fixed Block Header will be exactly the same size for every block of a table,
regardless of the oracle block size.
Where INITRANS is the value specified for the INITRANS Parameter in the
create table statement when the table is created (default value in 1)
This immediately follows the fixed block header in the block and is dependent on the
no.of rows stored in the block.
The initial 4 bytes contain the table directory and there is 2 byte row directory for each
stored row.
NOTE:
FBH remains constant size for every block of a particular table for most tables in reality
unless INITRANS is specified VBG is dynamic and depends on the no.of rows stored.
The reason : eg : A database having an oracle block size of 2048 (2k) will loose about
3.9% of each block (57 + 3 bytes) to the FBH while a database having 8k block size will lose
only .97% of each block.
More smaller rows in a table will result in less available space in the remainder of the
block than will fewer, larger rows.
Data Storage Area : The balance of the block is used for data storage for example to store the
actual rows of a table The calculation of the available storage in each block is not
straightforward since it is dependent on several factors including :
• Oracle DB_BLOCK_SIZE
• Percent free space (PC TFREE)
• Average row length
• No.of rows stores per block.
The average row length can be estimated as
Here in these calculations the possibility of trailing NULLs Long strings and so on are not taken
into account which may have impact on exact calculations.
EXTENT: AN extent is an amount of storage that is rounded upto the next multiple of the oracle
block size.
INITIAL: This defines how much space will be allocated to the first extent when an object is
created. This may be in k, kb,mb.
EG : INITIAL 1048576
INITIAL 1024k
INITIAL 1m
The default value for initial is the INITIAL value established in the DEFAULT
STORAGE for the table space in which the object is being created.
NOTE: Extent sizes should be specified as integer multiples the Oracle block size; otherwise
allocation is rounded up to the next oracle block. For eg,. With a 2k (2048) block size a request
for INITIAL 4097 results in three oracle blocks being allocated.
NEXT: The next parameter in the storage clause determines how much space will be allocated
for the second and subsequent extents allocated for an object. This NEXT parameter is specified
same as INITIAL parameter.
Although this parameter may be set to specific value that value may be modified
dynamically if the PCTINCREASE parameter is set to a non-zero value.
The default value for the NEXT is the NEXT value established in the DEFAULT
STORAGE for the table space in which the object is being created.
MINEXTENTS:
The MINEXTENTS parameter in the STORAGE clause determines how many storage
extents will be allocated to the object at the time of initial creation. Typically this parameter is
set to 1, but if it is set to a value greater than 1, the second and sub segments extents will use the
NEXT parameter and will be subject to dynamic modification if PCTINCREAE is set to a non-
zero value.
The default value for MINEXTENTS is the MINEXTENTS value established in the
DEFAULT STORAGE for the table space in which the object is being created.
PCTINCREASE:
The PCTINCREASE parameter in the STORAGE clause determines the degree to which
oracle will automatically increase the size of sub segment extent allocations.
This value is expressed as an integer percentage and is applied to the then current value
of NEXT parameter.
NOTE :If the default PCTINCREASE for a tablespace is set to 0, oracle will not automatically
coalesce smaller but contiguous extents back into larger extents in that table space.
As a result oracle may be unable to allocate a particular extent even when sufficient
contiguous blocks are available. So setting PCTINCREASE to a value of 1 will overcome this
problem.
1. Oracle will look in the free space pool for 8k of space to assign as the INITIAL extent for
the table. Assuming a database with 4k-block size, two blocks would be allocated.
2. After providing space for block headers, 10% of remaining space would be reserved for
growth of data rows, as indicated by the PCTFREE 10 parameter.
3. Once the INITIAL extent is filled (in this case, both blocks are filled) oracle looks to the
NEXT extent parameter to determine how much additional space to allocate.
In this case a value of 4k is specified. Since the database has a block size of 4k, a single
block will be allocated and added to the table space allocation. After this extent is
allocated the value of the NEXT will be dynamically increased to 4506 because
PCTINCREASE is set to 10 (i.e. 4096 x 1.10)
4. When the 3rd block is filled, additional space is required. This time Oracle allocates two
blocks, since the current value of NEXT is 4506 and this value is rounded up to next
Oracle block.
Free Lists: When an object (eg. A table) is created one or more oracle blocks are allocated to
that object (here each allocation is called an extent).
Oracle maintains a list of blocks available in each table space called the “free block list”.
As blocks are added to a table, either through the allocation of an additional extent or by deleting
data from an existing block, they are added to the end of the free block list.
Since oracle allocates data to blocks by searching for a free block starting at the
beginning of the free block list, these newly freed or allocated blocks will be the last blocks used.
For each object, oracle also maintains a record of the highest relative block of the table
used to hold data. This high water mark is maintained in multiples of five blocks and is not reset
unless the TRUNCATE command is executed.
MANAGING THE PHYSICAL DATABASE STRUCTURE :
- Oracle opens the statement: Oracle first obtains a cursor or memory address in the library
cache of the shared pool, where the statement will execute. Then oracle obtains some
space in the PGA called a private SQL area, where the statement return values will be
stored.
- Oracle parses the statement: Oracle creates a parse tree or execution plan for the
statement and places it in the shared pool. The execution plan is a list of operations used
to obtain data.
- Oracle creates bind variables: For Select statements, bind variables for return values are
created in the parsed SQL statement. This allows Oracle to share parsed operation but
not data in the shared SWL area in the library cache of the shared pool. For update, insert
and delete commands this step is omitted.
At this point, Oracle performs all processing to complete the specified operation.
Row Migration: If PCTFREE is set to a low value, there may be insufficient space in a block to
accommodate a row that grows as a result of an update. When this happens the Oracle server
moves the entire row to a new block and leave a pointer from the original block to the new
location. This is known as row migration.
When a row is migrated I/O performance associated with this row decreases because the
oracle server must scan two data blocks to retrieves the row.
Row chaining: This occurs when a row is too large to fit into any block. This might occur when
the row contains the columns are very long. In this case, the oracle server divides the row into
smaller chunks called row pieces.
Each row piece is stored in a block along with the necessary pointers to retrieve and
assemble the entire row. Row chaining can be minimized by choosing a higher block size or by
splitting the table into multiple tables with fewer number of columns, if possible.
MANAGING INDEXES
Classification of indexes :
- Logical
• Single column or concatenated
• Unique or non unique
- Physical
• Partitioned or non partitioned
• B-tree or bitmap
- Normal or reverse Key (B-tree only)
- A single column index has only are column in the index key for ex. An index on the
employee no column of an employee tables.
NOTE : The maximum columns in a composite key index is 32. However, the combined size of
all the columns cannot exceed roughly one-third of the data block size.
B-TREE INDEX :
INDEX
ENTRY
ROWID
Key column
value
Although all indexes use a B-tree structure, the term B-tree index is usually associated
with an index that stores a list of ROWIDS for each key.
Structure of a B-Tree Index:
At the top of the index is the toot, which contains entries that point to the next level in the
index. At the next level are branch blocks which in turn point to blocks at the next level in the
index. At the lowest level are the leaf nodes, which contain the index entries that point to rows
in the table. The leaf blocks are doubly linked to facilitate scanning the index in an ascending as
well as descending order of key value.
Database Users :
PERFORMANCE TUNING
The SZ statistic is given in units of page size (normally 4 kb) and normally includes the
shared overhead.
To calculate the private or per process memory usage, subtract shared memory and
executable stack figures from the value of SZ.
Eg. SZ + 20,000
(-) SHM - 15,000
(-) executable - 1,000
--------
Actual per process memory 4,000
-------
i.e. the individual process consumes only 4,000 blocks (pages) the other 16,000 pages are shared
by all processes.
The above goals apply in general to most operating systems but the details of tuning OS
varies.
⇒ Real memory
⇒ Virtual memory
⇒ Expanded Storage
⇒ Disk
The operating system may also move information from one storage location to another.
This process is known as “paging” or “swapping” information that donot fit into real memory.
However, excessive swapping or paging can reduce the performance of many operating systems.
- Because the purpose of the SGA is to store data in memory for fast access, the SGA
should always be within main memory.
- If pages of the SGA are swapped to disk, its data is no longer quickly accessible. On
most operating systems the disadvantages of excessive paging significantly outweighs the
advantages of large SGA.
- Although it is best to keep the entire SGA in memory, the contents of the SGA will be
split logically between “hot” & “Cold” parts.
- The hot parts are always in memory because they are always referenced.
- Some cold parts may be paged out and a performance penalty may result
from bringing them back in.
- A performance problem likely occurs, however, when the hot part of the
SGA cannot remain in memory.
- Data is swapped to disk because it is not referenced. You can cause Oracle to read the
entire SGA into memory when you start your instance by setting the value of the
initialization parameter PRE_PAGE_SGA.
- Operating system page table entries are then prebuilt for each page of the SGA. This
setting may increase the amount of time necessary for instance starting but it is likely to
decrease the amount of time necessary for Oracle to reach its full performance capacity
after startup.
NOTE : This setting does not prevent operating system from paging or swapping of SGA after
it is initially read into memory.
By querying SQC statement SHOWSGA we can see how much memory is allocated to
the SGA and each of its internal structure.
Expanded storage : Some IBM mainframe O/S have expanded storage or special memory in
addition to main memory to which paging can be performed very quickly. The O/S may be able
to page data between main memory and expanded storage faster than oracle can read and work
data between SGA and disk.
For this reason allowing a larger SGA to be swapped may lead to better performance than
ensuring that a smaller SGA remains in main memory. If your OS has expanded storage, take
advantage of it by allocating a larger SGA despite the resulting paging.
On some O/S you may have control over the amount of physical memory allocated to
each user. Be sure all users are allocated enough memory to accommodated the resources they
need to use their application with Oracle.
On some O/s oracle software can be installed so that a single executable image can be
shared by many users. By sharing executable images among users, you can reduce the amount
memory required by each user.
The LOG_BUFFER parameter reserves space for redo log buffer that is fixed in size. On
machines with fast processors and relatively slow disks, the processors tuning private SQL and
PL/QL areas may be filling the rest of the buffer in the time it takes the redo log writer to move a
portion of the buffer to disk. The log writer (LGWR) always starts when the buffer begins to fill.
For this reason, a larger buffer makes it less likely that new entries collide with the part of the
buffer still being written.
The log buffer is normally small when compared with the total SGA size and a modest
increase can significantly enhance throughput.
If this ratio is greater than 1:5000, increase the size of the redo log buffer until the
space request ratio stops falling.
This consists of
- Tuning private SQL areas entails identifying unnecessary parse calls made by your
application and then reducing them. To reduce parse calls, you may have to increase number of
private SQL areas that your application can have allocated at once.
TUNING THE SHARED POOL:
This section explains how to allocate memory for key memory structures of the shared
pool Structures are listed in the order of importance for tuning.
NOTE: If you are using a reserved size for the shared pool, refer to “SHARED_POOL_SIZE
Too small”.
Oracle Alert, Trace Files & Events
Objective :
Diagnostic Information :
• Trace Files
• Events
If an error occurs while your oracle instance is running, the messages are written to alert
log file. During startup of the database, if the Alert log file does not exists, Oracle server creates
one.
The alert log file of a database is a chronological log of messages and errors. Oracle
server uses the Alert log file as an alternative to display such information
Trace files can also be generated by server process at user request to display resource on
consumption during statement processing.
If you are trouble shooting, you need to know when a process has waited for any
resources. Lists of wait events are present in the Oracle server.
Some dictionary views display the events for which sessions had to wait.
OEM Events:
The event manager of OEM allows systematic problem definitions by registering event
sets.
On UNIX, the default value is $ORACLE_HOME/rdbms/log and the name of the file is
alert <SID>.log
The following init.ora parameter controls the location of the background processes trace
files; BACKGROUND_DUMP_DEST.
User trace files can also be generated by server processes at user or DBA request.
The following statement enables the writing to a trace file for a particular session
SQL>EXECUTE dbms_System. Set_sql_trace_in_session (8,12,TRUE), where 8 & 12 are the
SID and SERIAL # of the connected user.
The following statement enables the writing to a trace file for the session of the
connected user SQL>ALTERSESSION SET sql_trace=TRUE
The following initialization parameters control the location and size of the user trace
files.
Where USER_DUMP_DEST defines where trace files will be created at the request of the user
or DBA.
MAX_DUMP_FILE_SIZE specified in O/S blocks, limits the size of user trace files.
On UNIX the default value is $ORACLE_HOME/rdbms/log and the name of the file is
<SID>_ora_<PID>.trc.
On NT, the default value is %ORACLE_HOME%\Rdbms80\Trace and the name of the file is
ora<PID>.TRC.
The MAX_DUMP_FILE_SIZE and USER_DUMP_TEST Parameters are dynamic
initialization parameters.
A collection of wait events provides information on the sessions that had to wait or must
wait for different reasons.
• V$EVENT_NAME View :
- Event #
- name
- parameter 1
- parameter 2
- parameter 3
There are more than 100 waiting events in Oracle servers. These events are listed in
V$EVENT_NAME View.
- Be careful not to confuse the wait events with the EVENT init.ora parameter, nor
with the ALTER SESSION SET EVENTS Command, used to debug the system by the oracle
technical support personnel.
EG:- The actual value of a bind variable is not normally displayed in a trace file. But setting the
following event, however, it becomes possible to see it.
SQL>ALTER SESSION SET EVENTS ‘10046 trace name context forever, 2 level 4’
Level “0” is default, 4 = binds, 8 = waits, 12 = both. The higher the level the larger the trace
files are level 4 should be used normally.
The statistic results of the session that had to wait or are currently waiting for a resource are
stored in V$SESSION_EVENT & V$SESSION_WAIT Views.
This view shows the total waits for a particular event since instance startup.
- If you are troubleshooting, you need to know when a process has waited for any resource.
Therefore, it becomes to query this view each time the system undergoes slowdown.
V$SESSION_EVENT View shows the same above information by session. It includes the
columns listed in the previous page, with an extra column for SID to identify the session. You
can join the SID Column to V$SESSION_SID to find user details.
NOTE : You can query these views directly to find out about all systems waits since startup.
V$SESSION_WAIT View : This view lists the resources for which active sessions are waiting.
Columns description :
• WAIT_TIME :
Value Explanation
>0 : The sessions last wait time
=0 : The sessions is currently waiting
= -1 : The value was less than 1/100 of Second
= -2 : The system cannot provide timing information.
NOTE : Not all the parameter columns are used for all events.
- Monitors for unusual conditions in databases, nodes and network by creating event sets
- automatic problem detection by registering event sets
- automatic problem correction by applying fix it jobs
eg.
1. When a database shuts down, it can generate an alert (such an alert message sent to the
console, your pager no. or your e-mail)
2. When a tablespace is about to run out of free space it can generate an alert.
3. When a particular table approaches or reaches its maximum limit it can generate a
warning or an alert.
All kinds of system-wide statistics are catalogued in V$STATNAME view : around 180
available statistics
Oracle server displays all calculated system statistics in the V$SYSSTAT view. You can
query this view to find cumulative totals since the instance started
Eg : Determine the sessions that consume more than 30,000 bytes of PGA memory.
After running the scripts utilbstat.sql and utilestat.sql as a result the Statistics report
contains
Report.txt
SQL>Spool report.txt;
SQL>Spool ……from stats$lib;
The above topics are discussed in detail later, but now a brief discussion
Library cache contains shared SQl and PL / SQL areas. Tuning this area means reducing
missing or either parse or execute steps in the processing of a SQL or PL/SQL statement
whenever detecting that library cache misses affect the performance of Oracle.
System statistics
This section of the report provides for each system_wide static, a total number of
operations, the total no.of operation per logon. This helps you tuning several areas.
DBWR checkpoint indicates the no.of checkpoint messages that were sent to DBWR.
The increase in I/O during a checkpoint can result in a decrease in performance.
Reduce the number and / or frequency of checkpoint by increasing the init.ora parameter
LOG_CHECKPOINT_INTERVAL.
Consistent gets is the no.of blocks accessed in the buffer cache for queries without the FOR
UPDATE clause.
DB block gets is the no.of blocks accessed in the buffer cache for INSERT, UPDATE and
SELECT FOR UPDATE statements.
Physical reads is the no,.of requests for a block that caused a physical I/O.
You calculate the hit ratio to detect if the size of the database buffer cache is large
enough (or) if it cannot keep often read blocks in memory.
Each system wait event is a context switch which costs CPU time. By looking at total
time, you can often determine what is the bottleneck that processes are waiting for.
Latch statistics
Oracle uses latches to protect access to internet structure such as the library cache for
shared cursors, or the LRU list for data buffer in the buffer cache.
If transactions have to wait to get a slot in roll back header before continuing performance is
decreasing .
This small section indicates if the “buffer busy wait” wait event is high, which class of
blocks is having high contention, data block, segment header or undo header.
Every SQL or PL?SQL statement implies access to dictionary objects and therefore to
the dictionary cache. Misses in the dictionary cache cause an increnase in I/O and a
corresponding decrease in performance.
Tuning this area means displays the gets and misses for each type of item cached.
This section displays how file I/O is spread across multiple disk drives, by counting the
number of physical read / write physical block read / writes and the amount of time spent for
these operations for each data file and table space.
Period of measurement
This section displays the time when utlbstat started to collect begin statistics when
utlestat started to collect end statistics.
TUNING CONSIDERATIONS FOR DIFFERENT APPLICATIONS :
Objectives :
• Use the available data access methods to tune the logical design of the database.
• Identify the demands of online transaction processing systems (OLTP)
• Identify the demands of decision support (DSS) systems
• Reconfigure systems on a temporary basis for particular needs.
OVERVIEW :
The database design process undergoes a normalization stage in which data is analysed
to ensure that no reduldant data is held anywhere. However you amy need to denormalise it for
performance reasons.
The index design ensuring that the data is neither over nor under indexed (this doesn’t
encounter the PK indexes, designed in the previous stage, but additional indexed to support the
application).
- B-tree
- Bitmap
- Reverse
OLTP :
- Availability
- Speed
- Concurrency
- Recoverability
DSS
When you design a DSS you must ensure that queries on large amounts of data can be
performed within a reasonable time.
Multipurpose Applications :
To enhance performance, you can use the following data access methods
⇒ Indexes
Bitmap
Reverse Key
B-Tree
B-Tree indexes improves the performance of queries that select a small percentage of
rows from a table. As a general guidelines, you should create indexes on tables that are often
queried for less than 10% to 15% of the table’s rows. This value may be higher in situations
where all data can be retrieved from an index, or where the indexed columns can be used for
joining to other tables.
INDEX_ORGANISED TABLES :
IOT is like a regular table with index on one or none of its columns, but instead of maintaining
two separate segments for table and B-tree index, the database system maintains one single B-
Tree index which contains both :
- There is no duplication of the values for the primary key column (index
and table column in indexed tables) less storage requirements
- Index organized tables provide faster key based access for queries
involving exact match or range search or both.
IOT are suitable for frequent data access through primary key or through any key that is
prefix of the primary key, such as in applications using inverted indexes used in text searches.
These indexes keep the value and all its locations together. Therefore each word has one entry
and that entry records all the places where the word occurs. Indexed_organized tables are very
efficient mechanisms for modeling inverted indexes.
Row Overflow :
PCTTHRESHOLD CLAUSE
INCLUDING CLAUSE
OVERFLOW CLAUSE
PCTTHRESHOLD CLAUSE :
This clause specifies the percentage of space reserved in the index block for an
index_organized table flow. If a row exceeds the size calculated based on this value, all columns
after the column named in the INCLUDING Clause are moved to the overflow segment. If
overflow is not specified then rows exceeding the threshold are rejected. PCTTHRESHOLD
default to 50 and must be a value from 0 to 50.
Including clause : This clause specifies a column at which to divide an index organized table
row into index and overflow portions. All columns that follow the INCLUDING keyword are
stored n the overflow data segment. If this is not specified and a row size exceeds
PCTTHRESHOLD, all columns except the primary key columns will be moved to the overflow
area. The column is either the name of the last primary key column or any non primary
keycolumn.
OVERFLOW CLAUSE AND SEGMENT : this clause specifies that index organized table data
rows exceeding the specified threshold are placed in the data segment defined by the segments
attributes, which specify the tablespace, storage and block utilization parameters.
SQL> select table name, table space name, iot name, iot type from DBA_TABLES
SQL> select index name, index type, table space name, table name from dba indexes.
SQL> select segment name, table space name, segment type from dba segments
CLUSTERS
Definition : A cluster is a group of one or more tables that share the same data blocks because
they share common columns and are often used together in join queries.
Performance Benefits :
- DISK I/O is reduced and access tune improved for joins of clustered tables
- Each cluster key value is stored once for all the rows of the same key value therefore it
uses less storage.
Performance Consideration : Full table scans are generally slower on clustered tables than on
non-clustered tables.
Cluster Type :
- Index cluster
- Hash cluster
Index cluster : An index cluster uses an index known as cluster index to maintain the data within
the cluster.
• The cluster index must be available to store access or maintain data in an index cluster
• The cluster index is used to point to the block that contains the rows with a given key
value.
• The structure of a cluster index is similar to that of normal index. Although a normal
index does not sotre a NULL key value, cluster index store NULL keys. There is only
one entry for each key value in the cluster index. Therefore they are likely to be smaller
than a normal index on the same set of key values
• To store or retrieve rows from a cluster the Oracle server uses the cluster index to locate
the first row that corresponds to given key value and then retrieves the rows for the given
key.
• If several rows in an index cluster have the same cluster key, the cluster key is not
repeated for each row. In a table with large no.of rows per key value, use of an index
cluster may reduce the amount of space needed to store data.
Hash Cluster : A Hash Cluster uses a function to calculate the location of the row. The hash
function uses the cluster key and can either user defined or system generated:
The hash function is used to locate the row while retrieving the data from a hashed table.
For equality searches that use the cluster key a hash cluster can provide greater
performance gains than an index cluster
• If the table is constantly growing and if it is impractical to rebuild a new large hash
cluster.
• If your application often performs full table scans and you had to allocate a great deal of
space to the hash cluster in anticipation of the table growing.
OLTP Requirements :
- Space Allocation :
• Avoid the performance load of dynamic space allocation allocate space explicitly to
tables clusters and indexes.
• Check growth patterns regularly to find the rate at which extents are being allocated so
that you can plan extents creation.
- Indexing :
Short Transactions :
Transactions are likely to be short, which has consequences for Roll back segment
configuration.
To get the correct number of roll back segments, you need to know about the transaction
pattern. For ex. Consider a system with the following characteristics
There is only a very small mathematical probability that at any given time more than 8
transactions are active. So 8 roll back segments are enough.
The roll back segment extent size can be relatively small (10k if these small transactions
are the only ones on the system)
You will need to set MINEXTENTS to be atleast 10 for small databases and 20 for large
databases because
Integrity constraints :
If there is choice between keeping application logic in procedural code or using declarative
constraints, bear in mind that constraints are always less expensive to process. Referential
integrity and CHECK constraints are the main types to consider here.
Shared Code :
Otherwise, you need to make certain that code is shared by stored procedural objects, such as
packages, procedures and functions.
Bind Variables :
You want to keep the overhead of parsing to a minimum. Try to ensure that the application code
uses bind variables rather than literals.
DSS Requirement
Storage Allocation :
1. DB_BLOCK_SIZE
You should normally set the DB_BLOCK_SIZE parameter to the maximum value
supported for your platform. Even if ithis means recreating a large database, it almost
certainly pays of because a large block size facilitates read extensive operations that are
characteristic of DSS application.
2. DB_FILE_MULTI_BLOCK_READ_COUNT parameter :
It determines during fully table scans how many databases blocks are read with a single
operating system read calls 8 or 8k block size, 4 or 16k block size.
A large value gives cheaper table scan cost and favours table scans over indexes.
• Indexing
Indexing : consider how you can minimize the space and performance overhead of index
maintenance. Since, most queries use full table scans, you could :
Clustering : Both types of clusters are to be considered and especially has clusters for their best
access performance, excluding the tables growing regularly during bulk loads, except if you
have the possibility to recreate the cluster.
Partitioning : Though an option, this feature must be considered for large amounts of data for
which queries concentrate access on rows that were generated recently. It offers partition scan
instead of full table scan.
Parse Time ;
The time taken to parse SELECT statements is likely to be very small proportion of the
time taken to execute the query. Tuning the library cache is much less of an issue for DSS thaw
for OLTP.
Your priority is an optional access path in the execution plan, small variations can cost
minutes or hours. Developers must
• Use parallel zed queries which enable multiple processes to work together simultaneously
to process a single SQL statement symmetric multiprocessor (SMP) clustered or
massively parallel processing (MPP) configurations gain the largest performance benefits
because the operation can be effectively split among many CPUs on a single system.
• Use the explain plan command to tune SQL statements and hints to control access paths.
If your application logic uses bind variables you look the befit of this feature : The
optimizer makes a blanket assumption about the selectivity.
Ex : if you use the following statement, the value of :1 is not known when the optimizer
determines the execution plan.
The optimizer cannot calculate the no. of rows returned by this step exactly. Theis may
mean that the server may use a sub-optional execution plan.
So although it is recommended strongly to use bind variable in OLTP systems with index
access, they are not ideal for decision support systems since there are few opportunities that the
same statement is executed twice.
• Memory use
- SHARED_POOL_SIZE
- DB_BLOCK_BUFFERS These parameter will have higher values for
- SOR_AREA_SIZE day time (i.e. OLTP)
• Parallel query
Parallel query
• Full table scans of large tables can be restricted : use different day time profiles to limit
LOGICAL_REDS_PER_CALL OR CPU_PER_CALL and assign these profiles to users.
• In off-peak time, you can reset these parameters to the appropriate number and reassign
night time profiles to the DSS querying users.
SQL Tuning:
Objectives
Overview:
DIAGNOSTIC TOOLS
• EXPLAIN PLAN
• SQLTRACE
• TKPROF
• AUTOTRACE
EXPLAIN PLAN
SQL>@ORACLE_HOME/rdbms/admin/utlxplan_sql
4. Switch OFF SQL trace. This is necessary to properly close the trace file at the operating
system level (or the TKPROF utility will not provide valid output)
5. Use TKPROF to format the trace file generated during the trace session. Unless the
output file is formatted, it will be very difficult to interpret the results.
6. Use the O/p from TKPROF to diagnose the performance of the SQL statement.
• MAX_DUMP_FILE_SIZE
• USER_DUMP_DEST
• TIMED_STATISTICS
Two parameters in the init.ora file control the size and destination of the output file from
the SQL trace facility.
USER_DUMP_DEST = directory
TIMED_STATISTICS = TRUE
The timing statistics have a resolution of one hundredth of a second. This means that any
operation that takes a hundredth of a second or less may not be timed accurately, especially for
simple queries that execute quickly.
• Instance level :
Setting the SQL_TRACE parameter at the instance level is one method to enable tracing.
However, it requires that the instance be shutdown then restarted when tracing is no longer
needed. This increases significant performance hit, because are sessions for the instance will be
traced.
• Session level : Session level tracing results in less of an overall performance hit, because
Specific sessions can be traced. Three methods for enabling or disabling SQL Trace are :
a) using the ALTER SESSION command, which results in tracing for the duration of
the session or until the value is set to FALSE
b) using the PL / SQL procedure DBMS_SESSION for the session
c) using the PL / SQL procedure DBMS_SESSION to enable tracing for a user
other than the logged in user at the session level systax.
The trace file is created in the directory specified by the USER_DUMP-DEST parameter
and the output is placed in the directory specified by the output file name.
TKPROF
The sum of query and current is the total no.of logical buffer accessed.
ORACLE INSTANCE
OBJECTIVES
SYS user has all of the base tables and views for the data dictionary SYSTEM. This has
additional tables and views are created that contain administrative information used by the
Oracle tools.
DBA users are SYS automatically created and granted DBA Role
SYSTEM
SYS : all the base tables and DD views are stored in SYS scheme
SYSTEM : additional tables and views are created that contain administrative information used
by Oracle tools.
CONNECT / AS SYSDBA
CONNECT / AS SYSOPER
• The use of command CONNECT INTERNAL used with earlier versions of oracle has
been replaced by the new syntax :
• Use the password utility on NT and UNIX to delete and create the password file OR
• Use the ORADIM80 utility on NT to delete and create a new password file.
OPEN
MOUNT
Instance started
SHUTDOWN
- Only during creation of db or recreation of control file we start an instance w/o mounting
a database.
- The DB must be mounted but not opened during
- Startup Command
\ MOUNT
\NO MOUNT]
To open the database from STARTUP NO MOUNT TO MOUNT stage or from MOUNT
to an open stage, use the ALTER DATABASE command
- Once the instance is started in NOMOUNT stage V$views that can be read from memory
are accessible
- views tat read data from control file require the database be mounted the view
V$FIXED_TABLE displays all dynamic performance views.
OPEN
Data Dictionary
MOUNT
Dynamic performance
views reading from memory
SHUTDOWN
Eg : V$PARAMETER
V$SGA
SGA V$OPTION
V$ PROCESS
V$SESSION
V$VERSION
V$INSTANCE
MOUNT STAGE
V$THREAD
V$CONTROLFILE
Control V$DATABASE
File V$DATAFILE
V$DATAFILE_HEADER
V$LOFFILE
DYNAMIC INITIALISATION PARAMETERS :
DD Views :
After the db creation _ catlog.sql & catproc_sql must be run as the user SYS dbmsspool.sql –
enables to display the sizes of the objects in the shared pool and mark then for keeping or
unkeeping in order to reduce shared pool fragmentation.
Each member in a group has identical log sequence numbers which are incremented at
log switch.
The log.seg no is stored in control file and header of all data files.
Create db command :
A checkpoint occurs
There are two ways in which online redo log file can be archived
- manually
- automatically
or V$INSTANCE
- ARCHIEVER
V$LOGFILE
GROUP
STATUS
MEMBER
STATUS - UNUSED
- CURRENT
- ACTIVE
- INACTIVE
When an online redo log group is dropped, the OS files are not deleted.
SIZE Minimum size of redo log file is 50K and max size is OS specific.
Indexes
• Logical
- Single column
- Concatenated / composite
- Unique or non unique
• Physical
- Partitioned
- Non-partitioned
- B-Tree or Bitmap
- Normal or reverse key (B-Tree only)
Type : B-Tree
Reverse key
Bitmap
- Except for SYSTEMS TS or TS having with active RBS, TSs can be taken off line
leaving the db running.
- TSs can be switched between RW_and Readonly status
Creating TS :
CREATE TABLESPACE dotsoft
DATAFILE ‘C:\DOTSOFT\dotsoft1.dbf’ SIZE 100m
‘D:\DOTSOFT\dotsoft2.dbf’ SIZE 200m
MINIMUM EXTENT 500k
DEFAULT STORAGE (INITIAL 500k NEXT 500k
MAXEXTENTS 500 PCTINCREASE 0);
- The max no TSs in database 64k, but no.of TSs cannot exceed the no.of data files.
- The max no.of datafile per TS is 1023
- The MINIMUM EXTENT OPTION can only specified for a TS, not for the storage of
individual objects with this option the DBA controls fragmentation.
n-2
PCTINCREASE
SIZE of the extent = NEXT x 1 + --------------------
n 100
- If MINEXTENTS is specified for a TS, the extents allocated in this TS are multiples of
this parameter.
2nd way
OFFLINE - NORMAL
- TEMPORARY
- IMMEDIATE
MOVING DATAFILES
ALTER TABLE SPACE DOTSOFT
RENAME DATAFILE ‘filename’ to ‘filename’;
NOTE : The source file name should match the names stored in the control file.
VIEW DBA_FREE_SPACE_COALESCED
INITRANS : default value = 1 for data segment
= 2 for Index segment
If transactions are more slot can be allocated from the free space in the block. MAXTRANS
default value 255.
DBA_TABLESPACES
DBA_EXTENTS DBA_FREE_SPACE
Managing Rollback Segments:
RBS stores block information such as file and block ID and aho date (before modified
image)
System
Types of RBS Private (Default)
Non-System
Public
Shrinkage of RBS : Deallocation of extents is not done as soon as transactions are completed.
The process of deallocating extents is performed only when head moves from one extent to the
other. Extents are deallocated if
MINEXTENT integer
MAXEXTENT integer / unlimited
OPTIMAL integer k/m/NULL
RBS Statistics
DBA_ROLLBABK_SEGMENT -----------------
V$ ROLL NAME V$ROLL STAT
Blocking Sessions :
V$ROLLSTAT, V$SESSION, V$TRANSACTION
Get SID, SERIA# and kill the session
username
V$SESSION
Session information
Managing Tables
Structure of a row :
ROWHEADER -- no.of columns in row chaining the info, row lock status
ROW DATA -- column length (1byte, 3 bytes), column value (250 bytes, more
than 250 bytes)
Creating a table :
• If MINEXTENT has been defined for the TS, the extent sizes for the table will get
rounded up to next higher multiple of MINIMUM EXTENT value
• If MINEXTENT > 1 and TS contains more than one data file, the extent will be spread
across the diff. Files in the TS.
Any of the block utilization parameters and some of storage parameters can be modified.
Storage
Block utilization :
If size is omitted, the default value NEXT EXTENT table from DBA_TABLES to allocate new
extent
Above HWM
To release all the space below the HWM even HWM is below MINEXTENTS use KEEP = 0
Init.ora SORTAREA_SIZE
- if a permanent TS is used for sorting an instance may have more than one temporary
segment in TS.
TEMP SEGS IN TEMP TS :
• Known as SORT SEGMENTS
• Only one segment per TS per instance
• Created when first disk sort occurs in the instance after startup
• Released on instance shutdown
The MAXEXTENT clause only affects a temporary segment if the table space is a permanent
space.
V$SESSION V$SORT_USAGE
7 bit USASCII
Single_byte
8 bit EBCDIC
Varying_widthMultibyte
Mixed_width Multibyte
Unicode
- Database character set must be super set of 7 bit ASCII or 8 bit EBCDIC
- Oracle does not support NCS on LONG data type
- Specifying language_dependent behaviour
Init.ora
NLS_LANGUAGE
• Lang. used for oracle messages
• Lang. used for day and month names and their
abbreviations
• Symbols for AD,BC,AM,PM
• The default sorting mechanism
NLS_TERRITORY
• Default date format, decimal character, group separator and
default ISO & local currency symbols
• Day and week numbering
Parameter Values
NLS_LANGUAGE American
• NLS_DATE_LANGUAGE American
• NLS_SORT BINARY
NLS_TERRITORY
• NLS_CURRENCY $ American
• NLS_ISO-CURRENCY $American
• NLS_DATE_FORMAT DD-MM-YY
• NLS_NUMERIC_CHARACTERS DD-MM-YY
SORTING
VIEWS : NLS_DATABASE_PARAMETERS
- PARAMETER info about char.sets
- VALUE
• V$NLS_VALID_VALUES
• V$NLS_PARAMETERS
Managing Users :
Authentication Mechanism
• Database
• Operating System
• Network
[PASSWORD EXPIRE]
[ACCOUNT {LOCK / UNLOCK}]
SYSTEM
PRIVILEGES
OBJECT
System Privilege The ANY keyword in the privilege signifies that users have the privilege in
every scheme.
CREATE CREATE
ALTER SESSION ALTER TS
RESTRICTED DROP
UNLIMITED
NOTE :
1. CREATE TABLE includes CREATE INDEX and the ANALYZE commands. But
the user must have a quota on TS or UNLIMITED TS.
2. UNLIMITED TS cannot be granted to a role
3. For truncating table, the DROP ANY TABLE privilege is necessary
A B C
X
No Cascading Effect
OBJECT PRIVILEGES
Displaying Object privs : To return all object privies granted to the specified user
DBA_TAB_PRIVS DBA_COL_PRIVS
PROFILES :
1. Are assigned to user by the CREATE / ALTER user command
2. can limit system resources on session or call level or both
3. Enforcing the resource limits is not required for enabling Oracle password request
[SESSIONS_PER_USER max_value]
[CPU_PER_SESSION max_value]
[CPU_PER_CALL max_value]
[CONNECT_TIME max_value]
[IDLE_TIME max_value]
[LOGICAL_READS_PER_SESSION max_value]
[COMPOSITE_LIMIT max_value]
[PRIVATE_SGA max_bytes]
COMPOSITE_LIMIT is the weighted sum of
CPU_PER_SESSION
CONNECT_TIME
LOGICAL_READS_PER_SESSION
PRIVATE_SGA
ALTER RESOURCE COST : use to how to specify weightage for each session resource.
SESSION LEVEL CALL LEVEL
CPU_PER_SESSION CPU_PER_CALL
SESSIONS_PER_USER LOGICAL_READS_PER_CALL
CONNECT_TIME
IDLE_TIME
LOGICAL_READS_PER_SESSION
PRIVATE_SGA
OR
RESOURCE_LIMIT = TRUE
OR
ALTER SYSTEM SET RESOURCE_LIMIT=TRUE enables enforcement
FALSE disables enforcement (default)
Altering Profile : ALTER PROFILE Default limit (spes…………)
Password Management :
Features : ACCOUNT LOCKING
PASSOWRD AGING AND EXPIRY
PASSWORD HISTORY
PASSWORD COMPLEXITY AND VERIFICATION
Enabling pwd mgmt : similar to resource limit settings create profile to limit pwd settings and
assign them to users by CREATE OR ALTER USER command.
FAILED_LOGIN_ATTEMPTS
PASSWORD_LOCK_TIME
PASSWORD_LIFE_TIME
PASSWORD_GRACE_TIME
PASSWORD_REUSE_TIME if one is set to default or unlimited.
PASSWORD_REUSE_MAX the other must be unlimited.
PASSWORD_VERIFY_FUNCTION
Viewing PWD Info : - use DBA_USERS to get info about expiration and locking dates and
account status
- query DBA_PROFILE view to display PWD profile info.
This option not available when INSERT INTO VALUES Command is used
This option is available when INSERT INTO SELECT Command is used
This operation maintains indexes and also enforces all enabled constraints
It also enables other users to concurrently modify other rows in the table
All data loaded in this method is placed above HWM. If the table contains many blocks where
rows have been deleted, space may be wasted and full table scans may be slower.
Parallel_direct load
The ALTER SESSION ENABLE PARALLEL DML must be executedat the beginning of
transaction.
The object that is modified using parallel direct insert cannot be queried or modified
again within the same transaction.
Indexes are not maintained by the load drop before parallel load and recreate later
Referential integrity check constraints and triggers must be disabled and have to be reenabled
manually.
Rows can only be appended to existing data. If existing data is to be replaced manually truncate
the table before parallel load.
B & R CONSIDERATIONS :
Business requirement :
• Mean_Time_To_Recover (MTTR)
• Mean time between failures (MTBF)
• Evolving process
Operational Requirements :
• 24 hour operations
• testing and validating backups
• database volatility
- are tables frequently updated
- is data highly volatile (so you need more frequent backups than a business
where data is static)
- does the structure of the database change often
- how often do you add data files.
Technical requirements :
Overview :
• You must restore the data files redo log files and control files from an earlier copy
of full database backup.
• If you used the export utility to backup the database, you can use the import utility
to restore lost data. However, this results in an incomplete recovery and
transactions may be lost.
OBJECTIVES :
Back up methods :
Closed database Open database
Physical backup
Closed DB B’UP
- closed db backup is an OS backup of all the datafiles redo log files control files,
parameter files and the plod file and net 8 configuration files that constitute an oracle db.
- it is not necessary to include the online redo log files as part of a whole database backup.
However, you may want to do this as a safeguard in the event you have to restore the database
since this simplifies the process.
Disadvantages :
• For online business operations the DB should always be available. so closed backup
cannot be performed as it needs shutting down of db.
• The mount of time that the db is unavailable is affected by the size of the db, the no.of
data files and the speed with which the copy operations on the datafiles can be performed.
• A recovery is only as good as the last full closed database backup and lost transactions
may have to be manually entered following a recovery operations.
Failure
- loss of disk, data file or corruption
Recovery
- data files for restore must be offline
- restore only lost or damaged data files
- do not restore the control files, redo logs, password or parameter files
- recover the data files
When media failure occurs with a database in archivelog mode and to completely recover up to
the time of failure, you must have the following :
• A valid backup containing the lost or damaged datafiles after database was set in archieve
mode.
• All archieved logs from the backup you are restoring to the present time.
Recovery steps :
Advantages
o Only need to restore lost files
o No committed data is lost. Restoring the files, then applying archieved and redo
logs, brings the database to the current point in time.
o Recovery time = time to restore lost files and apply all archieved logs
Disadvantages :
You must have all archieved logs from the time of your last backup to the current time.
1. closed DB recovery : For system, rollback segment data files or whole database
2. open database recovery, with DB initially open : for file loss
3. Open DB recovery with DB initially closed : for hardware failure
4. Recover a data file with no backup.
Recovery syntax : When DB is closed
SVRMGR>recover database
SVRMGR>recover data file ‘ /disk1/date/df2.dbf
SVRMGR>alter database recover database
When DB is open :
SVRMGR>recover table space USER_DATA
SVRMGR>recover data file 2
SVRMGR>alter database recover data file 2
Recovery using archieved logs :
• To change archieve location, use the “alter system archieve log ……. Command
• To automatically apply redo log files :
- issue “set autorecovery on “ before starting media recovery.
- Enter “ auto” when prompted for an archived log file
- Use the “recover automatic…..” command.
• Data files are not synchronized if in “hot backup” mode at time of failure.
• Recover the database using one of the methods already discussed.
• Determine what file (s) were in “hot backup” mode at the time of failure
• End the backup on the data files
• Open the DB
This is for situations for dbs in ARCHIVELOG MODE which need to be recovered before the
time of failure
INCOMPLETE RECOVERY :
Reconstructs the database to a prior point in time (before time of failure)
NOTE : This situatins results in loss of data from transactions committed after the time of
recovery. This data need to manually reentered so only perform this recovery when absolute
necessary. So incomplete recovery therefore is a difficult and time consuming operation.
Performing Incomplet Recovery :
• user error
• complete recovery fails because an archived log is lost
• recovery using a backup control file
• loss of all unarchived redo logs and the data file
Advantages :-
Recovery steps :