CLOB nach Reorg-Abend kaputt

Ansicht von 7 Beiträgen - 1 bis 7 (von insgesamt 7)
  • Author
    Posts
  • 27. Mai 2005 um 8:29 Uhr #2551

    Anonym
    Gast

    Hallo,
    wir betreiben ein DB2 Z/OS V7 und seit drei Monaten haben wir einen CLOB im Einsatz, der zwischenzeitlich auf 43 GB angewachsen ist. Der CLOB ist mit LOG=YES definiert.
    Einmal wöchentlich läuft ein Job der abgearbeitete Lobs löscht. Um diesen Platz auch wieder nutzen zu können und die Space-Allokation zu reduzieren haben wir einen Reorg mit anschließender Recovery über Base- und LOB-Table geplant.
    Der Reorg ist abgebrochen, hat einen Rollback gemacht und anschließend den LOB im Recovery-Pending-Status hinterlassen. Dem Recovery-Pending-Status folgend wurden Base- und Lob-Table Point-In-Time recovered.
    Danach war augenscheinlich erstmal alles in Ordnung, bis die Anwendung darauf zugegriffen hat und abgebrochen ist. Daraufhin wurde das CHECK-LOB-Utility ausgeführt und wies über 16tsd. defekte ROWIDs aus. ???
    Hat jemand schon einmal eine ähnliche Situation gehabt, und wie wurde dies gehandelt.
    Würde mich über jeden Beitrag dazu freuen.

    Gruß
    rollo

    1. Juni 2005 um 10:28 Uhr #3001

    Anonym
    Gast

    Hallo Rollo,

    wir hatten mal so ein ähnliches Problem. Daraufhin haben wir die LOBs ausgebaut und die Anwendung umgeschrieben, leider kein Witz!
    Die Space-Verwaltung in LOBs ist eine einzige Katastrophe, speziell bei Updates! Deshalb nehmen wir keine LOBs mehr in Betrieb die geändert werden.
    Wir haben damals versucht die Space-Verwaltung nachzuvollziehen, dazu gibts auch ein Redbook (müßte ich mal nach suchen wenns dich interessiert).

    Als konkrete Aktion würd‘ ich mal diverse Checks machen (hast du ja auch schon). Ansonsten: PMR eröffnen und den ganzen Mist an die IBM (DDL + DSN1DUMP, vielleicht auch Repro der LSDSe)! Vielleicht können die es reparieren….
    Selber würde ich nicht mehr viel dran machen, denn je mehr man macht umso kaputter wird das Ding und umso schwieriger wird es für IBM es zu korrigieren.

    MfG Rolf

    1. Juni 2005 um 11:23 Uhr #3315

    Anonym
    Gast

    Hallo Rolf,
    erst einmal vielen Dank für die Rückmeldung.
    Bis auf den LOB selbst, hat die IBM alles was rund um dieses Problem an Unterlagen existiert hat bekommen.
    Wenn Du das Redbook ‚Large Objects with DB2 for z/OS and OS/390‘ meinst, das liegt uns vor.
    Mittlerweile gibt es in der Anwendung Überlegungen von der LOB-Technik wieder abzurücken.
    Bis dahin werden wir halt Sicherungsmechanismen einsetzen (Sicherung vor Reorg, Check nach Rorg etc.), obwohl die eigentlich nicht erforderlich wären, wenn der LOB mit LOG=YES definiert ist.

    Gruß
    rollo

    1. Juni 2005 um 11:51 Uhr #3514

    Anonym
    Gast

    Hi Rollo,

    ja, das war das Redbook. Mit dem ‚eigentlich‘ ist das so eine Sache…
    Damals haben wir vom Labor auch nur ein deutliches Achselzucken gehört, wirklich helfen konnte man uns da nicht. Frag doch mal die IBM ob sie empfehlen würde bei dem LOB zu bleiben…
    Das waren richtig stressige Tage. War zwar mal ganz interessant in den Chunks rumzuwühlen, aber genutzt hat das alles nix!
    M. E. investiert die IBM an der Stelle viel zu wenig. Der gesamte LOB-Support ist schlecht, s. a. Unload/Load-Möglichkeiten.
    Das Problem ist natürlich, das man in so einem Fall erstmal recovert statt alles direkt an die IBM zu schicken. Und damit kommen die ersten Veränderungen wieder rein.
    Finden auf eurem LOB updates statt? Würd mich echt interessieren, ob die IBM sowas noch empfiehlt… Ich jedenfalls lasse die Finger davon – ein gebranntes Kind scheut das Feuer!

    MfG Rolf

    1. Juni 2005 um 12:21 Uhr #3652

    Anonym
    Gast

    Hallo Rolf,
    nein, Updates werden keine gemacht aber eine große Menge Inserts tgl. und einmal wöchentlich ein Massen-Delete.
    Erstaunlich war aus unserer Sicht, als wir den kaputten Lob der IBM meldeten, gleich die Frage kam, ob wir den Lob reorganisiert hätten. ???
    Desweiteren muß man das Check-Lob-Utility in Frage stellen. Lt. Anwendung wurden von dem Utility nicht alle defekten Rowid’s erfasst. Beim ersten Versuch haben wir nur tausend Exceptions angegeben, was aber nicht ausreichte. Im zweiten Versuch haben wir dann das Utility mit 1Mio. Exceptions laufen lassen, worauf ein Sysprint mir ca. 900tsd. Lines ausgegeben wurde, mit der Annahme, dass alles erfasst wurde, was sich letztendlich als Trugschluß erwiesen hat.

    Gruß
    rollo

    1. Juni 2005 um 14:00 Uhr #3752

    Anonym
    Gast

    Inserts und Massen-Delete hört sich nicht so schlecht an. Bei uns wurden Updates gemacht, bei denen sich der LOB immer verlängerte und deshalb nicht an die alte Stelle zurückgeschrieben werden konnte. Dadurch kam es zu erheblichen Space-Verbrauch, habs nicht mehr genau im Kopf, aber igendwann haben wir bestimmt auch reorgansisiert.

    Könnt ihr den LOB auch durch die Anwendung wieder aufbauen?

    MfG Rolf

    2. Juni 2005 um 5:13 Uhr #3816

    Anonym
    Gast

    Hallo Rolf,
    ja, über die Anwendung lassen sich die fehlenden Daten mühselig, aber Gott sei Dank wiederherstellen.

    Gruß
    rollo

  • Author
    Posts
Ansicht von 7 Beiträgen - 1 bis 7 (von insgesamt 7)

You must be logged in to reply to this topic.