Backup Problem mit QSQSRVR

[TARASIK]

Hallo,
laut IBM gibt es für den QSQSRVR folgende Lösung:

http://www-1.ibm.com/support/docview...075fcfa&rs=110

Ich würde auch noch den *mgtc beenden vor der Sicherung
und nach der Sicherung wieder starten gleich dem LDAP
Server.

[tomikra]

Hallo!

vielen Dank für Eure Hilfe !

IBM sagte ich solle den LDAP - Server beenden oder die Bibliothek QUSRDIRDB von der Sicherung ausklammern.

Werde ersteres tun, und schauen was passiert.

Aber eigentlich ist das doch ein BUG von IBM oder?

Gruß
tomikra

[Fuerchau]

Nicht unbedingt.
Wenn ich einen COMMIT absetze, wird ja gleichzeitig ein neuer COMMIT eröffnet auch wenn der erst mal keine Daten verändert.

Wenn ich beim SAVxxx keine SAVACT(*xxx) angebe, können halt Objekte nicht gesichert werden, die noch geöffnet sind.

Ich würde da eher mal über einen SAVLIB ... SAVACT(*LIB) SAVACTWAIT(0) nachdenken. Keine Angst, Datendateien werden auf jeden Fall korrekt gesichert, auch bei offenen Commit's.

[BenderD]

Das ist ausnahmsweise mal nicht exakt. Commit oder Rollback beenden die Transaktion und geben alle Sperren frei. Die nächste Transaktion startet erst mit dem Erwerb der ersten Sperre (sonst könnte man z.B.; Transaction Level nie ändern!) und wer so programmiert, dass Transaktionen länger hängen bleiben, der gehört mit der DB2 Reference erschlagen.

mfg

Dieter Bender

Nicht unbedingt.
Wenn ich einen COMMIT absetze, wird ja gleichzeitig ein neuer COMMIT eröffnet auch wenn der erst mal keine Daten verändert.

Wenn ich beim SAVxxx keine SAVACT(*xxx) angebe, können halt Objekte nicht gesichert werden, die noch geöffnet sind.

Ich würde da eher mal über einen SAVLIB ... SAVACT(*LIB) SAVACTWAIT(0) nachdenken. Keine Angst, Datendateien werden auf jeden Fall korrekt gesichert, auch bei offenen Commit's.

[Fuerchau]

Dieter, damit hast du sicherlich recht, aber das Hauptproblem hierbei ist der SQL-Optimizer, der bei einem Commit/Rollback die ODP's noch offen hält.
Somit sind leider nicht alle Resourcen freigegeben (es sind nur Update-Sperren aufgehoben), was einen SAV ohne SAVACT eben verhindert.
Welche Nachteile allerdings entstehen (in der Performance) bei einem Commit/Rollback tatsächlich alles freizugeben kann man leicht selbst ausrechnen.
Ausserdem, was ist mit den Open Cursor'n, die über Commit hinaus geöffnet bleiben sollen ?

[BenderD]

@Baldur: Probleme machen nur offene Commit Boundaries, alles andere wird vom Save active bewältigt. (-> ALCOBJ mit request release wird implizit gemacht. Nachteile gibts da für korrekte Programmierung keine, der Save zieht halt Ressourcen, aber was mutt, das mutt!
Dieter

Dieter, damit hast du sicherlich recht, aber das Hauptproblem hierbei ist der SQL-Optimizer, der bei einem Commit/Rollback die ODP's noch offen hält.
Somit sind leider nicht alle Resourcen freigegeben (es sind nur Update-Sperren aufgehoben), was einen SAV ohne SAVACT eben verhindert.
Welche Nachteile allerdings entstehen (in der Performance) bei einem Commit/Rollback tatsächlich alles freizugeben kann man leicht selbst ausrechnen.
Ausserdem, was ist mit den Open Cursor'n, die über Commit hinaus geöffnet bleiben sollen ?