Rolf B: "Backup-Verwaltung" für DB

Beitrag lesen

Hallo Raketenwilli,

weil der Zugriff auf die kleine Datenmenge der Indizes zwar „seriell“ erfolgt

Nein, immer nur als Baum.

der Zugriff auf die eigentlichen Daten sodann aber „wahlfrei“

Was auch ein Problem darstellen kann. Wenn ich viele Sätze in Indexreihenfolge lesen will, die Indexreihenfolge aber nicht der physikalischen Reihenfolge der Rows in der Table entspricht, dann springt er auf der Platte kreuz und quer herum. Bei kleinen Tables ist der Tablespace dann schnell im Buffer und man merkt nichts, bei Millionen von Rows kann das den Lesekopf schnell ins Flattern bringen.

Wenn die DB auf einer SSD liegt, ist es weniger schlimm, weil da kein Kopf herumhüpft, aber auch dort ist ein sequenzieller Zugriff schneller, als kreuz und quer Sektoren abzuholen.

Heißt: Wenn man beabsichtigt, via Index größere Mengen an Datensätzen abzuholen, sollte das tunlichst der Primärindex sein. Denn MySQL und sein Datenmariechen verwenden den Primärindex als "Clustering Index". Das bedeutet: Die Daten liegen nicht in Zugangsreihenfolge in der DB-Datei, sondern auch die DB-Datei ist als Baumstruktur organisiert und die Rows liegen in Reihenfolge des Primärschlüssels darin. Weshalb eine Reorganisation auch nützlich ist, denn dann werden die Knoten des Baums auf der Platte so umgeordnet, dass sie in Indexreihenfolge dort abgelegt sind.

Ob das Datenmariechen bei einer indexsequenziellen Leseoperation, die nicht über den Primärindex geht, dieses Problem automatisch erkennt und Zugriffe optimiert (z.B. durch erstellen einer Temp-Datei, die erst nachträglich sortiert wird), weiß ich nicht. Das ist die Magie des SQL Optimizers. Und die Optimierungsjobs, die über die Tablespaces rennen, dienen auch dazu, Informationen über die Datenverteilung zu gewinnen und dem Optimizer damit Futter zu geben.

Ein Hinweis noch zu Backups: Billigdatenbanken sind nicht unbedingt dazu gemacht, unterbrechungsfreie Backups zu ziehen. Denn während eines Backups darf aus Konsistenzgründen nichts an der Datenbank verändert werden - was für die DB Engine bedeutet, dass sie entweder die DB brutal gegen Updates sperren muss, oder die Updates, die trotzdem gefordert werden, erstmal irgendwo zwischenspeichern muss, bis das Backup fertig ist. Weißt Du, Raketenwilli, wie sich das beim Datenmariechen verhält?

Rolf

--
sumpsi - posui - obstruxi