dynaDAT | UNIXoni | REDATEK | ITVeteran - informix

alter_mode

Anonymous (anonymous@undisclosed.example.com) — 2026-09-08T13:09:26+00:00

Informix: ALTER-MODE und Flag 8388608

Kurzfassung

Bei der Untersuchung von zwei replizierten Tabellen wurde das Flag 8388608 (hexadezimal 0x800000) zunaechst als ALTER-MODE-Flag interpretiert. Das ist falsch. Das echte CDR-ALTER-MODE-Flag ist 4194304 (hexadezimal 0x400000).

0x800000 kennzeichnet eine In-Place-Alter-Historie (IPA) im Partition-Header. Es kann bestehen bleiben, obwohl alle Datenseiten bereits auf der aktuellen Row-Version liegen.

SERIAL kann als 4-Byte-INTEGER repliziert werden. Die unterschiedliche Definition ist daher kein Replikationsbruch: Der Leaf darf id als SERIAL erzeugen, waehrend der Master INTEGER ohne eigene Serial-Sequenz speichert.

cdr alter –off scheiterte trotzdem mit Return Code 137, weil die Unset-Pruefung das Master-Dictionary (coltype 2) streng mit dem lokalen Katalog (coltype 262) vergleicht. Zusaetzlich existierte ein Shadow-Replicate. Der spaetere MODIFY (id INTEGER) glich den Katalog zwar kuenstlich an und entblockte –off, war fachlich aber falsch, weil dadurch die lokale Soll-Serial-Definition verloren ging.

Anonymisierte Umgebung

Informix: 12.10.FC14WE
Leaf: servera, begrenzter ER-Server, SEND-ONLY
Master: serverb (ID server_id_b) auf serverb_host
Zieldatenbank: datenbank_a
Master-Datenbank: datenbank_b
Datenbank-Owner: benutzerA
Tabellen: tabelleA und tabelleB
Replicates: replikatA und replikatB

Die beiden relevanten Bits

Dezimal	Hexadezimal	Bedeutung
4194304	0x400000	Echtes CDR-ALTER-MODE-Flag
8388608	0x800000	IPA-Historie im Partition-Header

Das echte ALTER-MODE-Flag wird von oncheck -pt als TBLspace flagged for CDR alter mode angezeigt. Bei gesetztem 0x800000 allein erscheint dieser Text nicht.

Diagnoseabfrage

Die urspruengliche Suchabfrage nach dem Flag 8388608 lautet:

SELECT t.dbsname,t.tabname, p.flags,
       BITAND(p.flags, 8388608) AS alter_mode_bit
FROM sysmaster:systabnames t, sysmaster:sysptnhdr p, systables tab
WHERE t.partnum = p.partnum
  AND BITAND(p.flags, 8388608) > 0
  AND t.tabname = tab.tabname
  AND tab.tabid > 99
ORDER BY t.dbsname,t.tabname;

Diese Abfrage findet Partitionen mit IPA-Historie, beweist aber keinen aktiven CDR-ALTER-MODE. Fuer die Unterscheidung der beiden Bits kann beispielsweise folgende Abfrage verwendet werden:

SELECT t.dbsname,
       t.tabname,
       BITAND(p.flags, 4194304) AS cdr_alter_mode,
       BITAND(p.flags, 8388608) AS ipa_history
  FROM sysmaster:systabnames t,
       sysmaster:sysptnhdr p,
       systables tab
 WHERE t.partnum = p.partnum
   AND t.dbsname = 'datenbank_a'
   AND t.tabname IN ('tabelleA', 'tabelleB')
   AND t.tabname = tab.tabname
   AND tab.tabid > 99;

Zusaetzlich zeigt oncheck -pt den echten ALTER-MODE-Status:

oncheck -pt datenbank_a:benutzerA.tabelleA

Bei der betroffenen Umgebung war 0x400000 nicht gesetzt, waehrend 0x800000 gesetzt war. DML war deshalb nicht wegen des vermeintlichen ALTER-MODE-Bits blockiert.

Zusammenhang mit In-Place-Alter

Die Spalten pta_oldvers und pta_newvers im Partition-Header beschreiben die IPA-Versionskette. Ein gesetztes 0x800000 kann daher zusammen mit einer solchen Versionsspanne auftreten.

Ob noch alte Datenseiten vorhanden sind, wird mit oncheck -pT geprueft, nicht anhand des Bits:

Home Data Page Version Summary
       Version                         Count
       n (oldest)                      0
       ...
       m (current)                     Anzahl der Datenseiten

Wenn alle alten Versionen den Count 0 haben und nur die aktuelle Version Datenseiten traegt, ist die IPA operativ abgeschlossen. Das Bit kann trotzdem noch als Header-Historie vorhanden sein. update_ipa raeumt alte Datenseiten auf; es setzt den Partition-Header nicht zwingend zurueck.

Ursache fuer Return Code 137

Im Online-Log erschien sinngemaess:

GC operation alter mode unset operation on a replicated table failed:
Mismatch between local table dictionary and master dictionary

CDR WARNING: Column type or size mismatch detected

Der einzige Schemaunterschied war:

Spalte	Leaf	Master und Master-Dictionary
`id`	`SERIAL NOT NULL` (`coltype 262`)	`INTEGER`, nullable (`coltype 2`)

SERIAL und INTEGER sind hinsichtlich der Speicherbreite kompatibel und koennen ordnungsgemaess repliziert werden. Fuer das CDR-Dictionary sind es trotzdem unterschiedliche Typen. Die Spalte id war Teil des Replikationsschluessels (pknum 1, zusammen mit nlcode als pknum 2). Deshalb scheiterte die strenge Unset-Pruefung von cdr alter –off mit Return Code 137. Das ist kein Beleg dafuer, dass die Replikation von SERIAL nach INTEGER unzulaessig waere.

Ein aktiver Shadow-Replicate vom Master kann diesen Zustand zusaetzlich festhalten. Auf einem Limited Server ist das Loeschen von Replicates nicht erlaubt (Return Code 75); solche Verwaltungsaktionen muessen auf dem Master ausgefuehrt werden.

Durchgefuehrte Bereinigung

Shadow-Replicate auf serverb geloescht.
Fuer beide Tabellen ALTER-MODE kontrolliert gesetzt und ausgeschaltet.

Die anschliessende Aenderung von id auf INTEGER war ein Fehler und

  haette entfallen muessen:

cdr alter --on  datenbank_a:benutzerA.tabelleA
ALTER TABLE tabelleA MODIFY (id INTEGER);  -- FALSCH: nicht nachmachen
cdr alter --off datenbank_a:benutzerA.tabelleA
 
cdr alter --on  datenbank_a:benutzerA.tabelleB
cdr alter --off datenbank_a:benutzerA.tabelleB

Der dokumentierte MODIFY-Schritt wurde tatsaechlich ausgefuehrt und entblockte –off, war aber fachlich nicht korrekt. id haette lokal als SERIAL NOT NULL bleiben muessen. Der Soll-Zustand ist daher in einem separaten, kontrollierten Auftrag wiederherzustellen.

Offene IPA-Datenseiten mit update_ipa bereinigt:

DATABASE sysadmin;
EXECUTE FUNCTION task('table update_ipa', 'tabelleA', 'datenbank_a');
EXECUTE FUNCTION task('table update_ipa', 'tabelleB', 'datenbank_a');

Anschliessend beide Partitionen mit einem Slow-Alter neu geschrieben:

cdr alter --on datenbank_a:benutzerA.tabelleA
ALTER FRAGMENT ON TABLE tabelleA INIT IN datenbankbereichA;
cdr alter --off datenbank_a:benutzerA.tabelleA

Der letzte Schritt wurde analog fuer tabelleB ausgefuehrt. Dabei wurden keine Daten per Unload/Load bewegt, kein Katalog manuell geaendert und kein Remaster vom Leaf durchgefuehrt.

Ergebnis

Tabelle	Flags	0x800000	0x400000	pta_old/new	id-coltype
`tabelleA`	0x0000090A	0	0	0 / 0	2
`tabelleB`	0x0000080A	0	0	0 / 0	2

oncheck -pt zeigt jetzt nur noch die Replikationskennzeichnung, nicht mehr CDR alter mode. Die Zeilenanzahl blieb unveraendert. Die Primaer- und Unique-Indizes wurden nicht veraendert.

Wegen des falschen MODIFY erzeugt ein INSERT ohne angegebene id auf dem Leaf aktuell keine lokale Seriennummer mehr. Das ist ein Fehlerzustand: Der Soll-Zustand dieses SEND-ONLY-Knotens ist weiterhin SERIAL NOT NULL auf dem Leaf und INTEGER im Master. Andere unabhaengige Serial-Spalten bleiben davon unberuehrt.

Betriebsregeln

CDR-ALTER-MODE mit oncheck -pt, dem Bit

BITAND(flags, 4194304) > 0, dem Online-Log und Fehler 19992

  diagnostizieren.
* Nicht ''BITAND(flags, 8388608)'' als ALTER-MODE-Nachweis verwenden.
* IPA mit ''oncheck -pT'' anhand der Version Counts beurteilen.
* Bei Return Code 137 die Unset-Pruefung und den Shadow-Zustand untersuchen.
  ''SERIAL'' lokal gegen ''INTEGER'' im Master ist als Replikationskonvertierung
  zulaessig, auch wenn das Dictionary coltype 262 gegen 2 meldet.
* Bei Replikationsschluesseln muessen Namen, Reihenfolge und die
  Replikationskompatibilitaet stimmen. SERIAL lokal und INTEGER im Master
  kann dabei eine beabsichtigte Konvertierung sein.
* Shadow-Replicates auf dem fuehrenden Master verwalten, nicht auf einem
  Limited Leaf.
* Den Datenbank- und Owner-Qualifier bei ''cdr alter'' immer angeben.
* ''sysmaster''-Pseudo-Tabellen nicht per UPDATE veraendern.
* Replizierte Tabellen nur nach kontrolliertem ''cdr alter --on'',
  Shadow-/Participant-Bereinigung und anschliessendem ''--off'' aendern.
  Die lokale SERIAL-Definition dabei nicht auf INTEGER aendern, nur um
  die Unset-Pruefung zu umgehen.

Betroffene Objekte und Umgebung

Informix: 12.10.FC14WE, INFORMIXSERVER=tcp_servera
Leaf: servera; Master: serverb
Datenbank: datenbank_a
Tabellen: tabelleA und tabelleB
Replicates: replikatA (Teilnehmer tabelleA) und

replikatB (Teilnehmer tabelleB)

Befund

ipa_history ist kein Spaltenflag. Informix In-Place-Alter (IPA) laesst Datenseiten nach einem ALTER TABLE zunaechst in der alten Row-Version. Erst ein spaeteres INSERT oder UPDATE schreibt die jeweilige Zeile in das neue Layout. Sichtbar ist dies in oncheck -pT unter Home Data Page Version Summary sowie in sysmaster:sysptnhdr mit pta_oldvers und pta_newvers.

Bei tabelleA wurden 1504 Seiten in Version 0 (oldest) und 656 Seiten in Version 1 (current) gefunden; nupdates war 3596. Bei tabelleB waren 2034 Seiten in Version 0 und nur 1 Seite in Version 1; nupdates war 11. In beiden Faellen gab es nur eine neue Version (0 → 1). Der groesste Teil der Zeilen war daher noch nicht auf das neue Layout umgeschrieben. Das ist kein Datenfehler.

Ursache und zeitlicher Ablauf

Ursache waren manuelle ALTER TABLE … MODIFY-Laeufe als User informix, nicht ein automatischer Job und nicht das Flag selbst.

Am 04.09.2026 erledigte task('table update_ipa') eine aeltere IPA.

Danach wurden die Partitionen neu aufgebaut; die neuen Partitionen

  hatten anschliessend keine offene IPA.
* Am 07.09.2026 wurden unter anderem ''nbwvorwahl CHAR(7)'' und
  ''tabelleB.handynr CHAR(16)'' gesetzt. Diese Definitionen waren bereits
  in frueheren Dictionary-Dumps vorhanden und waren nicht der Ausloeser
  der zweiten Seitenversion.
* Die IPA-treibende Aenderung war der Wechsel von ''id INTEGER'' zu
  ''id SERIAL NOT NULL'': bei ''tabelleA'' am 07.09.2026 und bei
  ''tabelleB'' am 08.09.2026. Dazu kamen Syntaxversuche am Serial-Typ,
  ein UPDATE auf ''id IS NULL'' sowie ''cdr alter --off''.
* Am 08.09.2026 wurden Sitzungen von einem Arbeitsplatz beendet, die
  betroffene Sitzungen hielten.

Die lokalen und Master-Dictionary-Staende waren dabei nicht gleich: Im Master war id als INTEGER definiert, lokal als SERIAL. Der Nahtabzug zeigte fuer tabelleA bereits SERIAL NOT NULL und fuer tabelleB noch INTEGER; im aktuellen Schema sind beide lokal SERIAL NOT NULL. Dadurch bleibt das ER-Dictionary fachlich zu klaeren, auch wenn die Speicherbreite von SERIAL und INTEGER kompatibel ist.

Warum die Historie stehen blieb

task('table update_ipa') vom 04.09.2026 bezog sich nur auf die damaligen Partitionen. Nach den neuen Alters am 07. und 08.09. wurde die Bereinigung nicht erneut ausgefuehrt. IPA schreibt die alten Seiten nicht sofort um, sondern erst bei spaeterem DML.

Empfohlene Behebung

Eine offene IPA nur aufloesen, wenn dies fuer Reorg, Versionswechsel,

Revert oder Monitoring erforderlich ist. Normale DML konvertiert Zeilen

  nach und nach.
- Wenn alle Seiten bewusst auf die aktuelle Version gebracht werden
  sollen, dies in einem Wartungsfenster und nach Abstimmung mit ER
  ausfuehren:

DATABASE sysadmin;
EXECUTE FUNCTION task('table update_ipa', 'tabelleA', 'datenbank_a');
EXECUTE FUNCTION task('table update_ipa', 'tabelleB', 'datenbank_a');

  Optional kann die Task-Variante mit ''parallel'' verwendet werden. Nicht
  unter Last und nicht parallel zu Anwendungsschreibern auf denselben
  Tabellen ausfuehren; bei replizierten Tabellen ist der ER-Alter-Mode zu
  beruecksichtigen. Nach dem Checkpoint erneut ''oncheck -pT'' ausfuehren.
  Bei abgeschlossener IPA traegt nur noch die aktuelle Version Seiten;
  die alten Versionen haben Count 0.
- Nicht nochmals ''ALTER TABLE ... MODIFY'' auf ''id'', ''nbwvorwahl'' oder
  ''handynr'' zur Sicherheit ausfuehren. Auch gleiche oder kompatible
  MODIFYs koennen erneut Alter-Mode und IPA-Versionen erzeugen.
- Die ER-Masterdefinition und den lokalen Soll-Typ abstimmen. Wenn
  ''id'' absichtlich ''SERIAL'' sein soll, muss die Replicate-Definition
  kontrolliert nachgezogen werden; ein weiteres lokales Alterieren loest
  den Dictionary-Mismatch nicht.
- Kein zweites ''update_ipa'' auf Verdacht starten: Die Task schreibt alle
  Restzeilen um und erzeugt I/O, Log- sowie ER-Apply-Last. Vorher muss
  ''oncheck -pT'' den Bedarf bestaetigen.
- Nacharbeiten dokumentieren: verantwortlicher Aenderer, Soll-Typ im
  Master und die Frage, ob weitere Leaf-Knoten denselben Stand benoetigen.

IBM/HCL: Troubleshooting Tips for Alter Operations
IBM/HCL: Resolve outstanding in-place alter operations
IBM/HCL: CDR Return Codes 137 (Dictionary-Mismatch) und 75 (Limited Server)

Stichworte

Informix, Enterprise Replication, CDR, ALTER-MODE, In-Place-Alter, IPA, sysptnhdr, oncheck, cdr alter, Dictionary-Mismatch, Shadow-Replicate, Limited Server

chunks_pages

Anonymous (anonymous@undisclosed.example.com) — 2026-10-09T15:01:41+00:00

Chunk-Länge und Blob-Page

Notiz zur Anlage eines Chunks in einem Blobspace. Eine Blob-Page muss vollständig im Chunk liegen. IBM legt die Blob-Page als Vielfaches der System-Page fest und verbietet, dass sie über die Chunk-Grenze geht. onspaces -s rechnet in Kilobyte. Ein Wert, der nur in der System-Page aufgeht, ist für den Blobspace zu kurz oder zu lang.

Regel

Die System-Page steht in onstat -d beim rootdbs in pgsize. Die Blob-Page steht dort beim Blobspace. Auf dem betroffenen Server ist die System-Page 2 KiB (2048) und die Blob-Page von blobdbs 10 KiB (10240). 4 KiB wäre nur dann der Teiler, wenn die System-Page der Instanz 4 KiB ist.

Die 5 ist dieses Vielfache in Pages. onstat -d zeigt die Chunk-Länge size als Anzahl System-Pages S. Eine Blob-Page belegt

n = 10240 / 2048 = 5

System-Pages. Im Chunk liegen S / 5 Blob-Pages. Das ist eine ganze Zahl genau dann, wenn S durch 5 teilbar ist. Sonst bleibt am Ende ein Rest von 1 bis 4 System-Pages, und die nächste Blob-Page geht über die Chunk-Grenze.

onspaces erwartet -o und -s in Kilobyte, mindestens 1000 KB. Mit s als dieser Kilobyte-Zahl gilt

S = s * 1024 / 2048 = s / 2
S / 5 = s / 10

S ist durch 5 teilbar genau dann, wenn s durch 10 teilbar ist. Die 10 ist dieselbe Blob-Page in Kilobyte, 10240 / 1024. Es sind nicht zwei Regeln.

IBM formuliert bei -s nur „a multiple of the page size“. Die System-Page erfüllt das für viele Größen, die die Blob-Page nicht erfüllt. Maßgeblich ist die Blob-Page, weil sie den Chunk nicht überqueren darf.

Beispiel 2 GiB

2 GiB sind 2097152 KB. Geteilt durch 2 KiB geht das auf: 1048576 System-Pages. Geteilt durch 10 KiB nicht: 2097152 geteilt durch 10 ist kein Ganzes. 1048576 geteilt durch 5 lässt Rest 1. Es bleibt eine System-Page übrig. Der Schreibversuch am Ende fordert pagecnt 5 und landet hinter dem Chunk.

Passend sind 2097150 KB. Das sind 209715 Blob-Pages ohne Rest und 1048575 System-Pages, teilbar durch 5.

onspaces -a blobdbs -p /pfad/chunk -o 0 -s 2097150

Offset 0. Dieselbe Rechnung für jede andere Wunschgröße: den KB-Wert auf das nächste Vielfache von 10 abrunden.

Der I/O-Fehler tritt beim Schreiben in blobdbs auf, wenn diese Teilung einen Rest ungleich null lässt . Die Blob-Page geht am Chunk-Ende physisch nicht auf. Der Server fordert die volle Blob-Page an und schreibt hinter das Chunk-Ende.

datadbs

Für Chunks in datadbs ist das unkritisch. Dort ist die Zuordnungseinheit die Page dieses Dbspace, abzulesen in onstat -d unter pgsize in der Zeile von datadbs, nicht die Blob-Page von blobdbs.

Ist pgsize dort 2048, ist der Teiler 2 KB. 2097152 KB sind 1048576 Pages ohne Rest. Eine Daten-Page überquert den Chunk nicht, weil sie selbst die Page-Größe ist. Den I/O-Fehler aus der angebrochenen Blob-Page gibt es dort nicht.

IBM verlangt auch für einen Dbspace-Chunk ein Vielfaches der Page-Größe. Steht bei datadbs eine eigene Page-Größe, zum Beispiel 16384, muss -s durch 16 teilbar sein. Der Teiler 5 aus dem Blobspace gilt dann trotzdem nicht.

Prüfen

onstat -d
onstat -d update

pgsize von rootdbs und vom Blobspace ablesen. In der Chunk-Liste ist size die Zahl der System-Pages. Schief, wenn size geteilt durch 5 einen Rest lässt. 2621440 und 2000000 gehen auf, 1048576 nicht.

free nach onstat -d update vor und nach einem Speichern vergleichen. Der Chunk, dessen free sinkt, hat die Pages bekommen. Frei etwa 0 heißt, der Chunk wird übergangen. IBM kennzeichnet einen leeren Down-Chunk in dieser Liste gesondert. Das ist ein anderer Zustand als ein voller schiefer Chunk.

oncheck -pe blobdbs

oncheck -pe zeigt, welche Tabelle schon Pages auf welchem Chunk hat. Den nächsten Schreibvorgang zeigt es nicht.

Was davon bleibt

Ein voller schiefer Chunk ist damit nicht repariert. Sobald dort Pages frei werden, ist die überstehende Page wieder wählbar. Den Blobspace mit dem Suffix alt deshalb nicht löschen, solange BYTE-Werte auf so einem Chunk liegen.

onspaces -s mit -D setzt den Chunk auf Down. Down ist offline: Lesen und Schreiben entfallen. Einen Nur-Lesen-Zustand gibt es nicht. Zurück auf Online geht mit -O, nicht mit einem Lese-Flag. Einen leeren Chunk entfernen ist ein anderes Kommando (onspaces -d) und setzt voraus, dass nichts mehr darauf liegt.

IBM

IBM: Blobpages — Blob-Page ist ein Vielfaches der System-Page und liegt immer ganz in einem Chunk.
IBM Informix 12.10: onspaces -a — -o und -s in Kilobyte, mindestens 1000 KB, Vielfaches der Page-Größe.
IBM: onspaces -c -b — -g ist die Blob-Page in Einheiten der Basis-Page, 2 KiB oder 4 KiB.
IBM Informix 12.10: onstat -d — Chunk-Liste, size, free, Flag Down.
IBM: Chunks — onstat -d überwacht die freien Pages. Frei 0 in allen Chunks eines Dbspace blockiert neue Objekte.
IBM: Event alarm IDs — offline Chunk, Wiederherstellung mit onspaces -s.

Stichworte

Informix, Blobspace, datadbs, Blob-Page, Chunk, onspaces, onstat -d, pgsize, pagecnt, I/O, BYTE, TEXT

collate_umlaute

Anonymous (anonymous@undisclosed.example.com) — 2026-09-27T07:22:36+00:00

Informix: Codeset, Collation und deutsche Umlaute

Ziel und Rahmen

Diese Notiz beschreibt die operative Ursache von Problemen mit deutschen Umlauten in Informix aus Sicht eines System- oder Datenbankadministrators. Der Schwerpunkt liegt nicht auf der Sprachtheorie, sondern auf den tatsächlichen Betriebsebenen:

wie die Datenbank Zeichen kodiert,
welche Rolle die Locale spielt,
wo die eigentliche Ursache in Client/Server-Konvertierung liegt,
wann eine Collation nur die Sortierung beeinflusst und wann sie in Wirklichkeit ein Encoding-Problem maskiert.

Wichtig: In Informix sind Codeset und Collation getrennte Konzepte. Eine falsche Annahme, sie seien identisch oder austauschbar, erzeugt die typischen Umlaut-Fehler.

1. Locale-Architektur in GLS

Informix verwendet GLS (Global Language Support). Eine Locale hat die Form:

Sprache_Territorium.Codeset[@Modifikator]

Typische Beispiele:

ll_CC.819
ll_CC.819@dict
ll_CC.utf8
ll_CC.57372

Die Bestandteile bedeuten:

Sprache/Territorium: sprachliche und regionale Defaults, z. B. Datumsformate, Meldungen, kulturelle Regeln
Codeset: definierte Byte-Tabelle für die gespeicherten Zeichen
Modifikator: Vergleichs- und Sortierregeln, z. B. @dict

Das Entscheidende:

Codeset bestimmt das Speicherformat in CHAR/VARCHAR/LVARCHAR.
Collation bestimmt Vergleich, Sortierung und semantische Ordnung.
Die Collation ist keine zweite Kodierung, sondern eine Vergleichslogik.

2. Codeset vs. Collation: die zentrale Trennung

2.1 Codeset

Der Codeset beschreibt, welche Bytes in der Datenbank für ein Zeichen verwendet werden. Beispiel für ISO-8859-1 / IBM CCSID 819:

Ä = C4
Ö = D6
Ü = DC
ä = E4
ö = F6
ü = FC
ß = DF

In UTF-8 dagegen sind dieselben Zeichen mehrere Bytes, beispielsweise:

ä = C3 A4
ö = C3 B6
ü = C3 BC

Das bedeutet: Die logische Rune „ü“ kann in verschiedenen Codesets als unterschiedliche Bytefolge erscheinen. Deshalb ist der tatsächliche Fehler oft ein Encoding-Mismatch, nicht ein Unicode-Problem der Datenbank selbst.

2.2 Collation

Die Collation beschreibt, wie Zeichen verglichen und sortiert werden. Sie betrifft SQL-Regeln wie:

ORDER BY
BETWEEN
LIKE, je nach Typ und Locale
Unique-Index-Validierung
Range- und Partitionierungslogik
Replikations- und Vergleichssemantik je nach Definition

Ein Modifikator wie @dict ändert nicht das gespeicherte Byte für ü, sondern nur die Reihenfolge, in der Zeichen als vergleichbar bzw. sortierbar behandelt werden.

Praktisch:

819 und 819@dict sind identisch in der Byte-Tabelle.
819@dict kann die Sortierung ändern.
819@dict ändert nicht FC zu einem anderen Byte.
Ein Wechsel des Codesets (819 → UTF-8 oder umgekehrt) ändert dagegen das physische Bytebild der Daten.

3. DB_LOCALE und CLIENT_LOCALE

Der Ablauf ist immer:

Anwendung → CLIENT_LOCALE → GLS-Konvertierung → DB_LOCALE → Datenseite / Chunk

3.1 CLIENT_LOCALE

CLIENT_LOCALE beschreibt die Zeichenkodierung, mit der die Anwendung die Zeichen an den Server sendet. Ein Client kann Latin-1, UTF-8, UCS-2 oder ein anderer von GLS unterstützter Codeset verwenden.

3.2 DB_LOCALE

DB_LOCALE beschreibt den Codeset der Datenbank selbst. Sobald die Daten in die Datenbank gelangen, werden sie im DB-Codeset gespeichert. Die Datenbank selbst kennt nur diese interne Byte-Repräsentation.

3.3 Konvertierung

Wenn Client und Datenbank unterschiedliche Codesets verwenden, führt Informix eine Konvertierung durch. Das ist genau die Stelle, an der viele Fehler entstehen.

Beispiele:

Client sendet UTF-8-C3-BC für ü, DB erwartet 819: die Konvertierung wird zu FC erwartet, sofern alle Locales korrekt gesetzt sind.
Client sendet Latin-1 FC, DB erwartet UTF-8: der Server wandelt FC nach UTF-8, wenn die Konvertierung korrekt ist.
Client behauptet UTF-8, liefert aber Latin-1-Bytes oder umgekehrt: Die Konvertierung interpretiert die Faustdaten fälschlich, und das Ergebnis ist Mojibake.

Das ist genau die Ursache, wenn im Feld plötzlich „Ã¼“ oder andere verzerrte Zeichen auftauchen.

4. Warum @dict kein Encoding-Problem ist

Der häufigste Fehler im operativen Umgang ist die falsche Gleichsetzung von Collation und Encoding.

Korrekt:

@dict ist Sortier-/Vergleichsregeln.
819 ist das Code-Schema.

Falsch:

@dict geändert das Byte für „ü“.
@dict macht aus einem latin-1-Byte ein UTF-8-Zeichen.

Diese Annahmen sind technisch falsch.

Beispiel:

ll_CC.819 und ll_CC.819@dict speichern ü als FC, sofern der Codeset unverändert bleibt.
Nur die Vergleichsregeln und die Reihenfolge bei ORDER BY, BETWEEN und ähnlichen Operationen ändern sich.

Wenn Umlaute in einer Datenbank falsch erscheinen, ist der Fehler in der Regel nicht @dict, sondern:

falscher DB_LOCALE beim CREATE DATABASE,
falscher CLIENT_LOCALE,
falsche Umgebungsvariablen beim Import/Export,
Fehlinterpretation der Bytes durch ein Werkzeug.

5. Was auf der Platte wirklich liegt

Informix speichert im Regelfall keine abstrakten „Buchstaben“, sondern Bytefolgen im DB-Codeset. Für 819 gilt:

ä = E4
ö = F6
ü = FC
Ä = C4
Ö = D6
Ü = DC
ß = DF

Wer in einer 819-DB einen Ausdruck wie 'Müller' speichert, speichert in Wirklichkeit eine Bytefolge wie:

M
ü = FC
l
l
e
r

Das ist nicht UTF-8, keine kombinierende Darstellung und kein „U+00FC plus Trema“ in einem Zeichensatz-Container. Es ist einfach das DB-Byte.

Das ist der Kernpunkt für Betrieb und Diagnose:

Wenn der Codeset 819 ist, ist ein Umlaut ein Latin-1-Byte.
Wenn der Codeset UTF-8 ist, wird derselbe logische Buchstabe als zweibyte-Sequenz gespeichert.

6. Einfluss auf Länge, LIKE, Substring und Unique

Die Collation beeinflusst nicht die physische Bytefolge, aber sie wirkt auf die Semantik.

6.1 LENGTH und Substring

Bei 819 ist ein deutsches Zeichen ein einzelnes Byte. Ein Wert wie 'Müller' hat in einer 819-DB eine andere Byte-Länge als in einer UTF-8-DB.

Das ist operational wichtig:

CHAR- und VARCHAR-Längen können im Vergleich zu UTF-8 deutlich anders aussehen,
Substring-Operationen auf Bytes/Zeichen müssen vor dem Hintergrund des Codesets verstanden werden,
bei Exporten/Imports oder dbload-Workflows muss die Byte-Kodierung konsistent sein.

6.2 LIKE und Vergleichslogik

Collation beeinflusst, wie SQL-Engines Zeichen als „gleich“ oder in einer Reihenfolge behandeln. Damit können Werte in WHERE, ORDER BY, BETWEEN und Unique-Prüfungen unterschiedlichen Vergleichsergebnissen unterliegen, obwohl die gespeicherten Bytes identisch sind.

Dieser Effekt ist besonders deutlich bei:

Groß-/Kleinschreibung
Umlaute und Sonderzeichen
Sortierung in Dictionary-Order
Vergleichsregeln über Sprache/Gebiet

Bei CHAR und VARCHAR richtet sich die normale Vergleichsreihenfolge grundsätzlich nach der Codeset-Reihenfolge; ein in der Locale definierter Modifikator wie @dict kann die Sortierregeln beeinflussen. NCHAR und NVARCHAR verwenden die lokalisierte Kollationsreihenfolge der Datenbank-Locale. Die genaue Wirkung hängt von DB_LOCALE und dessen Collation ab; deshalb sollten Sortierung und Vergleiche mit den tatsächlich verwendeten Datentypen getestet werden.

Je nach Locale und Kollationsregeln können ß und ss beziehungsweise Ä und Ae oder A beim Sortieren ähnlich oder gleich gewichtet werden. Eine ähnliche Sortierposition bedeutet jedoch nicht automatisch, dass die Werte bei = oder in einem Unique-Index als gleich gelten. Diese Fälle separat mit ORDER BY, Gleichheitsvergleichen und gegebenenfalls einem Test-Unique-Index prüfen.

6.3 Unique-Index und Replikation

Wenn die Collation zwei Werte als gleich behandelt, kann ein Unique-Index den zweiten Datensatz ablehnen, obwohl die Bytefolgen auf den ersten Blick unterschiedlich aussehen. Das ist ein Kollationsproblem, kein Codepage-Problem.

Dasselbe gilt bei Replikation und ER: Die Vergleichssemantik und die lokale DB-Locale der beteiligten Kataloge und Tabellen müssen für die beteiligten Datenbanken konsistent sein. Eine scheinbar reine Sortierfrage kann sich als Vergleichs-/Katalogproblem zeigen.

Ändert eine logische Migration die Locale oder die zugrunde liegenden Vergleichsregeln, müssen die Indizes in der Zieldatenbank unter diesen Regeln angelegt werden. Vorhandene Indexstrukturen nicht ungeprüft übernehmen: nach dem Import die betroffenen B-Tree-Indizes und Unique-Bedingungen kontrollieren und sie bei Bedarf mit dem für die Informix-Version vorgesehenen Verfahren neu aufbauen, notfalls durch Löschen und erneutes Anlegen. Eine physische Wiederherstellung derselben Datenbank-Locale ist davon zu unterscheiden.

7. Typische Betriebssymptome

7.1 Mojibake

Beispiel: Ein Client sendet UTF-8-C3-BC, der Server erwartet 819, und die Daten werden als zwei falsche Latin-1-Bytes interpretiert. Ergebnis: Zeichen wie Ã¼, Ã¤, Ã¶ oder ähnliches.

Typische Ursache:

falscher CLIENT_LOCALE,
falscher Client-Charset,
ein Tool, das Bytes als UTF-8 ausgibt, obwohl der Server 819 erwartet,
UNLOAD/dbload mit inkonsistenter Locale-Mischung.

7.2 Abgeschnittene Strings

Wenn UTF-8-Sequenzen in einen 819-Server oder umgekehrt in die falsche Definition geraten, können die Zeichen als ungültig oder unvollständig interpretiert werden. Das führt zu:

abgeschnittenen Werten,
falschen String-Längen,
Umlautverlusten,
Fehlern bei String-Funktionen.

7.3 Falscher Sortier-/Eindeutigkeitsfehler

Diese Fälle sind häufig ein Kollationsproblem:

ORDER BY liefert rätselhafte Reihenfolge,
Umlaute erscheinen an unerwarteter Stelle,
Unique-Index verhält sich nach Collation, nicht nach Byte-Byte-Logik,
BETWEEN schließt Werte ein/aus, die bei reiner Byte-Logik nicht zusammenpassen.

8. Relevante operative Regeln

8.1 Die Besonderheit: Collation wird beim CREATE DATABASE fixiert

Die entscheidende Eigenschaft von Informix-GLS ist: Die Locale der Datenbank, inklusive der Collation, wird beim CREATE DATABASE in die Datenbankstruktur eingepflanzt und bleibt für die Existenz der Datenbank relevant. Das gilt nicht nur für den Sprach-Default, sondern auch für die Vergleichs- und Sortiersemantik der DB.

Das bedeutet praktisch:

Nach dem CREATE DATABASE ist die DB-Locale nicht nur eine Umgebungsvariable, sondern ein Bestandteil der Datenbank-Identität.
Ein späteres SET mit anderen Variablen oder ein geändertes Shell-Environment ändert die gespeicherten Daten nicht.
Die Datenbank selbst bleibt in der bereits festgelegten Locale-Definition verankert.

Dies ist der Grund, warum eine „Collation-Korrektur“ nachträglich nicht einfach über eine Environment-Variable oder einen einmaligen SET-Block erfolgen kann. Sobald die DB mit einem bestimmten Codeset und einer bestimmten Collation angelegt wurde, ist die physische und semantische Grundlage der Datenbank damit fixiert.

8.2 Warum Environment-Änderungen keine Korrektur sind

Die häufige falsche Annahme lautet: „Ich ändere DB_LOCALE oder CLIENT_LOCALE und die DB sortiert dann anders.“ Das ist nur für neue Verbindungen und neue Konvertierungen relevant, nicht für die bereits in der Datenbank gespeicherten Bytes und nicht für die bereits definierte DB-Locale.

Das ist ein wichtiger Punkt:

DB_LOCALE bestimmt den internen Codedata-Storage der DB.
CLIENT_LOCALE bestimmt die Interpretation der Client-Daten.
Eine angepasste Umgebung kann nur den Zugriff und die Konvertierung auf dem Weg steuern.
Sie kann eine bestehende DB nicht in eine andere Collation umwandeln, solange die DB nicht neu angelegt oder in einer kompatiblen Ziel-DB migriert wurde.

Kurz gesagt: Environment-Variablen sind nur die Konvertierungs- und Verbindungslogik; sie sind keine Definition der bereits gespeicherten DB-Semantik.

8.3 Die Abhängigkeit zwischen CLIENT_LOCALE, DB_LOCALE und Collation

Die operative Abhängigkeit ist:

CLIENT_LOCALE muss zur tatsächlichen Kodierung der Anwendungsdaten passen.
DB_LOCALE muss zum tatsächlichen DB-Codeset passen.
Die Collation bestimmt Sortier-/Vergleichsregeln nur innerhalb dieses fixierten Codesets.

Wenn diese drei Seiten nicht zusammenpassen, ist der Effekt:

fehlerhafte Konvertierung an der Client-/Server-Grenze,
falsche Interpretation der Bytes,
irreführende ORDER BY-/LIKE-/Unique-Ergebnisse,
scheinbar „verschiedene Umlauten“ bei identischen Bytes,
Fehler bei Imports/Exports und bei Replikations-/ER-Prozessen.

8.4 Warum eine Korrektur oft nur über neue DB oder Migration geht

Wenn eine DB mit dem falschen Codeset oder falscher Collation erstellt wurde, dann ist das Problem nachträglich nicht nur eine Frage der aktuellen Umgebung. Die logische Ursache liegt in der zu früh festgelegten DB-Locale und im fehlenden konsistenten Client-/Server-Codepfad.

In der Praxis ist die saubere Korrektur meist:

neue Ziel-DB mit gültiger DB_LOCALE und entsprechender Collation,
konsistente CLIENT_LOCALE beim Transfer,
sauberer Import/Export oder Copy-Workflow,
Prüfung der gespeicherten Bytes vor und nach dem Transfer,
Verifikation der Sortierung und Vergleichssemantik in der neuen DB.

Bei dbexport/dbimport die erzeugte Schema-Datei im Exportverzeichnis vor dem Import prüfen. Sie kann das ursprüngliche CREATE DATABASE-Statement und damit die bisherige Locale enthalten; nicht ungeprüft annehmen, dass dbimport automatisch die gewünschte Ziel-Locale verwendet. Falls nötig, den Datenbankkopf in der Schema-Datei auf die Zieldefinition anpassen. DB_LOCALE muss zur Ziel-Datenbank passen; CLIENT_LOCALE muss beim Export und Import jeweils zur tatsächlichen Kodierung der Textdateien passen. Nach dem Import Daten, Collation-Verhalten und neu angelegte Indizes verifizieren.

8.5 Praktischer DBA-Check: Host, Client und DB

Ein valider Admin-Workflow für die Diagnose sieht typischerweise so aus:

Host-Umgebung prüfen

Welche Locale ist im Betriebssystem gesetzt?
Welche Werte tragen DB_LOCALE, CLIENT_LOCALE, LANG, LC_ALL?
Ist das erwartete Codeset wirklich aktiv, oder wird ein anderes Umwelt-Setting übernommen?

Client-Umgebung prüfen

Welche Zeichenkodierung nutzt die Anwendung wirklich?
Gibt das Client-Tool bzw. die Sprache tatsächlich UTF-8 oder Latin-1 aus?
Werden beim Schreiben von Daten die Bytes eindeutig in der erwarteten Kodierung erzeugt?

DB-Locale prüfen

Welche DB_LOCALE gilt für die Datenbank?
Welcher Codeset ist für die Tabelle bzw. Datenbank festgelegt?
Ist die DB bereits mit einem anderen Codeset oder einem anderen Modifikator angelegt worden?

Reale Daten prüfen

Hex- oder Byte-Ausgabe der betroffenen Spalten prüfen.
Ist ein ü als FC im 819-Format sichtbar oder wird eine UTF-8-Sequenz erwartet?
Wurden beim Import/Export Rohbytes falsch interpretiert?

Semantik prüfen

ORDER BY, BETWEEN, LIKE, Unique-Checks separat auf Kollation testen.
Wenn die Sorte logisch auffällig ist, liegt die Ursache oft beim Modifikator / @dict.
Wenn die gespeicherten Bytes verfälscht sind, liegt die Ursache eher am Codeset-Mismatch.

8.6 Diagnostische Unterscheidung: Codeset-Problem vs. Collation-Problem

Ein typischer Entscheidungsbaum:

Fehler zeigt sich als „verzerrte Zeichen“ oder „Mojibake“

→ wahrscheinliches Codeset-/Konvertierungsproblem

Fehler zeigt sich als „falsche Sortierung“ oder „verwirrte Eindeutigkeit“

→ wahrscheinliches Collation-Problem

Die Bytes in der DB sind technisch korrekt, aber ORDER BY oder Unique-Checks wirken falsch

→ Collation oder Locale-Semantik ist die Ursache

Die Bytes in der DB sind technisch falsch, obwohl die gleiche Bedeutung erwartet wurde

→ codeset-/CLIENT_LOCALE-/DB_LOCALE-Mismatch

8.7 Zielgerichtete Korrekturstrategie

Im Betrieb sollte die Korrektur immer dem Ursachepfad folgen:

Wenn die DB in einem falschen Codeset angelegt wurde, muss man die Datenbasis in eine korrekt definierte Ziel-DB migrieren.
Wenn nur die Konvertierung zwischen Client und DB falsch ist, reicht oft eine konsistente Locale-Konfiguration.
Wenn nur die Sortierung falsch ist, liegt eine Collation- und Vergleichssemantikfrage vor, nicht ein Unicode-Transferproblem.

8.8 Betriebsregel in Kurzform

Collation wird bei CREATE DATABASE festgelegt und ist nicht nachträglich einfach „umzuschalten“.
DB_LOCALE legt das eigentliche Speicher-Codeset der Datenbank fest.
CLIENT_LOCALE legt die Codierung der Client-Daten fest.
Nur die Kombination aus korrekter DB_LOCALE, korrekter CLIENT_LOCALE und der passenden Collation liefert konsistente Umlaute und stabile Vergleiche.

Wenn zwei dieser Ebenen nicht zusammenpassen, entstehen die typischen Probleme mit ä, ö, ü, ß und anderen Sonderzeichen.

8.9 Runbook: Symptom → Ursache → Prüfung → Korrektur

Symptom A: Zeichen werden als Ã¼, Ã¤, Ã¶ dargestellt

Ursache:

UTF-8-Bytes werden in eine 819-DB oder als Latin-1 interpretiert.

Prüfung:

locale
env | grep -E 'LANG|LC_|CLIENT_LOCALE|DB_LOCALE'

SELECT name, LENGTH(name) FROM TABLE_NAME WHERE name LIKE '%M%';

Korrektur:

export CLIENT_LOCALE=en_US.819
export DB_LOCALE=en_US.819

Falls die Datenbank bereits im falschen Codeset steht, keine reine Laufzeitkorrektur, sondern neue DB oder sauberer Transfer planen.

Symptom B: ORDER BY oder Unique zeigt falsche Reihenfolge

Ursache:

Collation / @dict entspricht nicht den erwarteten Vergleichsregeln.

Prüfung:

SELECT col FROM tab ORDER BY col;
SELECT col, COUNT(*) FROM tab GROUP BY col HAVING COUNT(*) > 1;

Korrektur:

DB-Locale mit passender Collation neu definieren oder passende Ziel-DB anlegen.
Nicht allein durch CLIENT_LOCALE beheben.

Symptom C: Import/Export zeigt Umlaute erst nach Transfer falsch

Ursache:

Prozess- oder Tool-Kodierung inkonsistent.

Prüfung:

file datafile
hexdump -C datafile | head

Korrektur:

Daten explizit mit passender CLIENT_LOCALE/DB_LOCALE transferieren.
Lade-/Export-Tools mit gleicher Kodierung konfigurieren.

9. Interner Runbook-Block

Problem

Umlaute oder Sonderzeichen werden im Informix-System falsch dargestellt, sortieren falsch oder erzeugen Unique-/Vergleichsfehler.

Ursache

Die häufigste Ursache ist keine fehlende Informix-Funktionalität, sondern ein Mismatch zwischen:

DB_LOCALE,
CLIENT_LOCALE,
realer Client-Kodierung,
angelegter DB-Collation beim CREATE DATABASE.

Prüfung

locale
env | grep -E 'LANG|LC_|CLIENT_LOCALE|DB_LOCALE'

SELECT name, VALUE
FROM sysmaster:sysdbslocale
WHERE name IN ('dbs_collate', 'dbs_cset');

SELECT col,
       LENGTH(col),
       col = 'Müller' AS eq_mueller,
       col = 'Muller' AS eq_muller
FROM tab
LIMIT 10;

SELECT col
FROM tab
ORDER BY col;

file exportfile
hexdump -C exportfile | head

Diagnose

Wenn Zeichen verzerrt sind: Codeset-/Konvertierungsproblem wahrscheinlich.
Wenn Sortierung/Unique falsch ist: Collation-/@dict-Problem wahrscheinlich.
Wenn die DB bereits existiert und die Locale beim CREATE DATABASE falsch war: keine reine Laufzeit-Umstellung, sondern neue DB oder Migration.

Lösung

export CLIENT_LOCALE=en_US.819
export DB_LOCALE=en_US.819

Oder mit UTF-8:

export CLIENT_LOCALE=en_US.utf8
export DB_LOCALE=en_US.utf8

Wenn die Datenbank bereits mit einem falschen Codeset oder falscher Collation angelegt wurde:

CREATE DATABASE db_new WITH LOG
   DB_LOCALE = 'en_US.819@dict'
   CLIENT_LOCALE = 'en_US.819';

Danach Daten mit konsistenter Locale transferieren und die Ergebnisse erneut prüfen.

Verifikation

SELECT col,
       LENGTH(col),
       col = 'Müller' AS eq_mueller,
       col = 'Muller' AS eq_muller
FROM tab
ORDER BY col;

locale

Erwartung:

Umlaute werden konsistent dargestellt,
Sortierung entspricht der definierten Collation,
Vergleichssemantik stimmt mit der DB-Locale überein,
keine neuen Verzerrungen beim Transfer.

10. Diagnostik im Betrieb

Für den Admin ist die wichtigste Frage nicht „Ist @dict aktiv?“, sondern:

Welche DB_LOCALE gilt für die Datenbank?
Welcher Codeset wird auf dem Client verwendet?
Werden die Daten tatsächlich im gleichen Codeset geschrieben und gelesen?
Werden beim Import/Export Bytes mit einer falschen Interpretation behandelt?

9.1 Richtige Prüfungen

Checkliste:

DB-Locale mit Informationen zur Datenbank ermitteln.
Client-Umgebung prüfen: Locale, Codeset, Terminal-/Applikationskette.
Daten vor und nach Export/Import hexadezimal prüfen.
Relevante String-Operationen gegen erwartete Bytewerte prüfen.
Wenn die Datenbank ein Latin-1-Codeset verwendet, nachsehen, ob der Client tatsächlich Latin-1 liefert oder fälschlich UTF-8 behauptet.
Sortier- und Vergleichsregeln separat prüfen, da @dict die Sortierung ändern kann, aber nicht das physische Zeichen selbst.

9.2 Beispielhafte Logik

Wenn ein ü in der Datenbank anstelle von UTF-8-C3-BC als FC auftaucht, ist der Speicher korrekt für 819. Wenn der Client aber UTF-8-Strings liefert und der Server 819 erwartet, entsteht ein Konvertierungsfehler. Das muss am Übergang korrigiert werden, nicht durch einen Collation-Wechsel.

10. 1-Seiten-Checkliste für den Betrieb

Kurzfassung

Problem = falsch dargestellte Umlaute, falsche Sortierung oder Unique-/Vergleichsfehler.
Ursache = Mismatch zwischen DB_LOCALE, CLIENT_LOCALE und realer Client-Kodierung; ggf. falsche DB-Locale beim CREATE DATABASE.
Wichtig = Collation kann nur innerhalb eines bereits fest definierten Codesets wirksam werden; sie ändert keine gespeicherten Bytes.

Schnellprüfung

locale
env | grep -E 'LANG|LC_|CLIENT_LOCALE|DB_LOCALE'

SELECT name, VALUE
FROM sysmaster:sysdbslocale
WHERE name IN ('dbs_collate', 'dbs_cset');

Entscheidungsregel

Verzerrte Zeichen = Codeset-/Konvertierungsproblem
Falsche Reihenfolge / Unique-Fehler = Collation-/@dict-Problem
DB existiert bereits mit falscher Locale = neue DB oder Migration nötig

Korrektur

export CLIENT_LOCALE=en_US.819
export DB_LOCALE=en_US.819

Oder:

export CLIENT_LOCALE=en_US.utf8
export DB_LOCALE=en_US.utf8

Wenn die DB bereits falsch angelegt wurde:

CREATE DATABASE db_new WITH LOG
   DB_LOCALE = 'en_US.819@dict'
   CLIENT_LOCALE = 'en_US.819';

Verifikation

SELECT col,
       LENGTH(col),
       col = 'Müller' AS eq_mueller,
       col = 'Muller' AS eq_muller
FROM tab
ORDER BY col;

Erwartung:

Zeichen korrekt dargestellt,
Vergleichs- und Sortiersemantik passen zur DB-Locale,
keine neuen Konvertierungsfehler beim Transfer.

11. IBM-Referenzen

Die folgenden IBM-Dokumentationsstellen sind die maßgeblichen offiziellen Referenzen für die Kernregeln von Informix GLS und Locales:

IBM Informix Documentation: DB_LOCALE: Beschreibt die Datenbank-Locale und die Beziehung zwischen Locale, Codeset und gespeicherten Zeichen.
IBM Informix Documentation: CLIENT_LOCALE: Beschreibt die Client-Seite und die GLS-Konvertierung an der Client-/Server-Grenze.
IBM Informix Documentation: GLS und Locales: Beschreibt Codeset-, Collation- und localebezogene Regeln.
IBM Informix Documentation: CREATE DATABASE und Locale: Beschreibt die Einbettung der Datenbank-Locale beim Anlegen der Datenbank.
IBM Informix Documentation: Zeichensatzkonvertierung: Beschreibt, dass die Konvertierung nach Codeset und nicht nach Collation erfolgt.

Hinweis: IBM-Dokumentation kann je nach Version und Produktseite leicht verlinkt werden; die oben genannten Referenzen sind die offiziellen Einstiegspunkte für die hier beschriebenen Funktionen.

11. Schlussfolgerung

Das entscheidende technische Ergebnis lautet:

Deutsche Umlaute sind in einer 819-DB nicht „nicht unterstützt“.
Sie werden als einzelne Latin-1-Bytes im Codeset gespeichert.
Der Fehler entsteht typischerweise durch falsche Locale- und Codeset-Kombinationen auf Client/Server-Grenze.
@dict beeinflusst Sortierung und Vergleich, nicht das physische Byte.
Für die operative Analyse muss man immer zwischen Datenspeicherung, Collation und Client-/Server-Umsetzung sauber trennen.

Nur wenn Codeset, Collation und Client-Locale zusammenpassen, funktionieren ä, ö, ü, ß korrekt in Informix.

12. Konkrete Konfigurationsbeispiele

12.1 Typische Umgebungsvariablen

Beispiel für eine Linux-/bash-Umgebung, in der der Client als UTF-8 arbeitet und die DB als 819 erwartet:

export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
export CLIENT_LOCALE=en_US.utf8
export DB_LOCALE=en_US.819

Beispiel für eine Latin-1-/819-Spezifikation im Client:

export LANG=en_US.ISO8859-1
export LC_ALL=en_US.ISO8859-1
export CLIENT_LOCALE=en_US.819
export DB_LOCALE=en_US.819

Wichtig: Diese Werte sind nur richtig, wenn die Anwendung wirklich exakt in diesem Codeset arbeitet. Ein falscher oder „nur vermuteter“ Wert erzeugt echte Byte-Verzerrungen.

12.2 Beispiel für CREATE DATABASE mit fixierter Locale

CREATE DATABASE dbname WITH LOG
   IN dbspace1
   DB_LOCALE = 'en_US.819@dict'
   CLIENT_LOCALE = 'en_US.819'
   MODE ANSI;

Oder ebenfalls üblich:

CREATE DATABASE dbname WITH LOG
   DB_LOCALE = 'en_US.819'
   CLIENT_LOCALE = 'en_US.utf8';

Das ist der kritische Punkt: Nach dem CREATE DATABASE ist diese Locale für die DB fest. Ein späteres Setzen von CLIENT_LOCALE oder DB_LOCALE in der Shell ändert die bereits vorhandenen Daten nicht.

12.3 Beispiel für eine sichere SQL-Prüfung der DB-Locale

SELECT name, VALUE
FROM sysmaster:sysdbslocale
WHERE name IN ('dbs_collate', 'dbs_cset');

Wenn die DB definiert ist, zeigt die Datenbankkataloginformation, welcher Codeset und welche Collation für die DB gelten. Das ist der richtige Nachweis, nicht die aktuelle Shell-Umgebung.

12.4 Beispiel für einen Host-/Client-Check

echo "$LANG"
echo "$LC_ALL"
echo "$CLIENT_LOCALE"
echo "$DB_LOCALE"
locale

Prüfungen, die in der Praxis sinnvoll sind:

locale charmap
iconv --list | grep -Ei 'UTF-8|ISO-8859-1|IBM-819'

Wenn der Client als UTF-8 deklariert ist, aber tatsächlich Latin-1-Bytes ausliefert, ist die Konvertierung falsch, obwohl die Shell-Umgebung „gut“ aussieht.

12.5 Testbeispiele für Codeset und Umlaut

Beispiel A: Datenbank ist 819, Client ist korrekt als 819 gesetzt.

CREATE TABLE test_umlaut (
    id SERIAL,
    name VARCHAR(50)
);
 
INSERT INTO test_umlaut(name) VALUES ('Müller');
SELECT name, LENGTH(name) FROM test_umlaut;

Erwartung:

Der Wert wird als Latin-1-Byte im DB-Codeset abgelegt.
LENGTH ist an der gespeicherten Byte-Länge orientiert; bei 819 ist „ü“ ein einzelnes Byte.

Beispiel B: Client liefert UTF-8, DB erwartet 819.

SET CLIENT_LOCALE 'en_US.utf8';
INSERT INTO test_umlaut(name) VALUES ('Müller');

Wenn die Client-Umgebung nicht exakt mit den tatsächlich gesendeten Bytes übereinstimmt, kann der String als falsche Bytefolge interpretiert werden. Der Gefahrensignal: sichtbare Verzerrung, Spracheingang fehlerhaft, Abweichungen bei LENGTH oder ORDER BY.

12.6 Test für Sortierung ohne Encoding-Wechsel

CREATE TABLE test_sort (
    id SERIAL,
    name VARCHAR(20)
);
 
INSERT INTO test_sort(name) VALUES ('Muller'), ('Müller'), ('Muller2');
SELECT name FROM test_sort ORDER BY name;

Erwartung:

Die Reihenfolge hängt von Collation und codesetbezogener Vergleichslogik ab.
Das ist ein Vergleichsproblem, nicht automatisch ein Zeichen-/Byteproblem.

12.7 Test für sichere Konvertierung bei Export/Import

Beispiel für einen Import-Workflow mit festem Client-Codeset:

export CLIENT_LOCALE=en_US.819
export DB_LOCALE=en_US.819
 
# Beispiel: Export mit konsistentem Format
# Danach Import in die Ziel-DB mit derselben DB_LOCALE

Wenn Import/Export mit widersprüchlichen Locales läuft, wird das Zeichenmaterial falsch geordnet oder verfälscht.

12.8 Typischer Verifikations-Block nach einer Änderung

SELECT name,
       LENGTH(name),
       name = 'Müller' AS match_1,
       name = 'Muller' AS match_2
FROM test_umlaut;
 
SELECT name
FROM test_sort
ORDER BY name;

Ziel dieser Prüfung:

Sind die gezeigten Bytes und Zeichen konsistent?
Stimmt die Sortierung zur erwarteten Collation?
Ist die DB-Locale wirklich die gewünschte und nicht nur ein Shell-Setting?

12.9 Praktischer Entscheidungsbaum

1. Werden Zeichen verzerrt dargestellt?
   Ja -> Codeset-/Konvertierungsproblem prüfen
   Nein -> Sortier-/Collation-Problem prüfen
 
2. Sind Daten in DB bereits gespeichert?
   Ja -> DB_LOCALE und DB-Definition prüfen, kein bloßes SET erwartet
   Nein -> CREATE DATABASE / locale-Definition erneut prüfen
 
3. Ist CLIENT_LOCALE konsistent mit den tatsächlich gelieferten Bytes?
   Nein -> Client- oder Import-Fehler
   Ja -> DB_LOCALE prüfen
 
4. Ist ORDER BY / LIKE / Unique inkonsistent?
   Ja -> Collation und @dict prüfen
   Nein -> auf Export/Import oder Anwendungskodierung schauen

12.10 Betriebskorrektur in der Praxis

Minimaler, robuster Ablauf:

# 1. Umgebung prüfen
locale
env | grep -E 'LANG|LC_|CLIENT_LOCALE|DB_LOCALE'
 
# 2. Ziel-DB mit korrekter Locale anlegen
# CREATE DATABASE ... DB_LOCALE = 'en_US.819@dict'
 
# 3. Client auf dieselbe Semantik stellen
export CLIENT_LOCALE=en_US.819
 
# 4. Daten transferieren, danach Byte- und Vergleichsprüfungen durchführen

Wichtig: Wenn die vorhandene DB bereits im falschen Codeset bzw. mit falscher Collation erstellt wurde, ist eine reine Laufzeit-Umstellung meistens keine saubere Lösung. Dann ist eine neue, korrekt definierte DB oder eine glasklare Migration die belastbare Korrektur.

13. Schlagwörter

Informix, GLS, Locale, DB_LOCALE, CLIENT_LOCALE, Codeset, Collation, @dict, ISO-8859-1, CCSID-819, Latin-1, UTF-8, Unicode, deutsche Umlaute, äöüß, Byte-Repräsentation, Datenbankspeicher, ORDER BY, BETWEEN, LIKE, Unique-Index, String-Länge, Substring, Mojibake, dbload, UNLOAD, Import, Export, Replication, ER, Encoding, Character Conversion, Client-Server-Konvertierung, Datenbankadministrator, Troubleshooting, CREATE DATABASE, locale-check, hex-dump, shell-environment

fehlervermeidung_cas_mon_ddl

Anonymous (anonymous@undisclosed.example.com) — 2026-10-09T06:32:28+00:00

Sysadmin-Scheduler: cas_mon_ddl und PANIC

Notiz zur Datenbank sysadmin. Der Scheduler führt Tasks und Sensoren aus der Tabelle ph_task innerhalb von oninit aus, als Benutzer informix. Ein normaler SQL-Fehler beendet nur diesen Task-Lauf. Ein NULL-Zeiger im aufgerufenen Servercode nicht: der Thread stirbt, im Online-Log steht PANIC: Attempting to bring system down, die Instanz geht herunter.

Konkreter Fall hier: der Sensor cas_mon_ddl. Er wertet den SQL-Trace aus. NULL im Trace (Anweisungstext oder Host-Variable) läuft in diesen Zeiger und damit in den PANIC. Abhilfe ist, den Sensor abzuschalten, nicht sysadmin zu löschen.

Prüfen

Als informix, gegen die Datenbank sysadmin:

echo "SELECT tk_name, tk_enable FROM ph_task WHERE tk_name = 'cas_mon_ddl';" | dbaccess sysadmin

tk_enable ist t, solange der Sensor läuft, und f, wenn er aus ist. Fehlt die Zeile, ist der Sensor nicht installiert.

Abschalten

echo "UPDATE ph_task SET tk_enable = 'f' WHERE tk_name = 'cas_mon_ddl';" | dbaccess sysadmin

Das ist der von IBM dokumentierte Schalter. Dieselbe Spalte setzt IBM in der Gegenrichtung auf t, zum Beispiel für idle_user_timeout. Die Zeile in ph_task bleibt stehen. Nur der nächste geplante Lauf entfällt. Ein Lauf, der schon im Server steckt, wird von diesem UPDATE nicht abgebrochen.

Nach einem PANIC zuerst starten, dann diese Abschaltung, bevor der Sensor wieder an der Reihe ist. Danach die SELECT-Abfrage erneut ausführen. tk_enable muss f sein.

Warum der Scheduler die Instanz mitnimmt

Tasks und Sensoren sind SPL oder SQL in sysadmin, oft mit admin() oder task() und mit Abfragen auf sysmaster. Das läuft im Adressraum von oninit.

Ein SQL-Fehler (fehlende Tabelle, Rechte, Datenkonflikt) wird protokolliert. Die Instanz bleibt oben.
Ein Assert oder ein NULL-Zeiger im Servercode, den der Task dabei betritt, ist kein SQL-Fehler. IBM fährt die Instanz dann mit PANIC herunter. Eine Assertion-Datei muss dabei nicht entstehen.

cas_mon_ddl gehört in die zweite Klasse, weil er den SQL-Trace liest. IBM hat genau diesen Pfad als Absturz dokumentiert, ohne den Sensornamen zu nennen:

SQL-Trace eingeschaltet und Host-Variablen mit NULL: Absturz der Instanz (IC60371).
SELECT aus syssqltrace kann die Engine zum Absturz bringen (IC63448).
NULL-Zeichen über eine Host-Variable bei SQLTRACE HIGH: Absturz (IC67763).
SELECT auf syssqltrace oder der dbCron-Task sql_showsnap: Speicherfehler (IC70193).

Der Sensor schaltet den Trace und liest syssqltrace. Trifft er dabei auf NULL, ist das derselbe Codepfad. Weil der Aufruf aus dem Scheduler kommt, ist das Ergebnis ein PANIC der Instanz.

IBM

IBM: Built-in tasks and sensors — Task über tk_enable = f in ph_task abschalten.
IBM Informix 12.10: idle_user_timeout — offizielles UPDATE ph_task SET tk_enable gegen sysadmin als informix.
IBM Informix 12.10: Creating a task — Tasks liegen in ph_task, Verbindung nur als informix oder ein berechtigter Benutzer.
IBM: Master Daemon Died — Online-Log PANIC: Attempting to bring system down. Eine Assertion-Datei muss nicht da sein.
IBM Fix List 11.50.xC4 — IC60371, SQL-Trace und NULL in Host-Variablen.
IBM Fix List 11.50.xC5W4 — IC63448, Lesen von syssqltrace.
IBM Fix List 11.50.xC7 — IC67763 und IC70193.

Stichworte

Informix, sysadmin, ph_task, Scheduler, cas_mon_ddl, tk_enable, SQLTRACE, syssqltrace, NULL, PANIC

informix_fdw

Anonymous (anonymous@undisclosed.example.com) — 2026-05-03T06:47:34+00:00

IMPORT FOREIGN SCHEMA von Informix nach PostgreSQL

Vorbereitung

Zur besseren Nachverfolgung aktivieren wir das erweiterte Debugging:

SET client_min_messages TO DEBUG2;

Vollständiger IMPORT aller Tabellen eines Informix-Datenbank-Schemas

IMPORT FOREIGN SCHEMA daten
    FROM SERVER tcp_azur_Test
    INTO test
    OPTIONS (DATABASE 'test');

LIMITIERTER IMPORT (z. B. nur eine Tabelle)

IMPORT FOREIGN SCHEMA informix
    LIMIT TO (abfrage)
    FROM SERVER tcp_azur_Test
    INTO test
    OPTIONS (DATABASE 'test');

Hinweis:

`IMPORT FOREIGN SCHEMA` bezieht sich nicht auf das PostgreSQL-Schema, sondern auf den Owner der Tabellen im Informix-System.
Die Angabe wie z. B. `daten` ist ein Benutzer (Owner) in Informix, nicht der Name eines Schemas.
Beispielhafte vom Server generierte Abfrage:

    DEBUG:  PREPARE query "SELECT tabid, trim(owner), tabname FROM systables 
    WHERE tabid >= 100 AND owner = 'daten' 
    AND tabname IN ('abfrage') ORDER BY tabname DESC"

Wichtiger Hinweis zur Richtung des Imports

Ein `IMPORT FOREIGN SCHEMA` ist nur unidirektional möglich:

Von Informix nach PostgreSQL. Nicht umgekehrt! Ein Export oder Zugriff von Informix auf PostgreSQL über dieselbe Methode ist nicht möglich. Das Schema muss also zwingend auf Informix vorhanden sein!

Kopieren der Tabellen lokal in PostgreSQL (struktur+daten)

Die folgende PL/pgSQL-Prozedur kopiert Tabellen aus dem per Foreign Schema importierten Schema (`quelle`) in ein lokales Zielschema (`ziel`).

Dabei wird:

das Zielschema ggf. neu angelegt,
jede Tabelle zuerst strukturell dupliziert (`LIKE … INCLUDING ALL`),
anschließend werden die Daten kopiert.
Bei einem Fehler wird trotzdem die leere Tabelle erstellt (zur späteren Analyse oder Wiederholung).

CREATE OR REPLACE PROCEDURE db.kopie(
    IN quelle TEXT,
    IN ziel TEXT)
LANGUAGE 'plpgsql'
AS $$
DECLARE
    tabelle TEXT;
BEGIN
    -- Schema prüfen und ggf. erstellen
    PERFORM 1 FROM information_schema.schemata WHERE schema_name = ziel;
    IF NOT FOUND THEN
        EXECUTE format('CREATE SCHEMA %I', ziel);
    END IF;
 
    -- Tabellenstruktur kopieren
    FOR tabelle IN
        SELECT TABLE_NAME
        FROM information_schema.tables
        WHERE table_schema = quelle
    LOOP
        EXECUTE format('DROP TABLE IF EXISTS %I.%I', ziel, tabelle);
        RAISE NOTICE 'Struktur % verarbeitet', tabelle;
        EXECUTE format(
            'CREATE TABLE %I.%I (LIKE %I.%I INCLUDING ALL)',
            ziel, tabelle, quelle, tabelle
        );
    END LOOP;
 
    -- Daten kopieren mit Fehlerbehandlung
    FOR tabelle IN
        SELECT TABLE_NAME
        FROM information_schema.tables
        WHERE table_schema = quelle
    LOOP
        BEGIN
            EXECUTE format('INSERT INTO %I.%I SELECT * FROM %I.%I',
                           ziel, tabelle, quelle, tabelle);
            RAISE NOTICE 'Tabelle % verarbeitet', tabelle;
        EXCEPTION WHEN OTHERS THEN
            RAISE NOTICE '------------ FEHLER bei % --------------', tabelle;
            COMMIT;
        END;
    END LOOP;
END;
$$;
 
ALTER PROCEDURE db.kopie(text, text)
    OWNER TO postgres;

Zusammenfassung

`IMPORT FOREIGN SCHEMA` erlaubt das Einbinden externer Informix-Tabellen als Foreign Tables in PostgreSQL.
Ein vollständiger Import kann auf Wunsch auf einzelne Tabellen beschränkt werden.
Für dauerhafte Nutzung oder Fehlerunabhängigkeit empfiehlt sich die Kopie der Tabellen lokal via PL/pgSQL.
Der Prozess ist einseitig – nur von Informix zu PostgreSQL möglich.

Stichworte

PostgreSQL, Informix, IMPORT FOREIGN SCHEMA, FDW, Foreign Data Wrapper

leap_16_informix_konfig

Anonymous (anonymous@undisclosed.example.com) — 2026-05-03T06:46:46+00:00

Informix unter openSUSE Leap 16.0: fehlende /etc/services und /etc/hosts.equiv

Nach einem Update auf openSUSE Leap 16.0 startet ein Informix-Server, der in der sqlhosts mit einem Servicenamen konfiguriert ist, nicht mehr auf dem erwarteten Port. Zusätzlich werden Client-Verbindungen mit Fehler -956 „Client host or user is not trusted by the server“ abgewiesen, weil /etc/hosts.equiv fehlt.

Ursache

Mit Leap 16.0 hat openSUSE den Weg der Trennung von Distribution-Defaults (/usr/etc) und lokalen Overrides (/etc) konsequent umgesetzt:

  /etc/services ist nur noch eine **leere Dummy-Datei** und soll
  künftig ganz entfallen. Der eigentliche Inhalt liegt jetzt unter
  /usr/etc/services. Das Paket netkit-rsh / rsh-server ist abgelöst durch
  **OpenSSH**. Dadurch werden die klassischen Trust-Dateien /etc/hosts.equiv und /etc/hosts.lpd **nicht mehr automatisch angelegt**.

Quellen:

Auswirkung auf Informix

sqlhosts mit Servicename

Enthält $INFORMIXDIR/etc/sqlhosts einen Servicenamen statt einer Portnummer, z. B.:

ol_azur   onsoctcp   azur.local   sqlexec

… dann löst Informix über getservbyname() gegen /etc/services auf. Unter Leap 16.0 ist diese Datei leer, der Start schlägt mit Meldungen wie

listener-thread: err = -25595: oserr = 0: errstr = ...: Service not found

fehl bzw. der Server bindet nicht auf dem erwarteten Port.

Trusted-Host-Authentifizierung

Informix prüft eingehende Verbindungen standardmäßig gegen eine Trusted-Hosts-Datei:

entweder /etc/hosts.equiv
oder die in onconfig über REMOTE_SERVER_CFG konfigurierte Datei
sowie ~/.rhosts des Zielusers

Fehlt /etc/hosts.equiv komplett, meldet der Client:

-908  Attempt to connect to database server (...) failed.
-956  Client host or user (...) is not trusted by the server.

Siehe: IBM Docs – Trusted-host information

Lösungen

A: Portnummer direkt in sqlhosts

Am robustesten: den Servicenamen durch die numerische Portnummer ersetzen. Damit entfällt die Abhängigkeit von /etc/services vollständig.

ol_azur   onsoctcp   azur.local   9088

Variante B: /etc/services wiederherstellen

Eintrag für Informix manuell ergänzen (auf Server und Client):

sqlexec       9088/tcp
sqlexec-ssl   9089/tcp

Wahlweise als Override in /etc/services (wird gegenüber /usr/etc/services vorgezogen) oder als Drop-in.

IANA-konforme Ports: 9088/tcp (sqlexec), 9089/tcp (sqlexec-ssl).
Siehe: IANA standard service names in sqlhosts.std

hosts.equiv wiederherstellen

Datei /etc/hosts.equiv mit den vertrauenswürdigen Hosts neu anlegen:

# hostname        user
client1.local     informix
client1           informix
10.0.0.15         informix

Zwingende Voraussetzungen (laut IBM Docs):

Besitzer: informix:informix
Rechte: 0644, 0640, 0444 oder 0440
Sowohl Kurzname als auch FQDN eintragen, um DNS-Probleme zu vermeiden.

touch /etc/hosts.equiv
chown informix:informix /etc/hosts.equiv
chmod 0644 /etc/hosts.equiv

Variante empfohlen: REMOTE_SERVER_CFG nutzen

Seit Informix 11.70 kann die Trusted-Hosts-Datei über die onconfig umgelenkt werden – damit ist kein Root-Zugriff auf /etc/hosts.equiv nötig und das Problem ist zukunftssicher gelöst:

In $INFORMIXDIR/etc/onconfig:

REMOTE_SERVER_CFG  trusted_hosts.cfg

Dann Datei $INFORMIXDIR/etc/trusted_hosts.cfg mit den erlaubten Hosts füllen. Änderungen lassen sich im laufenden Betrieb übernehmen:

onmode -wf REMOTE_SERVER_CFG=trusted_hosts.cfg

Quelle: XTIVIA – Informix Trusted Client Connections

Prüfbefehle

# Existiert /etc/services und hat es Inhalt?
ls -l /etc/services /usr/etc/services
getent services sqlexec
 
# Kann Informix den Servicenamen auflösen?
su - informix -c "getent services sqlexec"
 
# Trusted-Host-Datei prüfen
ls -l /etc/hosts.equiv $INFORMIXDIR/etc/hosts.equiv 2>/dev/null
onstat -g cfg | grep REMOTE_SERVER_CFG

Zusammenfassung

Leap 16.0 liefert /etc/services nur noch als Dummy aus – echter

Inhalt liegt in /usr/etc/services.

/etc/hosts.equiv fehlt, da rsh durch OpenSSH ersetzt wurde.
Informix bricht deshalb mit Servicename-basierter sqlhosts und

bei Trusted-Connections (Fehler -956) nach dem Update.

Schnellste Lösung: Portnummer direkt in sqlhosts verwenden, /etc/hosts.equiv wiederherstellen oder auf REMOTE_SERVER_CFG umstellen.

Weiterführende Quellen

Stichworte

Informix, openSUSE Leap 16, sqlhosts, /etc/services, hosts.equiv, REMOTE_SERVER_CFG, Fehler -956, Trusted Host

onconfig_memory

Anonymous (anonymous@undisclosed.example.com) — 2026-10-08T08:17:03+00:00

Informix-Speicher mit onconfig_memory.py

Notiz zum Skript onconfig_memory.py. Es setzt die Speicherzeilen einer Informix-onconfig aus dem RAM des Hosts, legt die Bufferpools fest und schaltet die HugePage-Reservierung aus.

Die onconfig wird erst nach einem Neustart von Informix gelesen. Die Sysctl-Änderung gilt sofort, soweit der Kernel HugePages freigeben kann.

Aufruf

sudo python3 onconfig_memory.py [RAM_GB] [ONCONFIG]
python3 onconfig_memory.py --self-check

RAM_GB ist optional und muss eine ganze Zahl ohne Einheit sein. 32 wird als 32 GiB gelesen und intern in Kibibyte umgerechnet (32 GiB = 33554432 KiB). 32.5, 32GB oder ein negativer Wert gelten nicht als Zahl. Dann nimmt das Skript MemTotal aus /proc/meminfo. Diese Angabe steht im Kernel bereits in Kibibyte.

ONCONFIG ist optional. Standard ist /opt/IBM/informix/etc/onconfig.local. Die Argumente stehen fest: zuerst RAM, danach der Pfad.

–self-check darf an beliebiger Stelle der Argumente stehen. Dann prüft das Skript nur die Formel für 8 GiB und 64 GiB, druckt self-check ok und beendet sich mit Exit 0. Es wird keine Datei angefasst.

Unter 4 GiB RAM endet der Lauf mit Exit 1, bevor etwas geschrieben wird. Genau 4 GiB läuft durch. Der Benutzer informix muss existieren (id -g informix). Fehlt er, bricht Python ab, ebenfalls bevor etwas geschrieben wird. Root-Rechte, Schreibrechte und ob Informix online ist, prüft das Skript nicht. Es gibt keinen Probelauf.

Rechnung

Alle Teilungen runden ab. Für ein ganzes GiB-Vielfaches sind die Anteile exakt.

Anteil	Rechnung aus dem RAM
2K-Pool	40/64, also 62,5 %
16K-Pool	10/64, also 15,625 %
erstes virtuelles Segment	4/64, also 6,25 %
Summe	54/64, also 84,375 %

Der Rest von 10/64 bleibt für das Betriebssystem, den Overhead im Resident-Segment und für später nachgelegte virtuelle Segmente. Diesen Rest reserviert das Skript nicht.

Die Poolgrößen stehen in der onconfig in Megabyte, SHMVIRTSIZE in Kilobyte. Kontrolle, dieselben Werte wie im Self-Check:

RAM	2K-Pool	16K-Pool	SHMVIRTSIZE
8 GiB	5120 MB	1280 MB	524288 KB
64 GiB	40960 MB	10240 MB	4194304 KB

Bei 4 GiB sind es 2560 MB, 640 MB und 262144 KB. Die drei Größen zusammen bleiben unter dem RAM.

SHMADD ist fest 256000 KB, EXTSHMADD fest 8192 KB. Beides hängt nicht vom RAM ab.

Was in die onconfig geschrieben wird

Vorher liegt eine bytegenaue Kopie neben der Datei: onconfig.bak_YYYYMMDD_HHMMSS. Zwei Läufe in derselben Sekunde treffen denselben Namen. Die zweite Kopie enthält dann schon die erste Änderung.

Bestehende Zeilen SHMVSIZE mit Wert werden auskommentiert. Alle Zeilen, die am Zeilenanfang mit BUFFERPOOL beginnen, werden auskommentiert. Danach setzt oder ergänzt das Skript:

SHMTOTAL 0
SHMADD 256000
EXTSHMADD 8192
RESIDENT 1
SHMVIRTSIZE <Kilobyte aus 4/64 des RAM>
SHMVIRT_ALLOCSEG 0,3
BUFFERPOOL size=2K,extendable=0,start_memory=<MB>MB,memory=<MB>MB
BUFFERPOOL size=16K,extendable=0,start_memory=<MB>MB,memory=<MB>MB

start_memory und memory sind gleich. extendable=0 lässt die Pools nicht wachsen. lrus, lru_min_dirty, lru_max_dirty und buffers schreibt das Skript nicht.

Ein zweiter Lauf kommentiert die zuvor geschriebenen Poolzeilen und hängt ein neues Paar an. Die alten Zeilen bleiben als Kommentar in der Datei.

Ersetzt wird nur die erste Zeile eines Parameters, die am Zeilenanfang steht. Eine eingerückte Zeile bleibt stehen, das Skript hängt eine zweite Zeile an. Informix würde dann beide sehen.

Dateien am Betriebssystem

Erst nach dem Schreiben der onconfig. Scheitert ein späterer Schritt, ist die onconfig schon neu.

/etc/security/limits.d/99-informix-memlock.conf wird vollständig ersetzt. Inhalt nur noch informix soft memlock unlimited und informix hard memlock unlimited. Vorhandene andere Limits in dieser Datei sind danach weg.
In /etc/profile.d/profile.local.sh wird export IFX_LARGE_PAGES=0 gesetzt oder angehängt. Fehlt die Datei, wird sie nicht angelegt und die Variable bleibt dort ungesetzt.
/etc/sysctl.d/99-informix-hugepages.conf wird vollständig ersetzt durch vm.nr_hugepages = 0 und vm.hugetlb_shm_group mit der GID von informix. Anschließend lädt sysctl -p diese Datei. Den Rückgabewert wertet das Skript nicht aus.

Bleibt HugePages_Total danach größer als 0, gibt es einen Hinweis auf der Konsole und der Lauf endet trotzdem erfolgreich. Belegte HugePages gibt der Kernel nicht frei, solange Informix sie hält. Das Skript leert keinen Cache und fährt Informix nicht herunter.

Abschlusszeile für den Start:

export IFX_LARGE_PAGES=0
ulimit -l unlimited
oninit

memlock aus der Limits-Datei gilt für neue Anmeldungen. Ein bereits laufender oninit bekommt sie nicht. ulimit -l muss in der Startumgebung stehen.

Wirkung und verbleibender OOM

SHMTOTAL 0 ist der Herstellerstandard: keine Obergrenze für Resident-, Virtual-, Communication- und Extension-Anteile.

RESIDENT 1 hält das Resident-Segment im RAM. Darin liegen die Bufferpools. Dafür braucht oninit memlock.

SHMVIRTSIZE ist das erste virtuelle Segment beim Start. Weitere Segmente legt Informix in der Größe SHMADD bzw. EXTSHMADD an.

SHMVIRT_ALLOCSEG 0,3 ist die Vorgabe aus onconfig.std. Die 0 bedeutet laut IBM: der Server legt ein Shared-Memory-Segment an, wenn er es braucht. Ein Wert von 0,40 bis 0,99 wäre ein Füllgrad für eine vorausschauende Anlage, ein Wert von 256 bis 10000000 eine Restmenge in Kilobyte. Die 3 ist nur die Alarmstufe, wenn die Anlage scheitert (Klasse 24, Ereignis 24003). Der Alarm wiederholt sich alle 30 Minuten. Einen onconfig-Wert, der diese Bedarfsanlage abschaltet, gibt es nicht.

Zusammen mit SHMTOTAL 0 hat die Bedarfsanlage keine Informix-Decke. Jedes weitere Segment vergrößert den virtuellen Anteil um 256000 KB bzw. 8192 KB, solange das Betriebssystem den Speicher gibt. Ist der RAM aufgebraucht, kann der OOM-Killer oninit beenden. RESIDENT 1 verschärft das, weil die Bufferpools nicht ausgelagert werden können.

Auch eine nachträglich gesetzte SHMTOTAL-Decke schließt den Pfad nicht. Page Cleaner und Checkpoint dürfen sie überschreiten. Das steckt im Server. Schlägt die Anlage fehl, steht im Nachrichtenlog unter anderem No memory available for page cleaners, und die verursachenden Transaktionen werden zurückgesetzt. Fehlt dann Betriebssystemspeicher, bleibt der OOM-Killer möglich.

IBM Informix 12.10: SHMVIRT_ALLOCSEG. Dieselbe Beschreibung bei HCL: SHMVIRT_ALLOCSEG und Shared-memory size.

Prüfung

grep -E '^(SHMTOTAL|SHMADD|EXTSHMADD|RESIDENT|SHMVIRTSIZE|SHMVIRT_ALLOCSEG|BUFFERPOOL)' \
  /opt/IBM/informix/etc/onconfig.local
grep -E '^(MemTotal|HugePages_Total):' /proc/meminfo
onstat -g seg

Nach dem Neustart trägt das Resident-Segment die beiden festen Pools. Das erste virtuelle Segment hat die Größe von SHMVIRTSIZE. Jedes weitere virtuelle Segment in onstat -g seg ist die Bedarfsanlage und der Weg in den OOM.

Stichworte

Informix, onconfig, SHMTOTAL, SHMADD, EXTSHMADD, SHMVIRTSIZE, SHMVIRT_ALLOCSEG, BUFFERPOOL, RESIDENT, memlock, HugePages, OOM