How the FSCR search mechanism works when several threads are inserting data?
db2csi 2700021UF6 Comments (2) Visits (4261)
Before data is inserted into a table, an insert search algorithm examines the free space control records (FSCRs) to find a page with enough space for the new data.
If memory serves me correctly (from v10.1+), in non-Purescale, FSCR cache size is 1 page. Concurrent inserts will all use the same FSCR cache per table and end up going to the same page to look for space. In Purescale, the FSCR cache is generally 1 extent per member. Concurrent inserts will potentially do 2 rounds of searching through the cache. The first time, pages are latched conditionally. If case of a latch conflict, move on to the next page. If a second round is required, page latching is done unconditionally. An attempt is made to prevent all inserts from starting on the same page in the cache -- I believe the starting page within the cache is determined by tid%cache size. If the table is of sufficient size, each member gets a unique set of pages.