DB2-Z OS / Löschen der SYSLGRNX
- Dieses Thema hat 8 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 17 Jahre von
Anonym.
-
AuthorPosts
-
22. August 2006 um 12:39 Uhr #2718
AnonymInaktivHallo liebe Forumsteilnehmer
unsere SYSLGRNX ist inzwischen ca. 20 Cyls. groß geworden. Eine Analyse ergab, daß sich da Sätze drin befinden
welche ziemlich alt sind – so um die 10 jahre.Nun gibt es einen den Installations.-job um diese Tabelle neu zu initialisieren.
Die Frage ist nun: kann man dies machen Рwelche Probleme k̦nnten den da auftreten.Mfg
zefrim
24. August 2006 um 16:08 Uhr #3113
AnonymInaktivHallo Zefrim,
20 Cyls sind ja nun nicht wirklich beunruhigend, vermutlich ist dies eher von akademischem Interesse für Dich.
Eine interessante Frage! Scheinbar kann man tatsächlich SYSLGRNX neu anlegen (eine Sicherungskopie empfiehlt sich). Um den Mechanismus wieder in Gang zu bekommen sollte man vermutlich Full Offline Backups von allen Objekten erstellen und dann das System durchstarten (Stop/Start). Ein Recover auf eine RBA davor könnte problematisch werden.
Viel Erfolg & Gruß
GernotPS: Der Ausgang Deines Experiments interessiert mich sehr!!! 🙂
25. August 2006 um 8:57 Uhr #3391
AnonymInaktivHallo Zefrim
Wenn du nur die alten Einträge löschen willst.
Mit dem Modify Utility können die alten Einträge gelöscht werden.
Natürlich muss über jeden Tablespace ein Modify laufen.
Beispiel:
MODIFY RECOVERY TABLESPACE DSNDB01.SCT02 DELETE AGE(32)
MODIFY RECOVERY TABLESPACE DSNDB01.SPT01 DELETE AGE(32)
MODIFY RECOVERY TABLESPACE DSNDB01.SYSLGRNX DELETE AGE(32)
MODIFY RECOVERY TABLESPACE DSNDB06.SYSDBASE DELETE AGE(32)
MODIFY RECOVERY TABLESPACE DSNDB06.SYSDBAUT DELETE AGE(32)
MODIFY RECOVERY TABLESPACE DSNDB06.SYSDDF DELETE AGE(32)
.
.
.
.
.
.
MODIFY RECOVERY TABLESPACE DSN8D81U.NEWPHONE DELETE AGE(32)Alle Einträge älter als 32 Tagen werden hier gelöscht. Wieviele Tage man löschen will, entscheidet das Backupkonzept. Wir behalten die Backups nur 30 Tagen, das heisst ich kann/muss nie auf einen Zeitpunkt älter als 30 Tage zurückrecovern.
Damit der allozierte Space wieder freigegeben wird muss natürlich noch ein Reorg gemacht werden.mfg
Piff
29. August 2006 um 6:48 Uhr #3564
AnonymInaktivAlso – nach Rückfrage bei der IBM kann man die SYSLGRNX neu initialisieren.
man verwendet die beiden jobs://DSNTU02 EXEC DSNTIN,SAMP=DSNTIS02,LIB=SYSLGRNX Â
//DSNTU73 EXEC DSNTIN,SAMP=DSNTIS73,LIB=DSNLLX01 Â
//DSNTU74 EXEC DSNTIN,SAMP=DSNTIS74,LIB=DSNLLX02 ÂDie jobs stehen in der SAMPLIB und werden beim erstmaligen Einrichten von einem DB2 zur Initialisierung verwendet.
Nun wenn man das in einem laufenden System macht , was ich inzwischen getan habe, so werden bei einer
evtl. Recovery eines Tablespaces alle archivierten Logbänder herangezogen und nicht mehr nur diejeniger welche auch
tatsächlich verwendet werden würden. Dies gilt solange bis man auf alles wieder eine Sicherung gemacht hat.
Danach verhät sich das DFb2-System so als ob nie etwas manipuliert worden wäre.Gruß
Zefrim
31. August 2006 um 12:41 Uhr #3688
AnonymInaktivHallo Zefrim,
Hast du die SYSCOPY auch durchsucht, ob du da alte Einträge drin hast? Habe mal bei mir mal eine  Auswertung gemacht und zu meinem Erstaunen Einträge gefunden, die teilweise 3 Jahre alt sind:
Â
Wäre es nicht sinnvoll, dann die SYSCOPY vor einer Komplettsicherung auch zu initialisieren?by the way: wie hast du eigentlich die alten Einträge in der SYSLGRNX gefunden? Mit SQL-Mitteln ist die ja nicht zugänglich. Oder gibt es da einen Trick dazu?
Grüsse, Freso              Â
1. September 2006 um 8:42 Uhr #3776
AnonymInaktivwie ich das gemachte habe?
mit folgendem Job:
//REPRO EXEC PGM=IDCAMS Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
//DDIN Â Â DD DISP=SHR,DSN=DB2P.DSNDBC.DSNDB01.SYSLGRX.I0001.A001 Â Â
//DDOUT Â Â DD DSN=xxxx.syslg,SPACE=(CYL,(50,40),RLSE),UNIT=SYSDA, Â Â Â
// Â Â Â Â DISP=(,PASS,DELETE),DCB=(RECFM=FB,LRECL=4096) Â Â Â Â Â Â
//SYSPRINT DD SYSOUT=* Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
//SYSIN Â Â DD * Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
REPRO INFILE(DDIN) Â OUTFILE(DDOUT) Â Â REUSE Â Â Â Â Â Â Â Â Â Â Â Â
/*
den kann man ablaufen lassen auch während das DB2-System aktiv ist.dann habe ich ein Analyse-PGM, welches ich selbst erstellt habe, ablaufen lassen. Diese PGM liest die Sätze
von xxxx.syslg und erstellt mit diesen Daten ein DB2-tabelle in der folgende Angaben stehen:DBID Â Â Â Â Â Â Â Â SMALLINT
PSID Â Â Â Â Â Â Â Â SMALLINT
MOD_TIMESTAMP Â Â Â TIMESTMP
START_RBA Â Â Â Â Â CHAR Â Â
STOP_RBA       CHAR  Âda kann man festestellen, welche Objekte verändert wurden. Man Sieht auch am Datum wie alt die Einträge sind.
Grundsätzlich gilt: Beim Modify werden auch alle einträge in der SYSLGRNX gelöscht . Allerdings nicht für die vergangenen Versionen. Ich glaub erst ab V7 ist dies der Fall. Desweiteren wenn man eine tabelle droppt und keinen Moidify vorher macht
bleiben die Sätze auch in der SYSLGRNX.Gruß Zefrim
28. September 2006 um 11:15 Uhr #3833
AnonymInaktivHallo zusammen,
Ich hätte nochmals eine Zusatz-Frage:
Nach Analyse der SYSLGRNX-Einträge habe ich festgestellt, dass einige Sätze in der SYSLGRNX keine ENDRBA haben.
Beim Kopieren enes Systems und anschliessendem RECOVER LOGONLY greift dann das DB2 aber zu weit zurück, teilweise so weit, dass die Archiv-logs nicht mehr vorhanden sind.
Gibt es eine Möglichkeit, diese hängengebliebenen LOG-Records mit einer END-RBA zu versehen. Ein MODIFY RECOVERY löscht diese Sätze nämlich nicht (nicht mal mit AGE(0)!!).
Und ein komplettes Löschen der SYSLGRNX möchte ich umgehen.
Vielen Dank im Vorraus für eure Hilfe und Vorschläge
28. September 2006 um 12:25 Uhr #3868
AnonymInaktivrein "aus dem Bauch heraus" könne ein QUIESCE Utility auf den Tablespace helfen. Vielleicht erkennt DB2 dadurch, dass keine offene UOW für den Tablespace vorliegt und schliesst den SYSLGRNX-Eintrag.
Alternativ mal einen -STO DB() SPACE() versuchen.
28. September 2006 um 14:15 Uhr #3896
AnonymInaktivHallo Ulrich,
Das Bauchgefühl war richtig, QUIESCE TABLESPACE hat das problem erledigt.
Danke, 🙂
-
AuthorPosts
You must be logged in to reply to this topic.
