Hm. That's an interesting note. There are a couple of things that puzzle me in it.
- If the first extent in each allocation unit it "short" as you labelled it and as such "invisible" to the allocation process that create index (clustered or any?) / fast bcp uses does it mean that there is roughly 3% of DB which is a no-man's-land for index creation / bcp process? Consequently one may encounter a situation when there is ample space in DB for a particular object but index creation fails (get's stuck indefinitely?) since the only free space in the DB is that of short extents useless for this type of operation (3 GB of each 100 GB of database space is in fact "invisible" for index creation)? As a consequence of this, I'd (also) expect that index creation performance will deteriorate to the same extent as fast bcp for the same object - do you see it too, Pål?
- If the first extent in each allocation unit is "useless" from index creation/fast bcp perspective, why the algorithm of locating the "useful" free extents is not made to ignore the first extent in the search for free extents necessary for index creation / fast bcp operation? I guess the reason is that there is only one bit in the GAM that simply states free/full for its allocation units which cannot be turned on on having all of the "long" extents exhausted as this will make these same 3% wasted globally.
- We are talking about performance drop from over 1K to below 100 - 90% drop due to reading sequentially all free/full allocation units in the DB - that sounds very bad. There should definitely be a faster way to locate free "large" extents than physically browsing through all allocation units in the DB? Another bit?
- If index creation/fast bcp hits at some point a sequential read from the beginning of the DB - than fast BCP/index creation should deteriorate over time in general? When one fills a large table (if I understand the process you outlined right) the process first tries to locate free extend on the same allocation unit with the extent it currently works on, failing to find one it moves to locating free extend on any other allocation units where the same object resides (via OAM), failing to find there it moves to GAM and starts browsing through all allocation units without reference to the current object sequentially (find free/full page - test it - nope, no large extents there - find next &c). Should not this always happen? Filling table with fast bcp should leave gaps (short extents) as it progresses, gradually reaching a point where OAM lists no more free extents for the object and pushing the search to get to GAM. From this point on the performance should sink consistently? What am I missing?