Sicherung QGPL dauert 3 Stunden

[MarkusM]

Hallo,

wir haben in unserem CL-Programm, das die nächtliche Sicherung macht, ein savlib *allusr drin. Die Bibliothek QGPL braucht ca. 3 Stunden zum Sichern.

Hat jemand eine Ahnung, warum die so lange braucht?


Gruß

Markus

[KingofKning]

Tja,

ich sach mal wie groß ist die denn? Mit welchen Befehlen wird denn gesichert? Vielleicht die Option sav while active?

GG

[MarkusM]

Hallo,

besten Dank für die Frage / Antwort, aber ich muss mich revidieren. Nachdem ich die QGPL omitet habe, braucht nun die QSYS2 so lange. Damit stelle ich fest, dass es immer die erste zu sichernde Bibliothek ist, die sehr lange braucht. Hier noch der Befehl (allerdings der Übersichtlichkeit halber ohne omit.

SAVLIB LIB(*ALLUSR) DEV(TAPMLB01) ENDOPT(*LEAVE) +
ACCPTH(*YES) OUTPUT(*OUTFILE) +
OUTFILE(QGPL/SAVLOGLIB) OUTMBR(*FIRST +
*ADD) INFTYPE(*LIB)


Gruß Markus

[Frank.Sobanek]

Hallo,

so müsste es rund laufen !!

Sichern im aktiven Zustand . . . *LIB
Wartez. b. Sich. im akt. Zust.:
Objektsperren . . . . . . . . 1


Gruß

[MarkusM]

Hallo,

läuft irgendwie immer noch nicht so rund.

Beginn Sicherung um 22:46 Uhr, QSYS2 um 02:05 Uhr beendet und QUSRSYS um 03:35 Uhr beendet.

QSYS2 mit 166 Objekten, QUSRSYS mit 190566 Objekten.

Gruß Markus

[Fuerchau]

Dass die QSYS2 so lange dauert liegt wohl daran, dass die meisten Objekte ständig in Benutzung sind. Das selbe gilt auch für die QUSRSYS (wieso sind da überhaupt soviele Objekte drin ? Normal sind da her so um die 5000.).

Siehe auch F1-Hilfe auf LIB.
Um Systembibliotheken zu sichern sollte das System im eingeschränkten Zustand sein.
Auch *ALLUSR ist kritisch, da auch bei SAVACT(*LIB) Wartezeiten je Objekt einkalkuliert werden müssen.
Die SAVACTWAIT-Zeit wird bei journalisierten Objekten (z.B. in QSYS2/QUSRSYS) zum Teil erheblich überschritten, da auf Commit-Grenzen gewartet wird. Da die Sperren nicht parallel gesetzt werden sondern Objekt für Objekt summieren sich die Zeiten eben.
Objekte, für die keine Sperre erhalten werden kann, werden nicht gesichert.
Nicht jedes Objekt kann im aktiven Zustand gesichert werden. Auch der Platz auf der Platte muss ausrechend groß sein, um die während der Sicherung anfallenden Änderungen aufzuzeichnen.

[MarkusM]

Hallo Fuerchau,

der Tipp mit den vielen Objekten in der QUSRSYS war goldrichtig. Wir haben da ca. 185.000 Objekte drin, die mit QODB* beginnen und wahrscheinlich von irgendeinem STRDBMON kommen. Nachdem ich die bei der Sicherung ausgeschlossen habe, war unsere Sicherung ca. 3 Stunden schneller. Hat vielleicht jemand noch eine Ahnung wo die herkommen können und ob ich die einfach löschen kann?

Gruß Markus

[andreaspr@aon.at]

Hi Markus,

die Files werden zb erstellt, wenn bei ODBC-Zugriffen im der verwendeten DSN die Datenbanküberwachung eingeschaltet ist.
Dann werden alle Aktivitäten in dieses File protokolliert.
Wenn du in das File reinschaust, siehst du ja auch von welchem Job, User das Monitoring gestartet wurde.
Bei QZDASOINIT und QUSER können es ODBC-Verbindungen sein.

Ich wüsste auch nicht, was dagegen sprechen würde, diese daten einfach zu löschen, wenn du diese nicht mehr benötigst.

lg andreas