| INFORMIX® Q&A (1) |
WICHTIG! Die Antworten und Programme wurden nach bestem Wissen und Gewissen erstellt. Der Autor übernimmt keine Gewährleistung dafür, dass alle Tipps und Tricks einwandfrei funktionieren. Die Anwender handeln auf eigene Gefahr. Bei eventuellen Datenverlusten oder Beschädigungen besteht kein Haftungsrecht gegenüber dem Autor. Die Antworten und Programme sind frei anwendbar, jedoch verbleibt das Copyright beim Autor. Bei deren Weitergabe oder Veröffentlichung muss der ursprüngliche Autor als solcher kenntlich gemacht werden. Externe Beiträge sind jederzeit willkommen.
- Welche INFORMIX-Umgebungsvariablen sind unter UNIX besonders wichtig?
- Warum funktioniert der "dbimport" und die SQL-Anweisung "SET EXPLAIN ON" nicht?
- Shared Memory lässt sich bei einigen UNIX-Versionen bei ONLINE bis V5.x nicht über ca. 14 MB konfigurieren!
- Probleme mit Jahrtausendwechsel?
- Wie kann ich unter UNIX feststellen, ob eine Raw-Partition defekt ist?
- Ich benötige meine INFORMIX-Raw-Partitions nicht mehr und möchte sie dem UNIX wieder bekannt geben. Was tun?
- Nach dem Umstieg von UnixWare 1.x auf 2.x kann kein Shared Memory mehr für INFORMIX-ONLINE initialisiert werden.
- Nach einer "Long Transaction" und killen des "sqlturbo"-Prozesses unter INFORMIX-ONLINE V4.0 hat sich das ONLINE-System heruntergefahren und lässt sich nicht wieder starten!
- Wo bekomme ich weitere Informationen zu den INFORMIX-Produkten?
- Wie kann eine schnelle Migration von 4GL nach NewEra durchgeführt werden?
1. Welche INFORMIX-Umgebungsvariablen sind unter UNIX (sh, ksh, bash ...) besonders wichtig?
INFORMIX-Verzeichnis (dort wurde INFORMIX installiert, z.B.):
- INFORMIXDIR=/usr/informix; export INFORMIXDIR
- je nach Shell auch mit "setenv..." (csh, tcsh ...)
Pfad der INFORMIX-Programme:
- PATH=$PATH:$INFORMIXDIR/bin; export PATH
Einsatz des Backends:
- SQLEXEC=$INFORMIXDIR/lib/sqlexec (=> SE)
- SQLEXEC=$INFORMIXDIR/lib/sqlturbo (=> ONLINE bis V5.x)
- SQLEXEC=$INFORMIXDIR/lib/sqlrm (=> ONLINE ab V6.x)
- export SQLEXEC
Server:
- INFORMIXSERVER=yourServerName¹; export INFORMIXSERVER
- (¹ s. $INFORMIXDIR/etc/sqlhosts)
Datenbank- und Maskenpfad:
- DBPATH=Datenbankverzeichnis¹:Maskenverzeichnis²; export DBPATH
- (¹ Verzeichnis, in dem sich die "*.dbs" befinden; ² Verzeichnis, in dem sich die "*.frm befinden, kann im aktuellem Verzeichnis weggelassen werden. Beim ONLINE/NET/STAR u.U. Datenbank des Servers)
Nationale Besonderheiten (falls Datenbank nicht entsprechend konvertiert):
- DBFORMAT=":.:,:"; export DBFORMAT # Dezimalformat mit Komma
- DBDATE=DMY4. ; export DBDATE # Datumsformat DD.MM.YYYY
2. Warum funktioniert der "dbimport" und die SQL-Anweisung "SET EXPLAIN ON" nicht?
Die Ursache liegt in der Reihenfolge der INFORMIX-Produkteinstallation. Wichtig ist hierbei, dass zuerst die Frontends wie z.B. INFORMIX-SQL, INFORMIX-4GL, dann die Backends (z.B. SE, ONLINE) und zum Schluss die Netzwerkprodukte (z.B. NET,STAR) installiert werden müssen.
Kernel-Parameter "SVMMLIM" erhöhen (z.B. UnixWare 2.01 auf "0x80000000") bzw. "MAXPMEM" und "MAXUMEM" (SYSVR 3.2)
Ja, liebe Freunde. Hierfür gibt es einerseits die Möglichkeit, ALLE entsprechenden Masken oder Programme auf vierstellige Jahreszahlen umzusetzen oder ab der INFORMIX-Datenbank- Serverversion 7.2 die Variable "DBCENTURY" zu benutzen ("C" = Closest, je nachdem, was näher liegt z.B. "96" bis 2046 gleich 1996, danach 2096; "P" = Past, relativ zum aktuellem Datum rückwärts gerechnet z.B. "96" bis 2095 gleich 1996, danach 2096; "F" = Future, umgekehrt, "96" gleich 2096, danach 2196).
5. Wie kann ich unter UNIX feststellen, ob eine Raw-Partition defekt ist?
Eine einfache Lösung besteht darin, den UNIX-Befehl "dd"
für die jeweilige Partition folgendermaßen anzuwenden:
dd
if=rawdevice of=/dev/null
("rawdevice" ist dann das Characterdevice
wie z.B. "/dev/rdsk/1s7".)
Eine defekte Partition würde zu einem
Fehler des "dd"-Befehls führen.
Vorsicht ist geboten! Soll die Partition tatsächlich "platt"
gemacht werden, so dass dort ALLE Daten verloren gehen? Das versehentliche
Entfernen einer Partition kann im Gesamtzusammenhang des I-ONLINE-Systems genau
jenes komplett lahm legen.
Nun, für die Entschlossenen hier zwei
Alternativen:
1. Der einfache Weg führt über den UNIX-Befehl
"mkfs" (s. Systemdokumentation). Hiermit wird ein neues (UNIX-)Filesystem auf
der Partition neu erzeugt. Ich erlebte jedoch auf einigen UNIX-Plattformen,
dass dieses Vorgehen absolut scheiterte.
2. Deswegen kann man sich mit
folgendem Trick behelfen. Mittels "dd"-Befehl und Wissen einer anderen
vorhanden UNIX-Partition (im Zweifelsfall die "Root-Partition") ist die
INFORMIX-Partition "plattzumachen":
dd if=otherUnixRawPartition
of=InformixRawPartition
("otherUnixRawPartition"=vorhandene
UNIX-Partition, "InformixRawPartition"=INFORMIX-Raw-Partition).
Der
"dd"-Befehl schreibt nun zumindest die notwendigen Informationen (Superblock
etc.) auf unsere Zielpartition. Sicherlich wird der "dd"-Befehl später mit
einer Fehlermeldung abbrechen, da die Partitionen nicht völlig identisch
sein werden. Aber das stört uns nicht weiter und wir können mittels
"mkfs" und "mount" das neue Filessystem erzeugen.
Zunächst weise ich nochmals auf die zu ändernden
Kernel-Parameter SHMSEG (Anzahl möglicher Shared Memory Segmente) und
SHMMAX (Größe eines Segments in Bytes) hin, die ja ohnehin dem
System angepasst werden müssen. Hierbei ist zu bedenken, dass sowohl die
Dateien "/etc/conf/cf.d/mtune" und "/etc/conf/mtune.d/kernel" bzw.
"/etc/conf/mtune.d/ipc" entsprechend den gewünschten Maximalwerten evtl.
noch modifiziert werden müssen, bevor man mittels "idtune"-Befehls die
Parameter hochsetzt.
Beispiel:
cd /etc/conf/bin; idtune SHMMAX
1572864;
Das eigentliche Problem jedoch ist dadurch noch nicht
behoben. Falls man kein INFORMIX-Update für den Release-Wechsel zur
Verfügung hat, bleibt noch die Möglichkeit, die "Shared memory base
address" in der Datei "/usr/informix/etc/tbconfig" (bzw. "onconfig") manuell zu
ändern, z.B. von "0x100000" auf "0xe800000":
#SHMBASE 0x100000 #
Shared memory base address (alten Wert durch "#" auskommentieren!)
SHMBASE
0xe800000 # Shared memory base address (neuer Wert)
Tja, Freunde des Geizes, falls Ihr keinen INFORMIX-Wartungsvertrag
abgeschlossen habt (, welche wohlbemerkt nicht gerade günstig sind,)
bleiben Euch folgende Möglichkeiten offen:
a) System neu
initialisieren und letzte Datensicherung einlesen (habt Ihr ja
regelmäßig durchgeführt, nicht wahr?) oder
b) INFORMIX
kontaktieren und für (sehr) teures Geld per DFÜ-Verbindung an das
System zur Restaurierung lassen.
Mit einem vorhanden Wartungsvertrag
(auf die Art kommt es an!) sollte schleunigst auf eine höhere Version
umgestiegen werden, da der Bug dort nicht mehr auftritt. (Die ehemaligen
Anwender von INFORMIX-TURBO sind ja noch ganz anderes gewohnt...)
9. Wo bekomme ich weitere Informationen zu den INFORMIX-Produkten?
U.a. bei der
10. Wie kann eine schnelle Migration von 4GL nach NewEra durchgeführt werden?
Pustekuchen. Die manuelle schnelle Migration gibt es nicht.
Lediglich nicht-bildschirmorientierter Code ist direkt übernehmbar.
Empfehlenswert meinerseits ist in diesem Fall jedoch die vollständige
Neuprogrammierung, da sonst der objektorientierte Ansatz und Bezug
weitestgehend verloren geht.
Ansonsten bietet INFORMIX mittels eines
Consulting-Programms eine automatische Migration an, was - natürlich -
nicht umsonst angeboten wird.
|
|||||||||
| Letzte Änderung: (Copyright © ) |