Anonym.
Hallo zusammen!
Ich habe hier das Problem, dass ich ein paar Tablespaces (testweise) auf einen Zeitpunkt recovern wollte, der in unserer adminstrativen Reorg-Zeitscheibe liegt. Mein Test war leider von wenig Erfolg gekrönt, da ein paar Recovery-Jobs immer wieder mit 00E20027 abgebrochen sind – komischerweise waren dabei Recovery-Jobs, die Objekte recovered haben, die im Reorg nicht zwingenderweise beteiligt waren! Mittlerweile haben wir bei der IBM ein PMR eröffnet und das Problem scheint von der IBM auch verstanden worden zu sein, so dass mit Hochdruck an einer Lösung gearbeitet wird…
Dennoch würde mich interessieren, wer ausser mir auf dieses Problem gestossen ist?
Schliesslich bedeutet das doch, dass man während der Reorg-Zeitscheibe nicht recoverfähig ist! Und aus Erfahrung weiss ich, dass manche Kollegen über zig Stunden bis zu über einen Tag reorganisieren. Ganz zu schweigen von den "Realtime/OnDemand"-Wartungsverfahren, die rund um die Uhr sichern, reorganisieren und runstatsen…
Zum 00E20027 siehe: http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2.doc.mc/x00e2.htm
Vielen Dank für Euer Feedback und viele Grüße aus Karlsruhe sendet Euch
Thomas Merz
dm-drogerie markt GmbH & Co. KG
Abteilung Filiadata DPS DB-System-ZS
Hallo Thomas,
auf ein derartiges Problem bin ich noch nicht gestossen. Diesen Fehlercode les ich auch zum ersten mal.
Gib uns doch bitte ein paar Infos zu Eurem DB2-System ( welche Version, welcher Modus, Sysplex usw. ) und zum Recover-Job
( RECOVER TOCOPY oder TORBA oder mittels DSN1COPY … ? ) bzw zum Testszenario ( simple Tablespace, segmented, partitioned … ).
Dann können wir das ganze etwas besser einordnen.
Grüsse
Uli
Hallo Uli!
Wir haben DB2v8 im NFM im Einsatz. Unsere DB2s sind Datasharing-enabled mit 1 bzw. 2 Membern in einem z/OS 1.8 Sysplex.
Ich habe den Zeitpunkt für meine Recovery als CRCR in das BSDS geschrieben und dann nur noch RECOVER TABLESPACE bzw. RECOVER INDEXSPACE gesagt. In meinen Tests habe ich kein Muster erkennen können; es waren also mal Tablespaces, mal Indexspaces, mal LOBs betroffen.
Viele Grüße
Thomas
Jetzt bin ich verwirrt …
Einen CRCR ( conditional restart control record ) brauche ich doch nur, wenn ich das komplette DB2-System kalt durchstarten will, aber doch nicht für einen einfachen Recover Tablespace ??
Hallo Uli!
Um das Ganze etwas zu entwirren:
In diesem Fall habe ich tatsächlich das gesamte System zurückgesetzt, aber mit einem Admintool nur die Objekte recovered, die recovered werden mussten. Und die Syntax der Recover Jobs lautet dank CRCR nur noch RECOVER TABLESPACE oder RECOVER INDEX.
Wichtig an der Situation erscheint mir, dass ein RECOVER in eine Zeitscheibe, in der ein beliebiger Reorg Job lief, anscheinend nicht immer (oder sogar niemals?) möglich ist und ob andere auch schon diese Erfahrung gemacht haben bzw. im Vorfeld zu warnen, dass da möglicherweise etwas sehr Unangenehmes passieren kann…
Viele Grüße
Thomas
You must be logged in to reply to this topic.
