Die Seitengröße, die Sie für Ihre Datenbank auswählen, kann sich auf die Performance der Datenbank auswirken. Im Allgemeinen sind kleine Seiten eher bei Vorgängen nützlich, die eine relativ kleine Anzahl von Zeilen von wahlfreien Positionen abrufen. Im Gegensatz dazu sind große Seiten bei Abfragen nützlich, die einen sequenziellen Table-Scan ausführen, vor allem wenn die Zeilen auf den Seiten in einer ähnlichen Reihenfolge gespeichert sind, wie sie über einen Index abgerufen werden. In diesem Fall kann das Lesen von einer Speicherseite, um die Werte einer Zeile zu erhalten, als Nebeneffekt bewirken, dass der Inhalt der nächsten Zeilen in den Speicher geladen wird. Häufig ermöglicht es das physische Design von Plattenspeichern, dass wenige große Blöcke effizienter als viele kleine abgerufen werden.

SQL Anywhere erstellt für jede Tabelle eine Bitmap, welche die Position jeder Tabellenseite in der kompletten DBSpace-Datei reflektiert. Der Datenbankserver verwendet die Bitmap, um große Blöcke (64 KByte) von Tabellenseiten anstelle von einzelnen Seiten zu lesen. Diese Effizienz, die auch als Gruppenlesevorgang bezeichnet wird, reduziert die Gesamtzahl der I/O-Vorgänge auf der Festplatte und verbessert die Performance. Benutzer können die Kriterien des Datenbankservers für die Erstellung oder Verwendung von Bitmaps nicht beeinflussen.

Falls Sie eine größere Seitengröße, wie zum Beispiel 8 KByte, wählen, sollten Sie auch die Cachegröße erhöhen, da sonst nur eine geringere Zahl der großen Seiten in den Cache passt. So kann zum Beispiel ein 2-MByte-Speicher 512 Seiten speichern, die jeweils 1 KByte groß sind, aber nur 128 Seiten mit einer Größe von 8 KByte. Das optimale Verhältnis von Seitengröße zur Cachegröße hängt von Ihrer Datenbank und der Art der Abfragen ab, die Ihre Anwendung durchführt. Sie können Performance-Tests mit unterschiedlichen Cachegrößen durchführen. Wenn Ihr Cache nicht genügend Seiten aufnehmen kann, wird die Performance leiden, da der Datenbankserver beginnt, häufig benutzte Seiten auf den Plattenspeicher auszulagern. Dies ist wichtig, wenn Sie SQL Anywhere unter Windows Mobile anwenden, da größere Seitengrößen intern möglicherweise stärker fragmentiert werden.

SQL Anywhere versucht, Seiten so weit wie möglich anzufüllen. Leerer Speicherplatz nimmt nur dann zu, wenn neue Objekte zu groß sind, um in den leeren Platz auf vorhandenen Seiten zu passen. Daher wirkt sich ein Anpassen der Seitengröße nicht unbedingt signifikant auf die Gesamtgröße Ihrer Datenbank aus.

Die Seitengröße hat auch Einfluss auf Indizes. Jede Indexsuche erfordert einen Seitenlesevorgang pro Indexebene plus einen Seitenlesevorgang für die Tabellenseite, und für eine einzige Abfrage können mehrere Tausend Indexsuchen erforderlich sein. Die Seitengröße kann sich signifikant auf die Auffächerung auswirken, was wiederum Folgen für die Tiefe des für eine Tabelle erforderlichen Indexes hat. Eine hohe Auffächerung bedeutet oftmals, dass weniger Indexebenen benötigt werden, wodurch die Suchvorgänge beachtlich verbessert werden. Für große Datenbanken mit einer beträchtlichen Anzahl von Seiten erzielen Sie mit einer Seitengröße von 8 KByte die beste Performance. Es wird dringend empfohlen, beim Wählen einer Seitengröße die Performance zu prüfen (ebenso wie andere Aspekte). Danach wählen Sie die kleinste Seitengröße, die zufriedenstellende Ergebnisse liefert. Es ist wichtig, dass eine korrekte und angemessene Seitengröße gewählt wird, wenn Sie vorhaben, mehrere Datenbanken auf demselben Server zu starten.

Siehe auch

• Angemessene Seitengröße verwenden
• Dienstprogramm Initialisierung (dbinit)
• CREATE DATABASE-Anweisung