9ib MANAG

Memory Management
Automated SQL Execution Memory Management

Dynamic SGA
Buffer Cache Advisory
Server-side Manageability Improvemements 1-1

Objectives
After this lesson, you should be able to:

• Outline the benefits of the SQL execution
memory management feature.
• Setup the new PGA’s automatic tuning mode.
• Use new columns and views to support SQL
execution memory management.
• Understand the infrastructure, rules of
operation, and allocation and tracking of
memory behind a dynamic SGA.

Objectives
• Change the sizes of the Buffer Cache, Shared

Pool, and Large Pool without shutting down
the instance.
• Identify new and deprecated parameters in
support of a dynamic SGA.
• Identify the differences between the new and
old Buffer Cache parameters.
• Understand and use the buffer cache advisory
parameter.

Automated SQL Execution Memory
Management

Automated SQL Execution Memory
Management
• The Automated SQL Execution Memory
Management feature simplifies and improves the
way memory is allocated for SQL execution.
• The size of the SQL working areas of memory can
be automatically and dynamically adjusted without
shutting down the database.
• The benefits that this feature provides include:
– Ease of memory tuning
– Reduction of time to tune memory
– Better throughput when large number of users
are on the system
– Improved response time on queries
Automated SQL Execution Memory Management

Benefits Provided By This Feature
Manageability: In Oracle8i, a DBA can control the maximum size of the working areas using various
parameters such as SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE,
and CREATE_BITMAP_AREA_SIZE, but these parameter are difficult to set and tune. This feature
releases the DBA from having to set the various *_AREA_SIZE parameters. It provides automatic
and dynamic memory tuning reducing the amount of time required to set and tune these parameters.
Performance: Since the parameters will be automatically and dynamically adjusted, this feature can
compensate for low or high memory usage, along with controlling the maximum amount of memory a
query can use, which can exacerbate over-allocation of memory and often causes thrashing due to
memory depletion. In addition, memory consuming operations such as Hash-Join, Sort, etc.,
dynamically alter their memory profile to ensure best possible use of system memory and optimal
system performance.
Usability: The above mentioned parameters can often waste PGA memory because more memory is
allocated than is needed. By reducing the amount of memory used, the memory otherwise allocated
can be better put to use by other queries.

Enabling Automated SQL Execution
Memory Management
• This feature introduces an automatic mode for
allocating working areas in the PGA to
maximize the overall system performance.
• Setting the automatic mode is done via the
new session and system level parameter,
WORKAREA_SIZE_POLICY.
• This parameter allows a DBA to select between
automatic or manual tuning of work area sizes.
– MANUAL: Tuning will be done using the
*_AREA_SIZE parameters.
– AUTO: Tuning will be done automatically.
Enabling the Automated SQL Execution Memory Management

WORKAREA_SIZE_POLICY
The MANUAL and AUTO values can be dynamically modified at the instance or session level.
MANUAL MODE: The MANUAL mode is the default. Under the manual mode, tuning will be
done using the existing *_AREA_SIZE parameters.
AUTO MODE: Under the AUTO mode, the work areas will be sized to accomplish three
goals.
Tuned so overall size of the PGA memory never exceeds the value of
PGA_AGGREGATE_TARGET.
Tunable memory allocated by a process will be regulated so that a process never runs out of
memory.
Memory should be allotted to work areas to optimize both throughput and response time.

PGA Memory Management
• PGA memory is classified to differentiate

between tunable and untunable memory.
• Tunable memory is memory consumed by SQL
working areas while untunable memory is the
rest.
• This feature concentrates on the sizing of the
tunable fraction of the PGA memory when the
automatic mode is enabled.
PGA Memory Management

In order to define what part of the PGA memory was affected by the automatic tuning
operation, the PGA was classified to differentiate between tunable and untunable memory.
Tunable vs Untunable Memory
For complex DSS workloads, the tunable memory accounts for most of the PGA memory,
(>90%) and most of the memory used by the instance. In the context of a DSS environment,
managing the tunable fraction is a very effective way to automatically manage the overall PGA
memory consumed by the instance.
In an OLTP system, tunable memory consumed is relatively limited (<1%) of total PGA
memory.

Sizing the Tunable Portion of
PGA Memory
• In the automatic tuning mode, the size of the
tunable portion allocated by an instance
depends on an overall PGA memory target
explicitly set by the DBA via the parameter
PGA_AGGREGATE_TARGET.
• Based on the DBA guidelines set by the
PGA_AGGREGATE_TARGET, the automatic tuning
mode always tries to achieve the following
equation.
UNTUNABLE_MEMORY_SIZE + TUNABLE_MEMORY_SIZE
<= PGA_AGGREGATE_TARGET
Enabling Automated SQL Execution Memory Management

PGA_AGGREGATE_TARGET: A new initialization parameter set by the DBA to specify the
target aggregate amount of PGA memory available to the instance. This parameter is only a
target and can be dynamically modified at the instance level by the DBA. It will accept a
number of bytes, kilobytes (K), megabytes (M), or gigabytes (G).

New Statistics in V$SYSTAT and
V$SESSTAT
Four new statistics have been added to report work

area information.
• PGA WORK AREA MEMORY ALLOCATED (KB)
• WORK AREA EXECUTIONS: OPTIMAL SIZE
• WORK AREA EXECUTIONS: ONE PASS SIZE
• WORK AREA EXECUTIONS: MULITPASSES SIZE
New Statistics in V$SYSTAT and V$SESSTAT

WORK AREA MEMORY ALLOCATED (KB): Total amount of PGA memory dedicated to
work areas allocated on behalf of a given session (V$SESSTAT) or system (V$SYSTAT).
WORK AREA EXECUTIONS - OPTIMAL SIZE: The cumulative count of work areas
which had an optimal size. For example: optimal size is defined if the sort does not need to
spill to disk.
WORK AREA EXECUTIONS - ONE PASS SIZE: The cumulative count of work areas
using the one pass size. One pass is generally used for big work areas where spilling to disk
cannot be avoided.
WORK AREA EXECUTIONS - MULIPASSES SIZE: The cumulative count of work
areas running in more than one pass. This should be avoided and is a symptom of a poorly
tuned system.

Example of Monitoring Private Memory
V$SYSTAT can be used to monitor private memory,

returning a percentage of work areas used with
optimal memory size.
SELECT
trunc( (sum(case when name like ’work area executions –
optimal size’ then value else 0 end) * 100)
/
(sum(case when name like ’work area executions –
optimal size’ then value else 0 end) +
sum(case when name like ’work area executions –
one pass size’ then value else 0 end) +
sum(case when name like ’work area executions –
multipasses size’ then value else 0 end) )
) optimal_percent
FROM v$sysstat
WHERE name like ’work area executions - %’;
Example of Monitoring Private Memory

The above query can be executed at regular interval (e.g. every minute) to monitor how this
percentage evolves.
In AUTO mode, the value of the PGA_AGGREGATE_TARGET dictates how many work areas can run
using optimal memory. If the DBA starts with the ONE PASS memory requirement and slowly
increases the value of the parameter PGA_AGGREGATE_TARGET, the number of cached work areas
(optimal) increases. First, small increase in the value of the aggregate PGA target should lead to big
increase in the number of cached work areas. But at some point, increasing the target is not going to
significantly increase this ratio. At this point, it is probably not worth increasing the size of the
private memory.
Note: The V$SESSTAT view can be used to drill down to a particular session by using the exact
same statistics as shown above in the V$SYSTAT but for each session instead of the whole instance.

New Columns in V$PROCESS
Three new columns have been added to the

V$PROCESS view to report the PGA memory
allocated and used by an Oracle process.
• PGA_USED_MEM
• PGA_ALLOCATED_MEM
• PGA_MAX_MEM
New Columns in V$PROCESS

PGA_USED_MEM: PGA memory currently used by the process.
PGA_ALLOCATED_MEM: PGA memory currently allocated by the process. Allocation
includes free PGA memory not yet released to the OS by the server process.
PGA_MAX_MEM: Maximum PGA memory ever allocated by the process.

New Views to Support
SQL Execution Memory Management
Three views have been created to display SQL

execution memory management information.
• V$SQL_WORKAREA: Displays information about
work areas used by SQL cursors.
• V$SQL_WORKAREA_ACTIVE: Displays an
instantaneous view of the work areas currently
allocated by the system.
• V$SQL_MEMORY_USAGE: Displays memory usage
statistics.

Example Use of V$SQL_WORKAREA
Scenario: Find the top ten work areas requiring the

most cache memory.
SELECT *
FROM
( SELECT workarea_address, operation_type, policy,
estimated_optimal_size
FROM v$sql_workarea
ORDER BY estimated_optimal_size DESC )
WHERE ROWNUM <= 10;

Example Use of V$SQL_WORKAREA
Scenario: Find the percentage of work areas using

maximum memory.
SELECT operation_type,
total_executions*100/optimal_executions "%cache"
FROM v$sql_workarea
WHERE policy = ’AUTO’
AND optimal_executions > 0
ORDER BY operation_type;

Example Use of
V$SQL_WORKAREA_ACTIVE
Scenario: Find the top ten biggest work areas

currently allocated in the system.
SELECT c.sql_text, w.operation_type, top_ten.wasize
FROM ( SELECT *
FROM ( SELECT workarea_address, actual_mem_used
wasize
FROM v$sql_workarea_active
ORDER BY actual_mem_used )
WHERE ROWNUM <= 10 ) top_ten,
v$sql_workarea w, v$sql c
WHERE w.workarea_address = top_ten.workarea_address
AND c.address = w.address
AND c.child_number = w.child_number
AND c.hash_value = w.hash_value;

Example Use of
V$SQL_WORKAREA_ACTIVE
Scenario: Find the percentage of memory that is

over and under allocated.
SELECT total_used,
under*100/(total_used+1) percent_under_use,
over*100/(total_used+1) percent_over_use
FROM
( SELECT sum(case when expected_size >
actual_mem_used
then actual_mem_used else 0 end) under,
sum(case when expected_size <
actual_mem_used
then actual_mem_used else 0 end) over,
sum(actual_mem_used) total_used
FROM v$sql_workarea_active
WHERE policy = ’AUTO’ ) usage;
Example Use of V$SQL_WORKAREA_ACTIVE

Note: Over or under allocated memory can happen because it can take some time for existing work
areas to adapt to a sudden increase in the workload.

Example Use of V$SQL_MEMORY_USAGE
Scenario: Find various pieces of memory information.
SELECT p.value pga_aggregate_target, PGA_inuse,

(PGA_inuse-PGA_auto)*100/PGA_inuse Percent_untun,
PGA_auto*100/PGA_inuse percent_tun,
onepass_req
FROM (SELECT
sum(case when name like ’Total PGA inuse%’
then value else 0 end) PGA_inuse,
sum(case when name like ’Total PGA used for auto%’
then value else 0 end) PGA_auto,
sum(case when name like ’Maximum % one -pass’
then value else 0 end) onepass_req,
FROM v$sql_memory_usage) mem_usage,
v$parameter p
WHERE p.name = ’pga_aggregate_target’;
Example Use of V$SQL_MEMORY_USAGE

The above query returns the current PGA target, the amount of PGA memory used in the system, the
percentage of PGA untunable memory used, the percentage of PGA memory used for work areas
running under AUTO policy, and the amount of memory required for one pass execution. In order to
guarantee good performance, it’s recommended that the DBA ensure that the PGA target is always
higher than the memory size required for one pass. The above query can be executed at regular
interval (e.g. every minute) to monitor the PGA memory consumption.

Dynamic SGA

Dynamic SGA
• The dynamic SGA feature implements an

infrastructure to allow the Oracle server to
change its SGA configuration without shutting
down the instance.
• With a dynamic SGA, the Oracle server can
modify its physical address space use to
respond to the operating system’s use of
physical memory.
• A dynamic SGA provides an SGA that will grow
and shrink in response to a DBA command.
Dynamic SGA
Since its inception, the SGA has always been a static allocation of memory, which was shared
across all Oracle threads of execution. Beginning with Oracle9i, the dynamic SGA
infrastructure will allow for the sizing of the Buffer Cache, Shared Pool, and the Large Pool
without having to shutdown the instance, modify the initialization parameter file, and restart the
instance. In addition, the dynamic SGA infrastructure will allow limits to be set at run time on
how much physical memory will be used for the SGA. Instances will be started under-
configured and allow the instance to use as much memory as the operating system gives it.

Dynamic SGA’s Unit of Allocation
• In the dynamic SGA model, a new unit of

allocation called a granule has been created.
• SGA memory will be tracked in granules by
SGA components.
• A new view, V$BUFFER_POOL has been created
to display granule allocation and de-allocation.
Dynamic SGA’s Unit of Allocation

V$BUFFER_POOL Columns
BLOCK_SIZE: Block size for buffers in this component.
PRIMARY: Primary Block Size (YorN).
BUFFER_POOL: Buffer pool this cache represents. Possible values are DEFAULT, KEEP,
RECYCLE, or NULL (For NonPrimary block sizes.).
TOTAL_SIZE: Present size of the component in MB.
BUFFER: Present # of buffers in this component.
TARGET_SIZE: If a resize in progress, records new target size. Otherwise it is NULL.
LO_SETNUM: Low working set number for this component.
HI_SETNUM: High working set number for this component.

Granule
• A granule is a unit of contiguous virtual

memory allocation.
• The size of a granule depends on the estimated
total SGA size whose calculation is based on
the value of the parameter SGA_MAX_SIZE.
– 4 MB if estimated SGA size is < 128 MB
– 16 MB otherwise
• The Buffer Cache, Shared Pool, and Large Pool
are allowed to grow and shrink based on
granule boundaries.

Allocating Granules at Startup
• At instance startup, the Oracle server allocates

granule entries, one for each granule to
support SGA_MAX_SIZE bytes of address
space.
• As startup continues, each component
acquires as many granules as it requires.
• The minimum SGA configuration is three
granules.
– One granule for fixed SGA (includes redo
buffers)
– One granule for buffer cache
– One granule for shared pool

Adding Granules to Components
• A DBA can grow a component’s SGA use by

issuing an ALTER SYSTEM command to modify
the initialization parameter value.
• Increasing the memory use of a component by
adding a number granules will succeed only if
there are enough free granules to satisfy the
request.
• Another component's granules will not be
freed in order to satisfy the increase.
• If the current amount of SGA memory is less
than SGA_MAX_SIZE, then more granules can
be allocated.

Growing a Components SGA Memory Area
Init.ora parameter values:

MAX_SGA_SIZE = 128M
DB_CACHE_SIZE = 96M
SHARED_POOL_SIZE = 32M
ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

(insufficient memory error message)
ALTER SYSTEM SET DB_CACHE_SIZE = 64M;

(insufficient memory error message)
(check scoreboard to see if shrink has
completed)

Statement processed.
Growing a Components SGA Memory Area
A database administrator grow a component’s SGA use by issuing an alter system command to
modify the init.ora parameters value. Oracle takes the new size, rounds it up to the nearest
multiple of 16MB and adds or takes away granules to meet the target size.
Adding a number of granules to a component (increasing the memory use of a component) with
an with an alter system command will succeed if Oracle has enough free granules to satisfy the
request. Oracle does not start freeing another component’s granules for adding. Instead, the
database administrator must ensure the instance has enough free granules to satisfy the increase
of a component’s granule use. If the current amount of SGA memory is less than
MAX_SGA_SIZE, then Oracle is free to allocate more granules until the SGA size reaches
MAX_SGA_SIZE.
The Oracle server, which invokes the alter system command reserves a set of granules for the
corresponding SGA component (init.ora parameter which defines the component’s SGA use).
After the reservation is complete, the foreground hands the completion to the background
process. The background process completes the operation by taking the reserved granules and
adding them to the component’s granule list. This is also referred to as growing a components
SGA memory area.

Dynamic Shared Pool
• After instance startup the Shared Pool can be

dynamically resized (to grow or shrink) using
the ALTER SYSTEM command.
• The allocation size has the following limits:

– The size must be an integer multiple of the
granule size.
– Total SGA size cannot exceed
SGA_MAX_SIZE.

Dynamic Large Pool
• After instance startup the Large Pool can be

ALTER SYSTEM SET LARGE_POOL_SIZE = 64M;

– The size must be an integer multiple of the
granule size.
SGA_MAX_SIZE.

Dynamic Buffer Cache
• After instance startup the Buffer Cache can be

ALTER SYSTEM SET DB_CACHE_SIZE = 1100M;

– An integer multiple of the granule size.
MAX_SGA_SIZE.
– DB_CACHE_SIZE can never be set to zero.

Buffer Cache Parameter Values
Computed Automatically
• DB_BLOCK_LRU_LATCHES: The number of LRU

latches in each buffer pool for each block size
will be equal to half the number of CPUs.
• DB_WRITER_PROCESSES: The number of
DBWRs will be equal to 1/8 the number of
CPUs.

Deprecated Buffer Cache Parameters
• Three parameters have been deprecated and

will be maintained for backward compatibility.
– DB_BLOCK_BUFFERS
– BUFFER_POOL_KEEP
– BUFFER_POOL_RECYCLE
• If these parameters are set, their values will be
used but a warning message will be made to
encourage the user to migrate to the new
parameter scheme.
• These parameters cannot be combined with
the dynamic size parameters.
Deprecated Buffer Cache Parameters

The present Buffer Cache size parameters DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP ,
and BUFFER_POOL_RECYCLE are maintained for backward compatibility (so users can
continue to use pre Oracle9i parameter files) but are deprecated and will be made obsolete in
the future.
The syntax for the BUFFER_POOL_SIZE parameters allowed the user to optionally specify
the number of LRU latches for the buffer pool in addition to the number of buffers in the buffer
pool. These latches were allocated out of the total number of latches specified in
DB_BLOCK_LRU_LATCHES. Since DB_BLOCK_LRU_LATCHES is now obsolete, the
specification of the number of LRU latches for the buffer pool, if provided, is ignored.
These parameters will continue to be static parameters. Furthermore, these parameters cannot
be combined with the dynamic size parameters. Combining them in the same parameter file
will produce an error.

New Buffer Cache Sizing Parameters
• The Buffer Cache consists of independent sub-

caches for buffer pools and for multiple block
sizes.
• The parameter DB_BLOCK_SIZE determines the
primary block size. The block size used for the
SYSTEM tablespace.
• The following size parameters define the sizes
of the caches for buffers for the primary block
size.
– DB_CACHE_SIZE
– DB_KEEP_CACHE_SIZE
– DB_RECYCLE_CACHE_SIZE
New Buffer Cache Size Parameters

The size of the DEFAULT buffer pool for buffers with the primary block size is defined by the
parameter DB_CACHE_SIZE. In addition, KEEP and RECYCLE buffer pools may be
configured for the primary block size: the parameters for these sizes are
DB_KEEP_CACHE_SIZE and DB_RECYCLE_CACHE_SIZE respectively. Unlike the
previous parameter scheme, DB_CACHE_SIZE does not subsume DB_KEEP_CACHE_SIZE
and DB_RECYCLE_CACHE_SIZE. The values of these parameters are therefore independent
of one another.

Dynamic Buffer Cache Size Parameters
• All Buffer Cache size parameters are made

dynamic and can be changed while the
instance is running via ALTER SYSTEM
command.
• Each parameter is sized independently.
• New cache sizes are set to the next granule
boundary.

Differences Between the New vs Old
Buffer Cache Parameters
• The new buffer cache size parameters are
specified in units of memory rather than in
units of buffers.
• The new value of DB_CACHE_SIZE refers only
to the size of the DEFAULT buffer pool versus
total size of the DEFAULT, KEEP, and RECYCLE
buffer pools.

Buffer Cache Advisory

Dynamic Buffer Cache
Advisory Parameter
• The buffer cache advisory feature enables and
disables statistics gathering for predicting
behavior with different cache sizes.
• The information provided by these statistics
can help DBAs size the buffer cache optimally
for a given workload.
• The buffer cache advisory is enabled via the
initialization parameter DB_CACHE_ADVICE.
– This parameter is dynamic via ALTER
SYSTEM.
– Three values are allowable: OFF, ON,
READY.
Dynamic Buffer Cache Advisory Parameter

DB_CACHE_ADVICE Parameter Values
OFF: Advisory is turned off and the memory for the advisory is not allocated
ON: Advisory is turned on and both cpu and memory overhead is incurred.
Attempting to set the parameter to this state when it is in the OFF state may lead to ORA-4031
(Inability to allocate from the shared pool) when the parameter is switched to ON. If the
parameter is in state READY (below) it can be set to ON without error since the memory is
already allocated.
READY: Advisory is turned off but the memory for the advisory remains allocated.
Allocating the memory before the advisory is actually turned on will avoid the risk of ORA-
4031. If the parameter is switched to this state from OFF, it is possible than an ORA-4031 will
be raised.

New View to Support Buffer Cache
Advisory
• Buffer cache advisory information is collected
in the V$DB_CACHE_ADVICE view.
• The view contains different rows that predict
the estimated number of physical reads for
different cache sizes.
• The rows also compute a physical read factor,
which is the ratio of the number of estimated
reads to the number of reads actually
performed during the measurement interval by
the real buffer cache.
New View to Support Buffer Cache Advisory

V$DB_CACHE_ADVICE Columns
ID: Buffer pool ID (Ranges from 1-8).
NAME: Buffer pool name.
BLOCK_SIZE: Block size in bytes for buffers in this pool. Possible values are the standard
block size, and the power of two non-standard block sizes; 2048, 4096, 8192, 16384, 32768.
ADVICE_STATUS: Status of the advisory.
SIZE_FOR_ESTIMATE: Cache size for prediction (in megabytes).
BUFFERS_FOR_ESTIMATE: Cache size for prediction (in terms of buffers).
ESTD_PHYSICAL_READ_FACTOR: Physical read factor for this cache size; ratio of
number of estimated physical reads to the number of reads in the real cache. If there are no
physical reads into the real cache, the value of this column is NULL.
ESTD_PHYSICAL_READS: Estimated number of physical reads for this cache size.

Summary
In this lesson, you should have learned how to:

• Setup automatic tuning of work areas using
the PGA_AGGREGATE_TARGET and
WORKAREA_SIZE_POLICY initialization
parameters.
• Monitor work area allocation through new V$
views.
• Dynamically modify the sizes of the Buffer
Cache, Shared Pool, and Large Pool via the
ALTER SYSTEM command.
• Allocate granules at startup and add granules
to existing components.

Summary
• Identify new, obsolete, and deprecated

parameters in support of a dynamic SGA.
• Identify the differences between the new and
old Buffer Cache parameters.
• Enable and disable the buffer cache advisory
in order to gather statistics for predicting
behavior of different cache sizes.

Space Management
Oracle Managed Files

Delete Datafiles
Default Temporary Tablespace

Objectives

• Understand the concept and benefits behind
Oracle Managed Files (OMF).
• Create and manage OMF files.
• Use options in SQL syntax to remove
associated OS files when removing a non-OMF
tablespace from the database.
• Create, and alter default temporary
tablespaces.


• Oracle Managed Files (OMF) simplify file

administration by eliminating the need for
DBAs to directly manage the files in an Oracle
database.
• An OMF file is automatically created and
deleted by the Oracle server when needed.
• This new feature has two major thrusts.
– Allows DBAs to create database objects
without specifying the underlying OS file.
– Automatically remove obsolete data files
and online redo logs.

A DBA creates and deletes control files, online redo logs, and tablespaces. The
Oracle server automatically names, creates and deletes the OMF files.
This feature has two major thrusts. The first is to use file system directories rather
than file names for creating control files, data files, and online logs. This simplifies
administration since there is no need to invent a file name. The file system defines
the characteristics of the storage and the pool where it is allocated. A consistent set
of rules are used to name all files. Every new file has a single unique name so it
cannot damage an existing file. Using the same file in two different databases is a
common mistake that can cause very large down times and loss of committed
transactions. Using two different names that refer to the same file is a mistake that
causes major corruptions. The second is automatically removing old control files,
data files, and online logs. Currently a major administrative task is removing files
that are no longer needed on disk. This frequently leads to deleting files that are still
needed. If all file deletions are handled by the Oracle server there will be fewer
mistakes since DBAs will never have to decide if a file should be deleted. A lot of
disk space is wasted on large systems simply because no one is sure if a particular
file is needed any more.

Benefits of Oracle Managed Files
• Eases development of portable applications by

eliminating the need to put OS specific file
names in SQL scripts.
• Simplifies creation and administration of test
and development databases.
• Reduces corruption caused by DBAs
specifying the wrong file names.
• Reduces wasted disk space consumed by
obsolete files.

Oracle Managed File Configurations
• The first and preferred OMF configuration

consists of setting two initialization parameters.
– DB_CREATE_FILE_DEST: set to give the
default location for data files.
– DB_CREATE_ONLINE_LOG_DEST_N: set to
give the default locations for online redo logs
and control files.
• The second configuration exists where all files
(data files, control files, and online redo logs)
are created in the same file system location
defined by the single initialization parameter,
DB_CREATE_FILE_DEST.
OMF Configurations
Two basic OMF configuration exist. The first, a single initialization parameter,
DB_CREATE_FILE_DEST is specified. All the data files, control files, and online logs are created
in the same file system location. The second configuration and the preferred is setting two
initialization parameters. DB_CREATE_FILE_DEST is set to give the default location for data
files. DB_CREATE_ONLINE_LOG_DEST_n is set to give the default location(s) for online logs
and control files. This second configuration provides good separation of data files, online redo logs,
and optional Oracle multiplexing of online redo logs and control files where N is an integer between
1 and 5 (For example: DEST_1, DEST_2, ...DEST_5).

Oracle Managed File Name Structure
• OMF files comply with the Oracle Flexible

Architecture (OFA) and are platform
dependent.
• For example: On Solaris, OMF files are named
as follows:
– Control files: ora_%u.ctl
– Redo log files: ora_%g_%u.log
– Data files: ora_%t_%u.dbf
– Temporary data files: ora_%t_%u.tmp
• OMF file names are accepted in SQL
commands whenever a file name is used to
identify an existing file.
OMF File Name Structure

OMF files will comply with the Oracle Flexible Architecture (OFA). The
following characters are defined as:
%u is an 8 character string that guarantees uniqueness.
%t is the tablespace name, truncated if necessary to fit into the maximum length
file name. Placing the tablespace name before the uniqueness string means that all
the data files for a tablespace will appear next to each other in an alphabetic file
listing.
%g is the redo log file group number.
ora_ identifies the file as an Oracle Managed File.
Undo files do not have a special extension. As with temp files, they are considered
just like any other data files.

Oracle Managed File Example
Scenario: Create a database where control files

and online redo logs are created in separate
Directories and are multiplexed.
• Set the initialization parameters.
DB_CREATE_FILE_DEST = ’/u01/oradata/’
DB_CREATE_ONLINE_LOG_DEST_1 = ’/u02/oradata/’
DB_CREATE_ONLINE_LOG_DEST_2 = ’/u03/oradata/’
• Once the initialization parameters are set, the

database can be created using the CREATE
DATABASE SQL statement.
OMF Example
The DB_CREATE_FILE_DEST parameter sets the default file system directory for the data files
(/u01/oradata).
The DB_CREATE_ONLINE_LOG_DEST_1 and DB_CREATE_ONLINE_LOG_DEST_2 set the
default file system directories for online redo log and control file creation.
Each online redo log and control file is multiplexed across the two directories; /u02/oradata and
/u03/oradata.
Once the initialization parameters are set, the database can be created using the CREATE
DATABASE command. If the command fails, any OMF files created are removed. The internally
generated file names can be seen when selecting from DBA_DATAFILES and V$LOGFILE.

Managing Control Files with OMF
• If the CONTROL_FILES initialization parameter is

not specified at database creation time, the
default control files are created at
DB_CREATE_ONLINE_LOG_DEST_N locations
and thus, are OMF.
• The control file names are uniquely generated
and displayed in the ALERT.LOG file when the
files are created.
• The CONTROL_FILES parameter in the
initialization parameter file must be set to the
generated file names.
Managing Control Files

The CONTROL_FILES parameter in the initialization parameter file must be set to the generated file
names, which can be found by selecting from V$CONTROLFILE. If a persistent parameter file is
used (new Oracle9i feature), the CONTROL_FILES parameter is automatically set and saved when
the database is created.

Managing Online Redo Log Files with OMF
• A complete group can be added with no file

specification.
ALTER DATABASE ADD LOGFILE;
• If a group is dropped, all the corresponding

OMF files are deleted at the OS level.
ALTER DATABASE DROP LOGFILE GROUP 3;
Managing Online Redo Log Files

Adding a Group
To create a new group of online redo log files, the DBA uses the ALTER DATABASE ADD
LOGFILE command. The command has been modified so that the file specification is not necessary.
The above example adds a logfile with a member in the DB_CREATE_ONLINE_LOG_DEST_1
location and a member in the DB_CREATE_ONLINE_LOG_DEST_2 location. Unique file names
for the logfile members are generated automatically.
Dropping a Group
The GROUP clause can be used to drop a logfile. In the above example the OS file associated with
each OMF logfile member is automatically deleted.
Archived Redo Logs and OMF
Archived Redo Log files cannot be OMF files. A file system location for the archived log files can
be specified via the LOG_ARCHIVE_DEST_n initialization parameters. The file names will be
formed based on the LOG_ARCHIVE_FORMAT parameter or its default.

Managing Tablespaces with OMF
• The CREATE TABLESPACE command has been

modified so the DATAFILE clause is no longer
required.
CREATE TABLESPACE TBS1 [DATAFILE SIZE 1M];
• The data file will be created in the file system

specified by DB_CREATE_FILE_DEST.
• By default the created OMF files are 100M in
size and set to autoextend with an unlimited
restriction.
• When tablespace is dropped, all OMF files are
also deleted at the OS level.

Managing Tablespaces with OMF
• An OMF can be added to an existing

tablespace. The ADD DATAFILE command no
longer requires file specification.
ALTER TABLESPACE TBS1 ADD DATAFILE;
• The default file system directory can be

dynamically changed.
ALTER SYSTEM SET
DB_CREATE_FILE_DEST=’/u04/oradata/’;
• This does not change any existing data files,

only future creations.

Delete Datafiles

Delete Datafiles
• This new Oracle9i feature provides automatic

removal of a tablespace’s OS files when
deleting non-OMF tablespaces from the
database.
• Advantages:
– Simplifies the administration of Oracle
databases.
– Reduces corruption caused by DBAs
accidentally removing the wrong operating
system files.
– Reduces disk space consumed by obsolete
files.

Delete Datafiles
The Delete Datafiles feature adds additional

functionality to the following commands in order
to allow the option to remove associated
operation system files from non-OMF files.
• DROP TABLESPACE
DROP TABLESPACE TBS1
INCLUDING CONTENTS AND DATAFILES;
• ALTER DATABASE TEMPFILE

ALTER DATABASE
TEMPFILE ‘disk2:tmp1.dat’
DROP INCLUDING DATAFILES;
Delete Datafiles
DROP TABLESPACE
The DATAFILES option will delete the operating system files associated with the
tablespace.
ALTER DATABASE TEMPFILE
The DROP INCLUDING DATAFILES option will drop the tempfile from the
database and delete the operating system file associated with it. The tablespace
remains. A message will be written to the ALERT.LOG file for each file deleted.
The command will succeed even if an operating system error prevents the deletion
of the file.


• The Oracle9i default temporary tablespace

feature, allows a DBA to specify a database
wide default temporary tablespace.
• This feature eliminates the use of the SYSTEM
tablespace for storing temporary data.
• The default temporary tablespace can be
created using the CREATE DATABASE or ALTER
DATABASE commands.
• When created with the CREATE DATABASE
command the default temporary tablespace
will be of locally managed type, and cannot not
be specified as SYSTEM.

• If a default temporary tablespace is not defined

at database creation, the SYSTEM tablespace
will be the default temporary tablespace and a
warning in ALERT.LOG will be made.
• Once defined, users not explicitly assigned to
a temporary tablespace are assigned to the
default temporary tablespace.

Oracle strongly encourages the creation of a default temporary tablespace when
creating the database in order to move away from using the SYSTEM tablespace for
temporary data.

Create Default Temporary Tablespace
Example of a Default Temporary Tablespace

created at database creation time.
CREATE DATABASE db1

CONTROLFILE REUSE
LOGFILE ‘log1.log’ SIZE 50K
LOGFILE ‘log2.log’ SIZE 50K
DATAFILE
‘df1.dbf’ AUTOEXTEND ON
‘df2.dbf’ AUTOEXTEND ON
NEXT 10M MAXSIZE UNLIMITED
DEFAULT TEMPORARY TABLESPACE dts1
TEMPFILE ‘dts_1.f’ SIZE 20M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;

Alter Default Temporary Tablespace
• The ALTER DATABASE command has been

extended to allow changing the default
temporary tablespace.
ALTER DATABASE db1
DEFAULT TEMPORARY TABLESPACE dts2;
• Users using the old default temporary

tablespace are automatically reassigned to the
new default temporary tablespace.
Alter Default Temporary Tablespace

When migrating from earlier versions of Oracle, the DBA will be able to assign any
temporary tablespace, either dictionary or locally managed, as the default
temporary tablespace using the ALTER DATABASE command.

Restrictions on
• The default temporary tablespace cannot be

dropped until after a new default is made
available.
• Altering the default temporary tablespace to a
permanent tablespace is not allowed.
• The default temporary tablespace cannot be
taken offline.
Restrictions on Default Temporary Tablespace

Dropping a Default Temporary Tablespace
Dropping the default temporary tablespace is not allowed until after a new default
is made available. The ALTER DATABASE command must be used to change the
default temporary tablespace to a new default. The old default temporary
tablespace is then dropped only after a new default temporary tablespace is made
available. Users assigned to the old default temporary tablespace will automatically
be reassigned to the new default temporary tablespace.
Changing to a Permanent Type vs Temporary Type
Since a default temporary tablespace must be either SYSTEM tablespace or a
temporary type tablespace, changing the default temporary tablespace to a
permanent type is not allowed.
Taking Default Temporary Tablespace Offline
Tablespaces are taken offline to make that part of the database unavailable to other
users (i.e., an offline backup, maintenance, or making a change to an application
that uses the tablespace). Since none of these situations apply to a temporary
tablespace, taking a default temporary tablespace offline is not allowed.

Summary

• Create and manage an OMF database.
• Use options in SQL syntax to automatically
remove associated operating system files
when removing a non-OMF tablespace from
the database.
• Create and alter a default temporary
tablespace.
• Identify restrictions on default temporary
tablespaces.

Segment and Index Management
Automatic Segment Free Space Management

Maintaining Global Indexes During DDL
Identifying Unused Indexes

Objectives

• Understand and determine the difference
between a free list managed segment and a
segment with automatic free space management.
• Create a segment with automatic segment free
space management.
• Migrate free list managed segments to automatic
free space management.
• Use new option to update global indexes during
Data Definition Language (DDL) operations.
• Identify unused indexes.

Automatic Segment Free Space
Management

Management
• Automatic Segment Free Space Management
introduces a new scheme of managing free
space inside the database segments.
• Tracking in-segment free and used space is
done via bitmaps as opposed to free lists.
• The benefits provided by this new capability
include:
– Ease of management for DBA.
– Better space utilization.
– Better performance for concurrent INSERT
operations.
Automatic Segment Free Space Management

Benefits
Ease of Use: The use of PCTUSED, FREELISTS, FREELIST GROUPS are
no longer required.
Better Space Utilization: Especially for the objects with highly varying size rows.
Better Concurrency Handling: Better run-time adjustment to variations in
concurrent access.
Better Performance: Improved multi-instance behavior in terms of
performance/space utilization.

Management Methodology
• With bitmap segments, a bitmap describes the
status of each block in the segment with
respect to its fullness.
• The map is contained in a separate state of
blocks referred to as bitmapped blocks
(BMBs).
• When a new row is inserted, the map is
searched for a block with sufficient space.
• When the block becomes more full (or less
full), its new state is reflected in the bitmap.

Management at Work
B Extents BMB
I
T
M BMB BMB
A
P
BMB BMB
S
E
DATA
G
M
E
N
T Block
Automatic Segment Free Space Management at Work

The basic idea behind automatic segment free space management is a bitmap segment. Behind the
bitmap segment a set of control blocks called BMBs exist for every segment (data/index/lob) that
describe the space utilization of the data blocks in that segment. For each data block, there is also a set
of bits per block that provides information about space available in that block.
At a high level, the diagram above illustrates that there is a tree hierarchy of BMBs inside the segment.
The maximum number of levels inside this hierarchy is three. The leaves of this hierarchy represents
the space information for a set of contiguous data blocks that belong to the segment. The BMB leaves
are the unit at which space has affinity to an instance in a multi-instance (Real Application Cluster)
environment. When segments are growing with larger amounts of data being stored in the database, it
becomes prohibitively expensive to search all the leaves of that hierarchy during an insert. Thus, an
intermediate level of BMBs is created to contain meta-data about the leaves. The root level of the
hierarchy, which stores the references to all intermediate BMBs is in fact stored in what was called the
segment header. During an INSERT statement, starting from the root of the hierarchy, the Oracle
server chooses the segment header containing an intermediate BMB to find a useful bit map block,
which will point to data blocks containing free space. These BMBs are acquired in shared mode so that
multiple processes can search into the same BMB. Within an intermidiate BMB, concurrent processes
get distributed by hashing on the instance number and process id. In this kind of BMB’s hierarchy, the
leaves point to a range of data blocks that are potential candidates for the insert operation.

High Water Mark Movement
B
I
T
• Low High Water Mark
M (LHWM) indicates
A blocks below this
P mark are formatted.
S • High High Water
E Mark (HHWM)
G
M
indicates blocks
E above this mark are
N not formatted.
T
LHWM HHWM
Highwater Mark (HWM) Movement

In freelist implementation, the HWM indicates that blocks above the HWM are unformatted and not
available for insertion. The HWM is advanced five blocks at a time when freelist do not contain
insertable blocks.
In bitmapped segments, the presence of unformatted blocks in the middle of the segment is allowed.
First, an extent can be represented by more than one bitmap block and during extent allocation we want
to amortize the cost of formatting data blocks over several inserts. When processes are spread over
several bitmap blocks (hashing), they will format the first range of data blocks they come across in the
bitmap blocks. This naturally leads to holes in the segment where blocks can remain unformatted.
Second, during direct loads, new extents are added above the current HWM. Right after the direct load,
the previous unused blocks are then formatted and put in the segment freelist. During subsequent
reloads into the segment, the blocks from the freelist are not used, instead new extents are added again
above the HWM for use. If a segment is typically direct loaded all the time, it is possible that there are
several unused blocks in the freelists that will never get a chance to be used. This could lead to
tremendous waste of space. Leaving the blocks unformatted instead of marking them as formatted,
gives the ability to reuse the holes.
This leads Oracle to maintain two high water marks stored in the segment header. A Low HWM -
below which all blocks are formatted, and a High HWM above which all blocks are not formatted.
During sequential scans, the unformatted blocks will be ignored. This information about a block being
formatted or not comes only from the bitmaps for blocks lying in between the two HWMs. While
scanning the segment for blocks, the scan algorithm need not consult the bitmaps for blocks below the
Low HWM. The low HWM contains the BMB’s database address. So it is easy to locate the bitmap
block to start scan from. The list of BMBs to scan can be obtained from the extent map. The High
HWM is used by sequential scan algorithms to indicate when to stop scanning.

Creating a Segment with Automatic
Segment Free Space Management
• Automatic segment free space management

can be enabled at the tablespace level only for
locally managed tablespaces.
CREATE TABLESPACE tbs_1
DATAFILE ’tbs1.dbf’ EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;
• PCTUSED, FREELIST, and FREELIST GROUPS

specifications will be ignored.
• Once a tablespace is created with automatic
segment free space management, the
specifications will apply to all segments
subsequently created in the tablespace.
Creating a Segment Managed via Bitmap

Bitmapped segments are specified through the SEGMENT SPACE MANGEMENT AUTO clause,
which cannot be subsequently altered. The specifications of PCTUSED, FREELIST, and
FREELIST GROUPS are ignored if defined.
Segments that can be bitmap managed are heap tables, indexes, IOTs, and LOBs

Modifications to the DBMS_SPACE
Package
• UNUSED_SPACE procedure, which provides the
HWM information may contain un-initialized
blocks below this mark.
• FREE_BLOCKS procedure, which provides
information about free blocks, will return an error
if called on a bitmapped segment.
• SPACE_USAGE a new procedure, added to provide
information about free blocks in the segments
with automatic segment free space management.
Modifications to the DBMS_SPACE Package

UNUSED_SPACE Procedure
LAST_USED_EXTENT_FILE_ID, LAST_USED_EXTENT_BLOCK_ID, and
LAST_USED_BLOCK still refer to the highest used block in the segment (HWM), but some of the
blocks below this mark may be un-initialized. This is not the case with freelist segments. Due to
some new algorithms, when allocating a new extent for a segment, the Oracle server does not format
the corresponding blocks for performance reasons. Thus, it is possible to find unformatted blocks
below the HWM of the segment. In order not to complicate the UNUSED_SPACE procedure, the
information about un-initialized blocks below HWM is presented in a different procedure called
SPACE_USAGE. The Oracle server does not account for unformatted blocks below HWM in
COMPUTE STATISTICS.
SPACE_USAGE Procedure
SEGMENT_OWNER: Schema name of the segment interested in.
SEGMENT_NAME: Segment name.
PARTITION_NAME: Name of an individual partition (NULL for non-partitioned objects).
SEGMENT_TYPE: Type of the segment (TABLE, INDEX, etc).
INSTANCE_NUMBER: Instance number of instance for which information is returned.
FS1_BLOCKS: Blocks below HWM with at least 0 to 25% free space.
FULL_BLOCKS: Blocks which are totally full.

Modifications to DBMS_REPAIR Package
• A new procedure, SEGMENT_FIX_STATUS was

added to provide the capability to fix the
corrupted state of a bitmap entry.
• The bitmap status can be fixed manually using
one of the following options.
– Recalculate the state based on the
corresponding block current contents.
– Set the state to a specific value.
Modifications to DBMS_REPAIR Package

SEGMENT_FIX_STATUS Procedure
SEGMENT_FIX_STATUS is a new procedure that will allow the user to fix the bitmap status
manually.
SEGMENT_OWNER: Schema name of the segment interested in.
SEGMENT_NAME: Segment name.
PARTITION_NAME: Name of an individual partition (NULL for non-partitioned objects).
SEGMENT_TYPE: Type of the segment (TABLE, INDEX, etc).
FILE_NUMBER: Tablespace-relative file number of the block whose status has to be fixed.
BLOCK_NUMBER: File relative file number of the block whose status has to be fixed.
STATUS_VALUE: Value to which the block status described by the FILE_NIUMBER and
BLOCK_NUMBER will be set. If omitted, the status will be set based on the block’s current state.
This should almost always be the case, but if there is a bug in the calculation algorithm, the value can
be set manually.

Views Modified to Support Automatic
Segment Free Space Management
• DBA_TABLESPACES and USER_TABLESPACES:
New column, SEGMENT_SPACE_MANAGEMENT,
added to indicate whether the segment in the
tablespace is managed using free lists or
automatic segment free space management.
• DBA_TABLES: New interpretation for the
BLOCKS, EMPTY_BLOCKS, and PCTUSED columns.
• DBA_SEGMENTS: Values for FREELISTS and
FREELIST_GROUPS columns modified.
Views Modified to Support Automatic Segment Free Space Management

SEGMENT_SPACE_MANAGEMENT Values
MANUAL: Indicates segment space management is via free lists.
AUTO: Indicates segment space management is via automatic segment free space management.
DBA_TABLES
BLOCKS: The number of blocks read by a full table scan.
EMPTY_BLOCKS: Remainder of blocks not read by the full table scan.
PCTUSED: Value will be NULL.
DBA_SEGMENTS
FREELISTS: Value set to NULL.
FREELIST_GROUPS: Value set to NULL.

Compatibility and Migration
• In order to downgrade to a pre Oracle9i release,

tablespaces with automatic segment free space
management must be dropped.
• Tablespaces with automatic segment free space
management can be found using the following
query.
SELECT TABLESPACE_NAME
FROM DBA_TABLESPACES
WHERE SEGMENT_SPACE_MANAGEMENT = ’AUTO’;
• ALTER…MOVE, and CREATE…AS SELECT can be used

to migrate existing free list segments to automatic
segment free space management.
Compatibility and Migration

Automatic segment free space management is only enabled if the COMPATIBLE parameter is
Oracle9i.
Downgrading
In practice, the existing objects (if any) will have to be moved to a tablespace(s) with the freelist
segment management, since no explicit migration is being provided from the automatic free space
management format to the freelist format.
ALTER…MOVE, and CREATE…AS SELECT can be used to migrate existing free list segments to the
automatic free space management format. First, create tablespaces with automatic segment free
space management feature. Secondly, move the objects to new tablespaces. In order to convert
existing data, the user will have to create a tablespace(s) with automatic segment free space
management and move the objects into them. Existing mechanisms, such as ALTER ... MOVE,
and CREATE ... AS SELECT can be used for this purpose. They will work automatically, since
the segments will inherit automatic segment free space management from the tablespace in which
they are created.


Global Index Maintenance During
Partition DDLs
• Oracle9i provides the capability to update a
global index automatically during a DDL via an
optional clause, UPDATE GLOBAL INDEXES.
• The benefits to this new clause include:
– Usability: Partition DDL becomes more
user friendly.
– Availability: Database becomes more
available.
– Manageability: Global indexes are
maintained with the base table.

Prior to Oracle9i, when DDL operations were issued, index partitions that
corresponded to the data partitions affected by the DDL became invalidated. The
DBA was then required to rebuild the indexes. This was not a problem for local
indexes as the DBA only needed to rebuild the local index of the partition(s).
Unlike local indexes, when a partition DDL was performed, even though the
partition DDL might affect only a small fraction of the data in the table, the entire
global index became invalidated and required a DBA to rebuild. In some cases,
this proved to be a very costly operation. Having the capability to automatically
update global indexes during DDL eliminates this problem.
Benefits to Maintaining Global Indexes During DDL
Usability: This feature makes partition DDL’s much more user friendly. This is
because there is no need to look up the names of all invalid global indexes and then
issue DDL’s to individually rebuild them. This feature replaces a two step process
(Step 1: Partition DDL Step 2: Rebuild Index) with a one step process.
Availability: Using this feature will make the database more available. If a
partition DDL is issued and specifies the UPDATE GLOBAL INDEXES clause, all
global indexes are available throughout the operation. In contrast, if one were to
not use this feature, global indexes would be marked invalid. They would remain
invalid until they were rebuilt. In practice this would have a severe
performance/availability impact on applications accessing this partitioned table.
Manageability: Global indexes are maintained in conjunction with the base table.
There is no need to worry about rebuilding global indexes independently.

• UPDATE GLOBAL INDEXES is allowed

immediately after the partition specification
clause and immediately before the parallel
clause.
ALTER TABLE EMPLOYEES
DROP SUBPARTITION EMP1
UPDATE GLOBAL INDEXES
PARALLEL (DEGREE 4);
• The parallel clause will be allowed in

conjunction with the syntax for DROP,
TRUNCATE, and EXCHANGE when updating
global indexes.

For EXCHANGE partition, only global indexes on the table whose partition is being
exchanged will be updated. Indexes for the table being exchanged will continue to
be invalidated.

• UPDATE GLOBAL INDEXES is available when

executing the following partition DDL
statements: SPLIT, MERGE, ADD, MOVE,
COALESCE, MOVE, ADD, DROP, TRUNCATE,
EXCHANGE.
• Only indexes that are valid and in a USABLE
state will be updated.
• The use of this clause is not supported with
the following types of indexing:
– Index Organized Table (IOT).
– Domain

Performance Considerations When
Choosing to Update vs Rebuild
• The partition DDL will take longer to complete

because the global indexes that were
previously marked invalid will now be updated.
• DROP, TRUNCATE, EXCHANGE will no longer
be fast, data-dictionary only, operations
because a scan of all rows in the partition will
be done.
• Updates to the global index will be logged,
hence, redo and rollback will be generated.
• Update index is favorable when the amount of
row work is low.

Performance Considerations When
Choosing to Update vs Rebuild
• Update index ensures application performance

does not drastically fall until the index is
rebuilt.
• Rebuilding the entire index will make the index
more efficient.
• Rebuilding the index allows the the user to
reorganize the index.


• Oracle9i provides the capability to gather

statistics about the usage of an index.
• The benefits afforded with this new feature
include:
– Space conservation.
– Improved performance by eliminating
unnecessary overheads during DML
operations.

Enabling and Disabling Monitoring Index
Usage
• To start monitoring the usage of an index, use
the following statement.
ALTER INDEX EMPLOYEES_idx MONITORING USAGE
• To stop monitoring the usage of an index, use

the following statement.
ALTER INDEX EMPLOYEES_idx NOMONITORING USAGE

New View to Support Identifying
Unused Indexes
• The new view, V$OBJECT_STATS, displays
information about the usage of an index.
• The view contains columns to identify the
index name, corresponding table, whether
monitoring is on or off, whether the index is
being used, and a start and begin monitoring
timeframe.
• Each time the MONITORING USAGE clause is
specified, the V$OBJECT_STATS view will be
reset for the specified index.
• Previous information is cleared or reset, and a
new start time is recorded.
New View to Support Identifying Unused Indexes

V$OBJECT_STATS
INDEX_NAME: The index name.
TABLE_NAME: The corresponding table.
MONITORING: Indicates whether monitoring is ON or OFF.
USED: Indicates YES or NO whether index has been used during the monitoring
time.
START_MONITORING: Time monitoring began on index.
STOP_MONITORING: Time monitoring stopped on index.

Summary

• Create a segment with automatic segment free
space management.
• Use the UPDATE GLOBAL INDEXES option to
update global indexes during a DDL operation.
• Use the MONITORING USAGE clause to begin
monitoring the usage of index.
• Use the V$OBJECT_STATS view to identify
whether an index is being used.

Database Operations and Performance
Automatic Undo Management

Resumable Space Allocation
Multiple Block Size Support
Cached Execution Plans
Persistent Parameter Files

Objectives

• Understand the concept of automatic undo
management.
• Create and maintain UNDO tablespaces.
• Understand the purpose of, and enable or
disable resumable space allocation.
• Create and properly use multiple block sizes
within a database.
• Understand the benefit and use of cached
execution plans.

Objectives
• Identify the differences and benefits between a

persistent parameter file, SPFILE, versus the
traditional parameter file, INIT.ORA.
• Create an SPFILE from an INIT.ORA file and
vice versa.
• Understand the usage and create an SPFILE in
a Real Application Cluster environment.


• The Automatic Undo Management feature

simplifies and automates the management of
rollback segments.
• A DBA now has the choice of managing
rollback segments automatically or manually
by choosing a rollback mode.
• The rollback mode is set by the initialization
parameter UNDO_MANAGEMENT with the values
of {AUTO/MANUAL}.
– If AUTO the instance will manage rollback
segments automatically.
– If MANUAL, DBAs will need to create and
manage rollback segments manually.

Automatic Undo Management Concept
• In the automatic undo management mode,

rollback data is managed via an UNDO
tablespace.
• For each Oracle instance, a DBA will allocate
enough disk space for the workload of the
instance in the UNDO tablespace versus
allocating a number of rollback segments in
different sizes.
• The notion of a single SYSTEM rollback
segment is retained.
– Created automatically within the SYSTEM
tablespace at CREATE DATABASE time.
– It is automatically managed and can not be
taken offline.

With this design, DBAs allocate undo space in a single UNDO tablespace, instead of
distributing them into a set of statically allocated rollback segments. For each
Oracle instance, the DBA will only have to allocate enough disk space for the
workload in that instance, in an UNDO tablespace. A DBA will no longer have to
decide on the different number and sizes of rollback segments to create, and on how
to strategically assign transactions (of different sizes) to individual rollback
segments. A DBA also will not have to adjust the attributes of rollback segments, in
order to juggle between undo block contentions and space utilization issues.

• With automatic undo management, a DBA has

no reason to CREATE, DROP, or ALTER rollback
segments.
• Rollback segments are still used for execution
of transactions but are internally created and
maintained.

UNDO Tablespace
• An UNDO tablespace can be created via the

CREATE DATABASE statement.
CREATE DATABASE TEST
. . .
UNDO TABLESPACE UNDO [DATFILE FILE,…;
• If the UNDO TABLESPACE clause is not specified

during CREATE DATABASE, an UNDO tablespace
with the name SYS_UNDOTBS will be created.
• Size will be operating system dependent.
• AUTOEXTEND will be set to ON
• DBU1<ORACLE.SID>.dbf will be the default
data file name.

UNDO Tablespace
• An UNDO tablespace can also be created using

the CREATE UNDO TABLESPACE command.
CREATE UNDO TABLESPACE UNDOTBS1

DATAFILE 'UNDOTBS1.DBF' SIZE 2M;
• An UNDO tablespace can also be specified at

instance startup using the dynamic parameter
UNDO_TABLESPACE.
• UNDO tablespaces can only be used in the
AUTOMATIC mode for storing rollback
information, are organized internally, and are
of locally managed type.
UNDO Tablespace
Note in the creation of an UNDO tablespace, the DATAFILE clause is the only
clause allowed.
UNDO Tablespace for Real Application Cluster
An UNDO tablespace must be created per instance.

Altering an UNDO Tablespace
• The ALTER TABLESPACE command can be

used to make changes to UNDO tablespaces.
• The following example adds another data file
to the UNDO tablespace.
ALTER TABLESPACE UNDOTBS_1
ADD DATAFILE 'UNDOTBS_2.DBF'
AUTOEXTEND ON;
Altering an UNDO Tablespace

The following clauses are supported when altering an UNDO Tablespace.
•ADD DATAFILE
•RENAME
•DATFILE [ONLINE|OFFLINE]
•BEGIN BACKUP
•ENDBACKUP

Dropping an UNDO TABLESPACE
• The DROP TABLESPACE command can be used

to drop an UNDO tablespace.
DROP TABLESPACE UNDOTBS_2;
• This syntax behaves the same as DROP

TABLESPACE UNDOTBS_2 INCLUDING
CONTENTS.
• An UNDO tablespace can only be dropped if not
currently used by any instance.
• Like dropped MANUAL rollback segments,
readers accessing transactions residing in
dropped UNDO tablespaces may result in
ORA1555.
Dropping an UNDO Tablespace

An UNDO tablespace can only be dropped if not currently used by any instance, its
transaction tables must not contain any uncommitted transactions.
DROP TABLESPACE <TABLESPACE NAME> behaves the same as DROP
TABLESPACE <TABLESPACE NAME> INCLUDING CONTENTS.
Like dropped MANUAL rollback segments, readers accessing transactions residing
in dropped UNDO tablespaces may result in ORA1555, if the snapshot is older than
the DROP-SCN of the UNDO tablespace.

Switching UNDO Tablespaces
• A DBA can switch from using one UNDO

tablespace to another
• Only one UNDO tablespace can be used by an
instance at a time.
• Only one UNDO tablespace can be assigned
active at a time.
• Switching is done by using the ALTER SYSTEM
command.
ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS2;

New Parameters to Support
• UNDO_MANAGEMENT: Specifies weather the

system should use AUTO or MANUAL mode.
• UNDO_TABLESPACE: Specifies a particular
UNDO tablespace to be used.
• UNDO_SUPPRESS_ERRORS: Set to TRUE, this
parameter will suppress errors while
attempting to execute MANUAL operations such
as ALTER ROLLBACK SEGMENT ONLINE while
in AUTO mode.
• UNDO_RETENTION: Controls the amount of
rollback information to retain.

New Data Dictionary View to Support
• V$UNDOSTAT contains information to monitor

how rollback segments are executed in the
current instance.
• This view is available for both MANUAL or AUTO
mode.
New Data Dictionary View to Support Support Automatic Undo

Management
Columns in V$UNDOSTAT
ENDTIME: Indicates the end of a time interval marked. The rows are ordered
descending by this column.
UNDOBLOCKSUSED: Represents the total number of undo blocks consumed.
Used to obtain consumption rate of undo blocks, and to estimate the size of the
undo tablespace needed to handle the workload of the system.
TXNCONCURRENCY: Represents the maximum number of transactions executed
concurrently. Used as a reference for users to understand the level of concurrency
in the current system.
TXNTOTAL: Shows the total number of transactions executed within the period.
QUERYLENGTH: Represents the maximum length of queries executed in the
instances.
EXTENTSSTOLEN: Shows the number of times an undo extent has to be
transferred from one undo segment to another within the period.
SSTooOLDERROR: Shows the number of OER (Snapshot Too Old) errors
occurred within a period.

New Data Dictionary View to Support
• This V$UNDOSTAT example illustrates how

undo space is consumed in the system for the
previous 24 hours from time 16:07.
End-Time UndoBlocks Txn Concrcy TxnTotal QueryLen ExtenStolen SSTooOldError
16:07 252 15 151 25 2 0
16:00 752 16 1467 150 0 0
15:50 873 21 1954 45 4 0
15:40 1187 45 3210 633 20 1
15:30 1120 28 2498 1202 5 0
15:20 882 22 2002 55 0 0
…
New Data Dictionary View to Support Automatic Undo Management

V$UNDOSTAT
The example above illustrates the peak undo consumption happened at the interval
of (15:30, 15:40), 1187 undo blocks were consumed in 10 minutes (or about 2
blocks/second). Also, the highest transaction concurrency occurred during that
same period with 45 transactions executing at the same time. The longest query
(1202 seconds) was executed (and ended) in the period (15:20, 15:30).


• The resumable space allocation feature

provides the ability to suspend, fix, and
resume execution of large database operations
in the event of correctable errors.
• Benefits to resumable space allocation
include:
– Provides support for errors related to space
limits and out-of-space conditions.
– Provides an opportunity to take the
corrective steps to resolve the error and
automatically continue operation when the
problem is fixed.

Large operations routinely may run out of space or reach space limits after
executing for a long time. When this condition occurs, the operation is rolled back
and the error is returned to the user. With the resumable space allocation feature,
the Oracle server will suspend these large operations that run into correctable
problems. Suspending the operation gives the DBA an opportunity to take the
corrective steps to resolve the error condition. Once the error condition disappears,
the suspended operation automatically resumes the operation’s execution.

Enabling and Disabling Resumable Space
Allocation Mode
• To make a session resumable enabled.

ALTER SESSION ENABLE RESUMABLE
[TIMEOUT timeout] [NAME name];
• To disable resumability of subsequent

operations.
ALTER SESSION DISABLE RESUMABLE;
• A new system privilege, RESUMABLE, has been

added to allow the ability to use the resumable
space allocation feature.
Enabling and Disabling Resumable Space Allocation Mode

Enabling Mode
The NAME clause is a user defined text string that will be inserted into the USER/DBA_RESUMABLE
view.
Resumable System Privilege
Because a suspended operation will hold up some system resources, a new RESUMABLE system
privilege is added so that a DBA can decide who can execute resumable operations.

Altering Resumable Space Allocation
• A suspended operation is aborted if the error

is not fixed within the specified TIMEOUT
seconds. TIMEOUT can be altered using ALTER
SESSION or DBMS_RESUMABLE.
ALTER SESSION ENABLE|DISABLE RESUMABLE
[TIMEOUT]
Call DBMS_RESUMABLE.SET_SESSION_TIMEOUT
(sessionID, timeout)
Call DBMS_RESUMABLE.SET_TIMEOUT(timeout)
• Altering resumable name within a session.

ALTER SESSION ENABLE|DISABLE
RESUMABLE NAME 'new name';
Altering Resumable Space Allocation

TIMEOUT Seconds
A suspension time out interval is associated with every resumable operation. The
default is two hours and it can be set to any value using ALTER SESSION
ENABLE RESUMABLE TIMEOUT <timeout period in seconds>
command or calling upon the new DBMS_RESUMABLE package.
DBMS_RESUMABLE Package
The DBMS_RESUMABLE package helps to control the resumable operation via the
following procedures.
ABORT(sessionID): Aborts a suspended resumable operation.
GET_SESSION_TIMEOUT(sessionID): Returns current timeout value in
seconds of resumable operation for session with sessionID.
SET_SESSION_TIMEOUT(sessionID, timeout): Sets a new timeout
setting immediately of resumable operation for session with sessionID.
GET_TIMEOUT(): Returns current timeout value of resumable operation for
current session.
SET_TIMEOUT(timeout): Sets timeout of resumable operation for current
session.
Note: It is not possible to use this package to enable resumable operation in a
particular session. Instead, DBAs can create a logon trigger that will enable this
feature by using an ALTER SESSION command.

Life Cycle of Resumable Space Allocation
• Resumable space allocation is enabled using

the ALTER SESSION ENABLE RESUMABLE
command.
• Resumable operation is suspended under one
of the following conditions:
• Out of space
• Max extents reached
• Space quota exceeded
• The error is reported in the ALERT.LOG.
• A trigger is executed, if it has been registered
on the AFTER SUSPEND system event.

Suspending an operation automatically results in suspending the transaction, therefore, all
transactional resources are held through an operation suspend and resume.
Resumable Operations
Queries: Select statements that have run out of temporary space.
DML: INSERT, UPDATE, DELETE
SQL*Loader: When invoked with the resumable option.
Import/Export: When invoked with the resumable option.
DDL: CREATE TABLE AS SELECT, CREATE INDEX, ALTER INDEX REBUILD,
ALTER TABLE MOVE PARTITION, ALTER TABLE SPLIT PARTITION, ALTER
INDEX REBUILD PARTITION, ALTER INDEX SPLIT PARTITION, CREATE
MATERIALIZED (SNAPSHOT) VIEWS, CREATE MATERIALIZED(SNAPSHOT) VIE W
LOG.

• Error condition is fixed.

• The suspended operation automatically
resumes.
• A resumable operation may be suspended
and resumed multiple times during
execution.
• A DBA can abort a suspended operation any
time using DBMS_RESUMABLE.ABORT() or
ALTER SESSION KILL.
• DBMS_RESUMABLE.ABORT() only aborts
the suspended operation.
• ALTER SESSION KILL kills the session.

AFTER SUSPEND System Event
• An AFTER SUSPEND trigger is fired when a

resumable operation encounters a correctable
error.
CREATE OR REPLACE TRIGGER RES_DEFAULT
AFTER SUSPEND ON DATABASE
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
/* SEND AN EMAIL TO NOTIFY DBA */
COMMIT;
END;
• SQL statements executed within an AFTER

SUSPEND trigger are always non-resumable.
AFTER SUSPEND System Event

A DBA may create a trigger on this system event. Whenever a resumable operation is suspended,
the AFTER SUSPEND trigger is executed. Inside the trigger, the DBA may access information
regarding the suspended operation from the DBMS_RESUMABLE package.
The trigger must be declared as an autonomous transaction. The autonomous transaction uses a
rollback segment in the SYSTEM tablespace. Done to reduce the chance of running into the same
error as the user statement.
The trigger may encounter the following errors.
Deadlock with a lock held by the user transaction, which is executing the resumable operation. This
may happen if the trigger attempts to update a row locked by the user transaction. The Oracle server
detects the deadlock, rolls back work done in the trigger and throws the original exception to the
user. Thus, if trigger deadlocks (self locks) with the user transaction, the result is that of not
suspending the operation. Also, the deadlock is also pushed under the user error.
Out of space or space limit reached condition. If trigger throws these errors, it does not get
suspended, instead the trigger and the resumable operation are aborted. Note, an exception handler
may be inside the trigger to clear the error, in order not to abort the suspended operation.

New Dictionary Views to Support
• Two new views have been created to support
resumable space allocation.
– USER_RESUMABLE: Lists resumable
operation being executed by the user.
– DBA_RESUMABLE: Lists and monitors
progress on all resumable operations being
executed in the system.
• These views contain all currently executing or
suspended resumable operations.
New Dictionary Views to Support Resumable Space Allocation

Information in these views are not persistent.
Columns in USER/DBA_RESUMABLE
USER_ID: ID # of resumable operation owner. (DBA_RESUMABLE only)
SESSION_ID: Session ID of resumable operation.
INSTANCE_ID: Instance ID of resumable operation.
COORD_SESSION_ID: Session ID of Parallel Coordinator.
COORD_INSTANCE_ID: Instance ID for running Parallel Coordinator.
SQL_TEXT: Resumable operation selected from V$SQL view.
NAME: Name given in the resumable operation clause to identify resumable
operation.
STATUS: Can be RUNNING, SUSPENDED, ABORTING, ABORTED,
TIMEOUT.
ERROR_NUMBER: Holds error code of the last correctable error.
ERROR_MSG: Error message corresponding to ERROR_NUMBER.
ERROR_PARAMETER1 – 5: 1st, 2nd, 3rd, 4th, 5th parameter for the error message.
NULL if no error.
Start_TIME: Start time of the transaction which invoked the resumable
operation.
SUSPEND_TIME: Last time the resumable operation was suspended.
RESUME_TIME: Last time the resumable operation was resumed.
TIMEOUT: Timeout of resumable operation.


• Oracle9i supports the creation of databases

with multiple block sizes.
• The benefits to this feature include:
– Ability to locate objects in tablespaces of
appropriate block size in order to maximize
I/O performance.
– Ability to transport tablespaces between
databases with different block sizes.
(OLTP to Warehouse)

• An Oracle database can be created with a

standard block size and up to five non-
standard block sizes.
• Block sizes can have any power-of-two value
between 2K and 32K.
– 2K, 4K, 8K, 16K, 32K
– ORA-382: N not a valid block size.
• A BLOCKSIZE column has been added to the
DBA_TABLESPACES and USER_TABLESPACES
views.

Standard Block Size
• The standard block size is set during database

creation using DB_BLOCK_SIZE parameter and
cannot be changed subsequently without
recreating the database.
• The standard block size is used for the system
tablespace.
• DB_CACHE_SIZE specifies the size of DEFAULT
buffer pool for standard block size.
– Minimum size equals the size of one
granule (4MB or 16 MB)
– The default value is 48M.

Non-Standard Block Sizes
• To enable the usage of non-standard block

sizes in the database, corresponding
additional caches need to be configured.
– DB_2K_CACHE_SIZE used for 2K blocks
• These parameters are dynamic, therefore, their
values can be changed without shutting down
and re-starting the instance.

• Parameter DB_nK_CACHE_SIZE can be used

only if n is not the standard block size,
otherwise an ORA-380 will be received.
• Each sub-cache is sized independently of
others and can be specified in K, M or G bytes.
• The value of DB_nk_CACHE_SIZE can be set to
zero if there is no online tablespace with the
nK block size.
• The default size of all DB_nK_CACHE_SIZE is
0M.

ORA-380: cannot specify DB_nK_CACHE_SIZE since nK is
the standard block size.

• If set, DB_nk_CACHE_SIZE has a minimum size

of of one granule (either 4or 16 MB).
• It is not possible to make use of old and new
buffer parameters simultaneously.
– DB_BLOCK_BUFFERS, BUFFER_POOL_KEEP,
and BUFFER_POOL_RECYCLE cannot be
used with the new parameters of
DB_NK_CACHE_SIZE.
– ORA-381: Cannot use both new and
old parameters for buffer cache
size specifications.

Sizing KEEP and RECYCLE Buffer Cache
• The KEEP and RECYCLE buffer caches can only

be created for the standard block size
(db_block_size).
• These caches are sized using the parameters:
– DB_KEEP_CACHE_SIZE
– DB_RECYCLE_CACHE_SIZE
• The parameters BUFFER_POOL_KEEP and
BUFFER_POOL_RECYCLE are deprecated in favor
of those mentioned above.
– A warning message will be written to the
alert log while using these parameters.
– Remain to be static.

Sizing KEEP and RECYCLE Buffer Cache
• DB_CACHE_SIZE does not include the size of

KEEP and RECYCLE.
• The equation is as follows:
Total Buffer Cache size =
DB_CACHE_SIZE
+ DB_KEEP_CACHE_SIZE
+ DB_RECYCLE_CACHE_SIZE
+ Non-Standard Block Size Sub-Cache

Creating a Non-Standard Block Size
Tablespace
• Tablespaces of non-standard block sizes can be

created using the CREATE TABLESPACE
command with the new BLOCKSIZE keyword.
CREATE TABLESPACE tbs_1
DATAFILE 'tbs_1.f' SIZE 10M BLOCKSIZE 4096;
• The block size can also be specified in kilobytes.

CREATE TABLESPACE tbs_8k
DATAFILE 'tbs_2.f' SIZE 10M BLOCKSIZE 8K;
• A BLOCKSIZE field has been added to

DBA_TABLESPACES and USER_TABLESPACES.
Creating a Non-Standard Block Size Tablespace

The statement above creates a new tablespace called tbs_1 with the file
file_1.f having a block size of 4K. In order for this statement to succeed, the
buffers of size 4K must currently be configured in the buffer cache.

Multiple Block Sizing Rules
• All partitions of a partitioned object must

reside in tablespaces of the same block size.
• All temporary tablespaces, including
permanent being used as default temporary
tablespaces, must be of standard block size.
• Index Organized Table (IOT) Overflow and out-
of-line LOB segments can be stored in a
tablespace with a block size different than the
base table.


• The cached execution plans feature enables

the Oracle server to preserve the actual
execution plan of a cached SQL statement in
memory.
• Once the SQL statement ages out of the
Library Cache, the corresponding cached
execution plan will be removed.
• The main benefit of this feature is better
diagnosis of query performance.

New View to Support
• A new dynamic performance view,

V$SQL_PLAN, stores actual execution plan
information for.
• The view contains all of the PLAN_TABLE
columns (with the exception of the LEVEL
column) in addition to seven new columns.
• Columns that are also present in the
PLAN_TABLE will have the same value as those
in V$SQL_PLAN.
New View to Support Cached Execution Plan History

The V$SQL_PLAN view will store the actual execution plan information for a
cached cursor. The view contains all of the Plan Table columns with the exception
of the LEVEL column and seven new columns. The columns present in the Plan
Table will have the same values as those in the V$SQL_PLAN.
Additional V$SQL_PLAN Columns Not Found in the PLAN_TABLE
ADDRESS: Cursor parent handle address.
HASH_VALUE: Parent statement hash value in Library Cache.
CHILD_NUMBER: Number using this execution plan.
DEPTH: Level of the operation in the tree.
CPU_COST: CPU cost of the operation as estimated by Cost Based Optimizer. If
using the Rule Based Optimizer this column is NULL.
IO_COST: Cost of the operation as estimated by the Cost Based Optimizer. If
using the Rule Based Optimizer this column is NULL.
TEMP_SPACE: Space usage of sort or hash-join estimated by Cost Based
Optimizer.

New Column Added to V$SQL to Support
• A new column, PLAN_HASH_VALUE has been

added to the V$SQL view.
• The column information is a hash value built
from the corresponding execution plan.
• The column can be used to compare cursor
plans the same way the HASH_VALUE column
is used to compare cursor SQL texts.

Persistent Parameter File

Persistent Parameter File (SPFILE)
• A new parameter file called SPFILE has been

introduced to store instance parameters
persistently by the server.
• The benefits afforded by this new parameter
file include:
– Provides ability to make changes to
parameter values (via the ALTER SYSTEM
command) persist across shutdown and
startup.
– Allows use of a single parameter file by all
members of a Real Application Cluster.

Maintaining the SPFILE
• The SPFILE always resides on the server side.

• The default server side location is
$ORACLE_HOME/DBS directory.
• The default name is SPFILE<SID>.ora.
• The SPFILE is automatically maintained by the
Oracle server.
• Front end tools (OEM, SQL*Plus) need not
specify a parameter file if using the default
SPFILE.

Parameter Values within an SPFILE
• All changes made to the values of parameters

using the ALTER SYSTEM command will be
recorded in the SPFILE.
• A DBA can specify whether the change being
made is temporary or persistent.
• A parameter value from the SPFILE can be
deleted or reset to allow an instance to revert
back to the default value of that parameter.

STARTUP Command Behavior
• The default SPFILE name is used to startup the

instance. If the default SPFILE is not found, it
will attempt to start the instance using the
default INIT.ORA file on the server side.
STARTUP
• The specified INIT.ORA file will be used to

startup the instance. However the PFILE can
optionally contain a definition to indicate use
of an SPFILE.
STARTUP PFILE = $ORACLE_HOME/DBS/INITDBA1.ora

Creating an SPFILE
• An SPFILE can be created from an INIT.ORA

file using the CREATE SPFILE command,
which can be executed before or after instance
startup.
CREATE SPFILE [='SPFILE-NAME']
FROM PFILE[='PFILE-NAME'];
• Where:
– SPFILE-NAME: is the name of the SPFILE
to be created. If not specified, the default
SPFILE name is assumed.
– PFILE-NAME: is the name of a PFILE
which must be available on the server side.

Creating an SPFILE
• The comments specified on the same lines as

a parameter setting in the PFILE will be
maintained in the SPFILE. All other comments
will be ignored.
• The CREATE SPFILE command requires
SYSDBA role to execute.

Exporting an SPFILE
• The contents of a SPFILE can be exported into

an old-style PFILE.
CREATE PFILE[='PFILE-NAME']
FROM SPFILE[='SPFILE-NAME'];
• This command requires the SYSDBA role to

execute.
• If an SPFILE-NAME is not specified, the default
SPFILE name will be used.
• The PFILE will be created as a text file on the
server side.
• This can be executed either before or after
instance startup.
Exporting an SPFILE
The contents of an SPFILE can be exported into an old-style PFILE in order to
make modifications to the SPFILE by first exporting it, editing the output file, then
recreating it.
Exporting an SPFILE to a PFILE can also be used to create backups of the
persistent parameter file. NOTE: With Oracle9i, this would be a secondary
method as RMAN can also backup persistent parameter files.
Lastly, exporting an SPFILE can be used to provide a list of parameter values
much the same as SHOW PARAMETER.

SPFILE and Real Application Cluster
Environments
• In order to simplify the management of a Real

Application Cluster, a single SPFILE can be
used to start the entire Real Application
Cluster.
• It is possible to have more than one SPFILE on
a node. However, only one of the SPFILEs can
be used at a time.
• Oracle9i will support traditional PFILE
(INIT.ORA) files that can be different for
different Real Application Cluster instances.
SPFILE and Real Application Cluster Environments

Real Application Cluster, formerly known as Oracle Parallel Server (OPS).

SPFILE and Real Application Cluster
Environments
• If a SPFILE is used it must be the same on all

instances.
• The SPFILE must reside on a shared device,
since it must be accessible from each instance
node.
• Instance specific parameter settings can be
specified by qualifying the parameters with
ORACLE_SID. For Example:
– SID1.PAR_1 = V1
– SID2.PAR_1 = V2
– *.PAR_2 = V2
SPFILE and Real Application Cluster Environments

New Form of Specifying Parameters Using ORACLE_SID
The value V1, in the example above, is applied to parameter PAR_1 when the
instance is started with SID1. The value of V2 is applied to parameter PAR_1
when the instance is started up with SID2. Parameter *.PAR_2 takes the value
V2 for all instances since a SID of * is considered special and the value specified in
the parameter setting is applied to all the SIDs.

Creating an SPFILE for Real Application
Cluster Environments
• For Real Application Cluster environments, a
single SPFILE needs to be created by
combining all the instance specific PFILEs.
– Copy all shared IFILE contents as is. All
the parameters defined in the IFILE are
database wide and should be created as
PARAMETER=VALUE (without any SID prefix).
– Copy all instance specific parameter
definitions as SID.PARAMETER=VALUE.
– Use CREATE SPFILE syntax.

New View to Support SPFILE
• A new view, V$SPPARAMETER, has been

created to present the contents of the SPFILE.
• Columns in V$SPPARAMETER
– SPSID: SID for which parameter is defined.
– SPNAME: Parameter name.
– SPVALUE: Parameter value.
– ISDEFAULT: Is parameter specified in
SPFILE.
– ISMODIFIED: Modified via ALTER SYSTEM
or ALTER SESSION.
– ORDINAL: Ordinal number of value if in list
of strings.
– UPDATE_COMMENT: Last update comments.
V$SPPARAMETER
The view will return NULL values if a PFILE was used to startup the instance.

Views Modified to Support SPFILE
• A new column, UPDATE_COMMENT, which

provides comments associated with the most
recent update of an SPFILE has been added to
V$PARAMETER and V$PARAMETER2.
• The SID column has been removed from
V$PARAMETER and V$PARAMETER2, since
parameters within an SPFILE will not be
identified by specific instances in a Real
Application Cluster.
• A new column, ORDINAL, has been added to
V$PARAMETER2, to display the ordinal number
depicting the position of the value if in a list of
string values.

Migration to SPFILE
• To migrate from the old initialization

parameter style, INIT.ORA, to the new
persistent parameter style, SPFILE:
– FTP the PFILE from the client side to the
server side, if needed.
– Create the default SPFILE from an existing
client-side INIT.ORA.
• Use the created SPFILE to startup the

instance.
STARTUP;

Summary

• Manage an UNDO tablespace.
• Create and maintain resumable operations.
• Create and properly use multiple block sizes
within a database.
• Use new views to display cached execution
plan information.
• Create and use a persistent parameter file.

Database Resource Manager Enhancements
Active Session Pool

Maximum Estimated Execution Time
Automatic Consumer Group Switching
Undo Quota

Objectives

• Set an active session pool for a consumer
group.
• Automatically switch the consumer group of a
running session.
• Set a maximum estimated execution time for
each consumer group.
• Set a maximum limit on the total amount of
undo generated per resource consumer group.

Overview
Oracle9i, extends the Database Resource

Manager's capabilities to better manage system
workloads with several new features.
• Controlling the number of concurrently active
sessions.
• Automatically switching a resource consumer
group based on a DBA's defined criteria.
• Setting a maximum estimated execution time
for each consumer group.
• Assigning quotas for undo space to each
consumer group.

Active Session Pool

Active Session Pool
• The Database Resource Manager now allows a

DBA to limit the amount of concurrent active
sessions per resource consumer group by
defining an active session pool.
• Benefits of an active session pool
– Allows DBAs to meet performance service
level objectives by limiting the concurrent
system workload.
– Reduces the number of servers taking
resources in the system avoiding
inefficient paging, swapping, and other
resource depletion.
Active Session Pool

Historically, the Oracle Database Resource Manager provided the mechanism to
partition CPU resources. These resources were typically allocated at the beginning
of a transaction or query and not freed until the transaction was committed, or
query was finished. There was no means to free the resources associated with such
operations until the operation was complete. Thus, newly arriving operations
would either cause the system performance to be significantly impeded, or caused
individual operations to error when unable to allocate a resource such as temporary
space. The active session pool feature allows the DBA to control the maximum
number of concurrently active sessions per resource consumer group. With this
functionality, a DBA can indirectly control the amount of resources that any
resource consumer group uses since resource consumption is proportional to the
number of active sessions. Once the active session pool is filled, the Database
Resource Manager will queue all subsequent requests and run them only after
existing active sessions complete. The main goal of the active session pool is to
reduce the number of servers taking resources in the system, thus avoiding
inefficient paging, swapping and other resource depletion (memory, temp space,
etc.) resulting from attempting to run too many jobs simultaneously. In essence, it is
an attempt to guarantee some minimum resources to an operation, and to establish
limits on the resource consumer group.

Active Session Pool Mechanism
• A DBA will set an active session pool size per

resource consumer group.
– Active session pool is the maximum number
of concurrently active sessions.
– Active session is defined as a session
currently part of an active transaction,
query, or parallel operation.
– Only one active session pool size is allowed
per consumer group.
• Once the active session pool is filled with active
sessions, all subsequent sessions attempting to
become active are queued.
Active Session Mechanism

Queuing Method
Once the active session pool is filled with active sessions, the Database Resource
Manger queues all subsequent sessions attempting to become active until other
active sessions complete or become inactive. With Oracle9i, there will be only one
queue per resource consumer group and the queuing method will be one of first in
first out (FIFO) with a timeout.

Active Session Pool Parameters
• The active session pool is defined by setting

the parameters ACTIVE_SESSION_POOL_P1
and QUEUEING_P1.
• The ACTIVE_SESSION_POOL_P1 parameter
identifies the number of active sessions that
establishes the resource consumer group's
threshold.
• The QUEUEING_P1 parameter is optional, and
will indicate how long any session will wait on
the queue before aborting the current
operation.
Active Session Pool Parameters

ACTIVE_SESSION_POOL_P1: Identifies the number of active sessions that
establishes the resource consumer group’s threshold, and therefore, its active
session pool.
QUEUEING_P1: This parameter will indicate how long any session will wait on
the queue. If a session waits on the consumer group’s queue for longer than the
specified QUEUEING_P1, the session will abort with an error.

Setting the Active Session Pool
• Example: GROUP ACTIVE SESSION POOL
OLTP
BATCH ACTIVE_SESSION_POOL_P1 = 5
QUEUEING_P1 = 600
• OLTP: ACTIVE_SESSION_POOL_P1 not set, no

limit on concurrent active sessions.
• BATCH: ACTIVE_SESSION_POOL_P1 set to limit
concurrent active sessions to 5. QUEUEING_P1
set to 600, aborts all sessions waiting on the
queue for more than ten minutes.
Setting the Active Session Pool

Example
In the above example, the resource consumer group OLTP has no limit on the
number of concurrent active sessions since the ACTIVE_SESSION_POOL_P1
parameter was not set. The resource consumer group BATCH has an
ACTIVE_SESSION_POOL_P1 of SIZE 5. The BATCH group also has the
QUEUEING_P1 parameter set to 600 (ten minutes). All sessions waiting on the
queue for more than ten minutes will abort with an error.


• The Database Resource Manager in Oracle9i

can estimate the execution time of an
operation proactively.
• A DBA can specify a maximum estimated
execution time for an operation at the
resource consumer group level using a new
resource plan directive parameter.
– MAX_ESTIMATED_EXEC_TIME: Maximum
estimated time an operation can take.
– Operation will not start if estimate is longer
than MAX_ESTIMATED_EXEC_TIME.
• The benefit of this feature is the elimination of
the exceptionally large job that uses too much
system resources.

A DBA can define the maximum estimated execution time any operation can take
at any given time by setting the resource plan directive
MAX_ESTIMATED_EXEC_TIME parameter. Once this parameter is set, the
Database Resource Manager will estimate the time a specific job will take. If the
operation's estimate is more than the MAX_ESTIMATED_EXEC_TIME defined,
then the operation will not start, therefore, eliminating the exceptionally large job
that would utilize too much of the systems resources.
If a resource consumer group has more than one plan directive referring to it, it may
have more than one MAX_ESTIMATED_EXEC_TIME. The Database Resource
Manager will then choose the most restrictive of all incoming values.


• The Database Resource Manager automatically

will switch a session's consumer group based on
the following resource plan directive parameters.
– SWITCH_GROUP: Group switched to.
– SWITCH_TIME: Switch time in seconds.
– SWITCH_ESTIMATE: Estimate of how long the
operation will take to complete.
– USE_ESTIMATE: If value is TRUE, execution
time estimate will be used to decide whether
to switch an operation even before it starts.
• This feature can be used to limit the resources
consumed by long running operations.
Automatic Change of Resource Manager Group

The Database Resource Manager will switch a running session to
SWITCH_GROUP if the session is active for more than SWITCH_TIME seconds.
Active means the session is running and consuming resources, not waiting idly for
user input nor waiting for CPU cycles. Once the session finishes its operation and
becomes idle, it will be switched back to its original group. If a resource consumer
group has more than one plan directive referring to it, it may have more than one
SWITCH_GROUP and SWITCH_TIME. The Database Resource Manager will
choose the most restrictive of all incoming values.
If USE_ESTIMATE is set to TRUE, the Database Resource Manager will use a
predicted estimate of how long the operation will take to complete to decide
whether to switch a session before an operation even starts running. If this
parameter is not set, the operation will just start running and will switch groups
only if the other switch criteria are met.
A DBA can use this feature to manage the workload better by segregating long
running batch jobs from short OLTP transactions. Batch jobs can be automatically
assigned to consumer groups with lower resource allocation during day time to
ensure good response time for OLTP users.

Undo Quota

Undo Quota
• The Database Resource Manager now allows a

DBA to manage the undo space consumed by
long running transactions using a new
resource plan directive parameter, UNDO_POOL.
• A DBA will define a quota of undo space per
resource consumer group.
• Whenever the total undo space is exceeded,
no further INSERT, UPDATE or DELETE will be
allowed until undo space is freed by another
session in the same group or undo quota is
increased.

Undo Quota
• If the consumer group’s quota is exceeded

during the execution of a DML statement, the
operation will abort and return an error.
• SELECT statements are allowed even when the
UNDO_POOL limit is exceeded.
• The default value for the UNDO_POOL is
UNLIMITED.
• UNDO_POOL is specified in kilobytes.
• The UNDO_POOL can be used with Automatic
Undo management as well as user defined
rollback segments.

Changing Undo Quota
The undo quota can be changed anytime during

database operation using the following resource
plan directive.
DBMS_RESOURCE_MANAGER.UPDATE_PLAN_DIRECTIVE
(plan => 'plan name',
group- or_subplan => 'consumer group name',
new_undo_pool => 'new quota');

Modified Views to Support Database
Resource Manager Extensions
• New column added to V$SESSION and

V$MYSESSION.
– CURRENT_QUEUE_DURATION : The current
amount of time in seconds the session has been
queued.
– If not currently queued value is zero.
• New columns added to V$RSRC_CONSUMER_GROUP.
– QUEUE_LENGTH: Number of sessions waiting on
the queue.
– CURRENT_UNDO_CONSUMPTION: Current amount
of undo consumed by consumer group.

Modified Catalog Tables and Views
• New column, QUEUEING_MTH, added to

DBA_RSRC_PLANS to define the queuing resource
allocation method for the plan.
• Six new columns added to
DBA_RSRC_PLAN_DIRECTIVES.
– QUEUEING_P1
– SWITCH_GROUP
– SWITCH_TIME
– SWITCH_ESTIMATE
– MAX_EST_EXEC_TIME
– UNDO_POOL
Modified Catalog Tables and Views

The following new columns were added to DBA_RSRC_PLAN_DIRECTIVES.
QUEUEING_P1: First parameter for queuing resource allocation method.
SWITCH_GROUP: Group to switch to.
SWITCH_TIME: Amount of run time before session is automatically switched.
SWITCH_ESTIMATE: TRUE if estimated execution time should be used for
switch criteria.
MAX_EST_EXEC_TIME: First parameter for the maximum estimated execution
time.
UNDO_POOL: Undo pool size for the consumer group.

Summary

• Set parameters to define an active session
pool.
• Set a maximum estimated execution time for
each consumer group.
• Set parameters to automatically switch the
consumer group of a running session.
• Set a maximum on the total amount of undo
generated per resource consumer group.

Using Oracle Names Servers as LDAP Proxies

Objectives
After finishing this lesson, you should be able to:

• List the advantages of using Oracle Names
Servers as LDAP proxies
• Name the NAMES.ADMIN_REGION TYPE
parameter values
• List the steps required to configure Oracle
Names LDAP Proxy Servers
• Describe the data contained in the
CKPTOP.ORA file

Oracle Names Server as LDAP Proxy
Advantages
• Using Oracle Names servers as LDAP proxies
helps makes the migration to LDAP seamless.
• Clients that are too old to "speak" LDAP can
continue name resolution from their traditional
source.
• Administration of the name/address data is
optimized, providing a single point of definition
for all data.
• Simultaneous use of both ONames and LDAP
without requiring that both systems be
maintained separately.

There is no architectural change for the Oracle Names server; it has always had a generalized
view of its data store, so it is simply an increment of evolution to add LDAP (and LDIF) to the
historic list of storage formats. The interface to the region data store has been extended to
include LDAP/LDIF access modules, and parameters were added to
names.ora:names.admin_region to accommodate LDAP particulars.

ONames servers will load their region data from

an LDAP directory or LDIF file. Loading the
region data from an LDAP store involves:
• Recognizing 'LDAP' or 'LDIF' as values for the
TYPE field of the region descriptor in
NAMES.ORA
• Adding parameters to the region descriptor
which pertain to LDAP
• Adding functions to the region-loading module
which know how to find (based on parameters)
and interpret the LDAP data

The basic logic of the loader is:
1) Get the DN list from names. ora:names.admin_region for each
DN:
{
if the DN isn't an OrclCtx, query the subtree for
OracleContexts
for each OracleContext:

{
query for all DB addresses
for each address
{
translate the DN into dot-notation
add the name/address data to the in -memory cache
}
}
}
2) Flush the region data to the region checkpoint file

New NAMES.ADMIN_REGION TYPE
Values
Two new TYPEs of region-store were added, each
with it’s own set of additional parameters:
names.admin_region= (REGION= (...)
(TYPE = LDAP)
[ (USER = user-DN)
(PASSWORD = password)
(HOST = host)
(PORT = port) ]
)
names.admin_region= (REGION= (...)

(TYPE= LDIF)
(FILE = filename)
New NAMES.ADMIN_REGION TYPE Values

If TYPE=LDAP all the access parameters may be defaulted. The user/password can be
anonymous (all this data is assumed to be world-read for the sake of mainline name-lookup).
The host/port may be defaulted provided there are well-known system defaults. These are not
resolved exactly yet but I believe they will exist in the timeframe of the project. There may be
more than one DN to specify subtrees of the DIT. The default would be the context specified in
LDAP.ORA.
If TYPE=LDIF the only parameter required is the filename, and the server will load the entire
contents of the file

Configuring Oracle Names LDAP Proxy
Servers
The tasks to create Oracle Names LDAP Proxy
servers are as follows:
• Upgrade Oracle Names Servers to Oracle9i
• Configure Directory Access (optional)
• Populate Directory
• Configure Oracle Names Server as Proxies
• Start the Oracle Names LDAP Proxy Servers
and Create Topology
Configuring Oracle Names LDAP Proxy Servers

Task 1: Upgrade Oracle Names Servers to Oracle9i
Upgrade all Oracle Names servers within a region to Oracle9i. Older releases cannot use this
feature.
Task 2: Configure Directory Access (Optional)
If you want to reduce the amount of directory access configuration required in the NAMES.ORA
file, configure directory access settings in the LDAP.ORA file with the "Configure this
Oracle Home to use a directory server that is already set up
for Oracle features" option in the Net8 Configuration Assistant.
Task 3: Populate Directory
Export data from the Oracle Names, as described in "Exporting Data to a Directory Server" in
the Oracle9i Network Administrator’s Guide.
Task 4: Configure Oracle Names Server as Proxies
Configure each Oracle Names server in a region to act as an Oracle Names LDAP Proxy server
by specifying from which DNs to load directory information. To configure the DN, either
explicitly set the NAMES.ADMIN_REGION parameter in the NAMES.ORA file with the DN or
read the DN from a LDIF input file.

The CKPTOP.ORA File
• Starting the Oracle Names LDAP Proxy servers

creates a CKPTOP.ORA file in:
– $ORACLE_HOME/network/names on UNIX
– %ORACLE_HOME%\network\names on
Windows NT
– The directory specified by the
NAMES.TOPOLOGY_CHECKPOINT_FILE
parameter
• The CKPTOP.ORA file contains topology data.
– The information consists of both
administrative and authoritative data.
Starting the Oracle Names LDAP Proxy Server

Starting the Oracle Names LDAP Proxy servers creates a CKPTOP.ORA file in
$ORACLE_HOME/network/names on UNIX and %ORACLE_HOME\network\names%
on Windows NT, or in the directory specified by the
NAMES.TOPOLOGY_CHECKPOINT_FILE parameter. This file contains structural data, or
topology data, that defines the domains in the administrative region and the Oracle Names
servers authoritative for each domain. Specifically, topology data consists of:
• Domains, defined as a list of Oracle Names servers names with NS.SMD record types that are
authoritative for the domain
• Oracle Names servers, specified with a A.SMD record type and listening protocol addresses
The Oracle Names LDAP Proxy servers use this information to understand the structure of the
domain tree. If the directory DIT structure has been designed with domain components (DC) to
match the current Oracle Names structure, then the Oracle Names LDAP Proxy servers can use
the generated CKPTOP.ORA file. If the directory DIT structure has been designed with a DIT
that is dissimilar to the current Oracle Names domain structure, modify the CKPTOP.ORA file
so that it matches the structure of the DIT.

Sample CKPTOP.ORA File
. = (DATA_LIST=(FLAGS=0x11)
(DATA=(TYPE=ns.smd.)(NAME=svrroot.)))
svrroot. = (DATA_LIST=(FLAGS=0x209)
(DATA=(TYPE=a.smd.)(ADDRESS=(PROTOCOL=TCP)(Port=1575)(host= nineva)))
(DATA=(TYPE=tos.npd.omd.)(CTEXT=ORACLE_NAMESERVER))
(DATA=(TYPE=host.nm.omd.)(TEXT=nineva)))
south. = (DATA_LIST=(FLAGS=0x3)
(DATA=(TYPE=ns.smd.)(NAME=svr.south.)))
svr.south. = (DATA_LIST=(FLAGS=0x5)
(DATA=(TYPE=a.smd.)(ADDRESS=(PROTOCOL=tcp)
(HOST=oranamesrvr5)(PORT=1575)))
The CKPTOP.ORA File

The entry for the root (".") domain specifies that it is serviced by Oracle Names LDAP
Proxy server svrroot. The entry for the delegated domain south specifies that is it serviced
by Oracle Names LDAP Proxy server svr.south. The svrroot and svr.south entries
specify the listening protocol addresses of these servers. Note that svrroot contains several
more data types than svr.south entries. As the writer of the CKPTOP.ORA file, svrroot
includes the checkpoint information stored in ONRS_CONFIG table in the region database or in
its configuration checkpoint file, including:
• Type of service information, defined with the TOS.NPD.OMD record type and an
ORACLE_NAMESERVER value
• Host name of the Oracle Names server, specified with a HOST.NM.OMD record type and
host
name value
If you creating or modifying the topology data for the Oracle Names Proxy server that creates
the CKPTOP.ORA file, it is not necessary to include this additional topology information.

Flag Values in CKPTOP.ORA
Hex Value Description

Specifies that the domain or Oracle Names LDAP Proxy server is
0x1 authoritative for domain data, delegation data, or addresses for
other servers at delegation points.
0x2 Specifies that the domain is delegated
Specifies that the Oracle Names LDAP Proxy server is delegated
0x4
0x8 Specifies that the Oracle Names LDAP Proxy server is authoritative
0x10 Specifies that the domain is authoritative for a subtree
0x200 Identifies the Oracle Names LDAP Proxy server who wrote the
CKPTOP.ORA file
Flag Values
Understanding how the flag values are calculated will help in troubleshooting topology related
errors as well as authoritative problems. Each hex value corresponds to an element of the
topology or some characteristic of an element. Several values can be combined to fully
describe an element. The values were chosen in such a manner as to always provide a sum that
can be calculated in one way only. The following examples illustrate this.
In the sample CKPTOP.ORA file, the root domain has a hexadecimal sum of 0x11 that is
created from the following equation:
0x1 + 0x10 = 0x11
The svvroot root Oracle Names LDAP Proxy server has a hexadecimal sum of 0x209 that is
created from the equation:
0x1 + 0x8 + 0x200 = 0x209
The delegated domain south has a hexadecimal sum of 0x3 that is created from the equation:
0x1 + 0x2 = 0x3
The svr.south delegated Oracle Names LDAP Proxy server has a hexadecimal sum of 0x5
that is created from the equation:
0x1 + 0x4 = 0x5
0x10 and 0x8 represent authoritative domains and authoritative Oracle Names LDAP Proxy
servers respectively. 0x2 and 0x4 represent delegated domains and delegated Oracle Names
LDAP Proxy servers respectively.

Summary
After completing this lesson you should be able

to:
• Discuss the advantages of using Oracle
Names Servers as LDAP proxies
• Name the NAMES.ADMIN_REGION TYPE
parameter values
• Know the steps required to configure Oracle
Names LDAP Proxy Servers
• Understand the data contained in the
CKPTOP.ORA file

9ib MANAG

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9ib MANAG

Uploaded by

Copyright:

Available Formats

Memory Management

Automated SQL Execution Memory Management

Server-side Manageability Improvemements 1-1

After this lesson, you should be able to:

Server-side Manageability Improvemements 1-2

• Change the sizes of the Buffer Cache, Shared

Server-side Manageability Improvemements 1-3

Server-side Manageability Improvemements 1-4

Automated SQL Execution Memory Management

Server-side Manageability Improvemements 1-5

Enabling the Automated SQL Execution Memory Management

Server-side Manageability Improvemements 1-6

• PGA memory is classified to differentiate

PGA Memory Management

Server-side Manageability Improvemements 1-7

Enabling Automated SQL Execution Memory Management

Server-side Manageability Improvemements 1-8

Four new statistics have been added to report work

New Statistics in V$SYSTAT and V$SESSTAT

Server-side Manageability Improvemements 1-9

V$SYSTAT can be used to monitor private memory,

Example of Monitoring Private Memory

Server-side Manageability Improvemements 1-10

Three new columns have been added to the

New Columns in V$PROCESS

Server-side Manageability Improvemements 1-11

Three views have been created to display SQL

Server-side Manageability Improvemements 1-12

Scenario: Find the top ten work areas requiring the

Server-side Manageability Improvemements 1-13

Scenario: Find the percentage of work areas using

Server-side Manageability Improvemements 1-14

Scenario: Find the top ten biggest work areas

Server-side Manageability Improvemements 1-15

Scenario: Find the percentage of memory that is

Example Use of V$SQL_WORKAREA_ACTIVE

Server-side Manageability Improvemements 1-16

Scenario: Find various pieces of memory information.

SELECT p.value pga_aggregate_target, PGA_inuse,

Example Use of V$SQL_MEMORY_USAGE

Server-side Manageability Improvemements 1-17

Server-side Manageability Improvemements 1-18

• The dynamic SGA feature implements an

Server-side Manageability Improvemements 1-19

• In the dynamic SGA model, a new unit of

Dynamic SGA’s Unit of Allocation

Server-side Manageability Improvemements 1-20

• A granule is a unit of contiguous virtual

Server-side Manageability Improvemements 1-21

• At instance startup, the Oracle server allocates

Server-side Manageability Improvemements 1-22

• A DBA can grow a component’s SGA use by

Server-side Manageability Improvemements 1-23

Init.ora parameter values:

ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

ALTER SYSTEM SET DB_CACHE_SIZE = 64M;

ALTER SYSTEM SET SHARED_POOL_SIZE = 64M;

Growing a Components SGA Memory Area

Server-side Manageability Improvemements 1-24

• After instance startup the Shared Pool can be

• The allocation size has the following limits:

Server-side Manageability Improvemements 1-25