© pixelio.de

Der Informix Dynamic Server in Version 11 – IBMs neues OLTP-Datenbank-Flaggschiff – bietet eine ganze Fülle an Neuerungen. Dabei hat der Hersteller besonders in Bereiche wie Hochverfügbarkeit, Performance und die Anwendungsintegration investiert.

Seit Kurzem ist die Version 11 des IDS auf dem Markt. Viele neue Funktionen belegen, dass Informix in IBMs Datenbankportfolio ein gleichberechtigter Partner von DB2 geworden ist. Zudem genießt Informix den Ruf einer performanten und wartungsfreundlichen Datenbank, die sich besonders für den Einsatz in kritischen, transaktionslastigen Umgebungen und überall dort eignet, wo es keine spezialisierten Administratoren gibt. Vor allem beim Clustering wartet IDS 11 mit neuen Techniken auf, die hohe Verfügbarkeit sichern sollen. Die neue Version gibt es ab etwa 600 Euro.

Installation nach Maß

Schon bei der Installation ermöglicht der Deployment-Wizard in IDS 11 eine selektive Auswahl der gewünschten Komponenten. Wer sich für alle entscheidet, der benötigt für die Installation etwa 260 MByte Plattenplatz. Der Kern des Datenbankservers alleine belegt – je nach Plattform – nur 60 bis 90 MByte. Dazwischen liegt eine an die eigenen Bedürfnisse angepasste, individuelle Komponentenauswahl (Abbildung 1). Der Deployment-Wizard erlaubt außerdem das Klonen einer IDS-Installation auf beliebig viele weitere Maschinen.

Abbildung 1: Bei der Installation von IDS 11 auswählbare Funktions-Komponenten.

Applikation steuert Datenbank

Die neu geschaffene Administrations-Schnittstelle gestattet Entwicklern das Einbetten von Datenbank-Kommandos in Applikationen. Dafür stehen die beiden so genannten User Defined Routines (UDRs) »task()« und »admin()« in der ebenfalls in dieser Version neu hinzugekommenen Systemdatenbank »sysadmin« bereit.

Mit Hilfe dieser UDRs lassen sich rund 80 IDS-Befehle direkt per SQL aus einer Applikation heraus aufrufen. Unter anderem ist es möglich – die entsprechende Berechtigung immer vorausgesetzt -, den Datenbankserver in einen anderen Modus zu überführen, zum Beispiel den Single-User- oder Offline-Modus, oder User-Sessions zu beenden, neue Bufferpools zu allokieren oder neue Speichersegmente hinzuzufügen. Außerdem kann der Anwender auf diesem Weg auch Dbspaces anlegen, erweitern, löschen und spiegeln, Konsistenz-Checks veranlassen, Transaktions-Logs anlegen und löschen oder Konfigurations-Parameter ändern sowie das SQL-Statement-Tracing aktivieren.

Beide UDRs erwarten die gleichen Parameter, unterscheiden sich jedoch in ihrem Rückgabewert. Während »task()« eine Zeichenkette zurückliefert, die das Ergebnis im Klartext enthält, gibt »admin()« einen numerischen Wert zurück, der der eindeutigen Jobnummer in der Tabelle »sysadmin:command_history« entspricht. Ein positiver Wert signalisiert dabei eine erfolgreiche Ausführung, ein negativer deutet dagegen auf einen Fehler hin.

Die Listings 1 und 2 verdeutlichen den Unterschied zwischen den Aufrufen der beiden UDRs. In Listing 3 wird anhand der von »admin()« zurückgelieferten Jobnummer der entsprechende Eintrag aus der Tabelle »sysadmin:command_history« selektiert.

01 ---------------------------------------------------
02 --Anlegen eines neuen Dbspace "physdbs1" mit 101 MB 
03 --Größe mit Hilfe der UDR "task()"
04 ---------------------------------------------------
05 execute function sysadmin:task
06 (
07    "create dbspace",
08    "physdbs1",
09    "/db/inf/dev/cheetah/physdbs1",
10    "101m"
11 );
12 
13 --------------------------------------------------
14 --Von der UDR an die Applikation zurückgelieferter
15 --Meldungstext:
16 --------------------------------------------------
17 "Space 'physdbs1' added."

01 -- Verschieben des Physical Log in Dbspace "physdbs1"
02 -- und gleichzeitiges Vergrößern auf 100 MB
03 execute function sysadmin:admin
04   (
05    "alter plog",
06    "physdbs1",
07    "100M"
08   );
09 --------------------------------------------------
10 Zurückgeliefert::
11      134

01 ---------------------------------------------------------
02 --Abfrage der Tabelle "sysadmin:command_history" gem. der
03 --Job-Nummer, die die UDR "admin()" zurückgeliefert hat
04 ---------------------------------------------------------
05 select * from sysadmin:command_history
06 where cmd_number = 134;
07 
08 ------------------------------------
09 --Von IDS zurückgeliefertes Ergebnis
10 ------------------------------------
11 cmd_number      134
12 cmd_exec_time   2007-07-10 21:17:39
13 cmd_user        informix
14 cmd_hostname    apollo4
15 cmd_executed    alter plog
16 cmd_ret_status  0
17 cmd_ret_msg     Successfully altered physical log.n** 
18                 WARNING ** Because the physical log has 
19                 been modified, a level 0 archive must be 
20                 taken of the following spaces before an 
21                 incremental archhive will bepermitted 
22                 for them: physdbs1 physdbs (see 
23                 Dynamic Server Administrator's manual)

Die Verwaltung dezentraler IDS-Instanzen ist ebenso bequem per Remote-Aufruf der jeweiligen User-Defined-Routine möglich. Die Syntax für diesen Fall lautet dann »execute function sysadmin@remote_ids_instance:task«.

Integrierter Job-Scheduler

Der IDS 11 verfügt auch über einen im Datenbankserver integrierten plattformunabhängigen Scheduler, der die regelmäßige Ausführung von Routinejobs anstößt und überwacht. Er unterscheidet bei den Jobs zwischen so genannten Tasks und Sensors. Unter einem Sensor versteht er dabei einen spezialisierten Job, der vorrangig Daten für statistische Zwecke sammelt.

Beide Formen können aus einer oder aus mehreren SQL-Anweisungen bestehen, die die Datenbank zu einem bestimmten Zeitpunkt oder in einem vorgegebenen Intervall aufruft. Sie lassen sich auch als Stored Procedure beziehungsweise als eine in der Programmiersprache C oder in Java geschriebene UDR hinterlegen. Neben der zeitgesteuerten ist auch eine Event-gesteuerte Auslösung in Form so genannter Startup Tasks sowie über die Sensors möglich.

HA leicht gemacht

Highlight der Informix-Version 11 ist sicherlich die unter dem Codenamen MACH 11 (Multi-Instance Active Cluster for High Availability) innerhalb des Datenbank-Kernels implementierte Hochverfügbarkeits-Technologie. Sie umfasst eine ganze Reihe Optionen, um die Verfügbarkeit zu verbessern: HDR (High Availability Data Replication), RSS (Remote Standalone Secondary), SDS (Shared Disk Secondary) und CLR (Continuous Log Restore).

Bei HDR handelt sich um eine bereits aus früheren Informix-Versionen bekannte und häufig eingesetzte Replikations-Technologie, bei der die sekundäre Instanz gleichzeitig für lesende Abfragen oder als Failover-Instanz nutzbar ist. RSS-Instanzen erweitern das HDR-Konzept und erlauben die 1:n-Replikation einer Instanz auf beliebig viele sekundäre Rechner. Neu in diesem Zusammenhang ist außerdem ein Full-Duplex-Protokoll, das eine sichere Replikation über Leitungen mit relativ großer Latenz – zum Beispiel bei weltweit verteilten Standorten – ermöglicht.

Analog zu einer HDR-Sekundärinstanz sind auch die RSS-Instanzen gleichzeitig für lesende Abfragen verwendbar. Ein direktes Failover von der primären Instanz auf eine RSS-Instanz ist jedoch nur möglich, nachdem der Admin die RSS- in eine HDR-Sekundärinstanz überführt hat. Hintergrund ist, dass die RSS-Instanzen zunächst asynchron und erst als HDR-Sekundärinstanz vollständig synchron arbeiten.

SDS-Instanzen ermöglichen den gemeinsamen Zugriff auf die Plattenbereiche der primären Instanz. Dabei können die SDS-Instanzen auf demselben oder einem anderen Rechner laufen. Analog zu einer HDR-Sekundärinstanz erlauben sie den lesenden Zugriff und können als Failover-Instanz dienen.

Das Aufsetzen einer neuen SDS-Instanz ist innerhalb weniger Minuten möglich, da durch den Zugriff auf einen gemeinsamen Plattenbereich das Einspielen eines Backup zur Erst-Synchronisation entfällt. Ein Failover auf eine SDS-Instanz lässt sich innerhalb weniger Sekunden realisieren.

Mit Hilfe des Konfigurations-Parameters »HDR_ENCRYPT« verschlüsselt IDS den Netzwerkverkehr zwischen Instanzen, und zwar unabhängig davon, ob es sich um HDR-, RSS- oder SDS-Instanzen handelt. In diesem Zusammenhang ist erwähnenswert, dass es möglich ist, Transaktionsprotokolle auf einem sekundären Rechner kontinuierlich einzuspielen, Informix nennt das CLR (Continuous Log Restore). Auch hier kommen neue Optionen hinzu, mit denen sich dieser Prozess vereinfachen und automatisieren lässt. CLR ermöglicht außerdem ein zeitversetztes Nachfahren der Transaktionsprotokolle, sodass der Anwender logische Fehler, etwa eine falsch formulierte Update- oder Delete-Anweisung, noch korrigieren kann

Alle erwähnten Optionen sind kombinierbar. Bei einem Failover auf eine sekundäre Instanz rekonfiguriert sich der MACH-11-Cluster automatisch und die verbleibenden sekundären Instanzen konnektieren sich an die neue primäre Instanz, ohne dass ein Eingriff des Administrators erforderlich ist. MACH 11 ist äußerst flexibel und kann sowohl Hochverfügbarkeits- als auch Skalierungs-Anforderungen bedienen. Gerade im dynamischen E-Commerce-Umfeld eignen sich bei Bedarf ergänzte SDS-Instanzen gut dafür, sporadisch auftretenden Lastspitzen zu begegnen. Der Einsatz kostengünstiger Linux-Blade-Systeme in Kombination mit Informix 11 bietet viele Möglichkeiten (Abbildung 2).

Abbildung 2: Geografisch verteilter MACH-11-Cluster auf Basis von Blade-Systemen.

Die Entwickler bei IBM arbeiten bereits an der zweiten Generation von MACH 11, die auch schreibenden Zugriff auf die SDS-Instanzen erlauben soll. Mit der offiziellen Verfügbarkeit einer IDS-Version mit diesem Feature ist gegen Ende dieses Jahres zu rechnen.

Optimiertes Locking

IDS 11 erweitert zwei der vier Ansi-Isolationsstufen um den Zusatz »last committed«. Dieser Zusatz erlaubt lesenden Prozessen den nicht blockierenden Zugriff auf einen Datensatz, der sich zu diesem Zeitpunkt gerade in Bearbeitung befindet. Allerdings liefert IDS, im Gegensatz zu dem allgemein gebräuchlichen Isolationslevel Dirty Read, nicht die geänderte und noch nicht gesicherte Version des Datensatzes an die Applikation aus, sondern stattdessen die letzte konsistente und bestätigte Version.

Schreibende Prozesse blockieren lesende Prozesse bei Verwendung von »last committed« nicht mehr. Die Erweiterung ist sowohl für die Isolationsstufen »dirty read« als auch »committed read« einsetzbar. Bestehende Anwendungen können auch ohne Applikationsänderung von der neuen Funktion profitieren. Dafür muss der Admin lediglich den Konfigurationsparameter »USELASTCOMMITTED« entsprechend setzen.

Neben der Reduktion von Lock-Konflikten, Wartezuständen und Deadlocks hilft die »last committed«-Funktion auch bei der Portierung von Oracle-Anwendungen nach Informix.

Performance großgeschrieben

Ein in IDS 11 grundlegend überarbeiteter Checkpoint-Algorithmus sorgt dafür, dass blockierende Checkpoints Geschichte sind. Geänderte Bufferpages landen jetzt zeitgleich zu lesenden und schreibenden Transaktionen auf der Platte. Neben einem verbesserten Transaktionsdurchsatz erlaubt es der neue Checkpoint-Algorithmus dem Administrator, die Bufferpool-Schwellenwerte »LRU_MIN_DIRTY« und »LRU_MAX_DIRTY« deutlich zu erhöhen. Diese Maßnahme führt vor allem bei stark frequentierten Systemen zu spürbarer Entlastung der CPU.

Es ist aber darauf zu achten, dass sowohl das Physical Log als auch die Logical Logs ausreichend groß dimensioniert sind. Sollten diese Ressourcen zu knapp bemessen sein, kann es dennoch zu einem blockierenden Checkpoint kommen. Der IDS 11 weist aber den Admin freundlicherweise durch entsprechende Eintragungen im Message-Logfile auf diesen Umstand hin.

Wie bei Informix üblich, kann eine Re-Konfiguration der Ressourcen online erfolgen. Neben dem Hinzufügen weiterer Logical Logs erlaubt die Datenbank auch das Verschieben und Vergrößern des Physical Log während des laufenden Betriebs, ohne Beeinträchtigung der gerade aktiven Applikationen.

Garantierte Wiederanlaufzeit

Mit dem Konfigurations-Parameter »RTO_ SERVER_RESTART« vereinfacht der Administrator die Vereinbarung einer maximalen Wiederanlaufzeit (Recovery Time Objective, RTO) nach einem Ausfall. IDS sorgt selbstständig für die Einhaltung der Vorgabe, indem er, basierend auf dem aktuellen Transaktions-Workload, dynamisch Checkpoints schreibt.

Zusätzlich misst der IDS bei einem schnellen Wiederanlauf (Fast Recovery) die für das Lesen des Physical Log und der Logical Logs benötigte Zeit und vermerkt diese Kennzahlen unter der Bezeichnung »RAS_PLOG_SPEED« oder »RAS_LLOG_SPEED« innerhalb der IDS-Konfigurationsdatei. Der Datenbankserver lernt also bei jedem Neustart hinzu und passt sein Checkpoint-Verhalten dem aktuellen Workload sowie weiteren Gegebenheiten an, um die vom Admin vorgegebene Richtlinie zu erfüllen. Die aktuell erwartete Wiederanlaufzeit sowie weitere detaillierte Informationen zu individuellen Checkpoints gibt das Kommando »onstat -g ckp« aus.

Die neue IDS-Version richtet übrigens neben den Checkpoints auch die Anzahl der virtuellen I/O-Prozessoren, die Schwellenwerte für das Abspeichern der geänderten Bufferpool-Pages sowie die Zahl der hierfür benötigten Page Cleaner Threads dynamisch am aktuellen Workload aus. Diese automatischen Abläufe lassen sich bei Bedarf deaktivieren.

Die Policy-basierte Konfiguration ist ein großes Thema bei Informix. Sie ermöglicht die Abkehr vom Konzept der individuellen Stellschrauben und bedeutet für den Administrator eine Vereinfachung. In Kombination mit der dynamischen Anpassung von Ressourcen befindet sich IDS auf dem besten Weg in eine administrationsfreie Zone.

Gläserne SQL-Anweisungen

Der neu eingeführte Tracing-Mechanismus gibt detaillierte Informationen zu bereits ausgeführten SQL-Anweisungen aus. Dabei lässt sich das Tracing global für alle Verbindungen oder gezielt für eine einzelne Session anschalten. IDS hält die ausgeführten SQL-Anweisungen in einem konfigurierbaren Speicherpuffer vor. Das Kommando »onstat -g his« gibt nähere Informationen zu den einzelnen, aktuell im Puffer befindlichen SQL-Anweisungen aus, darunter sind beispielsweise:

• Wie oft wurde diese SQL-Anweisung bereits ausgeführt?
• Letzter Zeitpunkt der Ausführung
• Minimale, maximale und durchschnittliche
  Ausführungsdauer
• Benötigte CPU-, Speicher- und Log-Ressourcen
• Anzahl Puffer- und Platten-Zugriffe sowie gelesener Rows
  proSekunde
• Anzahl der Sortiervorgänge im Speicher oder auf
  Platte

Aktivieren lässt sich das Tracing wahlweise durch den Parameter »SQLTRACE« direkt in der IDS-Konfigurationsdatei oder durch das neue Administrations-API. Beides ist online durchführbar, die Änderung gilt sofort.

Administration per Browser

Open Admin heißt das neue, in PHP geschriebene Administrations-Tool. IBM plant die Freigabe von Open Admin als Open Source. Dadurch hätten Informix-Kunden und -Consultants die Möglichkeit, ihre eigenen Erweiterungen zu implementieren und Dritten zu überlassen und zugleich von den Entwicklungen anderer zu profitieren. Die zu verwaltenden dezentralen IDS-Instanzen benötigen keine zusätzliche Software, Open Admin nutzt das neue Administrations-API.

Open Admin bietet viele Konfigurations- und Monitoring-Möglichkeiten. Unter anderem kann sich der Admin die Ressourcen-intensivsten SQL-Anweisungen anzeigen lassen und bekommt über die Query-Drill-Down-Funktionalität eine detaillierte Aufstellung der allokierten Ressourcen. Dbspaces und Logs sind von hier aus bequem anzulegen und zu erweitern. Darüber hinaus lassen sich Jobs für den integrierten Scheduler definieren. Zahlreiche vorkonfigurierte Reports stehen zur Verfügung. Interessant ist auch der Dashboard-Mechanismus, mit dem der Admin die für ihn relevanten Metriken selbst definiert und übersichtlich darstellt (Abbildung 3).

Abbildung 3: Grafische Anzeige von Systemressourcen im IDS mit dem in PHP programmierten Open Admin Tool.

Fazit

IBM liefert mit IDS 11 eine umfangreiche neue Informix-Version aus, die vor allem in den Bereichen Hochverfügbarkeit, Performance und Integrierbarkeit in bestehende Anwendungen punktet. Unternehmen, die den 24×7-Betrieb ihrer Datenbank-Anwendungen benötigen, oder Softwarehäuser, die auf der Suche nach einer leistungsfähigen, leicht zu integrierenden und wartungsarmen Datenbank sind, sollten einen genaueren Blick auf IDS 11 werfen. Die in IDS 11 eingeführte Shared-Disk-Technologie stellt auch für Anwender von Oracle RAC und Dataguard eine valide und kostengünstige Alternative dar. (jcb)