Extrem unterscheidliche Sicherungsdauer bei der Systemsicherung

[bussibaer]

Hallo,

wir haben eine Partition V6R1M0 als einzige Partitione auf einer Power I7 Maschine mit angeschlossenem Ultrium 6 Bandlaufwerk. Seit wir die Maschine umgestellt haben (vorher lief die Partition auf einer Power I6 mit Ultrium 5 Bandlaufwerk) haben wir wahnsinnige Schwankunge in der Dauer der Systemsicherung. Ich habe auch schon die IBM mit im Boot gehabt, aber die konnten da auch nicht so recht was finden. Ich habe die von denen empfohlenen PTF's installiert und auf die Firmware des bandlaufwerkes aktualisiert. Das hat aber nichts gebracht. Habt ihr vielleicht noch eine Idee, woran es liegen kann? Im Anhang findet ihr mal eine Aufstellung der Zeiten.2015_DS_Sicherungsdauer WEB.pdf

[KingofKning]

Und der wartet nicht irgendwo auf ein Lock oder so? Ich nehme mal an Du machst ein GO SAVE 21.

Sind das die reinen Zeiten wo das Band angelaufen ist?

GG

[Fuerchau]

SAVE 21 geht ja normalerweise nur im eingeschränkten Zustand.
Ich vermute hier eher ein SAVACT mit Wartezeit.
Zu beachten ist, die Wartezeit gilt je Objekt kumulativ!
D.h., auf das 1. gesperrte Objekt wird 2 Minuten gewartet, danach erst auf das nächst Objekt, usw..
Dies kann zu unterschiedlichen Zeiten eben unterschiedliche Sicherungsdauern bedeuten.

Teste einfach mal im eingeschränkten Zustand und vergleiche die Zeiten dann.

[bussibaer]

Also das ist die Systemsicherung GO SAVE 21 im eingeschränktem Zustand. Wir notieren immer die Zeit -Datenfreigabe- bis der Screen wechselt, da wir nicht vor der Kiste sitzen. Selbst wenn ich jetzt mal einen Datenzuwachs und auch Datenlöschung mit einbeziehe, habe ich noch nicht diese Schwankungen erlebt. Auf unserer Power i8 sind die Sicherungszeiten konstanter.

[andreaspr@aon.at]

Hallo,

wir hatten ein ähnliches Problem mit unserer Sicherung, allerdings war das beim Umstieg von 7.1 auf 7.2.
Da dauerte es plötzlich auch sehr viel länger.
So weit ich mich erinnern kann hatte die IBM mit 7.2 den Default-Wert eines Parameters beim Sichern mit BMR geändert.
Ich glaub da ging es um Synchron/Asynchron.
Kann es aber nicht mehr zu 100% sagen.

Vielleicht ist bei euch was ähnliches passiert?

lg Andreas

[hel400]

Hallo Bussibaer,

ein paar Gedanken meinerseits dazu:

Zunächst die Frage an Dich, ob diese Zeiten auch 100% richtig sind?
Warum ich so Frage: Du beschreibst, dass Ihr die Zeiten zwischen den einzelnen Screens notiert, da "wir nicht vor der Kiste sitzen". Wie ist das gemeint?
Evtl. mal den Parameter "Eingabeaufforderung für Befehle" auf "N" setzen und die genauen Zeiten dann mit DSPLOG nachsehen.
Oder das Ganze überhaupt in einen Batchjob packen.

Evtl. interessant wären auch die Zeiten für jede einzelne Bibliothek (im DSPLOG nachsehen). Ist die Zeitdifferenz auf alle Bibliotheken aufgeteilt oder gibt's da evtl. eine Lib, die besonders stark schwankt?

Wie sieht's da weiters mit Spoolfiles aus?
Hatte letzte Woche einen Fall, da ging die *NONSYS-zeit von 5 auf 2(!) Stunden zurück, nur wegen Tonnen von (unnötiger) Spoolfiles.

Weiters ist auffällig, dass auch im IFS (SAV) sehr große Differenzen sind, fast noch mehr als beim SAVLIB!
Kann es sein, dass hier die Anzahl und/oder Größen der Objekte stark schwanken?

[Fuerchau]

Da es sich ja noch immer im Streaming-Bänder handelt kann es auch ein Qualitätsproblem sein.
Beim Schreiben werden die Daten direkt mit dem dahinterliegenden Lesekopf gelesen und geprüft.
Bei Fehler wird der Datenblock wiederholt. Erst wenn eine gewisse Wiederholrate überschritten ist, wird der Vorgang abgebrochen.
Bei schlechter Qualität kann sich somit der Schreibvorgang einfach verlängern.

Da ihr die Bänder wohl zyklisch verwendet, prüft doch einfach ob die Zeiten von bestimmten Bändern abhängen.
Wie viel nun gesichert wurde kann man notfalls per DSPTAP rausfinden. Allerdings nur, wenn auch Folgebänder benötigt wurden. Man kann dann an Hand der belegten Kapazität feststellen wie hoch der prozentuale Fehleranteil dann ist (wenn z.B. nur die Hälfte drauf ging).
Diese Bänder sind dann ggf. gegen neuere auszutauschen.

[KingofKning]

Dann würde ich doch lieber im SST nachsehen ob die Bänder Fehler haben.

GG

[bussibaer]

Also im SST gab es keine Fehler (gleich geluschert). Aber das was Furchau sagt könnte vielleicht eine Lösung sein. Wir werden mal neue Bänder nehmen und das beobachten. Leider, oder zum Glück, wird nur ein Band benötigt.

Andrea: Das ist ein eingebautes tape, was wir als tape auch benutzen (TAP01).

hel400: Der Datenbestand schwankt, das ist klar, aber nicht so doll. Spools werden auf der Kiste nicht so viele erzeugt.

[Fuerchau]

Schreibwiederholungen werden nicht als Fehler gemeldet, da sie keine sind.
Dies ist beim Streamen ein ganz normaler Vorgang.
Wie das System das derzeit verwendet weiß ich nicht, aber es kam früher auch schon mal vor, dass ein 2. Band angefordert wurde obwohl alles auf 1 Band passen sollt, es gab also keine Wiederholungsbeschränkung.
Auf dem 1. Band konnte mal gerade 10% gesichert werden, so kaputt war das.
Was da bei der Wiederherstellung passiert wäre...

[hel400]

Wenn's um Bandfehler geht, hilft das oft weiter:

PRTERRLOG TYPE(*VOLSTAT) VOLTYPE(nnnn)

(mit "DSPDEVD TAPxx" die Type nachsehen, diesen Wert dann bei VOLTYPE eintragen).

Wenn jedes Band einen eigenen, eindeutigen Namen hat, sieht man's noch besser.

[bussibaer]

Danke, werde ich mal schauen, was ich da vielleicht noch finde.