Each table and index on a table has an object allocation map (OAM), which holds information on pages allocated to the table or index and is checked when a new page is needed for the index or table.
The OAM is stored on pages allocated to the table or index and is checked when a new page is needed for the index or table. A single OAM page can hold allocation mapping for between 2,000 and 63,750 data or index pages. Each OAM page is the size of one logical page size. For example, on a server using a logical page size of 4K, each OAM page is 4K.
The number of entries per OAM page also depends on the logical page size the server is using. The following table describes the number of OAM entries for each logical page size:
|
2K Logical Page Size |
4K Logical Page Size |
8K Logical Page Size |
16K Logical Page Size |
|---|---|---|---|
|
250 |
506 |
1018 |
2042 |
The OAM pages point to the allocation page for each allocation unit where the object uses space. The allocation pages, in turn, track the information about extent and page usage within the allocation unit. In other words, if the titles table is stored on extents 24 and 272, the OAM page for the titles table points to pages 0 and 256.
The figure below shows an object stored on 4 extents, numbered 0, 24, 272 and 504 for a server that uses 2K logical pages. The OAM is stored on the first page of the first segment. In this case, since the allocation page occupies page 0, the OAM is located on page 1.
This OAM points to two allocation pages: page 0 and page 256.
These allocation pages track the pages used in each extent used by all objects with storage space in the allocation unit. For the object in this example, it tracks the allocation and deallocation of pages on extents 0, 24, 272, and 504.
dbcc checkalloc and dbcc tablealloc examine this OAM page information, in addition to checking page linkage.