Benefits of LMTs
Below are the key benefits offered by LMTs. Not all are achievable when migrating to LMTs.
Dictionary contention is reduced.
Extent management in DMTs is maintained and carried out at the data dictionary level. This requires exclusive locks on dictionary tables. Heavy data processing that results in extent allocation/deallocation may sometimes result in contentions in the dictionary.
Extents are managed at the datafile level in LMTs. Dictionary tables are no longer used for storing extent allocation/deallocation information. The only information still maintained in the dictionary for LMTs is the tablespace quota for users.
Space wastage removed.
In DMTs, there is no implied mechanism to enforce uniform extent sizes. The extent sizes may vary depending on the storage clause provided at the object level or the tablespace level, resulting in space wastage and fragmentation.
Oracle enforces the uniform extents allocation in the LMTs (when created with UNIFORM SIZE clause). Space wastage is removed, as this would result in all the same sized extents in the tablespace.
No Rollback generated.
In DMTs, all extent allocations and deallocations are recorded in the data dictionary. This generates undo information thus using vital resources and may compete with other processes.
In LMTs, no rollback is generated for space allocation and deallocation activities.
ST enqueue contention reduced.
In DMTs, Space Transaction (ST) enqueue is acquired when there is a need for extent allocations in DMTs. It is also exclusively acquired by SMON process for coalescing free space in DMTs. Only one such enqueue exists per instance, and may sometimes result in contention and performance issues if heavy extent processing is being carried out. The following error is common in such scenario.
ORA-01575: timeout warning for space management resource
As ST enqueue is not used by LMTs it reduces the overall ST enqueue contention.
Recursive space management operations removed.
In DMTs, SMON process wakes up every 5 minutes for coalescing free space in DMTs. Optionally, the ALTER TABLESPACE
On the other hand, LMTs avoid recursive space management operations and automatically track adjacent free space, thus eliminating the need to coalesce free extents. This further reduces fragmentation.
Fragmentation reduced.
Fragmentation is reduced in LMTs but not completely eliminated. Since adjacent free spaces are automatically tracked, there is no need to do coalescing, as is required in the case of DMTs.
Management of Extents in LMTs
Oracle maintains a bitmap in each datafile to track used and free space availability in an LMT. The initial blocks in the datafiles are allocated as File Space Bitmap blocks to maintain the extent allocation information present in the datafile. Each bit stored in the bitmap corresponds to a block or a group of blocks. Whenever the extents are allocated or freed, oracle changes the bitmap values to reflect the new status. Such updates in the bitmap header do not generate any rollback information.
The number of blocks that a bit represents in a bitmap depends on the database block size and the uniform extent size allocated to the tablespace. For example, if the DB_BLOCK_SIZE parameter is set to 8K, and the tablespace is created with uniform extent sizing of 64K, then 1 bit will map to one 64K extent, i.e., 64K (extent size)/8K (block size) = 8 database blocks.
......
LOCALLY MANAGED TABLESPACES IN ORACLE
Introduction
Traditionally, up to Oracle8 Release 8.0.5 the management of free and used extents of a tablespace was done in the data dictionary. These “traditional” tablespaces are also called “Dictionary Managed Tablespaces”, in order to differentiate them from a new type of table space called Locally Managed Tablespaces introduced in Oracle8i Release 8.1.5. All extent information in Locally Managed Tablespaces is tracked by bitmaps in the datafiles of a tablespace.
Dictionary Managed Tablespaces
In the traditional or Dictionary Managed Tablespaces, the data dictionary does extent management. When extents are allocated or freed, data dictionary tables are updated and rollback information about each dictionary table update is maintained. All data dictionary operations are subject to the same space management considerations as any other “user” space maintenance – for example, rollback activity due to updates of these dictionary tables could cause the rollback segment to extend causing more space management operations. This was the only option available before release 8.1.5.
Locally Managed Tablespaces
Bitmaps manage space allocation very efficiently, and require no dictionary access to allocate an extent to an object. In Locally Managed Tablespaces, bitmaps provide extent management. When extents are allocated or freed, a bitmap is updated to indicate the freed or used status of blocks in a datafile. Each datafile in a locally managed tablespace has its own bitmap. Each bit in the bitmap tracks a block or a group of blocks in an extent. When an extent is allocated or freed, the bitmap is changed to reflect the new status of these blocks in that extent. These bitmap changes do not generate rollback information for these “space management” operations. This is a new option available from Oracle8i Release 8.1.5.
Extent Allocation in Locally Managed Tablespaces
The LOCAL clause of the EXTENT MANAGEMENT clause specifies this method of space management in the tablespace CREATE statement.
Extents in Locally Managed Tablespaces can be created specifying either
UNIFORM SIZE - where all extents are the same size, or, AUTOALLOCATE - where extents are automatically sized by the system at tablespace creation time.
If AUTOALLOCATE or UNIFORM is not specified, then AUTOALLOCATE is the default.
No comments:
Post a Comment