Tips für 40-fach parallel Zugriffe

Ansicht von 4 Beiträgen - 1 bis 4 (von insgesamt 4)
  • Author
    Posts
  • 13. September 2011 um 6:55 Uhr #4132

    Anonym
    Inaktiv

    Hallo zusammen,

    da ihr mir schon häufig in schwierigen Situationen mit euren Ideen und Anregungen weitergeholfen habt, wende ich mich heute an euch. Ich hätte gerne Tunigtips für die folgende Situation.

    Wir haben im Rahmen eines Migrationsprojektes massive UPDATEs auf im Wesentlichen einer DB2-Tabellen zu machen.

    Mengengerüst:

    TAB hat 50 Mio rows und existiert redundant auf 4 DB2-Locationen. Die Tabelle ist 10-fach partitioniert nach dem eingestellten Objektschlüssel. (Table-partitioned)
    Auf die Tabelle wird auch während der Migration von diversen Prozessen zugegriffen. Daher suchen wir nach einer Systematik, die den Zugriff durch Dritte während der Migration zuläßt.

    Es müssen ca. 10% aller Rows per UPDATE manipuliert werden. Der Objektschlüssel bleibt unverändert, es werden lediglich 2 columns verändert.
    Diese befinden sich nicht im primary index oder im clustering index, allerdings in einem weiteren Index.

    Bisher haben wir den Ansatz, dass unsere Anwendung in einer LUW (Logical UNIT of WORK) immer alle 4 Lokationen für den gleichen key UPDATED. Dass bedeutet egal in welcher Lokation während unserer Migration gelesen wird, der key 4711 liefert immer Attribut A in jeder Lokation.
    Deshalb werden in einer LUW 100 Objektids in ein der ersten Lokation upgedated, dann folgt der CONNECT auf die 2. Lokation. Jetzt werden hier die gleichen 100 Objektsids upgedated usw. mit Lokation 3 + 4. Danach geht es mit den nächsten 100-Päckchen weiter (Hintergedanke: Anzahl CONNECTS – weil zeitaufwendig – reduzieren).

    Heutige Vorgehensweise:

    1. Beschaffung der 100%-UPDATE-Menge (Objektkeys) per SQL (DSNTIAUL-SELECT). Zeitlich unkritisch < 2 Minuten

    2. Zerlegung der Menge von 1. in 40 gleichgroße Teile per SORT.

    3. Ausführung von 40 parallelen PGM-Instanzen jeweils mit 1/40 der Daten. Ursprüngliche gelegentliche SQLOCDE -904 (Timeouts + Deadlocks) wurden durch Änderung des ursprünglichen lock levels von ANY auf ROW behoben. Die Programme arbeiten jetzt ohne Kollisionen! Dieser Prozess wird laut Hochrechnung 8-10 Stunden brauchen. Leider hat sich die Performance (Upadates/Minute) durch die Änderung des lock levels nicht verändert. Das hatten wir uns sehr erhofft!

    Welche Maßnahmen / Analysen haltet ihr für sinnvoll?

    Plattenverteilung? (wir haben nur eine Storagegroup)
    Verfahrensänderung (da Anwendungs-PGM nicht einfach)
    DB2-Parameter?
    etc.

    Ich freue mich auf eure Anregungen / Fragen.

    Gruss Klaus

    15. September 2011 um 9:55 Uhr #4279

    Anonym
    Inaktiv

    Hallo Klaus,

    ich hätte da spontan folgende Anmerkungen:

    Hast du die Möglichkeit einen DB2 Accounting Report zu starten ( DB2PM oder andere Monitore ) ?
    Hier wäre interessant zu sehen wie die Verhältnisse der class 1,2 und 3 Zeiten sind. Sollten die class 3 Zeiten
    einen wesentlichen Anteil an der elapsed time haben, wäre ein Blick auf die entsprechenden Wait counter sinnvoll um
    dann entsprechend reagieren zu können.

    Ich gehe mal davon aus dass du bei der Zerlegung der Daten per sort gleichzeitig auch nach dem Objektschlüssel ( bzw. dem clustered key ) sortierst.

    Auf wieviel Platten sind die Daten verteilt ? RMF reports bieten die Möglichkeit entsprechende Schwachpunkte aufzudecken ( I/O Queuing usw. ).

    So long and good luck

    Rocket

    15. September 2011 um 11:50 Uhr #4383

    Anonym
    Inaktiv

    Hallo Klaus,

    ich könnte mir vorstellen das viel Zeit für die Pflege der Indizes draufgeht (bei 50 Mio. Rows vermutlich 4 Levels) – droppen von Indizes für Zeit des Updates könnte da was bringen, nachher wieder mit Defer Yes und Rebuild aufbauen. Aber das ist vermutlich nicht drin.
    Hat der TS etwas Freespace, so das die Updates nicht zu Relocated Rows führen?
    Das PG könnte auf Rowset-Processing umgestellt werden, aber das würde nur was bringen wenn das Problem die Kommunikation zwischen DB2 – PG wäre.
    Der TS kann auf not logged umgestellt werden, allerdings würde dann ein Rollback (!) den TS/Partition in Recover-Pending-State setzen.
    Ich denke auch das die Class3-Zeiten hoch sind, also IO-Suspensions, und die kommen von den Indizes.
    Wichtig ist zu wissen ob das Problem nicht der Connect ist. Verbessert sich die Performance wenn ihr in einer UoW 1000 Updates durchführt?

    Viele Grüße
    Rolf

    19. September 2011 um 10:46 Uhr #4455

    Anonym
    Inaktiv

    Hallo Rolf,
    danke für deine Anregungen. Da wir wie geschrieben nach einer Systematik suchen, die den Zugriff durch Dritte während der Migration zuläßt, kommt für uns das droppen der "Balast-Indizes" während der Migration leider nicht in Frage.

    Gruss Klaus

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

You must be logged in to reply to this topic.