So groß wie möglich! Das kann durchaus bedeuten, den Bufferpool so groß zu wählen, dass die gesamte Datenbank dort hineinpasst. Der Bufferpool ist das Herzstück der Performance. Je größer der Bufferpool ist, desto mehr Daten können im (schnellen) RAM gehalten und entsprechend weniger müssen von Platte (langsam) gelesen werden. Zu beachten sind bei der Dimensionierung des Bufferpools, das das Betriebssystem genügend RAM erhält und die lizenzrechtlichen Hersteller-Vorgaben (Compliance) bezüglich der Shared Memory Limits. Diese variieren je nach eingesetzter Informix-Edition. Bei Verletzung der Compliance drohen Nachlizenzierungen und Strafzahlungen!

Extrem wichtig! Beide sind zentraler Bestandteil des Shared Memory (in dem auch der Bufferpool liegt) und somit für Performance und Stabilität des DBS verantwortlich. SHMVIRTSIZE wird beim Start einmal allokiert. Reicht dieser Speicher nicht aus werden mit SHMADD weitere Speichersegmente hinzugefügt. Wird zu oft nachallokiert führt dies zu Fragmentierung und schlechter Performance. Das Ziel sind also möglichst wenige Speichererweiterungen. Deshalb SHMVIRTSIZE möglichst groß setzen und SHMADD ebenfalls nicht zu klein. Werte zwischen 512 MB und 2 GB sind hier üblich.

Ja! Trennung ist Pflicht! Daten gehören in dbspaces, Logs in log dbspaces und temp Daten in temp dbspaces. Die Daten werden somit auf separate Disks im Storage geschrieben, was die Performance fördert.

Raw devices. Traditionell arbeitet die Informix-Datenbank mit Raw Devices, d. h. Informix kommuniziert direkt mit dem Storage Device unter Umgehung des Betriebssystems und dessen Cache. Das führt im direkten Vergleich mit „cooked files“ zu besserer Performance. DIRECT_IO sorgt nun dafür, dass sich das (Performance)Verhalten auch bei „cooked files“  dem Raw-Modus annähert. DIRECT_IO ist in der Linux und Informix-Welt bereits seit vielen Jahren bekannt, steht seit Informix 14.10 aber jetzt auch für TempSpaces zur Verfügung. Zuvor war es nur möglich, DIRECT_IO für „normale“ DBspaces zu aktivieren. DIRECT_IO und RAW weisen sehr ähnliche Resultate auf.

Vermeiden Sie in jedem Fall sogenannte „Journaling Filesystems“! Das ist bei Informix verheerend! Verzichten Sie auf EXT3, EXT4 (journaling enabled) und auch auf ZFS und BTFS. JFS2/OpenJFS sind akzeptabel. Auf Linux am besten: EXT2 und 3 (journaling disabled).

Verbindliche Größen gibt es hier nicht, aber einige Zusammenhänge und Faustregeln – ansonsten testen! Für das logische und physikalische log gilt: zusammen fallen hier bis zu 50% der gesamten „writes“ an. Daher müssen Anzahl und Größe der logs passend zur Last dimensioniert werden. Das physikalische Log sollte mind. so groß wie der Bufferpool sein, ein Checkpoint findet statt, wenn das physikalische Log zu 75% voll ist.

Informix nutzt virtuelle Prozessoren. Entscheidend sind hier die CPUVPs. Hier gilt: Anzahl der CPUVPs = Anzahl der CPU-Kerne (oder leicht darunter). In der Regel wird bei kleineren und mittleren Systemen immer mindestens ein Kern für das Betriebssystem reserviert – je nach Größe des Systems ggfs. auch mehr.

täglich! Update Statistics unterstützt den Optimizer bei der Erzeugung der Abfragepläne und ist somit ein wichtiger Performance-Hebel! Update Statistics (LOW) sollte täglich laufen. Es ist schnell, beansprucht wenig Ressourcen und aktualisiert Basisstatistiken – sollte also als regulärer Job laufen. Wenn sich Datenmenge und –verteilung spürbar geändert haben (ca. 30 %), macht es Sinn, Update Statistics Medium laufen zu lassen. Hier wird auch die Datenverteilung berücksichtigt. Allerdings ist hier die Last spürbar größer als bei LOW. Bei schlechten Abfragezeiten lohnt es immer zuerst zu prüfen, ob UPDATE STATISTICS gelaufen ist bevor tiefgreifende Tuning-Maßnahmen erwogen werden.