View Full Version : Sicherung QFILEUPR
moin,
Eine Sicherung (Save21) braucht 'plötzlich' viel viel länger.
1. gefundene Übeltäter
Schelle Sicherung:
160 Blöcke wurden für Dateikennsatz QFILEUPR, ...
dauer: 2 Minuten
aktuelle Sicherung
1073 Blöcke wurden für Dateikennsatz QFILEUPR, ...
dauer: 40 Minuten
Kann jemand erklähren, was QFILEUPR ist
Habe im Netz Infos gefunden die auf Userprofile und berechtigungen hindeuten.
Da hat sich aber NIX geändert, also .... Was ist da?
Danke
Robi
holgerscherer
02-08-16, 09:44
Da hat sich aber NIX geändert, also .... Was ist da?
Benutzerprofile (SAVSECDTA) - ist da einer hinzugekommen oder hat es viele neue Objekte auf dem System (im IFS z.B.)?
Eventuell mal ein RCLSTG laufen lassen...
-h
Benutzerprofile hat sich nix geändert.
Aber wie ich eben erfahren habe gibt es einen neuen Job, der IFS Dateien erzeugt, kann das die Ursache sein?
Neue Objekte im IFS verändern nicht das USRPRF.
http://www-01.ibm.com/support/docview.wss?uid=nas8N1017833
Es gibt allerdings Programme wie STRSQL, die in angehängten USRSPC-Objekten diverse Informationen speichern. Dies kann man per DSPOBJD *ALL *USRPRF mal prüfen, wer denn da so viel angehängt hat.
Danke Euch!
mit dem DSPOBJD *ALL *USRPRF habe ich ein Usrprf gefunden,
dessen Größe das 100 Fache des 'normalen' ist.
ein WRKOBJOWN zeigt, das der user der Owner der vielen IFS Dateien ist.
WAS macht den die Sicherung so langsam / das Usrprf so groß, wenn das Usrprf
durch die IFS Dokumente nicht verändert wird?
Ich habe da mal einen DMPSYSOBJ gemacht. Es scheint so zu sein, dass eine Liste der eigenen Objekte nebst den dazugehörigen Berechtigungen am USRPRF angehängt ist, also je mehr Objekte, desto länger die Liste.
Wobei die Objekttypen hier leider in Hex dargestellt werden und es mal wieder nur per API ggf. möglich ist, die Objektart "sprechend" umzuwandeln.
Nicht umsonst gibts ja neben dem RSTUSRPRF zusätzlich den RSTAUT. Irgendwo müssen diese Informationen ja liegen.
Ok, so komm ich aber nicht weiter,
die IFS Objekte müssen ja schließlich sein, die sind ja nicht zum Spaß vorhanden.
Das muß ich also akzeptieren.
Weitere 'Bremse' ist das sichern eines QAOSDI* Journal recievers
Text: "JOURNAL RECEIVER FOR DIA FILES"
Das Log weist darauf hin, das er im aktiven zustand nicht vollständig gesichert wurde.
Schnell: 73 minuten
Langsam: 216 minuten
Wäre es möglich die Journalisierung von ???was-auch-immer??? vor der Sicherung zu beenden!
Wenn ja, wie?
Danke
Journalisierung vor der Sicherung beenden ist schädlich, da dies ausßerdem je Objekt einzeln durchgeführt werden müsste.
Das Problem ist eher, dass die Programme noch aktiv sind und deshalb Transaktionen offen sind. Somit wird auf den/die Journalempfänger jeweils 2 Minuten (Default) gewartet um dann ohne Sicherung dieses Objektes weiter zu machen.
Sow wie es aussieht, ist dieses Journal für die "Document Library" zuständig. Dafür musst du den Dienst QZLSFILE (Hostservice) beenden um die Objekte freizugeben.
Ich denke, da werden dir noch einige Objekte begegnen, wenn du im laufenden Betrieb sicherst.
Danke
Tja,
ich dachte immer der save21 geht nur im eingeschrängten Zustand ... = alle ist zu/aus/beendet!
Da die Kiste nicht mehr in unserem zuständigkeitsbereich liegt weis ich eigendlich gar nicht genau, was gemacht wird.
Ich muß nur suchen, wo der imennse Zeit unterschied herkommt.
Sperren können da schon lässtig sein.
Wie gesagt, ein ENDSBS kann da schon mal länger dauern und wenn dann die Sicherung bereits startet gibts halt manchmal Zeitprobleme.
Dann ist da auch die Frage, ob ein ENDSBS *ALL gemacht wird und somit auch QSERVER und QUSRWRK beendet werden die schließlich für die TCP-/Hostservices zuständig sind.
Was die Zuständigkeit angeht so frag doch mal nach, wieso die Dauer interessant ist?
Schließlich könnt ihr eure Platten doch auch zu 95% auslasten und dann dauert die Sicherung wohl noch länger.
Wenn ich mir ein Auto miete wird ja auch nicht gefragt, wie viele Leute ich mitnehme.