IBM Informix Dynamic Server 10.0 Neuheiten (Teil IV):

Informix 10.0 - A Success Story ...

In der letzten ORDIX News Ausgabe haben wir den "Table Level Restore" erläutert und damit auch die Vorstellung der Neuerungen aus dem Bereich Backup & Recovery abgeschlossen. In diesem Artikel werden die noch ausstehenden Neuerungen beschrieben. Gleichzeitig endet mit diesem Artikel dann auch unsere Reihe zum Thema "IBM Informix Dynamic Server 10.0 Neuheiten".

Überblick

Die Neuerungen, die in diesem Artikel vorgestellt werden, beziehen sich im Wesentlichen auf die folgenden Bereiche:

• SQL-Erweiterungen
• Administration
• Skalierbarkeit/Performance

SQL-Erweiterungen

TRUNCATE TABLE

Mit dem IBM Informix Release 10.00UC4 ist die SQL-Anweisung TRUNCATE TABLE neu hinzugekommen. Sie dient dazu, alle Datensätze einer Tabelle zu löschen. Im Gegensatz zur DELETE FROM TABLE-Anweisung handelt es sich hierbei um eine DDL-Anweisung. Somit werden keinerlei Informationen ins Transaktionslog geschrieben.

Durch TRUNCATE TABLE wird die Tabellenstruktur nicht verändert, was bedeutet, dass die eigentliche Tabelle nicht gelöscht wird. Alle abhängigen Tabellenobjekte (Indizes, Trigger, Views und Con­straints) bleiben bestehen.

Der TRUNCATE TABLE-Befehl kann mit zwei Optionen ausgeführt werden:

1. DROP STORAGE (DEFAULT): Alle Extents des Objektes (auch abhängiger Objekte) werden gelöscht.
2. REUSE STORAGE: Extents bleiben bestehen.

Die REUSE STORAGE-Option eignet sich vor allem für Anwendungen, bei denen die gelösch­te Tabelle immer wieder schnell gefüllt wird, z. B. bei typischen Datawarehouse-Anwendun­gen (Löschen + Laden von Daten). Damit wird eine Allokation der neuen Extents vermie­den.

RAW Tables

Eine weitere, sehr interessante SQL-Funktion wurde mit dem Release 10.00UC5 implemen­tiert. Indizes können nun ebenfalls auf Non-Logging-Tabellen (RAW Tables) bestehen blei­ben bzw. angelegt werden. Durch diese Neuerung können nun besonders große Massenverarbeitungen deutlich beschleunigt werden (z. B. ETL- bzw. Datawarehouse-Anwendungen).

Administration

Rename DBSpace

Mit dem neuesten Release besteht nun die Möglichkeit, DBSpaces umzubenennen. Hierzu wurde das onspaces-Kommando um die Option "ren" erweitert. Wie Abbildung 1 zeigt, muss die Datenbank im "Quiescent"-Mode sein.

informix@linux:~> onmode -s

This will perform a GRACEFUL SHUTDOWN -
Do you wish to continue (y/n)? y
informix@linux:~>
informix@linux:~>onstat –
	
Informix Dynamic Server Version 10.00.UC4 
-- Quiescent -- Up 17:28:11 -- 105920 Kbytes
	
informix@linux:~> onspaces -ren datadbs -n datadbs_rename
Rename of Space completed successfully.
	
** WARNING **  A level 0 archive of Root DBSpace and the renamed
Space need to be done.
informix@linux:~>

Nach dem erfolgten Rename sollte auf jeden Fall eine Level 0 Sicherung durchgeführt werden, damit ein Restore des Systems wieder möglich wird!

tablespace - tablespace

Ab dem Informix Release 10.0 kann die Größe von Extents für den tablespacetablespace-tablespace bestimmt werden. Möglich ist dies allerdings nur beim Erstellen eines DBSpaces, das nicht vom Typ BLOB, SBLOB oder TEMP ist.

Für das Root DBSpace wurden dazu zwei neue ONCONFIG-Parameter eingeführt, die vor der Erst­initialisierung gesetzt werden können:

• TBLTBLFIRST: Größe des ersten Extents in KB
• TBLTBLNEXT: Größe aller weiteren Extents in KB

Da alle nachträglichen DBSpaces dem Datenbanksystem mit dem Befehl onspaces hinzugefügt werden, wurde auch dieser Befehl um entsprechende Optionen erweitert:

• -ef <KB>: Größe des ersten Extents in KB
• -en <KB>: Größe aller weiteren Extents in KB

Dadurch wird erreicht, dass alle Extents des tablespacetablespace-tablespace im initialen Chunk allokiert werden können. Somit wird das tablespace-tablespace über mehrere Chunks "verteilt" und die Anzahl der Extents wird vermindert.

Beide Vorteile, die Möglichkeit des Umbenennens von DBSpaces und des Festlegens von Extent-Größen, wirken sich positiv auf die Performance aus, da der Overhead bei der Tablespace-Verwaltung geringer wird.

Skalierbarkeit & Performance

Externe Optimizer-Direktiven

Während der Ausführungsplan den Weg des Optimizers lediglich anzeigen kann, kann dieser Weg durch so genannte "Externe Optimizer-Direktiven" schon vorab beeinflusst werden.

In früheren Informix Versionen konnten Direktiven ausschließlich im Statement durch einen Optimizer Hint ( --+ Direktive) explizit angegeben werden. Mit der Version 10.0 besteht jetzt die Möglichkeit der Speicherung von externen Optimizer-Direktiven für ein SQL-Statement.

Mittels des neuen SQL-Befehls save external wird ein Ausführungsplan für das nachfolgende Statement in der Datenbank gespeichert (siehe lokale Systemtabelle der Datenbank --> Tabelle sysdirectives).

Bei jeder Ausführung eines SQL-Statements überprüft nun der Op­timizer, ob eine entsprechende externe Direktive vorhanden ist. Dieser Vergleich wird mittels eines einfachen Quellcode-Vergleichs durchgeführt.

SAVE EXTERNAL DIRECTIVES 
 /*+ AVOID_INDEX(customer num_idx)*/ 
 ACTIVE FOR SELECT * FROM CUSTOMER 
             WHERE CUSTOMER_NUM > 10;
	
SELECT * FROM CUSTOMER WHERE CUSTOMER_NUM > 11; 

SAVE EXTERNAL DIRECTIVES 
 /*+ AVOID_INDEX(customer num_idx)*/ 
 ACTIVE FOR SELECT * __  FROM CUSTOMER 
             WHERE CUSTOMER_NUM > 10;
	
SELECT * FROM CUSTOMER WHERE CUSTOMER_NUM > 10;

# OPTCOMPIND
# 0 => Nested loop joins will be preferred 
#      (where possible) over sortmerge 
#      joins and hash joins.
# 1 => If the transaction isolation mode 
#      is not "repeatable read", optimizer 
#      behaves as in (2) below. Otherwise 
#      it behaves as in (0) above.
# 2 => Use costs regardless of the 
#      transaction isolation mode. Nested 
#      loop joins are not necessarily 
#      preferred. Optimizer bases its 
#      decision purelyon costs.

Die Statements in Abbildung 2 wären unterschiedlich, weil die "Literale" (siehe WHERE-Klausel) unterschiedlich sind. Die externe Direktive würde somit nicht genutzt.

Auch unterschiedliche Anzahlen von Leerzeichen im SQL-Statement verhindern die Nutzung von externen Direktiven (siehe Abbildung 3). Somit würde der Optimizer die externe Direktive auch hier nicht nutzen, obwohl die "Literale" nun gleich sind. (Zwischen SELECT * und der FROM-Klausel befinden sich zwei Leerzeichen "__")

Um externe Optimizer Direktiven speichern zu können, wird allerdings vorausgesetzt, dass die Beeinflussung durch Direktiven erlaubt ist. Dazu gibt es den ONCONFIG-Parameter EXT_DIRECTIVES bzw. die Umgebungsvariable IFX_EXTDIRECTIVES.

OPTCOMPIND

Der OPTCOMPIND-Parameter ist ein ONCONFIG-Parameter, mit dem man das "Grundverhalten" des Optimizers steuern kann. Abbildung 4 zeigt die Einstellungsmöglichkeiten.

Mit dem neuesten Release ist der OPTCOMPIND-Parameter nun je nach Anwendungslast (OLTP/Batch) mit dem Befehl SET ENVIRONMENT OPTCOMPIND für die aktuelle Datenbank-Session änderbar.

Der dadurch geänderte Wert ist für den Zeitraum der Session gültig und geht in dem Moment verloren, in dem diese Session beendet wird. Auf Abfragen von anderen Sessions hat der geänderte Wert allerdings keinen Einfluss.

Durch die dynamische Änderung dieses Parameters ergeben sich Performance-Vorteile, da man je nach Anwendungsverhalten den OPTCOMPIND-Parameter in der ONCONFIG "übersteuern" kann.

NONPDQ-Queries

Für nicht parallele Datenbankabfragen (NONPDQ-Queries) stehen standardmäßig lediglich 128 KB (bis 9.4 ausschließlich) an Speicher für eine Sortierung zur Verfügung. Bei komplexeren Abfragen (ORDER BY, GROUP BY, HASH JOIN) ist dies je nach Datenmenge nicht ausreichend, die Daten werden dann auf ein Temp DBSpace „ausgelagert“. Das bedeutet zusätzlichen I/O, der mit dem neuen Parameter nun umgangen werden kann.

Um NONPDQ-Queries mehr Speicherplatz zuweisen zu können, wurde der ONCONFIG-Parameter DS_NONPDQ_QUERY_MEM eingeführt. Dieser ermöglicht eine explizite Speicherallokierung, um oben beschriebenen Engpässen aus dem Weg zu gehen. Zugriffe auf das TEMP DBSpace werden dann nur noch notwendig, wenn der angegebene Wert von DS_NONPDQ_QUERY_MEM wiederum nicht ausreicht.

Genutzt wird hier der über DS_TOTAL_MEMORY (virtueller Spei­cherbereich) zur Verfügung stehende Bereich im Shared Memory. Daher kann der maximale Wert 25 Prozent des Parameters DS_TOTAL_MEMORY nicht überschreiten. Als Minimum können nur die bisher verwendeten 128 KB angegeben werden!

Auch der NONPDQ-Parameter kann dynamisch geändert werden. Hierzu wird die ebenfalls neue Option des onmode-Kommandos (-wm/-wf) genutzt (siehe Abbildung 5).

informix@trainix:/informix/ifx10/etc> onmode -wf DS_NONPDQ_QUERY_MEM=5000
Value of DS_NONPDQ_QUERY_MEM has been changed to 5000.

Shared Memory Verwaltung

Mit Informix 10 wird die änderbare PAGE Size für DBSPACES und Shared Memory Pages eingeführt. Hierdurch ergeben sich eini­ge Vorteile hinsichtlich der Performance und der maximalen In­stanzkapazität.

Standardmäßig hat die Informix-Page eine Größe von 2 KB, bei AIX und Windows sind es 4 KB. Ab dem Release 10.0 ist diese Page-Größe änderbar und kann somit auch für "normale" Daten-DBSpaces und temporäre DBSpaces genutzt werden (Die Page-Größe von BLOB-DBSpaces war schon immer änderbar!)

Zu beachten gilt allerdings, dass die Größe immer ein Vielfaches des Default-Wertes sein muss und 16 KB nicht überschreiten darf. Angegeben wird der Wert nach der Option –k, die zusätzlich für den Befehl onspaces implementiert wurde.

Voraussetzung für das Anlegen eines DB­Spa­ces mit einer vom Default-Wert abweichenden Page-Größe ist ein entsprechender BUFFER Pool. Daher wurde in der ONCONFIG ein neuer Parameter BUFFERPOOL eingeführt. Mittels diesem können ab dem IBM Informix Release 10 nun mehrere BUFFER Pools angelegt werden.

Weitere Features im Überblick

Weitere Neuerungen für die Bereiche Administration und Hochverfügbarkeit sind:

• Konfigurierbare LISTENER VP
• LISTEN_TIMEOUT / MAX_INCOMPLETE_CONNECTION
• Diverse Neuerungen und Anpassungen an der Enterprise Replication u. a.:
  • Möglichkeit der Veränderung von replizierten Tabellen innerhalb einer Master Replikation (z. B. add/drop fragments, add/drop columns)
  • Möglichkeit der Nutzung von Replication Templates

Fazit

Mit dem IBM Informix Dynamic Server 10.0 hat IBM sehr viele neue Funktionen implementiert, die in der Praxis schnell Anwendung finden werden. Unsere Erfahrungen mit dem Release sowie auch das Feedback unserer Kunden ist sehr positiv.

Hervorzuheben ist die von Informix bekannte Implementierungsweise (easy to admin)!

Die folgenden Neuerungen sind die Highlights, die uns und unsere Kunden überzeugt haben:

• Diverse SQL-Erweiterungen
• Security (Column Level Encryption, Netzwerk Encryption)
• Konfigurierbare Page Size (2 KB – 16 KB)
• Shared Memory > 4 GB
• NONPDQ-Queries
• Backup & Restore (Table Level Restore, Renamed Restore, ontape auf STDIO)
• Erweiterung der Enterprise Replikation

Mit diesem durchweg positiven Fazit schließen wir nun die Reihe "IBM Informix Dynamic Server 10.0 Neuheiten" ab.

Allerdings können Sie hier schon bald weitere, wichtige Informationen zum Thema IBM Informix lesen, denn im kommenden Jahr wird bereits das nächste Release, Codename "Cheetah" (engl.: Gepard), des IBM Informix Dynamic Server auf den Markt kommen.

Fordern Sie uns! Wir unterstützen Sie gerne bei der Umsetzung der neuen Funktion bzw. bei der Migration auf das neue IBM Informix Release 10.0.

Guido Saxler und Thorsten Schuhmacher (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen