Jonathan Lewis listet einige der Gründe, die gegen die Verwendung von Tabellen mit mehr als 255 Spalten sprechen - bekanntlich führt diese Spaltenanzahl zur Aufteilung einer row in mehrere row pieces, und damit zu inter- oder intra-row-chaining und sonstigem Ärger. Zu den unerfreulichen Effekten gehören:
- in 10g führt die Statistikerfassung bereits bei weniger als 255 Spalten - nämlich bei etwa 165 Spalten - dazu, dass mehrere FTS erforderlich werden, um die Daten einzulesen.
- das Splitting in row pieces startet am Ende der Spaltenliste: eine Tabelle mit 256 Spalten zerfällt also in ein erstes row piece mit einer Spalte und ein zweites row piece mit 255 Spalten. Da der Zugriff auf das zweite row piece kostspieliger ist als der auf das erste, ist das eine unglückliche Design-Entscheidung.
- im Fall von direct path tablescans führt inter-row-chaning zu einem db file sequential read-Zugriff, was sich sehr massiv auf die Performance auswirken kann.
- row chaining bringt außerdem hohe CPU-Kosten mist sich.
Vermutlich könnte man die Liste noch um weitere Punkte ergänzen.
Keine Kommentare:
Kommentar veröffentlichen