dynaDAT | UNIXoni | REDATEK | ITVeteran

chunks_pages - [Beispiel 2 GiB]

Thomas Schilling (admin@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

onconfig_memory - [Informix-Memory-Konfiguration mit HugePages]

Thomas Schilling (admin@undisclosed.example.com) — 2026-09-23T08:53:44+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

mail - [3. Testen des E-Mail-Versands]

Thomas Schilling (admin@undisclosed.example.com) — 2026-07-30T11:26:38+00:00

Konfiguration und Test von E-Mails im SAP NetWeaver System

1. Allgemeine Vorbereitung

Transaktion SICF: Aktivierung des ICF-Service `/sap/bc/mail` zur Nutzung des SAPconnect.
- Navigiere zu `SICF` und suche den Service `/sap/bc/mail`.
- Rechtsklick auf den Service und wähle „Aktivieren“.
- Stelle sicher, dass der Service im Status „Aktiv“ ist.
Transaktion SMICM: Überprüfung und Konfiguration des Internet Communication Manager (ICM), um sicherzustellen, dass der SMTP-Server ordnungsgemäß konfiguriert ist.
- Im Menü `Goto → Services` überprüfen, ob der SMTP-Server aktiv ist.
- Falls nicht aktiv, über das Menü `Administration → ICM → Restart` den ICM neu starten.

2. Konfiguration des SAPconnect

Transaktion SCOT: Zentrale Konfiguration für ausgehende E-Mails.
- Erstelle einen neuen SMTP-Node:
  - Navigiere zu `Node for Internet Mail` und erstelle einen neuen Node mit `SMTP`.
  - Konfiguriere den Hostnamen und den Port deines Mailservers.
  - Optional: Füge Authentifizierungsdaten hinzu, wenn der SMTP-Server diese erfordert.
- Konfiguriere die Zeitpläne:
  - Gehe zu `Send Jobs` und lege Zeitpläne für den Versand von E-Mails fest.
  - Stelle sicher, dass mindestens ein Zeitplan aktiv ist, um den automatischen Versand zu gewährleisten.
- Definiere Empfängerregeln:
  - In den Node-Einstellungen kannst du spezifische Empfängerregeln hinzufügen, um zu steuern, welche E-Mails über welchen Weg gesendet werden.
E-Mail-Adressen: Stelle sicher, dass im Benutzerstamm (Transaktion SU01) eine gültige E-Mail-Adresse hinterlegt ist.
- Bearbeite den Benutzer in `SU01` und gib eine gültige E-Mail-Adresse im Reiter „E-Mail“ ein.

3. Testen des E-Mail-Versands

Transaktion SOST: Überwachung des E-Mail-Versands.
- In `SOST` werden alle ausgehenden E-Mails angezeigt.
- SOST WORKFLOW TRACE ist sehr hilfreich bei Problemen!
- Prüfe den Status der E-Mails: `Waiting`, `Error`, `Sent`, etc.
- Bei Fehlern: Klicke auf den Eintrag, um Details und Fehlermeldungen einzusehen.
Transaktion SOIN: Prüfen eingehender E-Mails.
- In `SOIN` ¹⁾ werden alle eingehenden E-Mails angezeigt, die im System verarbeitet werden sollen.
- Falls eingehende E-Mails verarbeitet werden sollen, muss der entsprechende Node in SCOT konfiguriert sein.

4. Troubleshooting

Überprüfe Protokolle in SOST bei Problemen.
- Achte auf häufige Fehler wie falsche SMTP-Konfiguration, fehlende Authentifizierung oder Netzwerkprobleme.
Sicherstellen, dass der ICM korrekt läuft und die SMTP-Verbindung besteht (Transaktion SMICM).
- Prüfe, ob der SMTP-Dienst aktiv ist, und verwende den Befehl `telnet <SMTP-Server> <Port>`, um die Verbindung zu testen.
Transaktion SCOT: Prüfe, ob der Node korrekt konfiguriert ist und ob die Verbindung zum Mailserver funktioniert.

Stichworte

SAP, NetWeaver, SMTP, SCOT, SICF, SMICM, SOST, SU01, ICM

¹⁾

SOADM

leap_16_informix_konfig

Thomas Schilling (admin@undisclosed.example.com) — 2026-04-18T18:55:53+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

xfs_error_kernel

Thomas Schilling (admin@undisclosed.example.com) — 2025-08-04T15:23:38+00:00

XFS Fehler nach Kernel-Update

Fehlerbeschreibung

Nach einem Update auf folgenden Kernel:

Linux 4.18.0-553.58.1.el8_10.x86_64

trat beim Booten bzw. Mounten des XFS-Dateisystems folgender Fehler auf:

`kernel: XFS (dm-0): Corruption detected. Unmount and run xfs_repair`
`kernel: XFS (dm-0): Internal error i != 1 at line 481 of file fs/xfs/libxfs/xfs_alloc.c. Caller xfs_alloc_fixup_trees+0x198/0x3b0 [xfs]`

Änderungen an Kernel-Konfiguration

In der Datei `config-4.18.0-553.58.1.el8_10.x86_64` wurden folgende Optionen aktiviert:

CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
CONFIG_XFS_ONLINE_SCRUB=y

Analyse & Hintergrundwissen

Fehlerursache: Der Fehler `i != 1` in `xfs_alloc.c` deutet auf eine Inkonsistenz in den freien Speicherbaumstrukturen des Dateisystems hin. Dies kann durch eine beschädigte Metastruktur oder durch eine fehlerhafte Kernel-Implementierung ausgelöst werden.
xfs_repair: Das Tool `xfs_repair` sollte verwendet werden, um die Dateisystemstruktur zu prüfen und zu reparieren. Wichtig: Das Dateisystem muss vorher ausgehängt werden.
CONFIG_XFS_RT: Aktiviert Unterstützung für „Real-Time Subvolumes“, eine selten genutzte Funktion. Falls nicht benötigt, kann sie deaktiviert werden, um Komplexität zu reduzieren.
CONFIG_XFS_ONLINE_SCRUB: Ermöglicht die Online-Prüfung von Dateisystemstrukturen. Diese Funktion ist experimentell und kann bei bestimmten Kernel-Versionen instabil sein.
Kernel-Kompatibilität: Änderungen an XFS-bezogenen Optionen können zu Inkompatibilitäten mit bestehenden Dateisystemen führen, insbesondere wenn das Dateisystem mit einem älteren Kernel erstellt wurde.

Empfehlung

System im Rescue-Modus starten.
betroffene Partition aushängen (`umount /dev/dm-0`)
`xfs_repair /dev/dm-0` ausführen.
Bei wiederholtem Auftreten: Kernel-Konfiguration prüfen, insbesondere experimentelle Optionen wie `CONFIG_XFS_RT` und `CONFIG_XFS_ONLINE_SCRUB`.
Backup wichtiger Daten vor weiteren Tests!

In meinem konkreten Fall war das root Filesystem betroffen und ich bin das Risiko, ohne xfs_repair auf ausgegangenem Device, mit geänderter Konfiguration neu zu starten, eingegangen.

Quellen & Tools

`man xfs_repair`
https://xfs.org
Kernel-Quellcode: `fs/xfs/libxfs/xfs_alloc.c`

Stichworte

XFS, Kernel, RHEL, EL8, xfs_repair, Filesystem, Korruption, CONFIG_XFS_RT, Rescue

statistik_und_audit

Thomas Schilling (admin@undisclosed.example.com) — 2025-07-18T13:33:04+00:00

PostgreSQL DDL-Audit Setup

Dieses Setup dokumentiert alle strukturverändernden Aktionen (DDL) in PostgreSQL, wie z. B. CREATE TABLE, ALTER FUNCTION, DROP INDEX usw. Die Änderungen werden automatisch in einer zentralen Audit-Tabelle gespeichert und sind über ein Dashboard oder View auswertbar.

Verwandter Artikel: Tabellen, Trigger-Funktionen, Event Trigger und Wartung (DISABLE/ENABLE) sind in PostgreSQL DDL Audit Logging beschrieben (Referenzimplementierung).

Ziel

* Nachvollziehbare Dokumentation aller DDL-Änderungen * Speicherung in einer zentralen Tabelle im Schema public * Unterstützung für CREATE, ALTER, DROP und verwandte Befehle * Trennung von Schema und Objektname für bessere Auswertbarkeit * Minimale Belastung für produktive Systeme

Komponenten

* Audit-Tabelle: Speicherung der DDL-Ereignisse * Event Trigger: Reaktion auf DDL-Befehle * Trigger-Prozeduren: Extrahieren der Metadaten aus Systemfunktionen * Optional: pg_stat_statements: Ergänzende Erfassung von DDL-Texten

Schritt 1: Audit-Tabelle erstellen

CREATE TABLE public.ddl_audit_log (
id SERIAL PRIMARY KEY,
command_tag TEXT,             -- z. B. CREATE TABLE, DROP FUNCTION
object_type TEXT,             -- z. B. TABLE, FUNCTION, INDEX
schema_name TEXT,             -- z. B. public
object_name TEXT,             -- z. B. users
executed_by TEXT DEFAULT CURRENT_USER,
executed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Schritt 2: Prozedur für CREATE/ALTER

CREATE OR REPLACE FUNCTION public.log_ddl_command()
RETURNS event_trigger
LANGUAGE plpgsql
AS $$
DECLARE
ddl_record RECORD;
BEGIN
FOR ddl_record IN SELECT * FROM pg_event_trigger_ddl_commands()
LOOP
INSERT INTO public.ddl_audit_log (
command_tag,
object_type,
schema_name,
object_name,
executed_by
)
VALUES (
ddl_record.command_tag,
ddl_record.object_type,
split_part(ddl_record.object_identity, '.', 1),
split_part(ddl_record.object_identity, '.', 2),
CURRENT_USER
);
END LOOP;
END;
$$;

Schritt 3: Event Trigger für CREATE/ALTER

CREATE EVENT TRIGGER ddl_audit_trigger
ON ddl_command_end
EXECUTE FUNCTION public.log_ddl_command();

Schritt 4: Prozedur für DROP-Aktionen

CREATE OR REPLACE FUNCTION public.log_ddl_drop()
RETURNS event_trigger
LANGUAGE plpgsql
AS $$
DECLARE
obj RECORD;
BEGIN
FOR obj IN SELECT * FROM pg_event_trigger_dropped_objects()
LOOP
INSERT INTO public.ddl_audit_log (
command_tag,
object_type,
schema_name,
object_name,
executed_by
)
VALUES (
'DROP',
obj.object_type,
split_part(obj.object_identity, '.', 1),
split_part(obj.object_identity, '.', 2),
CURRENT_USER
);
END LOOP;
END;
$$;

Schritt 5: Event Trigger für DROP-Aktionen

CREATE EVENT TRIGGER ddl_drop_audit_trigger
ON sql_drop
EXECUTE FUNCTION public.log_ddl_drop();

Wartung: Trigger aktivieren/deaktivieren

Befehle und Erläuterung: PostgreSQL DDL Audit Logging — Abschnitt Wartung: Trigger aktivieren/deaktivieren.

Beispiel: DDL-Aktion und Auswertung

\-- Beispielaktion
CREATE TABLE public.audit_test (
id SERIAL PRIMARY KEY,
name TEXT
);
 
DROP TABLE public.audit_test;
 
\-- Auswertung
SELECT * FROM public.ddl_audit_log ORDER BY executed_at DESC;

Optional: View für Dashboard

CREATE VIEW public.ddl_audit_summary AS
SELECT
executed_at::DATE AS datum,
schema_name,
object_name,
command_tag,
object_type,
executed_by
FROM public.ddl_audit_log
ORDER BY executed_at DESC;

Erweiterung: pg_stat_statements

Die PostgreSQL-Erweiterung pg_stat_statements kann ergänzend verwendet werden, um vollständige DDL-Befehle (inkl. Spaltennamen) zu erfassen, die über Event Trigger nicht verfügbar sind.

SELECT query, calls, userid, dbid, queryid, total_time
FROM pg_stat_statements
WHERE query LIKE 'ALTER TABLE%'
AND query \~\* 'ADD COLUMN|DROP COLUMN|RENAME COLUMN'
ORDER BY total_time DESC;

oder eben selektiv mit lesbarem User und Datenbanknamen:

SELECT a.rolname,b.datname,c.query
FROM public.pg_stat_statements c, pg_roles a, pg_database b
WHERE a.oid = c.userid AND b.oid = c.dbid
AND c.query LIKE 'ALTER%';

Hinweis:

* Die Erweiterung speichert normierte SQL-Befehle * Die Statistik wird nicht sofort aktualisiert * Für produktive Systeme mit hoher Last kann die Kombination mit Event Triggern zu Performance-Einbußen führen

Hinweise

* Die Spalte ddl wurde entfernt, da der Typ pg_ddl_command nicht direkt gespeichert werden kann. * Spaltenänderungen (z. B. ADD COLUMN) enthalten keine Spaltennamen über Event Trigger. * Die Lösung ist leichtgewichtig und für produktive Systeme geeignet. * DDL-Audit vorübergehend aus: PostgreSQL DDL Audit Logging, Abschnitt Wartung: Trigger aktivieren/deaktivieren (ALTER EVENT TRIGGER … DISABLE / ENABLE). * Event Trigger und Tabellen-Trigger sind verschiedene Mechanismen — siehe folgender Unterabschnitt.

Event Trigger versus Tabellen-Trigger

Aspekt	Event Trigger (dieses DDL-Audit)	Tabellen-Trigger
Zweck	Reaktion auf DDL (`CREATE TABLE`, `DROP`, …) auf Datenbankebene	Reaktion auf Datenänderungen in einer Tabelle: `INSERT` / `UPDATE` / `DELETE`, oft `FOR EACH ROW`
Anlage	`CREATE EVENT TRIGGER …`	`CREATE TRIGGER … ON eine_tabelle …`
Abschalten (Beispiel)	`ALTER EVENT TRIGGER … DISABLE` / `… ENABLE`	z. B. `ALTER TABLE … DISABLE TRIGGER …`

Zum vorübergehenden Abschalten dieses DDL-Audits werden nur Event Trigger mit ALTER EVENT TRIGGER … gesteuert. ALTER TABLE … DISABLE TRIGGER … betrifft Tabellen-Trigger auf einer konkreten Tabelle und hat mit diesem DDL-Protokoll nichts zu tun.

Erweiterungen möglich

* Filterung nach Objektarten oder Benutzer * Integration mit Git zur Versionskontrolle * Visualisierung der Änderungen über Dashboards * Benachrichtigung bei kritischen Änderungen (z. B. DROP TABLE)

Bemerkung

Für mich ist das Standard Vorgehen meist unbrauchbar, da pg_stat_statements wie auch pgaudit nicht das Objekt selbst aufzeichnet. Ich schreibe meine eigene Triggerfunction — dokumentiert in PostgreSQL DDL Audit Logging.

Stichworte

PostgreSQL, DDL, Audit, Event Trigger, pg_stat_statements, Dashboard

informix_fdw - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2025-06-20T13:19:10+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

informix_rowid - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2025-06-17T12:23:25+00:00

Nutzung der rowid in SQL Statements

Die Verwendung der `rowid` in SQL-Statements sollte mit Vorsicht erfolgen und nach Möglichkeit vermieden werden. Dies gilt insbesondere im Kontext von Datenbankmigrationen oder bei der Verwendung von Datenbank-Wrapping-Technologien wie z.B. dem Informix-Wrapper für PostgreSQL.

Laut IBM-Dokumentation wird empfohlen, sich nicht auf `rowid` zu verlassen, da sie systemabhängig ist und sich unter bestimmten Umständen ändern kann. (vgl. https://www.ibm.com/docs/de/informix-servers/12.10.0?topic=statements-rowid-values-in-select)

In Informix ist `rowid` ein Integer-Wert. In PostgreSQL gibt es kein direktes Äquivalent, aber es existiert die systeminterne Spalte `ctid`, die eine ähnliche Funktion übernimmt. (vgl. https://www.enterprisedb.com/postgres-tutorials/what-equivalent-rowid-postgresql?lang=en und https://www.postgresql.org/docs/current/ddl-system-columns.html)

Unterschiede zwischen Informix rowid und PostgreSQL ctid

Der Informix-Wrapper leitet die `rowid` grundsätzlich an die PostgreSQL-`ctid` weiter. Dabei gibt es jedoch wichtige technische Unterschiede:

`rowid` in Informix ist ein einfacher Integer.
`ctid` in PostgreSQL ist ein Tupel bestehend aus (page_number, tuple_index).
Der Informix-Wrapper setzt `rowid` auf den ersten Wert von `ctid`, also ergibt sich die übergebene Form: `ctid = (rowid, 0)`.

Technische Eigenschaften der ctid in PostgreSQL

`ctid` ändert sich bei jeder UPDATE-Operation.
Wird durch VACUUM FULL neu zugewiesen.
Kann nach VACUUM ANALYZE wiederverwendet werden.
Ist systemintern und nicht als dauerhaft eindeutiger Schlüssel geeignet.

Beste Praktiken

Statt `rowid` oder `ctid` zu verwenden, sollten möglichst logische Identifikatoren eingesetzt werden. Empfohlene Alternativen:

Primärschlüssel nutzen (z.B. durch `SERIAL` oder `BIGSERIAL` erzeugt).
Aufbau geeigneter Indexstrukturen zur Performanceoptimierung.
Logische Referenzen statt physischer Adressen (z.B. Foreign Keys auf Primärschlüssel).
Anpassung der Anwendung, um auf `rowid`/`ctid` zu verzichten.

Mögliche Lösungen bei Migration oder Wrapper-Nutzung

Wenn eine bestehende Anwendung auf `rowid` angewiesen ist, gibt es folgende Workarounds:

Anlage einer eigenen physischen Spalte `rowid` vom Typ `BIGSERIAL` in der PostgreSQL-Zielstruktur.
Aufbau eines dedizierten Index zur effizienten Suche.
Anpassung der SQL-Statements in der Anwendung, um die neue Struktur zu unterstützen.

Hinweis: Die Verwendung von `ctid` als langfristiger Zeilenidentifikator sollte vermieden werden, da er sich durch normale Datenbankoperationen wie `UPDATE`, `VACUUM`, etc. verändern kann und somit nicht stabil ist.

Fazit

Die `rowid` bzw. `ctid` sind für temporäre oder systeminterne Zwecke nützlich, sollten jedoch nicht als zuverlässige Referenz in langlebigen Anwendungen oder Datenmodellen verwendet werden. Stattdessen ist auf Primärschlüssel-basierte Logik umzusteigen.

Stichworte

Informix, PostgreSQL, rowid, ctid, FDW, Migration, Primärschlüssel

dokuwiki

Thomas Schilling (admin@undisclosed.example.com) — 2025-06-08T14:17:04+00:00

DokuWiki

DokuWiki is a simple to use and highly versatile Open Source wiki software that doesn't require a database. It is loved by users for its clean and readable syntax. The ease of maintenance, backup and integration makes it an administrator's favorite. Built in access controls and authentication connectors make DokuWiki especially useful in the enterprise context and the large number of plugins contributed by its vibrant community allow for a broad range of use cases beyond a traditional wiki.

Read the DokuWiki Manual to unleash the full power of DokuWiki.

Download

DokuWiki is available at https://download.dokuwiki.org/

All documentation and additional information besides the syntax description is maintained in the DokuWiki at www.dokuwiki.org.

About DokuWiki

Installing DokuWiki

Using DokuWiki

Customizing DokuWiki

DokuWiki Feedback and Community

Copyright

The DokuWiki engine is licensed under GNU General Public License Version 2. If you use DokuWiki in your company, consider donating a few bucks .

Not sure what this means? See the FAQ on the Licenses.

Stichworte

DokuWiki, Wiki, Wiki-Syntax, Dokumentation, Open Source, Installation, Konfiguration, Plugins, ACL, Authentifizierung, Backups

²⁾

Please do not contact me for help and support – use the mailinglist or forum instead

enterpriselogorahmen2.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T07:35:35+00:00

favicon.ico - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T06:50:21+00:00

logo.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T06:50:21+00:00

vt52.jpg - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T05:59:40+00:00

gfud.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T05:59:40+00:00

banner.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T05:59:40+00:00

itveteran.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T05:59:40+00:00

bdrthomas-336x400-1.jpg - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-21T13:34:38+00:00

ksnip_20240821-144545.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-21T12:58:45+00:00

ksnip_20240821-144826.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-21T12:58:12+00:00

dynaDAT | UNIXoni | REDATEK | ITVeteran

chunks_pages - [Beispiel 2 GiB]

Chunk-Länge und Blob-Page

Regel

Beispiel 2 GiB

datadbs

Prüfen

Was davon bleibt

IBM

Stichworte

onconfig_memory - [Informix-Memory-Konfiguration mit HugePages]

Informix-Speicher mit onconfig_memory.py

Aufruf

Rechnung

Was in die onconfig geschrieben wird

Dateien am Betriebssystem

Wirkung und verbleibender OOM

Prüfung

Stichworte

mail - [3. Testen des E-Mail-Versands]

Konfiguration und Test von E-Mails im SAP NetWeaver System

1. Allgemeine Vorbereitung

2. Konfiguration des SAPconnect

3. Testen des E-Mail-Versands

4. Troubleshooting

Stichworte

leap_16_informix_konfig

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

Ursache

Auswirkung auf Informix

sqlhosts mit Servicename

Trusted-Host-Authentifizierung

Lösungen

A: Portnummer direkt in sqlhosts

Variante B: /etc/services wiederherstellen

hosts.equiv wiederherstellen

Variante empfohlen: REMOTE_SERVER_CFG nutzen

Prüfbefehle

Zusammenfassung

Weiterführende Quellen

Stichworte

xfs_error_kernel

XFS Fehler nach Kernel-Update

Fehlerbeschreibung

Änderungen an Kernel-Konfiguration

Analyse & Hintergrundwissen

Empfehlung

Quellen & Tools

Stichworte

statistik_und_audit

PostgreSQL DDL-Audit Setup

Ziel

Komponenten

Schritt 1: Audit-Tabelle erstellen

Schritt 2: Prozedur für CREATE/ALTER

Schritt 3: Event Trigger für CREATE/ALTER

Schritt 4: Prozedur für DROP-Aktionen

Schritt 5: Event Trigger für DROP-Aktionen

Wartung: Trigger aktivieren/deaktivieren

Beispiel: DDL-Aktion und Auswertung

Optional: View für Dashboard

Erweiterung: pg_stat_statements

Hinweise

Event Trigger versus Tabellen-Trigger

Erweiterungen möglich

Bemerkung

Stichworte

informix_fdw - angelegt

IMPORT FOREIGN SCHEMA von Informix nach PostgreSQL

Vorbereitung

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

LIMITIERTER IMPORT (z. B. nur eine Tabelle)

Wichtiger Hinweis zur Richtung des Imports

Kopieren der Tabellen lokal in PostgreSQL (struktur+daten)

Zusammenfassung

Stichworte

informix_rowid - angelegt

Nutzung der rowid in SQL Statements

Unterschiede zwischen Informix rowid und PostgreSQL ctid

Technische Eigenschaften der ctid in PostgreSQL

LIMITIERTER IMPORT (z. B. nur eine Tabelle)