Now, getting blocks off of the freelist is a serial process.

In order for multi ple processes to concurrently access and modify this linked list, we must ensure onl y one session at a time modifies it. Hence, in a heavy insert/update system -- the si ngle freelist can become a point of contention -- one data structure for ALL inserter s. This is where multiple freelists come into play. Oracle will take the free list and break it into many freelists. You are assigned a freelist for a segment in some fashion and other sessions will use other freelists for that same segment (sort of like how we bal ance transactions across rollback segments). Now, instead of having one data structu re for 5 concurrent inserts into a table -- we could have five data structures -- no cont ention now. In my book -- i demonstrate this with a multi-user example showing the before an d after effects of using multiple freelists. The result can be quite dramatic. Even th ough we permit (naturally) concucrrent inserts into a table -- there can be some serious free list contention in a heavily inserted into table, like an audit trail or such. Setting freelists to the estimated number of concurrent insert request can dramatically improve performance. Ok, so thats for single instance Oracle -- we can take a single freelist for a s ingle segment and break it into multiple freelists for that segment, increasing concur rency. Now, look at Oracle Parallel Server where there is more then one instance mounti ng and opening the same database. This is where freelist groups come into play. Freelist groups allow us to allocate freelists to specific instances -- to reduc e cross-instance contention for space. This allows instance 1 to have its freelis ts for its sessions, instance 2 to have its freelists for its sessions -- and they will not have to coordinate with eachother on space allocation.