Backup Problem mit QSQSRVR

[tomikra]

Hallo Forum,

ich weiss, dieses Problem tauchte hier schon mal auf, doch für mich nicht so richtig schlüssig.

Während des nächtlichen Backups Befehl
SAVLIB LIB(*ALLUSR) DEV(TAP01) ACCPTH(*YES)

Treten seit neustem folgende Meldungen auf:

CPI8365 COMMIT- oder ROLLBACK-Operation für Job 188501/QUSER/QSQSRVR zum Sichern im aktiven Zustand erforderlich.

CPI8367 Anforderung zum Sichern im aktiven Zustand für Job 191116/BACKUP/BACKUP beendet.

CPF377F Anforderung zum Sichern im aktiven Zustand durch anstehende Satzänderungen verhindert..

Soll ich das mit MONMSG CPF9999 abfangen?

Bei IBM habe ich gelesen das diese vorgestarten Jobs mit ENDPJ SBS(QSYSWRK) PGM(QSQSRVR) vor dem Backup beenden bzw. danach wieder gestartet werden soll.

Auf der iSeries V5R2 läuft kein Websphere aber java.

Vielen Dank für Eure Hilfe

Gruß
tomikra

[BenderD]

Hallo,

das siieht mir nach einem Bug, oder einem sehr brüchigen Client Server Programm aus; wenn ihr keine Client Anwendungen habt, die per ODBC zugreifen, dann würde ich mal Software defect reklamieren.

mfg

Dieter Bender

Hallo Forum,

ich weiss, dieses Problem tauchte hier schon mal auf, doch für mich nicht so richtig schlüssig.

Während des nächtlichen Backups Befehl
SAVLIB LIB(*ALLUSR) DEV(TAP01) ACCPTH(*YES)

Treten seit neustem folgende Meldungen auf:

CPI8365 COMMIT- oder ROLLBACK-Operation für Job 188501/QUSER/QSQSRVR zum Sichern im aktiven Zustand erforderlich.

CPI8367 Anforderung zum Sichern im aktiven Zustand für Job 191116/BACKUP/BACKUP beendet.

CPF377F Anforderung zum Sichern im aktiven Zustand durch anstehende Satzänderungen verhindert..

Soll ich das mit MONMSG CPF9999 abfangen?

Bei IBM habe ich gelesen das diese vorgestarten Jobs mit ENDPJ SBS(QSYSWRK) PGM(QSQSRVR) vor dem Backup beenden bzw. danach wieder gestartet werden soll.

Auf der iSeries V5R2 läuft kein Websphere aber java.

Vielen Dank für Eure Hilfe

Gruß
tomikra

[TARASIK]

Hallo,
ich denke den "Bug" brauchst Du wirklich nicht melden, das Problem gab es schon mit R440.
Mache einen der angeboten circumventions aus dem Apar

http://www-912.ibm.com/n_dir/nas4apa...t=0,msgCPI8365

[BenderD]

Hallo,
m.E. sind das alles faule Ausreden in dem APAR: wenn Management Central eine Commit Operation offen lässt, dann ist das ein Fehler, für den ich einen Anfänger über die Planke jagen würde, wenn er sowas in Produktion setzen würde! Und wenn dieser Bug wirklich schon seit mehreren Releases im Betriebssystem ist, dann ist dasfür jedes Release ein Grund mehr hier Fehlermeldung zu machen!

mfg

Dieter Bender

Hallo,
ich denke den "Bug" brauchst Du wirklich nicht melden, das Problem gab es schon mit R440.
Mache einen der angeboten circumventions aus dem Apar

http://www-912.ibm.com/n_dir/nas4apa...t=0,msgCPI8365

[kuempi von stein]

Hallo Forum,

ich weiss, dieses Problem tauchte hier schon mal auf, doch für mich nicht so richtig schlüssig.

Während des nächtlichen Backups Befehl
SAVLIB LIB(*ALLUSR) DEV(TAP01) ACCPTH(*YES)

Treten seit neustem folgende Meldungen auf:

CPI8365 COMMIT- oder ROLLBACK-Operation für Job 188501/QUSER/QSQSRVR zum Sichern im aktiven Zustand erforderlich.

CPI8367 Anforderung zum Sichern im aktiven Zustand für Job 191116/BACKUP/BACKUP beendet.

CPF377F Anforderung zum Sichern im aktiven Zustand durch anstehende Satzänderungen verhindert..

Soll ich das mit MONMSG CPF9999 abfangen?

Bei IBM habe ich gelesen das diese vorgestarten Jobs mit ENDPJ SBS(QSYSWRK) PGM(QSQSRVR) vor dem Backup beenden bzw. danach wieder gestartet werden soll.

Auf der iSeries V5R2 läuft kein Websphere aber java.

Vielen Dank für Eure Hilfe

Gruß
tomikra

hello tomikra,

ich hatte die gleichen probleme und habe das nach mehreren versuchen lösen können.
zum einen fahre ich inzwischen die serverjobs während der sicherung runter und zum anderen ist der pm/400 von mir manuell ausgeschaltet worden.
welcher der beiden nun genau verantwortlich war ist in meinem fall sekundär, die crux war die sicherung zum laufen zu bekommen....

alsodele ...
die serverjobs kannst du runterknallen mit:
ENDPJ SBS(QSYSWRK) PGM(QSQSRVR)
ENDTCPSVR SERVER(*DIRSRV)
ENDTCPSVR SERVER(*HTTP)
nach der sicherung das hochfahren nicht vergessen... geht easy nur eben umgekehrt... (str....)
den pm/400 kannst du wie folgt lahmlegen:
einmal über option 2 in go perform
und über go pm400 auch option2 da kann man die diversen jobs steuern sprich ente inaktivieren oder mit datum in die zukunft legen...

thats it.
glaub mir danach sollte es gehen....

berichte mal bei gelegenheit

kuempi

[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 ?