Informix IDS: Codename Panther (Teil I)

Informix: What´s new pussycat?

IBM hat für Mitte 2010 ein neues Major Release für IDS angekündig. Dieses Mal heißt die Raubkatze Panther. Ich bin gespannt, was sich mein Chef dazu im Editorial ausdenkt. Seit dem Start von IDS 11.5 im Mai 2008 hat sich einiges getan. IBM hat viel in die Entwicklung investiert und auch bei einfachen Fixpacks (IDS 11.5xC1 – 11.5xC5) sein Produkt um viele neue Leistungsmerkmale erweitert. Einige dieser Neuigkeiten werden in dieser neuen Reihe unter die Lupe genommen.

BEGIN WORK;
UPDATE kunde
SET nachname = "Müller" WHERE customer_num = 4711;
SAVEPOINT sav1;

Insert into kunde (kunr, nachname, vorname) values
(1234, 'Ratlos', 'Larry');
SAVEPOINT sav2;

UPDATE kunde
SET nachname = "Meier" WHERE customer_num = 4711;
SAVEPOINT sav3;

RELEASE SAVEPOINT sav2;
ROLLBACK TO SAVEPOINT;
COMMIT WORK;

SELECT kunr, nachname FROM kunde
WHERE kunr in (4711, 1234);
Ergebnis: kunr, nachname: 4711, Müller

BEGIN WORK;
UPDATE kunde
SET nachname = "Müller" WHERE customer_num = 4711;
SAVEPOINT sav1;

INSERT into kunde (kunr, nachname, vorname) values
(1234, 'Ratlos', 'Larry');
SAVEPOINT sav2;

UPDATE kunde
SET nachname = "Meier" WHERE customer_num = 4711;
SAVEPOINT sav3;

ROLLBACK TO SAVEPOINT sav2;
COMMIT WORK;
SELECT kunr, nachname FROM kunde
WHERE kunr in (4711, 1234);
Ergebnis: 	kunr nachname:
			4711 Müller
			1234 Ratlos

echo "execute function task('onmode', 'c')" | dbaccess sysadmin

Database selected.
(expression) Checkpoint Completed
1 row(s) retrieved.

echo "execute function admin('onmode', 'c')" | dbaccess sysadmin

Database selected.
(expression) 181
1 row(s) retrieved.

echo "select * from command_history where cmd_number in (180,
181)" | dbaccess sysadmin

cmd_number 180
cmd_exec_time 2009-10-21 11:09:04
cmd_user informix
cmd_hostname localhost
cmd_executed onmode
cmd_ret_status 0
cmd_ret_msg Checkpoint Completed
cmd_number 181
cmd_exec_time 2009-10-21 11:09:19
cmd_user informix
cmd_hostname localhost
cmd_executed onmode
cmd_ret_status 0
cmd_ret_msg Checkpoint Completed

execute function sysadmin@remote_ids_instance:task( 'onmode', 'u')

select task("drop log", number)
	from sysmaster:syslogfil
		where chunk = 1 and sysmaster:bitval(flags,"0x02") = 0;

Savepoints

In Oracle schon lange vorhanden, beinhaltet die IDS Version 11.50.xC3 nun auch die Funktionalität der Savepoints. Savepoints ermöglichen es, innerhalb einer Transaktion Zustände zu markieren, auf die im Verlauf der Verarbeitung ggf. wieder aufgesetzt werden soll. Das ist somit quasi eine „kleine Transaktion“ innerhalb einer Transaktion.

Einem Savepoint wird ein Identifier zugeordnet. Wird ein weiterer Savepoint mit demselben Namen gesetzt, so geht der vorherige Savepoint mit diesem Namen „verloren“. Um unbeabsichtigtes Überschreiben eines Savepoints zu verhindern, kann ein Savepoint mit dem Zusatz „UNIQUE“ geschützt werden. Eine neue Vergabe desselben Namens führt in diesem Fall zu einem Fehler.

Mit dem Kommando ROLLBACK TO SAVEPOINT kann auf den Zustand des letzten Savepoints zurückgesetzt werden. Wird beim Kommando ROLLBACK TO SAVEPOINT der Name des Savepoints angegeben, wird die Transaktion bis zu diesem Savepoint zurückgerollt.

Das Kommando RELEASE SAVEPOINT löscht den Savepoint <xxx> und alle folgenden (siehe Abbildung 1). Savepoints können natürlich nur in Datenbanken mit Transaktionslog genutzt werden und bestehen immer nur innerhalb einer Transaktion. Ein COMMIT bzw. ROLLBACK hebt alle gesetzten Savepoints auf.

Ein Beispiel für Savepoints finden Sie in Abbildung 1.

Durch das Release des Savepoints sav2 wurde dieser und alle folgenden Savepoints (hier sav3) aufgehoben. Damit ist beim ROLLBACK TO SAVEPOINT der letzte gesetzte Savepoint sav1. Alle Statements vor sav1 bleiben durch den COMMIT erhalten. Die Statements nach dem Savepoint sav1 werden durch den ROLLBACK TO SAVEPOINT zurückgerollt.

Es besteht zudem die Möglichkeit, auf einen bestimmten Savepoint zurückzugehen. Hierzu muss beim ROLLBACK der Name des Savepoints mit angegeben werden (Abbildung 2). Im Beispiel der Abbildung 1 hätte also ein ROLLBACK TO SAVEPOINT sav1 das gleiche erreicht wie die Befehle RELEASE und ROLLBACK.

Die Funktionalität der Savepoints ist sehr nützlich für eine bessere Granularität innerhalb großer Transaktionen. Besonders in Java, SPL-Prozeduren oder ESQL wird die Fehlerbehandlung durch Savepoints sinnvoll erweitert. Vorsichtig ist dort aber mit geöffneten Cursorn zu agieren, die zwischen Savepionts eröffnet werden.

Wichtig ist auch das richtige Handling von temporären Tabellen. Hier muss genau unterschieden werden, ob diese mit oder ohne Logging verwendet werden.

Erweiterungen des SQL Administration API

Die meisten Informix-Administratoren beherrschen die vielen, nützlichen Kommandos mit ihren Optionen (onstat, onmode, ...). Administratoren, die beispielsweise vom Datenbanksystem Oracle kommen, sind es aber gewohnt ihr Datenbanksystem mittels SQL-Kommandos zu administrieren.

Für die Freunde der Administration via SQL bietet Informix nun das SQL Adminstration API. Es dient dazu, IDS per SQL-Statements zu administrieren.

Das API besteht aus den beiden „User Defined Routines“ (UDRs) admin() und task(). Diese Funktionen erledigen im Wesentlichen die gleiche Aufgabe und unterscheiden sich nur im Format des Rückgabewertes.

Die Funktion admin() liefert als Rückgabewert immer Integer-Werte, die Funktion task() immer einen String. Beim erfolgreichen Erledigen einer Aufgabe (Task) liefert admin() die "cmd_number" aus der Tabelle "command_history" zurück, die Funktion task() die "cmd_ret_msg" (siehe Abbildungen 3 - 5).

Den Funktionen task und admin werden ein oder mehrere Argumente übergeben, um die „Aufgabe zu definieren“. Es können maximal 28 Argumente übergeben werden.

Bietet die SQL-Administration über das API Vorteile, wenn das gleiche auch über die Kommandozeilen-Tools funktioniert? Ja. Der größte Vorteil ist, dass die Funktionen auch remote von anderen Datenbank-Servern aus gestartet werden können (siehe Abbildung 6).

Außerdem besteht die Möglichkeit, die Funktionen admin() und task() innerhalb von SQLStatements zu verwenden. Abbildung 7 zeigt eine elegante Art, mit der Funktion task ()in einem Select alle logischen Logs im Rootdbs (Chunk 1) zu löschen, sofern es nicht „aktuell“ ist.

Ein weiterer Vorteil des SQL API ist, dass sämtliche Kommandos in der Tabelle sysadmin:command_history protokolliert werden und somit nachträglich ausgelesen werden können.

Weiterhin stehen ab IDS 11.5.xC1 nun auch Kommandos zur Konfiguration von HA (High Availability) Clustern zur Verfügung.

Alle API-Funktionen und Objekte sind in der sysadmin-Datenbank definiert. Die Funktionen können nur von folgenden Benutzern aufgerufen werden:

• Benutzer informix
• Benutzer root, wenn er Connect-Rechte auf die sysadmin-Datenbank besitzt
• Benutzer, die in der Gruppe DBSA sind, und wenn die Gruppe (Rolle) Connect-Rechte auf die sysadmin-Datenbank besitzt

Was geht nicht?

Das Starten (oninit) oder der Übergang vom quiescent in den Online Mode lassen sich natürlich nicht mit dem SQL API durchführen, da hierfür SQL-Kommandos in der sysadmin-Datenbank ausgeführt werden müssen. Genau dieses Ausführen der SQL-Kommandos ist allerdings nicht möglich, wenn der Server offline oder im Mode quiescent ist.

Fazit und Ausblick

Die vorgestellten Leistungsmerkmale sind nur ein kleiner Ausschnitt aus dem, was sich seit Informix 11.1 alles getan hat. Die neuen Funktionalitäten bringen fast immer einen echten Mehrwert im Produktivbetrieb. Es bleibt zu hoffen, dass nicht nur die Informix Entwicklung Fahrt aufgenommen hat, sondern auch der Vertrieb des Produktes wieder erfolgreicher wird.

Seit September diesen Jahres hat IDS 7.31 den Status EOS (End of Support) und die Versionen 10.00 und 11.10 den Status EOM (End of Maintenance) erreicht (siehe Abbildung 8). Wer über eine Migration nachdenkt, sollte direkt auf IDS 11.5xC5 migrieren. Denn auch das nächste Fixpack wird interessante Leistungsmerkmale bieten.

Ulf Papenfuß (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen