ISR TechNews

Wer eine IBM Informix High-Availability Data Replication (HDR) einsetzt, muss sich früher oder später überlegen, wie mit einem Ausfall des Primärservers umzugehen ist. Bei einem längeren Ausfall wird man einen Switch durchführen, bei dem ein Sekundärserver zum Primärserver promotet wird. Hierfür bieten sich mehrere Möglichkeiten an.

IBM Informix: CPU Last - woher kommt sie? Ansatz durch Thread Analyse
Ist die CPU durch oninit-Prozesse stark belastet, fällt es häufig schwer, die Ursache zu ermitteln. Dieser Artikel zeigt einige gebräuchliche Methoden auf, und widmet sich vor allem der Thread-Analyse.

Wenn eine Transaktion soviel Prozent des gesamten Logical Logspaces benötigt, wie durch den onconfig-Parameter Long-Transaction High-Watermark (LTXHWM) definiert ist, wird diese Transaktion zurückgerollt. Überschreitet sie dabei die durch die Long-Transaction Exclusive High- Watermark (LTXEHWM) definierte Menge an Logical Logspace, werden nahezu alle anderen Datenbankaktionen zugunsten des Rollbacks eingefroren. Wie kann man sich davor schützen?

Ändern sich in einer Tabelle Daten, müssen diese Datenänderungen auch in einem eventuell vorhandenen Index nachgepflegt werden. Seit Informix 9.40 hat sich in diesem Bereich einiges geändert. Die Neuerungen werden in diesem Artikel dargestellt.

Mittels external directives ist es möglich, auch Statements mit Direktiven gegen das System zu schicken, bei denen man keinen Zugriff auf den Quellcode hat. Die Direktiven werden in der Datenbank (Tabelle sysdirectives) abgelegt, und greifen, wenn das Statement beim Optimizer ankommt. Dieser Artikel dient als Einstieg, eine ausführliche Anleitung findet man in der Dokumentation zu IDS V10.00.

Aus einer Level 0-Sicherung lassen sich mittels "archecker" einzelne Tabellen extrahieren, und in eine bestehende Datenbank einfügen. Sinnvoll ist dieses immer dann, wenn versehentlich eine einzelne Tabelle gelöscht wurde, die nun wiederhergestellt werden soll.

Die im onstat -k ausgegebenen Sperrinformationen sind für viele Administratoren ein Rätsel. Diese Beschreibung soll ein wenig Licht ins Dunkel bringen, so dass man bei Problemen gezielt ermitteln kann, welche Sperre auf welchen Datensatz zeigt, wer der Eigentümer der Sperre ist, und welcher Benutzer auf diese Sperre wartet.

Wer kennt das nicht: Man startet wie jeden morgen sein ISQL, um schnell einige Daten aus der Datenbank abzufragen, und plötzlich erscheint die Meldung "rowids do not exist on table". Wem ISQL und Rowids nichts sagen, kann sich an dieser Stelle dem Lesen anderen Artikeln widmen, für alle anderen gibt es eventuell den ein oder anderen hilfreichen Tipp.

Beim Tuning von Datenbankservern wird in der Regel versucht, mehr Performance durch Änderung der Konfigurationsparameter bzw. durch Aufrüsten der Hardware zu erreichen. Ein Aspekt wird jedoch häufig übersehen: Das effiziente Speichern der Daten innerhalb der verfügbaren Dbspaces.