Wieder mal bin ich spät dran und exzerpiere relevante Artikel, kurz bevor sie aus dem 30-Tage-Korridor meines Blog Aggregators fallen. Und wieder mal ist es der zur Zeit ungeheuer produktive Jonathan Lewis, dessen Beiträge ich zusammenfasse. In den fraglichen Artikel beschäftigt sich der Herr Lewis mit dem Verhalten von "Index Splits", die auftreten, wenn ein neuer Index-Eintrag nicht mehr in den vorgesehenen Block der Index-Struktur passt:
- Index splits: erläutert den Unterschied zwischen dem 50:50-Split (den die Statistik "leaf node splits" erfasst) und dem 90:10-Split (erfasst unter "leaf node 90-10 splits"): letzterer tritt auf, wenn der neue Eintrag oberhalb aller bisher bekannten Werte liegt - und in diesem Fall wird nur der neue Eintrag in einen eigenen Block geschrieben (weshalb der Split eher als 100:0 zu bezeichnen wäre). Theoretisch könnte der zweite Fall (also der Sonderfall) effizienter sein als er erste - er ist es aber nicht, wie der im Artikel vorgestellte Test zeigt: die Erzeugung von undo und redo sind in beiden Fällen nahezu identisch. Die Ursache dafür ist, dass beide Fälle intern gleich behandelt werden: der alte Block wird gesichert, ein neuer Block ergänzt und dann werden beide Blocks gefüllt. Die Ursache dafür ist wahrscheinlich, dass die Entwickler bei Oracle den Code nicht komplizierter machen wollten als notwendig, obwohl hier vermutlich ein gewisses Optimierungspotential existieren würde.
- Index Splits – 2: liefert einen Test-Fall, der eine Erklärung für das im ersten Artikel beobachtete Verhalten liefert: die dabei durchgeführte Änderung am Index ändert das row directory des Blocks. Demnach ändert sich zwar nicht der Inhalt, aber die Sortierung des Blocks - und lässt das vollständige Schreiben beider Blocks sinnvoll erscheinen.
- Index Splits – 3: liefert ergänzendes Material.
Keine Kommentare:
Kommentar veröffentlichen