v$waitstat where class='free list' shows the so-called free list blocks, blocks created because you configure more than 1 freelist group as you usually do in OPS and RAC. So if you have only 1 freelist group which is default, you'll never see any number on that row even if you have heavy freelist contention problem. I think that's quite correct. With 1 freelist group, there's no freelist block. Freelists simply reside in the segment header block. If the tablespace is not ASSM, beginning with the 2nd block, you should see data. With 2 or more freelist groups (even on non-OPS or RAC), there're 2 or more, respectively, blocks dedicated to contain freelist information. (Note that you'll never have only 1 freelist block.) Only after segment header block and those freelist group blocks will you see data. The data dump trace file shows "nfb = 1" for a regular table (number of freelist blocks = 0 and number of freelist groups = 1); this table starts to show data on block 2. Trace shows "nfb = 3" for a table created with "storage (freelist groups 2)". So nfb is a misnomer if you think it's an acronym for "number of freelist blocks" (as on p.222, James Morle, Scaling Oracle8i, or in Stephan Haisley's "FREELIST MANAGEMENT WITH ORACLE 8I" at https://metalink.oracle.com/metalink/plsql/docs/FREEMGT.PDF). In fact, NFB may as well be thought of as the number of freelist blocks + 1 (the 1 is for segment header block). Note that it's impossible to see "nfb = 2" in a data dump trace, just as impossible to have only 1 freelist block as mentioned above. freelist freelist nfb groups blocks -------- -------- --- 1 (default) 0 1 2 2 3 3 3 4 ... Note1: As a side note, "nfl" in the dump trace is not a simple "number of freelists". When you specify "storage (freelists 1)" or omit this clause, the segment has one segment freelist and nfl=1. This freelist acts as the master freelist and is shared by all server processes that need free blocks. When you specify "storage (freelists n)" where n >=2, dump trace shows nfl=n but the actual total number of freelists is n+1, because Oracle additionally creates a segment freelist which acts as the master freelist and is not counted in n. Those n freelists are called process freelists and each process can only use one of them once that process is associated, and gets stuck, with it. So we can say "nfl" in the trace is the number of freelists when it's 1 but it is the number of *process* freelists when it's > 1. Note2: All above is only relevant in a non-ASSM tablespace. Yong Huang > The block dump output shows the blocktype, 0x16(22) is the freelist block. > > While for those tables without freelist groups [should be with the default > freelist group 1 -- Yong], segment header will act as the freelist block > (type = 16, 0x10). Maybe this is why oracle will always report NFB=1 for these > tables. > And for those tables with free list contention, it will report buffer busy > wait instead of "free list".