Heute habe ich relativ lange über das Thema Row Migration nachgedacht. Ausgangspunkt war eine partitionierte Tabelle, die im April neu erzeugt worden war, und deren seither gefüllte Partitionen durchschnittlich deutlich weniger Sätze aufnehmen konnten, als die im Rahmen des initialen Ladens erstellten Partitionen.
PARTITION_NAME BLOCKS NUM_ROWS COMPRESS ROWS_PER_BLOCK AVG_ROW_LEN PCT_FREE ---------------- ---------- ---------- -------- -------------- ----------- -------- XXX_201101 233677 33187356 ENABLED 142 86 10 XXX_201102 105034 15609036 ENABLED 149 87 10 XXX_201103 139202 20494440 ENABLED 147 86 10 XXX_201104 192264 19593779 ENABLED 102 87 10 XXX_201105 254736 19182945 ENABLED 75 87 10 XXX_201106 189427 14029238 ENABLED 74 87 10
Da die Länge der Sätze sehr stabil (und Row Chaining sehr unwahrscheinlich) sein sollte, war meine Theorie, dass die häufigen UPDATEs in der Tabelle in Verbindung mit der Compression zu Row Migration führen könnten - da die Standard Compression (und für Updates anscheinend auch die OLTP Compression, wie Randolf Geist gelegentlich gezeigt hat) Sätze nach dem Update nicht wieder komprimiert, so dass sogar eine logische Verkleinerung eines Eintrags zu einer physikalischen Vergrößerung führt. Oder in der Zusammenfassung des Herrn Geist: "Mixing compression with a significant number of updates is a bad idea in general".
Nachdem ich mir die Details zur Row Migration halbwegs vollständig zusammengesucht hatte, bin ich dann auf Tanel Poders Artikel Detect chained and migrated rows in Oracle – Part 1 gestoßen, der offenbar so ziemlich alle relevanten Informationen enthält. Mit dem Befehl ANALYZE ... LIST CHAINED ROWS konnte ich für einige Partition bestimmen, dass tatsächlich ca. 1-2% der Sätze chained (bzw. in diesem Fall eher migrated) sind. Ob das ein echtes Problem ist, ist mir dabei noch nicht ganz klar - aber günstig ist es bestimmt nicht.
Keine Kommentare:
Kommentar veröffentlichen