Anonym.
Hallo Leute,
eine mehr oder minder brisante Frage aus Wien – und ich bitte um Nachsicht, falls ich mich irgendwie undeutlich ausdrücken sollte, aber eigentlich bin ich ein IBM-Quereinsteiger! 😉
Mein Problem: ich habe die Aufgabe, einen JCL für das Sichern und Restoren von DB2-Tabellen, die BLOB’s beinhalten, zu erstellen.
Als Lösungsansatz hatte ich einen simplen COPY/RECOVER TABLESPACE im Auge – und prinzipiell funktioniert das auch ganz gut. Diese Lösung hat nur eine Schwäche: der JCL ist nur ein einziges Mal durchführbar, da DB2 offenbar Buch darüber führt, wohin der Tablespace kopiert wurde. Ein zweites Mal mit dem gleichen Sequential-File ist der Copy nicht möglich.
Daraufhin habe ich dann das Sequential-File in ein GDG File geändert, was dann erstmalig meine Erwartungen erfüllt hat.
Seit der DB2 Umstellung auf V8 habe ich plötzlich Probleme mit dem RECOVER, indem ich einen Syntax-Fehler bekomme. Diverse Tests ergaben, dass ich das GDG File nicht mit "x.y.z(0)" ansprechen kann, sondern die typische Endung bei GDG Files á-la "x.y.z.G0001V00" verwenden muss. Dies ist jedoch nicht wirklich praktikabel.
Ãœberlegungen, das gewünschte GDG File vor dem RECOVER auf ein Sequential-File umzukopieren, scheiterten daran, dass die DB2 prüft, ob der Tablespace auf das angegebene File jemals kopiert wurde – und wenn nicht, mit der Fehlermeldung "File not found" abbricht.
Ich bin jetzt irgendwie mit meinem Latein am Ende; vielleicht hat einer von Euch eine Idee?
Liebe Grüße aus Wien
Herby
Hallo Herby,
es gibt beim RECOVER auch die Möglichkeit, das aktuellste Image-Copy zu verwenden, indem Du statt
RECOVER … TOCOPY x.y.z(0)
schreibst:
RECOVER … TOLASTCOPY
das sollte eigentlich Dein Problem lösen.
DB2 führt übrigens tatsächlich Buch darüber, wohin ein Tablespace kopiert wurde. Diese Informationen stehen in der SYSIBM.SYSCOPY
Grüsse
Uli
Hi Herby,
alternativ gibts da noch das QUIESCE-Utility, das du statt einer Copy laufen lassen kannst. Dabe wird ein LRSN ausgegeben, auf die du jederzeit zurück recovern kannst (im Prinzip so eine Art Timestamp).
Wie DB2 dann auf diensen Punkt zurückkommt, entscheidet es selbst. Allerdings ist eine Fullcopy vor einem Quiesce natürlich eine grosse Hilfe… 😉
Du musst dir allerdings die LRSN des Quiesce merken, bzw. sie bei dem Fallback aus der SYSCOPY raussuchen (wird da eingetragen).
Recovert wird dann mit RECOVER … TOLRSN X’….‘.
Wenn ihr häufig Copies zieht ist der Quiesce eine einfache und schnelle Alternative um solche Fallback-Punkte zu etablieren.
MfG Rolf
@Ulrich Mayer: danke für die Information; werde dieses ‚TOLASTCOPY‘ mal ausprobieren und wenn es funktioniert (wovon ich mal ausgehe), dann ist das genau die Lösung, nach der ich gesucht habe.
@RolfD: auch Dir ein Danke; von diesem QUIESCE-Utility habe ich noch nichts gehört. Ist das ein IBM- oder ein Fremd-Tool? Ich suche nämlich unbedingt eine Lösung, die mit den Bord-Mitteln von z/OS funktioniert.
Nochmals danke für die rasche Hilfe!
LG – Herby
Hallo Herby,
QUIESCE ist ein ‚altes‘ DB2-Utility und gehört sozusagen zur DB2-Grundausstattung. Beschrieben ist es im ‚Utility Guide and Reference‘.
MfG Rolf
You must be logged in to reply to this topic.
