2.3.1.2.1 Entladen unter Postgres oder Informix / UNIX
Am einfachsten ist es, wenn Sie als User superx vom SuperX-Server direkt auf den SOS-Datenbankserver zugreifen und entladen können ("Pull"-Verfahren). Dann ist es sogar egal ob Sie SOS unter Informix f. Win., Informix f. Unix oder Postgres einsetzen; außerdem brauchen Sie die Dateien dann nicht vom SOS-Rechner nach SuperX kopieren.
Für Postgres ist dies auch deshalb die einfachste Lösung, weil zum Entladen aus Postgres die Bibliotheken des SuperX-Kernmoduls vorhanden sein müssen.
Für Informix ist auch das Entladen im "Push"-Verfahren möglich: kopieren Sie den gesamten Verzeichnisinhalt ab $SOS_PFAD/rohdaten auf den SOS-Rechner, geben Sie dem Script Ausführungsrechte. Die Scripte laufen nur, wenn die entsprechenden Umgebungsvariablen in der Datei SOS_ENV (im gleichen Verzeichnis, ein Muster liegt vor in SOS_ENV.sam) korrekt gesetzt sind, benennen Sie die Musterdatei um nach SOS_ENV und tragen die richtigen Umge bungsvariablen ein, z.B. den Pfad für $INFORMIXDIR , und das Semester, ab wann Sie entladen wollen ( start_stud_sem bzw. start_pruef_sem ).
|
SOS_ENV |
##Pfad für Entladedaten: SOS_PFAD=. ; export SOS_PFAD ##hier muss Unterverzeichnis unl existieren!
#ab hier werden Daten ausgewertet: start_stud_sem = 19881 #sos-studenten und fächer start_pruef_sem = 19921 #Prüfungen SOS_UNL_COMPLETE=true export SOS_UNL_COMPLETE |
Am besten nehmen Sie für den Testbetrieb nur ein paar Semester, denn wenn Sie weiter in die Vergangenheit zurückgehen, dann laufen die Scripte recht lange.
In der SOS_ENV müssen folgende Umgebungsvariablen gesetzt werden (defaults sind bereits vorbelegt, aber hier und da müssen Sie sicher ran):
|
|
Nur für Informix gelten: |
|
INFORMIXDIR |
Home-Verzeichnis von Informix |
|
INFORMIXSERVER |
Name des Informixservers |
|
ONCONFIG |
Name der onconfig, wenn auf dem SOS-Rechner mehrere Informix-Instanzen laufen |
|
CLIENT_LOCALE |
Sprachumgebung (wichtig fürs Entladen von Datumsformaten) |
|
SERVER_LOCALE |
dito |
|
|
Nur für Postgres gelten: |
|
PGDATESTYLE |
Datumsformat "German" |
|
PGPORT |
Port vom Postgres-Server, standardmäßig 5432 |
|
PGHOST |
Hostname oder IP-Adresse vom Postgres-Server |
|
PGUSER |
Benutzerkennung für Postgres-Server (nur Datenbank, nicht Betriebssystem) |
|
PGPATH |
Installationsverzeichnis von Postgres, z.B. /usr/local/pgsql |
|
DB_PROPERTIES |
Pfad zur db-sos.properties -Datei mit den Zugangsparametern für SOSPOS unter Postgres |
|
LOGGING_PROPERTIES |
Pfad zur Steuerungsdatei mit den Parametern für das Logging beim Entladen, voreingestellt auf ./logging.properties . Normalerweise brauchen Sie hier nichts ändern, wenn beim Entladen Probleme auftauchen, kann man den Level von SEVERE auf INFO oder FINEST ändern, dann werden die konkreten SQLs geloggt. Aber Achtung: wenn keine Fehler mehr auftreten, müssen Sie den Level wieder auf SERVERE ändern, sonst kommen Schlüsselworte in die Logdatei sos_unload.err , die dann bei der Übernahme nach SuperX fälschlicherweise zu Fehlermeldungen führen. |
Unter Postgres muss für das "Pull"-Verfahren beim Entladen die Datenbankverbindung in der Datei db-sos.properties eingetragen werden (Muster für Postgres liegt bei in db- sos_pg.properties ). Dazu laden Sie einmal die Datei SOS_ENV mit den obigen Parameter, starten den SuperX-Propadmin (siehe Administrationshandbuch Kernmodul) und richten die Verbindung zum SOSPOS-Server ein. Das Kennwort wird verschlüsselt gespeichert. Danach sind die Entladescripte für Postgres ausführbar.
Hinweis: Anders als Informix hat Postgres hat eine eigene, vom Basissystem unabhängige Benutzerverwaltung. Daher brauchen Sie den User, den Sie zum Entladen aus Postgres nutzen, nicht auf dem SuperX- oder SOSPOS-Rechner auf Betriebssystem-Ebene einrichten. Sie können also z.B. auf dem SuperX-Rechner zum Entladen aus SOSPOS die Kennung sospos des Postgres- Rechners verwenden. Oder Sie richten in der SOSPOS -Datenbank den Benutzer SuperX ein und geben ihm Leserecht auf die Tabellen sowie das Recht, Tabellen und Stored Procedures anzulegen.
|
|
Für alle Platformen gelten folgende Variablen: |
|
SX_CLIENT |
Entladeprogramm für SOSPOS-DB: dbaccess, psql oder jdbc #unix |
|
ERRORMAIL |
An wen solle eine Logmail verschickt werden, wenn das Entladen nicht geklappt hat? (nur Unix). |
|
LOGMAIL |
An wen soll immer eine Logmail verschickt werden |
|
MAILPROG |
Pfad zum ausführbaren Mailprogramm unter Unix, Vorbelegung ist "mail", manche Unixe haben aber auch "mutt".
|
|
|
Wenn die Rohdaten nach dem Entladen vom SOS-Rechner auf den SuperX-Rechner kopiert werden sollen, dann werden für das Script sos_copy.x folgende Umgebungsvariablen benötigt: |
|
COPY_METHOD |
Programm, das die Dateien kopiert; rsync und scp sind wählbar. |
|
REMOTE_DIR |
Verzeichnis, in das die Rohdaten auf dem SuperX-Rechner kopiert warden sollen, in der Regel ist dies "/home/superx/db/module/sos/rohdaten" |
|
REMOTE_USER |
Der Unix-Username auf dem SuperX-Rechner, in der Regel "superx". |
|
REMOTE_HOST |
Der Rechnername bzw. die IP-Nr. des SuperX-Rechners. |
Nach der Konfiguration muss einmal in der SOS-Datenbank das Script superx_sos_install.x ausgeführt werden, es wird eine Tabelle zur Pseudonymisierung von Matrikelnummern installiert.
Wenn Sie Informix oder Postgres unter Windows benutzen, können Sie das Script nicht ausführen. Setzen Sie stattdessen einmalig das SQL-Kommando ab:
|
Manuelles Anlegen der Pseudonymisierungstabelle |
create table mtknr_ldsg ( mtknr integer, mtknr_ldsg serial ); create unique index i_mtknr_1 on mtknr_ldsg (mtknr);
|
Mehr macht das Script superx_sos_install.x auch nicht.
Wenn "
SOS_UNL_COMPLETE=false
" gesetzt ist, dann muss darüberhinaus in der Datei
superx.datum
der Stichtag des Entladens angegeben werden, d.h. alle Sätze zu Matrikelnummern werden entladen, die in die Protokolltabellen
pprot
,
pro
eingetragen werden und nach dem Stichtag aufgetreten sind.
Defaultmäßig entlädt SuperX danach immer nur die Änderungen. Dies macht es aber erforderlicht, dass das Rohdaten-Verzeichnis auf dem SuperX-Rechner gemounted ist bzw. die Datei superx.datum nach dem Update auf SuperX-Seite regelmäßg rückgeschrieben wird. Wenn nämlich der Update auf SuperX-Seite mit Fehler beendet hat, dann wird das Entladedatum auf das vorherige Datum ( superx.datum.alt ) zurückgesetzt, damit beim nächsten Entladen die Sätze erneut übernommen werden.
Dieser Prozeß ist gerade in der Installationsphase recht fehlerträchtig, deshalb gibt es auch die Möglichkeit, die SOS-Daten immer komplett zu entladen. Dazu muss in SOS_ENV die Umgebungsvariable SOS_UNL_COMPLETE auf "true" gesetzt werden.
Dann starten Sie das Script sos_unload.x . Wenn es gelaufen ist, müssten die Dateien im unl -Verzeichnis stehen. Prüfen Sie dann bitte, ob dort Dateien mit 0 bytes stehen. Die Logdatei heisst sos_unload.err .
