PCTUSED

PCTFREE

As any experience DBA understand, the settings for PCTUSED can have a dramatic impact on
the performance of an Oracle database. Many new Oracle DBAs fail to realize that PCTUSED is
only used to re-link a full data onto the table freelist. A re-link only occurs when a DELETE or
UPDATE statement has reduced the free space in the data block. The setting for PCTUSED will
determine the amount of row space in this newly re-linked data block.

The default settings for all Oracle tables are PCTUSED=40. The PCTUSED=40 setting means
that a block must become less than 40 percent full before being re-linked on the table free list.

Let’s take a closer look at how the PCTUSED operator works and how it affects the operation of
re-links onto the table freelist. As I said, a data block becomes available for re-use when a block’s
free space drops below the value of PCTUSED for the table.

This happens when the amount of space in a database block falls below PCT_USED, and a free
list re-link operation is triggered. For example, with PCTUSED=60, all database blocks that have
less than 60 percent data will be on the free list, as well as other blocks that dropped below
PCT_USED and have not yet grown to PCT_FREE. Once a block deletes a row and becomes
less than 60 percent full, the block goes back on the free list.

There is a direct tradeoff between the setting for PCTUSED and database performance on insert
operations. In general, the higher the setting for PCTUSED, the less free space will be on re-used
data blocks at INSERT time. Hence, INSERT tasks will need to do more frequent I/Os than they
would if they were inserting into empty blocks. In short, the value for PCTUSED should only be
set above 40 when the database is short on disk space, and it must make efficient re-use of data
block space.

It should now be very clear that you need to consider the average row length when customizing
the values for PCTFREE and PCTUSED. You want to set PCTFREE such that room is left on
each block for row expansion, and you want to set PCTUSED so that newly-linked blocks have
enough room to accept rows.

Herein lies the tradeoff between effective space usage and performance. If you set PCTUSED to
a high value, say 80, then a block will quickly become available to accept new rows, but it will not
have room for a lot of rows before it becomes logically full again. In the most extreme case, a re-
linked free block may only have enough space for a single row before causing another I/O.

The script in Listing 1 (pctused.sql) allows you to adjust the setting for PCTFREE and PCTUSED
as a function of the number of rows that you want to store between I/Os.

Remember the rule: The lower the value for PCTUSED, the less I/O your system will have at
insert time, and the faster your system will run. The downside, of course, is that a block will be
nearly empty before it becomes eligible to accept new rows.

Because row length is a major factor in intelligently setting PCTUSED, a script can be written that
allows the DBA to specifically control how many rows will fit onto a re-used data block before it
unlinks from the freelist.
Note that the script below allows the DBA to define the blocksize and the number of rows for
which they want to leave room after the block re-links onto the freelist.

The file in pctused.lst will now contain the ALTER TABLE syntax to re-set PCTUSED.

Again, this script is generally used when the database is very “tight” on space and the DBA wants
to make the tradeoff between efficient space re-use and INSERT performance.

All professional DBA’s know that minimizing chained rows is a fundamental job role
and they recognize that row migration (chaining) is a function of:

• blocksize
• PCFREE
• load time average row length
• Expected row expansion (bytes per row)

Excessive migrated rows are often the result of a result of a DBA error, usually by failing
to anticipate the future row expansion. An improper PCTFREE (precipitating a high
chain_cnt) is a DBA error, and quite rare. In my world migrated rows are the result of
large objects in small blocks, and the most common remedy of to deploy a larger

pctfree and PCTUSED are the block storage parameters.

1. pctfree- This parameter is used to specify how much space should be left in the block for
updates.
For eg. if The pctfree for a block is 30, then Oracle keeps on adding new rows to the block until
the block is 70 % full. It leaves the 30 % for future updates. That is, in case, any row is
updated and requires some more space, it is taken out from the 30 % remaining in the Block. U
should specify the Value of this parameter HIGH if future updates in the rows of the table are
going to need more space. In case ur table is less prone to updates, then this value can be
specified LOW.

PCTUSED : As I have mentioned above, Oracle stops INSERTING new Rows in a table when the
space usage reaches the pctfree limit.
Now consider this ---- When should Oracle start inserting new rows in the Block ?
PctUSED parameter is taken into consideration for the answer of the above question.
Suppose u have specified PCTUSED as 40 %. and pctfree as 20 %.

1. Oracle will keep on inserting new rows till the space is 80 % used. It will reserve the
remaining 20% for future updates.
2. To start adding new rows again to the block, Oracle will check the space in the Block and the
PCTUSED parameter.
3. When the space falls below 40 %, Oracle will start adding new rows to the block.
Understanding INITRANS:

The INITTRANS setting controls Initial Transaction Slots (ITLs). A transaction slot is
required for any session that needs to modify a block in an object. For tables INITRANS
defaults to 1 for indexes, 2.

The MAXTRANS setting controls the maximum number of ITLs that a block can
allocate (usually defaults to 255). If a block is sparsely populated then Oracle will
dynamically increase the number of ITLs up to MAXTRANS.

ITL's and Block Waits

However, if the block has little or no free space then transactions will serialize waiting on
a free ITL. This is one cause for data base block waits. By setting INITRANS to the
number of expected simultaneous DML (data manipulation language – insert, update and
delete) transaction for a single block, you can avoid serialization for ITL slots.

The maximum value suggested for INITRANS is 100 and settings over this size rarely
improve performance. Therefore a setting of INITRANS to the average number of
simultaneous DML users and setting MAXTRANS to 100 will most likely result in the
best utilization of resources and performance. Remember, each ITL requires
approximately 23 bytes in the block header.

FREELISTS and their cousin FREELIST GROUPS:

A freelist if a one-way linked list (or a bitmap) that identified blocks that can accept data.

FREELIST GROUPS was designed for Oracle Parallel Query (OPQ) and used in Oracle
Real Application Clusters (RAC) where many instances need to attach to the same data
block.

For example, a setting of FREELISTS 4 and FREELIST GROUPS 2 result in 8 total

FREELISTS. Generally speaking FREELIST groups are used in Oracle real application
clusters where the setting should be equal to the number of nodes (instances)
participating in the cluster. FREELISTS should be set to the number of simultaneous
DML users for the table (not the block!), tables default to 1 FREELIST and 0 FREELIST
GROUPS.

Again, settings of greater than 100 rarely result in better performance for FREELISTS.
Also, tables will, by default, extend based on the minimum allowed extension times the
number of FREELISTS so be aware of this when setting FREELISTS.
Parallel/Noparallel :

Parallel process is advisable where we plan for a table which holds huge data where it will help in over
coming the delay on the table for effective parsing.
Noparallel processing is advantages if we plan for a small table and there is less transitions which will
reduce the over head of processing on the table.

SGA

The System Global Area (SGA) is a group of shared memory areas that are dedicated to an Oracle
“instance” (an instance is your database programs and RAM).

All Oracle processes use the SGA to hold information. The SGA is used to store incoming data (the data
buffers as defined by the db_cache_size parameter), and internal control information that is needed by
the database. You control the amount of memory to be allocated to the SGA by setting some of the
Oracle “initialization parameters”. These might include db_cache_size, shared_pool_size and
log_buffer.

In Oracle Database 10g you only need to define two parameters (sga_target and sga_max_size) to
configure your SGA. If these parameters are configured, Oracle will calculate how much memory to
allocate to the different areas of the SGA using a feature called Automatic Memory Management
(AMM). As you gain experience you may want to manually allocate memory to each individual area of
the SGA with the initialization parameters.