Shrinking Segments: Overview

The upper part of the diagram in the slide shows a sparsely populated segment. There is some unused
space both above and below the segments high-water mark (HWM).
Shrinking a sparsely populated segment improves the performance of scan and DML operations on
that segment. This is because there are fewer blocks to look at after the segment has been shrunk.
This is especially true for:
Full table scans (fewer and denser blocks)
Better index access (fewer I/Os on range ROWID scans due to a more compact tree)
You can make more free space available in tablespaces by shrinking sparsely populated segments.
When a segment is shrunk, its data is compacted, its HWM is pushed down, and unused space is
released back to the tablespace containing the segment.
Row IDs are not preserved. When a segment is shrunk, the rows move inside the segment to different
blocks, causing the row ID to change.
Note: The number of migrated rows in a segment may be reduced as a result of a segment shrink
operation. Because a shrink operation does not touch all the blocks in the segment, you cannot
depend on reducing the number of migrated rows after a segment has been shrunk.

Oracle Database 11g: Performance Tuning 18 - 1

Shrinking Segments: Considerations
A shrink operation is an online and in-place operation.
You cannot execute a shrink operation on segments managed by free lists. Segments in automatic
segment spacemanaged tablespaces can be shrunk. However, the following objects cannot be
shrunk:
Tables in clusters
Tables with LONG columns
Tables with on-commit materialized views
IOT mapping tables, even with the cascade clause
IOT overflow segments
Compressed tables
Other objects have restrictions:
ROWID-based materialized views must be rebuilt after a shrink operation on base tables.
Tables with function-based indexes are not supported
Tables with bitmap-join indexes are not supported
ROW MOVEMENT must be enabled for heap-organized segments.
Indexes are in a usable state after shrinking the corresponding table.
The actual shrink operation is handled internally as an INSERT/DELETE operation. However, DML
triggers are not fired because the data itself is not changed.

Oracle Database 11g: Performance Tuning 18 - 2

Shrinking Segments by Using SQL
Because a shrink operation may cause ROWIDs to change in heap-organized segments, you must
enable row movement on the corresponding segment before executing a shrink operation on that
segment. Row movement by default is disabled at the segment level. To enable row movement, the
ENABLE ROW MOVEMENT clause of the CREATE TABLE or ALTER TABLE command is used.
This is illustrated in the first example in the slide.
Use the ALTER command to invoke segment shrink on an object. The objects type can be one of the
following: table (heap- or index-organized), partition, subpartition, LOB (data and index segment),
index, materialized view, or materialized view log. Use the SHRINK SPACE clause to shrink space
in a segment. If CASCADE is specified, the shrink behavior is cascaded to all the dependent segments
that support a shrink operation, except materialized views, LOB indexes, and IOT (index-organized
tables) mapping tables. The SHRINK SPACE clause is illustrated in the second example.
In an index segment, the shrink operation coalesces the index before compacting the data.
Example 3 shows a command that shrinks a LOB segment, given that the RESUME column is a
CLOB. Example 4 shows a command that shrinks an IOT overflow segment belonging to the
EMPLOYEES table.
Note: For more information, refer to the Oracle Database SQL Reference guide.

Oracle Database 11g: Performance Tuning 18 - 3

Segment Shrink: Basic Execution
The diagram in the slide describes the two phases of a table shrink operation. Compaction is
performed in the first phase. During this phase, rows are moved to the left part of the segment as
much as possible. After the rows have been moved, the second phase of the shrink operation is
started. During this phase, the HWM is adjusted, and the unused space is released.
During a shrink operation, you can execute only the compaction phase by specifying the SHRINK
SPACE COMPACT clause. This is illustrated by the first example in the slide.
As shown by the second example in the slide, if COMPACT is not specified, the segment space is
compacted, and at the end of the compaction phase, the HWM is adjusted and the unused space is
released.

Oracle Database 11g: Performance Tuning 18 - 4

Segment Shrink: Execution Considerations
The compaction phase of a segment shrink operation is performed online. Conventional DML
operations as well as queries can coexist with a segment shrink operation.
During the compaction phase, locks are held on individual rows containing the data. Concurrent
DML operations such as updates and deletes serialize on these locks. However, only packets of rows
are locked at one time to avoid the locking of the entire segment.
Similarly, conventional DML operations can block the progress of the compaction phase until they
commit.
The COMPACT clause is useful if you have long-running queries that might span the shrink operation
and attempt to read from blocks that have been reclaimed. When you specify the SHRINK SPACE
COMPACT clause, the progress of the shrink operation is saved in the bitmap blocks of the
corresponding segment. This means that the next time a shrink operation is executed on the same
segment, the Oracle database remembers what has been done already. You can then reissue the
SHRINK SPACE clause without the COMPACT clause during off-peak hours to complete the second
phase.
During the second phase of the segment shrink operation, when the HWM is adjusted, the object is
locked in exclusive mode. This occurs for a very short duration and does not affect the availability of
the segment significantly. Dependent cursors are invalidated.

Oracle Database 11g: Performance Tuning 18 - 5

Using EM to Shrink Segments
Using Database Control, you can shrink individual segments as follows:
1. On the Database Control home page, click the Schema tab and the Tables link in the Database
Objects section.
2. On the Tables page, select your table, and then select Shrink Segment in the Actions drop-down
list. Click Go.
3. On the Shrink Segment page, choose the dependent segments to shrink. You can either compact
only, or compact and release the space. You can also choose the CASCADE option in the
Segment Selection section by selecting Shrink HR.EMPLOYEES and All Dependent
Segments.
4. Click the Continue button. This allows you to submit the shrink statements as a scheduled job.
Note: Before shrinking a heap-organized table, you must enable row movement on that table. You
can do that using the Options tab of the Edit Table page of Database Control.

Oracle Database 11g: Performance Tuning 18 - 6

Table Compression: Overview
The Oracle database was the pioneer in terms of compression technology for databases with the
introduction of table compression for bulk load operations in Oracle9i. By using this feature, you
could compress data when performing bulk load using operations such as direct loads or Create Table
As Select (CTAS). However, until now, compression was not available for regular data manipulation
operations such as INSERT, UPDATE, and DELETE. Oracle Database 11g extends the compression
technology to support these operations as well. Consequently, compression in Oracle Database 11g
can be used for all kinds of workloadonline transaction processing (OLTP) or data warehousing.
It is important to mention that table compression enhancements introduced in Oracle database 11g
are not just incremental changes. An enormous amount of work has gone into making sure that the
new compression technology has negligible impact on updates because any noticeable write time
penalty due to compression will not be acceptable in an OLTP environment. As a result, compression
technology in Oracle Database 11g is very efficient and could reduce the space consumption by 50
75%. So, your write performance does not degrade, and your read performance or queries improve.
This is because unlike desktop-based compression techniques where you have to wait for data to be
uncompressed, Oracle technology reads the compressed data (less fetches needed) directly and does
not require any uncompress operation.
Note: Compression technology is completely application-transparent. This means that you can use
this technology with any application such as SAP, Siebel, or EBS.

Oracle Database 11g: Performance Tuning 18 - 7

Table Compression Concepts
The slide shows you a data block evolution when that block is part of a compressed table. You should
read it from left to right. At the start, the block is empty and available for inserts. When you start
inserting into this block, data is stored in an uncompressed format (like for uncompressed tables).
However, as soon as you reach the PCTFREE of that block, the data is automatically compressed,
potentially reducing the space it originally occupied. This allows new uncompressed inserts to take
place in the same block, until PCTFREE is reached again. At that point, compression is triggered
again to reduce space occupation in the block.
Note: Compression eliminates holes created due to deletions and maximizes contiguous free space in
blocks.

Oracle Database 11g: Performance Tuning 18 - 8

Using Table Compression
To use the new compression algorithm, you must flag your table with the COMPRESS FOR ALL
OPERATIONS clause. You can do so at table creation, or after creation. This is illustrated in the
examples given in the slide.
If you use the COMPRESS clause without specifying any FOR option, or if you use the COMPRESS
FOR DIRECT_LOAD OPERATIONS clause, you fall back to the old compression mechanism that
was available in earlier releases.
You can also enable compression at the partition or tablespace level. For example, you can use the
DEFAULT storage clause of the CREATE TABLESPACE command to optionally specify a
COMPRESS FOR clause.
Note: You can view compression flags for your tables using the COMPRESS and COMPRESS_FOR
columns in views such as DBA_TABLES and DBA_TAB_PARTITIONS.

Oracle Database 11g: Performance Tuning 18 - 9

Oracle Database 11g: Performance Tuning 18 - 10