Sicherung QFILEUPR

[Robi]

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]

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

[Robi]

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?

[Fuerchau]

Neue Objekte im IFS verändern nicht das USRPRF.
http://www-01.ibm.com/support/docvie...d=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.

[Robi]

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?

[Fuerchau]

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.

[Robi]

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

[Fuerchau]

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.

[Robi]

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.

[Fuerchau]

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.

[Robi]

Endsbs läuft anscheinend nicht. (steht nicht im Joblog)
Diverse Jobs und Diesnste werden aber beendet
u.a. QZLSFILE jobs

das würde ich gerne verhindern / beschleunigen

00   01.08.16  23:29:29,219722  QIZARTV      QSYS        0084     QSRSLCP2    QSYS 
  Nachricht . . . :   Systeminformationen wurden abgerufen.                        
00   02.08.16  03:05:59,700262  QJOSAVRC     QSYS        023E     QSRSVPST    QSYS 
  Nachricht . . . :   Empfänger QAOSDI9624 in QUSRSYS gesichert, während er        
    zugeordnet war.                                                                
  Ursache  . . . . :  Der Journalempfänger QAOSDI9624 in Bibliothek QUSRSYS        
    wurde gesichert, während er dem Journal zugeordnet war. Diese                  
    Sicherungskopie des Journalempfängers QAOSDI9624 ist nicht vollständig, da     
    die Journaleinträge nach der Sicherung weiterhin in den Empfänger gestellt

Über 3, 5 Stunden für einen Reciever sichern?
da muß doch die Ursache mit dem 'wärend er dem Journal zugeordnet war' zusammenhängen oder?

[Fuerchau]

Bist du sicher, dass zwischen den beiden Einträgen nichts anderes steht?
Wenn kein ENDSBS gemacht wird, kann es sein, dass eben viele Objekte noch in Benutzung sind.
Die Sicherung macht nun mal auf jedem Objekt einen ALCOBJ und wartet ggf. mit der Standardwartezeit je Objekt einzeln darauf, dass die Sperre erhalten wird. Erst wenn alle benötigten Sperren gesetzt werden können wird überhaupt mit der Sicherung angefangen.
Ich denke eher da läuft irgendwas schief bei euch.

Wie groß ist denn der Empfänger QAOSDI9624 überhaupt?
Vielleicht hilft ja hier mal ein CHGJRN und manuelles killen des alten Empfängers.