ASSM Bug - Ursachen

Randolf Geist hat gerade einen Blog-Artikel ASSM bug reprise - part 1 veröffentlicht, in dem er eine sehr griffige Erklärung für den folgenden Bug gibt:

There is a more or less famous bug in ASSM (see bug 6918210 in MOS [...]) in versions below 11.2 that so far has been classified as only showing up in case of a combination of larger block sizes (greater the current default of 8K) and excessive row migrations. With such a combination it was reproducible that an UPDATE of the same data pattern residing in an ASSM tablespace caused significantly more work than doing the same in a MSSM tablespace, because apparently ASSM had problems finding suitable blocks to store the migrated rows.

Demnach tritt dieser Bug unter folgenden Umständen auf:

• ein Block erreicht die Obergrenze möglicher ITL-Einträge (255 für Blocks >= 16K oder der dafür verwendete Speicherplatz erreicht 50% der Blocksize: deshalb sind es für 8K Blöcke 169 Einträge)
• der Block ist aber hinsichtlich des FREE Spaces noch nicht gefüllt (ein niedriger PCTFREE-Wert erhöht also die Wahrscheinlichkeit des Auftretens)
• "The basic problem of the bug seems to be that blocks in such a state are still considered as possible candidates for inserts of migrated rows, but have then to be rejected as Oracle recognizes that no further ITL entries can be added. The more blocks get into this state, the harder Oracle has to work to find a block that really can be used for storing the migrated row."
• Für Blöcke bis 8K tritt der Fall vermutlich selten auf, da die migrierten Sätze in diesem Fall nur sehr klein sein können

Nachtrag 04.06.2011: den zweiten Teil seiner Untersuchungen zu Bug 6918210 beginnt Randolf Geist mit dem Hinweis "The most important part of the bug is that it can only be hit if many row migrations happen during a single transaction." Das war mir im ersten Teil ebenso entgangen wie der dort erscheinende Hinweis: "for each row migrated into a block a new ITL is allocated".