Zuordnung Tape-Unit geht verloren

[systemer]

Guten Morgen *all,

folgendes Problem:

Mittels einer BRMS Backupgroup werden nachts 3 Bibliotheken gesichert. Der Job läuft um 22:00 los, sichert bis ca. 5:00 die erste fette Lib. Dann schreibt er seinen End of File (oder was immer auf der iSeries das Äquivalent des VM-EOFs ist) auf das Band und soll danach auf dem gleichen Band die Libs 2 und 3 hintenan sichern; wie gesagt, das Ganze ist EIN Batchjob.

Und heute morgen hat sich doch tatsächlich zwischen dem Save-Ende der ersten Lib und dem Save-Anfang der zweiten Lib ein anderer Batchjob die Tape-Unit gekrallt, das Band runtergeschmissen, ein anderes montiert und seine eigene Sicherung gestartet. Natürlich ist der andere Job darauf abgebrochen mit der Fehlermeldung, daß die benötigte Unit einem anderen Job zugeordnet ist.

Die große Frage: Wie kann es sein, daß eine Tape-Unit, die einem aktiven Job zugeordnet ist, plötzlich einem anderen Job zur Verfügung steht?? OS-Fehler? Oder ist BRMS wirklich so dumm, beim Save mehrerer Objekte zwischendurch immer wieder seine Units freizugeben und neu zuzuordnen, was ja schon fast eine Art Russisches Roulette wäre??

Wer kann da etwas Licht reinbringen, um künftige Sicherungsabstürze zu vermeiden?

Vielen Dank vorab und schöne Grüße aus dem verschneiten Taunus,

Systemer

[Fuerchau]

Ich vermute, dass BRMS kein ALCOBJ auf das Tape macht, so dass die Sperre auf die Einheit nur währende der Sicherung erfolgt.

Wenn nun eine Sicherung in mehreren einzelnen SAVE-Befehlen abläuft, wird natürlich die Sperre des Bandes kurzfristig aufgehoben und steht somit anderen Jobs zur Verfügung.

Dies ist kein OS-Fehler sondern allenfalls ein BRMS-Fehler.

BRMS müsste die Bandeinheit mittels ALCOBJ exclusiv zuordnen !

[TARASIK]

Hallo Systemer,
welches Release der AS/400 wird benützt und im BRMS Log wird denn da etwas protokolliert ?

Gruss TARASIK

[systemer]

Hallo Tarasik,

OS- und BRMS-Release ist V5R1M0.

Im Joblog der Sicherung kommt lediglich die CPC3701, die besagt daß nnnn Objekte aus der ersten Lib auf Datenträger xxxx gesichert wurden.

Danach kommt eine BRMS1058, wonach die Sicherung der Lib xx auf der Einheit *MEDDFN startet.

Zwei Minuten später erscheint die Meldung CPF5729, daß Objekt TAP06 nicht zugeordnet werden kann...

Der Joblog des BRMS hat lediglich Einträge aus der Zeit um 22:00, als der erste Sicherungsjob anlief, und dann wieder um 6:10, als der zweite Sicherungsjob anlief, der sichh dann die (aktive) TAP06 schnappte. That's all.

Gruß, Systemer

[Fuerchau]

Kann man denn bei BRMS die Sicherung der 3 Lib's nicht in einem SAVE erzwingen ?

Es sieht so aus, dass tatsächlich zwischen den Sicherungen eine genügend lange Pause existiert.

Die Sicherung der Lib's in 1 SAVE-Kommando dürfte auch schneller sein, da ich glaube dass BRMS das Band auch noch zurückspult, so dass der folgende SAVE erst mal das Bandende wieder ermitteln muss.

[Bruno Jakob]

Hallo Systemer,

das Thema Sicherung sollte meiner Meinung nach in einer Hand sein (muss sich nicht unbedingt auf eine Person beschränken).

Und diese eine Hand sollte dann natürlich auch dafür sorgen, dass sich Sicherungsjobs nicht gegenseitig in die Quere kommen. Z. B. alle Sicherungsjobs in eine Jobq, die keine Parallelverarbeitung zuläßt.

Gruß
Bruno

[systemer]

Hallo Fuerchau,

ich muß gestehen, daß ich BRMS nicht tief genug verstehe, um da evtl. irgendwelche "dirty tricks" einzubauen. 1998 bei der Installation von BRMS wurde folgende Backup Group von unserem IBM-Berater eingerichtet:

Sicherungs- Befehl zum
Folge einträge Verlassen
10 *EXIT SNDMSG MSG('Start SIP01ON - Sicherung bei lfd. R3-
20 *EXIT CRTDTAARA DTAARA(QTEMP/QSRPARFMT) TYPE(*CHAR)
30 *EXIT ADDLIBLE LIB(R3P01OPT)
40 *EXIT SBMJOB CMD(CALL PGM(INSTLIB/SENDSMS)) JOB(SENDSMS)
50 *EXIT SBMJOB CMD(CALL PGM(INSTLIB/SENDSMSOK)) JOB(SENDSM
60 R3P01DATA
70 R3P01OPT
80 R3P01400
90 *EXIT RMVLIBLE LIB(R3P01OPT)
100 *EXIT SNDMSG MSG('SIP01ON: Sicherung für das R/3 System

Was das BRMS aus den Sicherungseinträgen macht (Generierung eines OS-Jobs mit SAVLIB-Befehlen oder statt dessen Aufruf irgendwelcher BRMS-spezifischer Funktionen, die mit einem "normalen" SAVLIB in der OS/400-Umgebung nicht vergleichbar sind), ist mir nicht bekannt. Werde aber mal versuchen, bei der IBM einen BRMS-Guru aufzutreiben und das mit ihm durchgehen.

@Bruno:

Da wir jede Nacht verschiedene Objekte unterschiedlicher Größen auf 4 iSeries mit nur 3 Tape-Units sichern müssen, lassen sich bestimmte Parallelitäten nicht immer vermeiden. Normalerweise laufen unsere Sicherungen alle aus dem Jobscheduler des OS/400. Bei den Startzeiten haben wir stets noch Puffer zwischen Jobs, die auf die gleichen Resourcen zugreifen. Insofern ist das Sicherungsgeschäft in einer Hand, indem der Scheduler nur von mir und einem Kollegen verwaltet wird.

Aber manchmal läßt sich nicht vermeiden, daß eine Sicherung klemmt (z.B. weil beim Save while active noch auf Commits gewartet werden muß). Doch normalerweise sollte eine solche Situation lediglich dazu führen, daß der Job, der als letzter anlief, mit einer Fehlermeldung, daß die Unit nicht verfügbar ist, in den Wait-Status geht, und nicht daß er in laufende Jobs reinfunkt.

Gruß,
Franz

[Bruno Jakob]

Laufen die Jobs, die auf die gleiche Resource zugreifen auch auf dem gleichen oder auf verschiedenen Systemen?

Wenn auf dem gleichen System: Eine Jobq für alle Jobs, die auf die gleiche Resource zugreifen. Wenn Job 1 fertig, kann Job 2 anlaufen - und das auch noch ohne Zeitverlust.

Wenn auf verschiedenen Systemen: Wird wohl davon abhängig sein, wie die Resource dem anderen System zugeordnet wird.

Gruß
bruno

[Fuerchau]

SAVACT kann auch das Problem der langen Sicherung verschärfen. Zusätzlich zu diesem Parameter ist auf SAVACTWAIT zu achten (default 120 Sekunden).

Diese Wartezeit gilt PRO OBJEKT der zu sichernden Bibliothek.

Um einen Synchronisationspunkt zu erstellen wartet der SAVE auf jedes Objekt (das für Veränderung geöffnet ist) bis zu 2 Minuten auf den CLOSE (der ja ggf. nie kommen wird).

Sind also z.B. 100 Objekte geöffnet, wartet der SAVE 12000 Sekunden bevor er überhaupt mit dem SAVE startet !

Die Wartezeit kann problemlos auch auf 0 (Null) gestellt werden.

Wo das allerdings beim BRMS gemacht wird weiß ich nicht.

Ggf. per CHGCMDDFT ?!

Frage: Wie groß ist denn die 1. LIB, dass 7 Stunden zum sichern benötigt wird ?

[systemer]

@ Bruno,

das geht bei uns ein wenig drunter und drüber. Um möglichst auf jeder Maschine parallel sichern zu können, ist generell jede Tape-Unit an jeweils zwei Maschinen angeschlossen.

Die Jobs für eine bestimmte Tape-Unit laufen also teilweise auf der gleichen, teils auf verschiedenen Maschinen. Aber die Idee mit einer dedizierten Jobq nur für die nächtlichen Backups werden wir hier mal näher erörtern.



@ Fuerchau,

besagte Lib ist mittlerweile etwa 900 GB groß und beinhaltet ca. 15.000 Objekte - es handelt sich um unsere SAP-Datenbank.

Das Problem mit den gesperrten Objekten stellt sich bei SAP in der Regel nur dann, wenn ein Programmierer Schrott produziert und ein z.B. ein Programm zur Massenänderung-/Löschung von Daten ohne Commitcycles erzeugt. Aber solche Programme laufen dann erfahrungsgemäß etliche Stunden, weswegen die Sicherung spätestens nach 20 Minuten (unser eingestellter SAVACTWAIT-Parameter) eh abbricht. Aber wie gesagt, der Puffer zwischen den Jobs beträgt manchmal nur 10-15 Minuten, mehr ist wegen anderer Abhängigkeiten nicht drin.


Gruß,
Systemer