Adam,

>
>> There was a bug in the
>> index re-combination code that could, under heavy load, leave a
>> pointer in a parent node to a page that had been a lower level index
>> node, but had since been recombined, released, and reused as a
>> data page.
>
> That makes sense. This is a large customer database, although not our
> largest or highest utilised database. The server has something like 16
> cores so there would be a greater chance for concurrent database load
> than the next largest server with 8 cores.
>

If memory serves, the bug shows up on an index where entries are made
out of order (meaning not sorted by the index key as they are when
the key is a timestamp or generator), and where key values are deleted
(meaning that the record was deleted, or the key value updated) often.
I think it only shows up when an index leaf node goes below 30% (or
33%) full when its leftmost neighbor is also below the same level,
causing them to be combined and the page released and reassigned as
a data page, and then the combined page fills and splits again
onto a different page, all while some transaction is trying to read
a record on the page that's come and gone and been recreated on
a different page. In short, a very busy index.

And yes, 16 cores would increase the chances of this happening.

Best,

Ann