Oracle7 Parallel Server Concepts and Administrator's Guide Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index

Go to previous file in sequence Go to next file in sequence

Space Management and Free List Groups

This chapter explains space management concepts:

See Also: "Using Free List Groups to Partition Data" [*] for a description of space management procedures.

How Oracle Handles Free Space

This section provides an overview of how Oracle handles free space. It contains the following sections:


Oracle Parallel Server enables transactions running on separate instances to insert and update data in the same table concurrently, without contention to locate free space for new records.

Figure 11 - 1. Instances Concurrently Inserting to a Table

To take advantage of this capability, you must actively manage free space in your database using several structures which are defined in this chapter.

For each database object (a table, cluster, or index), Oracle keeps track of blocks with space available for inserts (or for updates which may cause rows to exceed space available in their original block). A user process that needs free space can look in the master free list of blocks that contain free space. If the master free list does not contain a block with enough space to accommodate the user process, Oracle allocates a new extent.

New extents that are automatically allocated to a table add their blocks to the master free list. This can eventually result in contention for free space among multiple instances on a parallel server because the free space contained in automatically allocated extents cannot be reallocated to any group of free lists. You can have more control over free space if you specifically allocate extents to instances; in this way you can minimize contention for free space.

Definition of Structures

Oracle uses the following structures to manage free space:

Note: As of Oracle Server release 7.2, process free lists and free list groups are supported on all database objects alike: tables, indexes, and clusters.

Segments and Extents

A segment is a unit of logical database storage. Oracle allocates space for segments in smaller units called extents. An extent is a specific number of contiguous data blocks allocated for storing a specific type of information.

A segment thus comprises a set of extents allocated for a specific type of data structure. For example, each table's data is stored in its own data segment, while each index's data is stored in its own index segment.

The extents of a segment are all stored in the same tablespace; they may or may not be contiguous on disk. The segments can span files, but individual extents cannot.

Note that although you can allocate additional extents, the blocks themselves are allocated separately.

High Water Mark

The high water mark is the boundary between used and unused space in a segment. As requests for new free blocks are received, the block to which the high water mark points becomes a used block, and the high water mark is advanced to the next block. In other words, the segment space to the left of the high water mark is used, and the space to the right of it is unused.

Figure 11 - 2 shows a segment which consists of three extents containing 10K, 20K, and 30K of space, respectively. The high water mark is in the middle of the second extent, thus the segment contains 20K of used space (to the left of the high water mark), and 40K of unused space (to the right of the high water mark.

Figure 11 - 2. High Water Mark

See Also: Oracle7 Server Concepts for further information about segments and extents.

The Master Free List

The master free list (also known as the "common pool") is a repository of blocks which contain available space, drawn from any extent in the table. It exists by default, and includes:

In a highly concurrent environment there is potentially a lot of contention for the segment header (which contains the master free list). The segment header block contains information about the segment and the extents in the segment.

The following figure shows the blocks of a file in which the master free list is stored in the segment header block. Three instances are pinging this block in their effort to obtain free space. Because there is only one free list, there is only one insertion point. Process free lists can help to reduce this contention by spreading this insertion point over multiple blocks, each of which will be accessed less often.

Figure 11 - 3. Contention for Master Free List

Process Free Lists

A process free list (also termed simply a "free list" in this documentation) is a list of free data blocks that can be drawn from a number of different extents within the segment.

Process free lists must be specifically enabled by the user. You can specify the number of process free lists desired by setting the FREELISTS parameter when you create a table, index or cluster. The maximum value of the FREELISTS parameter depends on the Oracle block size on your system. In addition, for each free list, you need to store a certain number of bytes in a block to handle overhead.

Additional Information: The reserved area and the number of bytes required per free list depend upon your platform. For more information, see your Oracle system-specific documentation.

A process free list can be drawn from the master free list of blocks, or you can partition multiple free lists so that extents are allocated to specific database instances. The free list is tied to the instance--it determines where a row can be inserted. Process free lists are stored in the segment header block of a file, if no free list groups are allocated.

Blocks in free lists contain free space greater than PCTFREE (the percentage of a block to be reserved for updates to existing rows). In general, blocks included in process free lists for a database object must satisfy the PCTFREE and PCTUSED constraints described in the chapter "Data Blocks, Extents, and Segments" in Oracle7 Server Concepts.

As illustrated in Figure 11 - 4, process free lists provide free data blocks from available extents to different instances. However, without free list groups, the instances must nonetheless all ping the segment header block in order to access the free lists.

Figure 11 - 4. Process Free Lists

Process free lists thus help to solve the problem of multiple users in a single instance environment by easing contention on segment header blocks in an instance. By contrast, a parallel server has multiple instances, and the process free lists alone cannot solve the problem of contention here. Free list groups, however, effectively reduce pinging between instances.

Attention: In Oracle Parallel Server, we recommend that you always use free list groups, along with process free lists.

Free List Groups

A free list group is a set of free lists you can specify for use by one or more particular instances. When enabled, free list groups divide the set of free lists into subsets. Descriptions of process free lists are stored in separate blocks for the different free list groups. Each free list group block contains the same free lists described above (master free list and process free lists), except that every instance gets its own. (Or, in the case of more instances than free list groups, multiple instances hash into the same free list group.) This ensures that the instances do not compete for the same blocks

Each free list group provides free data blocks to accommodate inserts or updates on tables and clusters, and is associated with instance(s) at startup.

Example: Free List Groups

Figure 11 - 5 illustrates the division of free space for a table into a master free list and two free list groups, each of which contains three free lists.

The table was created with one initial extent, after which extents 2 and 5 were allocated to instance X, extents 3 and 4 were allocated to instance Y, and extent 6 was allocated automatically (not to a particular instance). Notice the following:

Each user process running on instance X uses one of the free lists in group X, and each user process on instance Y uses one of the free lists in group Y. If more instances start up, their user processes share free lists with instance X or Y.

Figure 11 - 5. Groups of Free Lists for a Table

SQL Options for Managing Free Space

Several SQL options enable you to allocate process free lists and free list groups for tables, clusters, and indexes. You can explicitly specify that new space for an object be taken from a specific datafile. You can also associate free space with particular free list groups, which can then be associated with particular instances.

The SQL statements include:

You can use these SQL options with the initialization parameter INSTANCE_NUMBER to associate data blocks with instances.

See Also: Oracle7 Server SQL Reference for complete syntax of these statements.

Managing Free Space on Multiple Instances

This section describes:

Partitioning Free Space into Multiple Free Lists

You can partition free space for individual tables, clusters (other than hash clusters), and indexes into multiple process free lists. Multiple free lists allow a process to search a specific pool of blocks when space is needed, thus reducing contention among users for free space. Within an instance, using free lists can reduce contention if multiple processes are inserting into the same table.

Each table has a master free list of blocks with available space, and can also contain multiple free lists. Before looking in the master free list, a user process scans the appropriate free list to locate a block that contains enough space.

Partitioning Data with Free List Groups

The separation of free space into groups can improve performance by reducing contention for free data blocks during concurrent inserting by multiple instances on a parallel server. You can thus create groups of process free lists for a parallel server, each of which can contain multiple free lists for a table, index, or cluster. You can use free list groups to partition data by allocating extents to particular instances.

In general, all tables should have the same number of free list groups, but the number of free lists within a group may vary, depending on the type and amount of activity of each table.

Partitioning free space can particularly improve the performance of applications that have a high volume of concurrent inserts, or updates requiring new space, from multiple instances. Performance improvements also depend, of course, on your operating system, hardware, data block size, and so on.

Note: In a multi-instance environment, information about multiple free lists and free list groups is not preserved upon import. If you use Export and Import to back up and restore your data, it will be difficult to import the data so that it is partitioned again.

See Also: "Free Lists with Import and Export Utilities" [*].

"Application Analysis" [*] for more information on partitioning data.

How Free Lists and Free List Groups Are Assigned to Instances

The following figure illustrates the way in which free lists and free list groups are assigned to instances.

Figure 11 - 6. How Free Lists and Free List Groups Are Assigned

* Free lists are partitioned as follows: If there are 3 instances and 35 free list groups, then instance 1 will handle the first twelve free list groups, instance 2 the next twelve, and instance 3 the remaining eleven. The actual free list group block is determined by hashing oracle_pid by the number of free list groups.

Free Lists Associated with Instances, Users, and Locks

This section describes:

Associating Instances with Free Lists

A table can have separate groups of process free lists that are assigned to particular instances. Each group of free lists can be associated with a single instance, or several instances can share one group of free lists. All instances also have access to the master free list of available space.

Groups of free lists allow you to associate instances with different sets of data blocks for concurrent inserts and updates requiring new space. This reduces contention for the segment header block, which contains information about the master free list of free blocks. For tables that do not have multiple free list groups, the segment header also contains information about free lists for user processes. You can use free list groups to locate the data that an instance inserts and accesses frequently in extents allocated to that instance.

Data partitioning can reduce contention for data blocks. Often the PCM locks that cover blocks in one free list group tend to be held primarily by the instance using that free list group, because an instance that modifies data is usually more likely to reuse that data than other instances. However, if multiple instances take free space from the same extent, they are more likely to contend for blocks in that extent if they subsequently modify the data that they inserted.

Assignment of New Instances to Existing Free List Groups

If MAXINSTANCES is greater than the number of free list groups in the table or cluster, then an instance number maps to the free list group associated with:

instance_number modulo number_of_free_list_groups

Note: "Modulo" (or "rem" for "remainder") is a formula for determining which free list group should be used by calculating a remainder value. In the following example there are 2 free list groups and 10 instances. To determine which free list group instance 6 will use, the formula would read 6 modulo 2 = 0. Six divided by 2 is 3 with zero remainder, so instance 6 will use free list group 0. Similarly, instance 5 would use free list group 1 because 5 modulo 2 = 1. Five is divisible by 2 with a remainder of 1.

If there are more free list groups than MAXINSTANCES, then a different hashing mechanism is used.

If multiple instances share one free list group, they share access to every extent specifically allocated to any instance sharing that free list group.


In a system with relatively few nodes, such as a clustered system, the FREELIST GROUPS option for a table should generally have the same value as the MAXINSTANCES option of CREATE DATABASE, which limits the number of instances that can access a database concurrently.

In a massively parallel system, however, MAXINSTANCES could be many times larger than FREELIST GROUPS so that many instances share one group of free lists.

See Also: "Associating Instances, Users, and Locks with Free Lists" [*].

Associating User Processes with Free Lists

User processes are associated with process free lists based on their Oracle process IDs. Each user process has access to only one free list in the free list group for the instance on which it is running. Every user process also has access to the master free list of free blocks.

If a table has multiple free lists but does not have multiple free list groups, or has fewer free list groups than the number of instances, then each free list is shared by user processes from different instances.

Associating PCM Locks with Free Lists

If each extent in the table is in a separate datafile, you can use the GC_FILES_TO_LOCKS parameter to allocate specific ranges of PCM locks to each extent, so that each set of PCM locks is associated with only one group of free lists.

Figure 11 - 7 shows multiple extents in separate files. The GC_FILES_TO_LOCKS parameter allocates 10 locks to files 8 and 10, and 10 locks to files 9 and 11. Extents A and C are in the same free list group, and extents B and D are in another free list group. One set of PCM locks is associated with files 8 and 10, and a different set of PCM locks is associated with files 9 and 11. You do not need separate locks for files which are in the same free list group (such as files 8 and 10, or files 9 and 11).

Figure 11 - 7. Extents and Free List Groups

See Also: "Setting GC_FILES_TO_LOCKS: PCM Locks for Each Datafile" [*].

Controlling the Allocation of Extents

This section covers the following topics:

When a row is inserted into a table and new extents need to be allocated, a certain number of contiguous blocks (specified with !blocks in the GC_FILES_TO_LOCKS parameter) are allocated to the free list group associated with an instance. Extents allocated when the table or cluster is first created and new extents that are automatically allocated add their blocks to the master free list. Automatic allocation of extents has the disadvantage that you cannot reallocate this free space to any group of free lists.

Automatic Allocation of New Extents

When a user explicitly allocates an extent without specifying an instance, or when an extent is automatically allocated to a segment because the system is running out of space (the high water mark cannot be advanced any more), the new extent becomes part of the unused space. It is placed at the end of the extent map, which means that the current high water mark is now in an extent "to the left" of the new one. The new extent is thus added "above" the high water mark.

Pre-allocation of New Extents

As of Oracle Server release 7.2, you have two options for controlling the allocation of new extents.

Pre-allocating extents is a static approach to the problem of preventing automatic allocation of extents by Oracle. You can pre-allocate extents to tables that have free list groups. This means that all the free blocks will be formatted into free lists, which will reside in the free list group of the instance to which you are pre-allocating the extent. This approach is useful if you need to partition data so as to greatly reduce all pinging on insert, or if you need to accommodate objects which you expect will grow.

Note: False pinging will not be eliminated.

See Also: "Pre-allocating Extents (Optional) [*].

Dynamic Allocation of New Extents

If you primarily need to accommodate growth, the strategy of dynamically allocating blocks to free list groups would be more effective than pre-allocation of extents. You can use the !blocks option of GC_FILES_TO_LOCKS to dynamically allocate blocks to a free list from the high water mark within a lock boundary. This method does not eliminate all pinging on the segment header-- rather, it allocates blocks on the fly so that you do not have to pre-allocate extents. This dynamic approach became available with Oracle Server release 7.2.

Remember that locks are owned by instances. Blocks are allocated on a per-instance basis--and that is why they are allocated to free list groups. Within an instance, blocks can be allocated to different free lists.

Using this method, you can either explicitly allocate the !blocks value, or else leave the balance of new blocks still covered by the existing PCM lock. If you choose the latter, remember that there still may be contention for the existing PCM lock by allocation to other instances. The blocks returned may be covered by a number of PCM locks.

See Also: "Dynamically Allocating Extents" [*].

Moving the High Water Mark of a Segment

A segment's high water mark is the current limit to the number of blocks that have been allocated within the segment. If you are allocating extents dynamically, the high water mark is also the lock boundary. The lock boundary and the number of blocks which will be allocated at one time within an extent must coincide. This value must be the same for all instances.

Consider the following example, in which there are 4 blocks per lock (!4). Locks have been allocated before the block content has been entered. If we have filled datablock D2, held by Lock 2, and then allocate another range of 4 blocks, only the number of blocks which fits within the lock boundary will actually be allocated: in this case, blocks 7 and 8. Both of these are protected by your current lock. With the high water mark at 8, when instance 2 allocates a range of blocks, all four blocks 9 to 12 are allocated, covered by lock 3. The next time instance 1 allocates blocks it will get blocks 13 to 16, covered by lock 4.

Figure 11 - 8. A File with High Water Mark Moving as Blocks Are Allocated


The example in this section assumes that GC_FILES_TO_LOCKS has the following setting for both instances:

GC_FILES_TO_LOCKS = "1000!5"

With the EACH option specified, each file in file_list is allocated #locks number of PCM locks. Within each file, !blocks specifies the number of contiguous data blocks to be covered by each lock.

Figure 11 - 9 shows the incremental process by which the segment grows:

In this way, if user A on Instance 1 is working on block 10, no one else from either instance can work on any block in the range of blocks that are covered by Lock 2 (that is, blocks 6 through 10).

Figure 11 - 9. Allocating Blocks Within an Extent

Go to previous file in sequence Go to next file in sequence
Prev Next
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index