Avoid and correct tablespace fragmentation in Oracle?
Correct Oracle Tablespace Fragmentation
Different causes for 'tablespace fragmentation' in Oracle
Tablespace fragmentation in Oracle can occur when free space in a tablespace is not contiguous, leading to inefficient space utilization and potential performance issues. This fragmentation can arise in two primary forms: extent fragmentation and segment fragmentation. Below are some common causes of tablespace fragmentation in Oracle:
Frequent Extent Allocation and Deallocation
When objects (e.g., tables or indexes) are frequently created, altered, or dropped, extents (contiguous blocks of storage) are allocated and deallocated within the tablespace. Over time, this can lead to free space being scattered throughout the tablespace, resulting in fragmentation.
For example, dropping a large table or index frees up space in non-contiguous chunks, leading to gaps in storage.
Improper Sizing of Extents
If extents are not sized appropriately (either too small or too large), this can cause issues with how free space is utilized. Using small extents may increase the likelihood of fragmentation since there may be many small, non-contiguous free spaces.
Before Oracle 8i, manual extent management could result in fragmented tablespaces due to varying extent sizes.
Although Oracle now uses automatic extent sizing with locally managed tablespaces (LMTs) in modern versions (such as Oracle 19c), legacy systems or databases that use dictionary-managed tablespaces (DMTs) are more prone to fragmentation.
Frequent DDL Operations
Operations such as `DROP TABLE`, `DROP INDEX`, `TRUNCATE TABLE`, and `ALTER TABLE` can lead to tablespace fragmentation because they free up space in the middle of the tablespace, causing non-contiguous blocks of free space.
Temporary segments generated during index creation, bulk inserts, or sorting can also contribute to fragmentation once they are removed, leaving behind fragmented free space.
Mix of Object Sizes in the Same Tablespace
If large and small objects (tables, indexes) are stored in the same tablespace, it can lead to fragmentation. Large objects might require contiguous space, but if only small, non-contiguous free spaces are available, Oracle may be forced to extend the tablespace or fragment it further.
For example, when small and large extents are mixed, and large objects are dropped or moved, it can result in scattered free space, making it hard to find large contiguous free blocks for future large object allocations.
Excessive Use of Temporary Segments
When large sort operations or temporary objects are created, temporary segments are used. If these segments are not managed well, they can leave fragmented free space behind once the temporary segments are released.
This problem is less common in newer Oracle versions with automatic segment space management (ASSM) and locally managed tablespaces (LMT), but it can still occur in databases with large sorting or temporary tablespace usage.
Inappropriate Use of PCTFREE and PCTUSED Parameters
PCTFREE and PCTUSED control how free space is managed in data blocks. Poor configuration of these parameters can cause row chaining or row migration, leading to inefficiencies and fragmentation at the block level.
For example, if PCTFREE is set too high, Oracle reserves too much free space in each block, leading to underutilized blocks, whereas setting it too low may result in row chaining or migration.
Row Chaining and Row Migration
Row chaining happens when a row is too large to fit into a single block, so it is stored in multiple blocks, which can lead to fragmentation at the block level.
Row migration occurs when a row that was initially inserted into a block grows in size (due to updates), and the row has to be moved to another block, leaving unused space in the original block. This can result in "holes" in the storage that contribute to fragmentation.
Datafile Autoextend
When datafiles in a tablespace are set to autoextend, Oracle adds space in increments defined by the `AUTOEXTEND` clause. If the size increments are too small or poorly managed, frequent auto-extension can cause non-contiguous space allocations, leading to tablespace fragmentation.
Dictionary-Managed Tablespaces (DMT)
In Oracle versions prior to Oracle 8i, tablespaces were often dictionary-managed. This management style was more prone to fragmentation because it used the data dictionary to track free space and extents.
Locally-managed tablespaces (LMT), introduced in Oracle 8i, reduced fragmentation by using bitmaps to manage extents within the tablespace.
DMT tablespaces are more susceptible to fragmentation due to varying extent sizes and manual space management.
Preventing and Resolving Tablespace Fragmentation
Use Locally Managed Tablespaces (LMT): LMTs with uniform extent sizes are less prone to fragmentation since the system automatically manages extents in a consistent manner.
Automatic Segment Space Management (ASSM): Enabling ASSM improves free space management, reducing fragmentation at the block level.
Proper Sizing of Extents and Segments: Using appropriate extent sizes for objects and using uniform extent sizes (instead of variable sizes) can help prevent fragmentation.
Reorganize Tablespaces: Rebuilding indexes and reorganizing fragmented tablespaces (e.g., using `ALTER TABLE MOVE`, `SHRINK`, or exporting/importing data) can help resolve existing fragmentation.
Monitor Space Utilization: Regular monitoring of tablespace and extent usage through Oracle Enterprise Manager or queries to the data dictionary views can help detect fragmentation early.
By employing these best practices and utilizing Oracle’s built-in features, you can minimize the risk of tablespace fragmentation.
There are two ways to prevent the problems caused by tablespace fragmentation:
you can correct the problem when it occurs or
avoid the problem through planning.
The statements you've provided about using the `ALTER TABLESPACE ... COALESCE` command to address tablespace fragmentation are partially correct but outdated. Here’s a detailed breakdown:
Single Command to Eliminate Fragmentation (COALESCE)
Correct: The `ALTER TABLESPACE ... COALESCE` command can be used to coalesce adjacent free extents in dictionary-managed tablespaces (DMTs). It merges contiguous free space into a larger chunk, helping reduce fragmentation by consolidating free extents. This command was used in older versions of Oracle (before Oracle8i) with dictionary-managed tablespaces.
Incorrect/Outdated: The `COALESCE` command applies only to free extents in dictionary-managed tablespaces (DMTs), which were common in earlier versions of Oracle. Locally-managed tablespaces (LMTs), introduced in Oracle8i and now standard in Oracle 19c and beyond, do not require this operation. LMTs use bitmaps to manage extents, which automatically handle fragmentation issues more efficiently without the need for coalescing.
Effect of COALESCE:
Correct (for DMT): The command indeed merges adjacent free extents into larger contiguous areas of free space. It does not move or alter the location of used extents but simply consolidates free extents.
Incorrect (Outdated for LMT): In locally-managed tablespaces, there is no need for this manual coalescing. Fragmentation issues are inherently minimized due to the way Oracle manages space using bitmaps, and Oracle automatically manages and tracks free space without requiring coalescing.
Syntax and Usage
Correct: The syntax `ALTER TABLESPACE tablespace_name COALESCE;` is valid for dictionary-managed tablespaces, and no additional parameters are allowed with the `COALESCE` keyword.
Important Note:
In Modern Oracle Versions:
Locally Managed Tablespaces (LMT) are the default and recommended option. They significantly reduce the possibility of fragmentation by using uniform or auto-allocated extent sizes, and bitmaps track the usage of blocks and extents.
For LMTs, there is no need to use the `COALESCE` command because the tablespace management automatically handles fragmentation efficiently.
1) The previously described tablespace has two 500 KB holes
How to reduce Fragmentation in Oracle?
Question: Does Oracle provide any other technique besides issuing a 'coalesce statement' to fix table fragmentation?
Yes, Oracle provides several techniques to address table fragmentation besides issuing a 'coalesce statement'. Some of these techniques include
Online Table Redefinition: Oracle offers the DBMS_REDEFINITION package to perform online table redefinition. This method allows you to redefine a table's structure while maintaining its data and keeping it available for DML and query operations. Online table redefinition is particularly useful for removing fragmentation while ensuring minimal downtime.
ALTER TABLE SHRINK SPACE: You can use the ALTER TABLE statement with the SHRINK SPACE clause to compact the table and release the freed space back to the tablespace. This operation can be performed online, allowing you to address fragmentation without affecting the table's availability.
ALTER TABLE table_name SHRINK SPACE [CASCADE];
Export/Import (Data Pump): You can use Oracle Data Pump (expdp and impdp) to export the data from the fragmented table, then truncate or drop the table, and finally import the data back into a newly created table. This method can help to eliminate fragmentation and reduce the overall size of the table, but it requires downtime for the table during the process.
Reorganizing tablespaces: Another way to address fragmentation is by reorganizing the tablespace that contains the fragmented table. You can create a new tablespace, move the fragmented table to the new tablespace using the ALTER TABLE MOVE statement, and then drop the old tablespace. This method can help to reduce fragmentation at the tablespace level.
ALTER TABLE table_name MOVE TABLESPACE new_tablespace_name;
Keep in mind that each technique has its own advantages and drawbacks, and the best method depends on your specific situation and requirements. Always make sure to test these operations in a non-production environment and backup your data before making any changes to your production environment.
COALESCE tablespace
Question: What are the different ways to defragment a table?
I have a table with some free space after I executed a delete and wanted to know what options I have for defragmenting the table.
Answer: Fragmentation occurs as DML changes Oracle rows form their untouched state and
intensive DML activity can cause full-table scans and index range scans to run too long, furthering the need to defragment the table to reduce block I/O. Oracle provides many methods for defragmenting a table, and any process that copies all of the table rows (i.e. create table as select) can be used to defragment a table:
Coalesce tablespace
Alter table tablename shrink space compact
Deallocate unused space: See these notes on the difference between coalesce and deallocate unused space
CTAS (or "alter table CUSTOMERS move"): This will defragment the table by copying the rows into their pristine state.
You can also use dbms_redefinition to defragment an Oracle table.
Honeycomb Fragmentation
Question: What is 'Honeycomb Fragmentation' within the context of Oracle table fragmentation?
Honeycomb fragmentation, in the context of Oracle table fragmentation, refers to a specific pattern of space fragmentation within a database object, such as a table or an index. This fragmentation occurs when the space within the object is not fully utilized, leading to the formation of gaps or "holes" in the data blocks that resemble a honeycomb structure.
Honeycomb fragmentation can arise due to various reasons, such as frequent updates, deletions, or insertions of rows in a table. These operations can cause the data within the table to become scattered, leaving empty spaces that are too small to accommodate new rows or updates efficiently. As a result, the overall performance of the database may be impacted, as additional I/O operations are required to access the fragmented data.
To address honeycomb fragmentation in Oracle databases, several techniques can be employed, including:
Online Table Redefinition: By using the DBMS_REDEFINITION package, you can redefine the table structure online while maintaining its data and availability. This method can effectively remove honeycomb fragmentation with minimal downtime.
ALTER TABLE SHRINK SPACE: The ALTER TABLE statement with the SHRINK SPACE clause can be used to compact the table, filling the gaps caused by honeycomb fragmentation and releasing the freed space back to the tablespace.
ALTER TABLE table_name SHRINK SPACE [CASCADE];
Export/Import (Data Pump): Oracle Data Pump can be used to export the data from the fragmented table, followed by truncating or dropping the table, and then importing the data back into a newly created table. This process helps eliminate honeycomb fragmentation and reduce the overall size of the table, albeit at the cost of some downtime.
Reorganizing tablespaces: By reorganizing the tablespace containing the fragmented table, you can address honeycomb fragmentation at the tablespace level. Create a new tablespace, move the fragmented table to the new tablespace using the ALTER TABLE MOVE statement, and then drop the old tablespace.
ALTER TABLE table_name MOVE TABLESPACE new_tablespace_name;
When dealing with honeycomb fragmentation, it is crucial to choose the appropriate technique based on your specific requirements and to test these operations in a non-production environment before applying them to your production database.
To fix honeycomb fragmentation you need to combine adjacent free segments into one by issuing a coalesce statement
Preventing Problem of Tablespace Fragmentation
You can prevent tablespace fragmentation by specifying all the extents within a tablespace to be the same size.
As you learned earlier, this standardization can be easily implemented by declaring storage parameters for the tablespace and not declaring storage parameters for the objects within the tablespace. This solution may seem like overkill to prevent an easily correctable problem. Sometimes it may be, since you may have good reasons, unrelated to extent size, for placing different objects in different tablespaces. Experienced researchers at Oracle have shown that there is not a great need for many different extent sizes. Some experts recommend only three different extent sizes; 160K, 160 MB and 4 GB. With fewer extent sizes, it is much easier to assign objects to a tablespace, as many of them will have the same extent size.
Resolving Fragmentation
As of Oracle Database 10g, resolving fragmentation issues became fairly trivial.
You can perform an online segment shrink using the Segment Advisor[1] interface accessible through EM. ADDM recommends segments to shrink, and you simply choose to accept the recommendations. For Oracle9i databases, a common means of reducing fragmentation was through an online reorganization accomplished through a
CREATE TABLE...AS SELECT
online operation. That is, the copying of the contents of one table to another while the original table is updated. Changes to the original table were tracked and applied to the new table. Physical and logical attributes of the table could be changed during this online operation, thus allowing an online reorganization. Prior to Oracle9i, reducing fragmentation was more difficult. The general recommendation was to avoid fragmentation through careful planning. But the usual way to solve fragmentation was to reorganize a table by exporting the table, dropping it, and importing it. The data was unavailable while the table was in the process of being reorganized. Many DBAs claimed that they saw improved performance after reorganizing segments into a single extent. Over time, a decrease in performance reoccurred as the number of extents the table occupied increased.
Oracle performance increased as a result of these reorganization operations, but this improvement was not due to a decrease in the number of extents. When a table is dropped and re-created, several things happened that increased performance:
Each block was loaded as full of rows as possible.
As a consequence, the high-water mark of the table (the highest block that has ever had data in it) was set to its lowest point.
All indexes on the table were rebuilt, which meant that the index blocks were as full as possible. The depth of the index, which determined the number of I/Os it takes to get to the leaf blocks or the index, was sometimes minimized.
By eliminating fragments and shrinking segments in a much more automated and online fashion, database releases since Oracle Database 10g greatly simplify solving fragmentation problems; the result is that optimal conditions exist for performance.
The next lesson is the wrap-up for this module.
[1]Segment Advisor:The Segment Advisor identifies segments that have space available for reclamation. It performs its analysis by examining usage and growth statistics in the Automatic Workload Repository (AWR), and by sampling the data in the segment.