Performaceproblem bei RECOVER TOLASTCOPY

Ansicht von 13 Beiträgen - 1 bis 13 (von insgesamt 13)
  • Author
    Posts
  • 7. September 2005 um 15:31 Uhr #2596

    Anonym
    Gast

    Hallo liebes Forum,

    wir haben ein riesiges Laufzeitprobem beim RECOVER TOLASTCOPY. Die Tablespaces und Tabellen der Datenbank existieren im DB2-Subsystem ca. 20 Mal (mit jeweils unterschiedlichen Ownern und Qualifieren).

    (DB2-Version 7)

    Im voraus vielen Dank !!

    Eva

    8. September 2005 um 7:34 Uhr #3032

    Anonym
    Inaktiv

    RECOVER TOLASTCOPY läuft auf Tablespace-Ebene. Und "Datenbank.Tablespace" ist immer eindeutig im DB2-System. ( Es ist also egal, ob 1 ,10 oder 50 Tablespaces gleich heissen ). Die Tabellennamen sind für den RECOVER völlig ohne Bedeutung.

    Welcher Teil des RECOVERs ist denn so langsam ?

    Wie sichert Ihr die Daten ? ( Immer mit Full-Copy oder auch Incremental ).
    Schon mal alte Daten aus der SYSIBM.SYSCOPY gelöscht ? ( mit MODIFY RECOVERY ) und den System-Tablespace reorganisiert ?

    8. September 2005 um 9:54 Uhr #3336

    Anonym
    Gast

    Hallo Herr Mayer,

    wir arbeiten nicht mit incremental copy.
    Die SYSIBM.SYSCOPY ist bereits bereinigt und enthält nur die letzten drei Sicherungen dieser Datenbank.
    Welcher Teil des Recovers: im Monitor ist es der Select Nr. 7, der sich nicht einsehen läßt. Auch unsere anderen Tools wie InTune zeigen nichts.

    Danke im voraus !!

    Eva

    8. September 2005 um 12:07 Uhr #3528

    Anonym
    Inaktiv

    Hallo Eva,

    was heißt "Laufzeitproblem", hängt das Ding? Immer? In welcher Phase befindet sich der Recover? Was sagt der -DISPLAY Command?

    Wenn Ihr nicht mit Incremental Backups arbeitet, warum kein RECOVER TOCOPY ‚die letzte GDG‘? (Ich habe ein kleines REXX’le, das die Steuerkarte aus dem Catalog generiert inkl. Rebuild IX).
    Nochbesser, wenn Log Apply erfolgen sein: RECOVER ohne was, also "to current".

    Ciao
    Gernot

    8. September 2005 um 16:35 Uhr #3659

    Anonym
    Gast

    Hallo Gernot,

    der Recover hängt in der RELOAD-Phase.

    Auffälligkeiten: Tablespace mit 10 Tabellen, die es unter gleichem Namen, aber mit unterschiedlichen Creatoren im Subsystem ca. 30 mal gibt. Diese 10 Tabellen haben je 4 RI-Beziehungen.

    Der RECOVER TOCOPY ‚die letzte GDG benötigt die gleiche Laufzeit. RECOVER ohne was geht leider nicht, da die Sicherung herangezogen werden soll.

    Der Monitor zeigt enorme Waits auf dem Tablespace SYSDBASE der DSNDB07.

    Vielen Dank !!

    Eva

    8. September 2005 um 19:41 Uhr #3756

    Anonym
    Inaktiv

    Also, in der SYSDBASE sind die Tabellen:

    SYSCOLAUTH
    SYSCOLUMNS
    SYSFIELDS
    SYSFOREIGNKEYS
    SYSINDEXES
    SYSINDEXPART
    SYSKEYS
    SYSRELS
    SYSSYNONYMS
    SYSTABAUTH
    SYSTABLEPART
    SYSTABLES
    SYSTABLESPACE

    nachdem der RECOVER einfach einen VSAM-Cluster wiederherstellt, ohne dass ihn Tabellen, Indices, RIs oder sonstwas interessiert, muss als einzig relevante Tabelle die SYSTABLESPACE herhalten. Der Index darüber ist ( DATABASE , TABLESPACE ), und der ist unique.
    Auch möglich bei Partinioned Tablespaces ist die SYSTABLEPART ( aber 10 Tabellen im Tablespace, dann kann’s nicht partitioned sein ) .

    Wodurch können WAITs darauf entstehen ?
    – zu kleine Bufferpools ( haben Systemtablespaces eigenen Bufferpool ? )
    – Locks auf den DBD/TS ( läuft parallel dazu ein CREATE … , zeigt der Monitor irgendwas mit IRLM an ? )

    Hat das RECOVER-Utility überhaupt eine RELOAD Phase ?
    Lt. Denne gibt es eine
    – UTILINIT
    – RESTORE
    – RESTORER
    – RESTOREW
    – LOGAPPLY
    – UTILTERM
    Phase ??

    Sind die ImageCopies auf Band ? Kann es ein Problem mit den Band-Stataionen sein ?

    9. September 2005 um 15:00 Uhr #3818

    Anonym
    Gast

    Hallo Herr Mayer,

    mia culpa: der Recover hängt in der RESTORE-Phase.
    Parallele Läufe wurden ausgeschaltet.

    Der Tablespace wurde per fullimage-copy vorher auf DISC gesichert. Der Index wurde nicht gesichert. Partitioniert ist nichts.

    Eigenartig ist, daß immer nach drop der RI’s der Recover sehr schnell läuft.

    Werden die RI’s danach wieder angelegt, braucht das CHECK-Utility endlos lange.

    Nochmal vielen Dank !!

    Eva

    9. September 2005 um 15:35 Uhr #3858

    Anonym
    Inaktiv

    Tut mir leid, ich habe momentan keine Erklärung für dieses Phänomen mit der RI.

    10. September 2005 um 12:27 Uhr #3888

    Anonym
    Inaktiv

    Hallo Eva,

    nach dem Du mit den Mitteln eines DBA’s versucht hast das Problem zu analysieren und nichts gefunden hast, ist ja von einem DB2 Defekt auszugehen. Du solltest mal den Sysadmin fragen, wie gut das DB2 gepflegt ist. Welchen PTF-Stand hat der letzte Refresh?

    Es gibt einen älteren APAR’s/PTF’s von Juli 2004, der ein solches/ähnliches Problem zum Inhalt hat:

    PQ82758: DSNB5COM LOOP PMB POINTS TO ITSELF: http://www-1.ibm.com/support/docview.wss?rs=64&context=SSEPEK&dc=DB520&dc=D600&dc=DB530&dc=D700&dc=DB500&dc=DB540&dc=DB510&dc=DB550&q1=RECOVER+hang&uid=swg1PQ82758&loc=en_US&cs=utf-8&lang=en

    Ãœber DIAGNOSE MEPL Utility bekommst Du leider nicht heraus, ober der PTF installiert ist. DU mußt also jemanden zu Rate ziehen, der im SMP/E die SYSMOD’s prüfen kann. Der PTF zu PQ82758 heißt UQ84361.

    Hope that helps?!
    Gernot

    12. September 2005 um 13:51 Uhr #3910

    Anonym
    Gast

    Kleine Anmerkung: Eine PIT-Recovery setzt alle Child-Tablespaces in Check-Pending.
    Gibt es zu der Tabelle besonders viele Childs? Oder sind in dem DB2 besonders viel RI definiert, so das ein Scan auf SYSKEYS oder SYSRELS o. ä. besonders lang dauern würde?

    Gruß, Rolf

    12. September 2005 um 14:04 Uhr #3922

    Anonym
    Inaktiv

    Stimmt SYSADM. Das wird’s sein !

    Es gibt ja ca. 40 abhängige Tabellen dafür.

    ( Ich hätte das In-Check-Pending-setzen aber nicht in der RETORE-Phase vermutet ).

    Kann mich daran erinnern, dass ein REPORT TABLESPACESET auch mal so ewig lange gedauert hat.

    Was kann man dagegen tun ? Hilft ein REORG auf die SYSDBASE ?

    12. September 2005 um 15:20 Uhr #3933

    Anonym
    Gast

    Ich meine mich erinnern zu können das es von der IBM empfohlene Catalog-Indizes gibt, vielleicht fehlt da was. Bin mir aber nicht sicher, ob diese auch von Utilities benutzt werden.
    Was auf die Schnelle hilft, ist RI droppen und nachher wieder drauf-altern und evtl. mit -STA …. ACC(FORCE) starten (oder REPAIR NOCHECKPENDING) – aber nur falls die Daten es zulassen! Den Check kann man später nachholen (Scope all!), oder mit V8 sogar mit Shrlevel Change machen.

    Gruß, Rolf

    20. September 2005 um 16:50 Uhr #3942

    Anonym
    Gast

    Hallo liebes Forum,

    vielen Dank an alle, die mir zu dem Thema etwas geschrieben haben !!!
    Die Lösung hat die IBM im Mainz nun geliefert (neues PTF, erst wenige Tage alt).

    Herzliche Grüße !!

    Eva

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

You must be logged in to reply to this topic.