SQL @ DB2 auf z/OS - gezielt Partitionen ansprechen

[Asaraki]

Weiss nicht ob hier jemand mit DB2 (auf OS/390, z/OS) arbeitet, aber wenn :

- Gibt's Möglichkeiten per Command die Partition(en) zu setzen für welche das nachfolgende SQL gilt?

like SET SQLPARTITON = '1'; oder sowas *g*

Konkret will ich einen Data-Extrakt 16fach splitten um paar Minuten rauszukitzeln und müsste dann natürlich die einzelnen Jobs auf einen Teil der Partitionen begrenzen.

Daaaaanke & Gruss Asa

[samm]

Ich arbeite mit DB2 auf Linux und habe nie wirklich mit Partitionen gearbeitet, aber kann vielleicht trotzdem helfen ;) Was das bedeuten soll:like SET SQLPARTITON = '1';ist mir aber schonmal sehr unklar.

Ich glaube, man kann nicht spezifizieren, auf welcher Partition etwas ausgeführt wird. Allerdings kennst du ja die Kriterien, mit welcher die Partitionen erstellt wurden. Wenn du nur auf Daten arbeiten lässt, welche die Kriterien der gewünschten Partition erfüllen, wird nur diese Partition benutzt. Wenn du über einen Datenbereich, der mehrere Partitionen betrifft, arbeiten lässt, werden doch sowieso nur die betroffenen Partitionen benutzt.


Oder redest du von DB Partitions?

[daflow]

Hab leider auch keine z/OS Erfahrung, so du von partitionierten Tabellen redest im Sinne von OSY-DB2, versteh ich auch nich so ganz wo da der Performancegewinn sein soll ;)

SQL-Syntax kannste dir für jedes z/OS, OS/390 hier aussführlichst anschauen
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp
Für V9.1 findet sich die Referenz z.B. hier http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.sqlref/db2z_sql_select.htm

[Gast]

Ich kenne mich zwar mit DB2 nicht aus, aber partitionierte Tabellen bringen natürlich i.d.R. eine Performancesteigerung (sonst gäbe es ja keine partitionierten Tabellen). Der Sinn ist ja die Abfragelast zu reduzieren, indem die Daten kategorisch in unterschiedliche Tabellen ausgelagert werden (z.B. eine Tabelle für Jahr 2007, eine für 2008 etc.), aber einheitlich als logische ganze Tabelle agieren. Eine garantierte Performancesteigerung sollte man aber erzielen, wenn die Partitionen in unterschiedlichen Filegroups liegen, die sich auf unterschiedlichen Festplatten befinden. Dann kann man natürlich parallel lesen (wobei das in einem großen SAN schon nicht mehr so einfach funktioniert).

[daflow]

Ich kenne mich zwar mit DB2 nicht aus, aber partitionierte Tabellen bringen natürlich i.d.R. eine Performancesteigerung (sonst gäbe es ja keine partitionierten Tabellen). Der Sinn ist ja die Abfragelast zu reduzieren, indem die Daten kategorisch in unterschiedliche Tabellen ausgelagert werden (z.B. eine Tabelle für Jahr 2007, eine für 2008 etc.), aber einheitlich als logische ganze Tabelle agieren. Eine garantierte Performancesteigerung sollte man aber erzielen, wenn die Partitionen in unterschiedlichen Filegroups liegen, die sich auf unterschiedlichen Festplatten befinden. Dann kann man natürlich parallel lesen (wobei das in einem großen SAN schon nicht mehr so einfach funktioniert).

Ach ne X-D Es stellt hier auch keiner in Frage, das partitionierte Tabellen u.a. performantere Zugriffe erlauben. Es stellt sich viel eher die Frage was der TE unter einer Partition im Zusammenhang mit DB2 auf z/OS (und auf dem Großrechner sind nunmal viele Begrifflichkeiten und Mechanismen anders ;)) versteht. Und falls es dabei wirklich um partitionierte Tabellen geht, wo der Sinn darin sein soll, einen Sql auf eine Tabellenpartition zu beschränken :upara:
Ich kenne hier nur 2 Architekturen:
1. Eine Tabelle ist nach einem bestimmten Schlüssel auf die Physik aufgeteilt -> Je nach Bedingung verwendet das DBMS also die Partition(en), in denen die Bedingung zutrifft. Der Zugriff auf die richtige(n) Partition(en) über den Schlüssel erfolgt so schnell, das man sich nix sparen würde, wenn man vorher einschränkt, welche Partition er verwenden soll
2. Shared Nothing: Alle Daten sind auf allen Datenknoten (aka Servern) der partitionierten Umgebung vorhanden -> Ein Select wir dan den Koordinationsserver abgegeben und der entscheidet dann, welchen Teil der Daten er auf welchem Node wie zusammentragen lässt... Das macht das DBMS imho höchstwahrscheinlich performanter, als wenn man selber anfängt ein bischen was heir und ein bischen was da berechnen zu lassen :upara:

[Gast]

Der Zugriff auf die richtige(n) Partition(en) über den Schlüssel erfolgt so schnell, das man sich nix sparen würde, wenn man vorher einschränkt, welche Partition er verwenden soll


Das habe ich jetzt nicht so ganz verstanden. Was sparst du dir womit nicht?

Punkt 2 hat für mich nichts mit Partitionierung zu tun.

Aber du hast Recht, mit den Begriffen kann letztendlich was ganz anderes gemeint sein.

[daflow]

Das habe ich jetzt nicht so ganz verstanden. Was sparst du dir womit nicht?

Punkt 2 hat für mich nichts mit Partitionierung zu tun.

Aber du hast Recht, mit den Begriffen kann letztendlich was ganz anderes gemeint sein.

Damit


- Gibt's Möglichkeiten per Command die Partition(en) zu setzen für welche das nachfolgende SQL gilt?
like SET SQLPARTITON = '1'; oder sowas *g*
Konkret will ich einen Data-Extrakt 16fach splitten um paar Minuten rauszukitzeln und müsste dann natürlich die einzelnen Jobs auf einen Teil der Partitionen begrenzen.


spart man sich imho eben nix (Im Sinne von: dadurch wirds auch nicht schneller), wenn wir hier eben von einer partitionierten Tabelle ala Szenario 1 reden. ;)

In Szenario 2 versteht man unter Partition eben jeden Datenknoten als Partition -> Jeder Knoten beinhaltet die komplette Datenbank (siehe z.B. http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.bcu.doc/c0012221.htm Architekturbeispiel für die etwas betagte DB2 V8.1)


Nachtrag: beim Ansehen der Beispiele ist mir noch eine idee gekommen, wie das ganze Sinn machen könnte:
Falls man einen Select gegen den Coordinator schickt und er lässt diesen (also den kompletten SQL) immer nur auf einem Datenknoten laufen (aber verteilt halt weitere SQLa als Loadbalancer auf die einzelnen Datenknoten), könnte man mit einer festen Zuweisung der "Partition", eben festelegen, das die 16 SQLs auf 16 verschiedenen Knoten laufen. Selbst dann macht das aber der Coordinatornode selbst wahrscheinlich geschickter, weil der z.B. weiß das node16 halt z.B. für die nächste halbes Stunde ausgelegt ist weil da grad schon der MörderSQL schlechthin läuft ;)


@Asaaaa: klär uns unwissende nicht-Mainframer mal auf, was du unter Paartition verstehst ;)

[Gast]

spart man sich imho eben nix (Im Sinne von: dadurch wirds auch nicht schneller), wenn wir hier eben von einer partitionierten Tabelle ala Szenario 1 reden. ;)


Wenn die Tabelle schon partitioniert ist, was ist dann das Problem? Wenn etwas partitioniert ist, gibt es ja keine Redundanzen. Aber ich glaube ich verstehe, was du meinst bzw. was mit dem Statement vom Ursprungsposter gemeint war.


In Szenario 2 versteht man unter Partition eben jeden Datenknoten als Partition -> Jeder Knoten beinhaltet die komplette Datenbank (siehe z.B. http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.bcu.doc/c0012221.htm Architekturbeispiel für die etwas betagte DB2 V8.1)


Das habe ich schon verstanden, nur hat das für mich nichts mit Partitionierung von Daten zu tun. Das kenne ich nur unter dem Begriff distributed query. Aber da hat wohl jeder Hersteller seine eigene Terminologie.

Letztendlich wollt ihr doch parallel lesen. Dann entweder über die Methode von Peta bzw. was ich unter distributed query verstehe oder aber ihr legt die Tabellen auf unterschiedliche Festplatten, so dass das DBMS seine Query parallelisieren kann (natürlich sofern es das DBMS kann).

[daflow]

Wenn die Tabelle schon partitioniert ist, was ist dann das Problem? Wenn etwas partitioniert ist, gibt es ja keine Redundanzen. Aber ich glaube ich verstehe, was du meinst bzw. was mit dem Statement vom Ursprungsposter gemeint war.



Das habe ich schon verstanden, nur hat das für mich nichts mit Partitionierung von Daten zu tun. Das kenne ich nur unter dem Begriff distributed query. Aber da hat wohl jeder Hersteller seine eigene Terminologie.

Letztendlich wollt ihr doch parallel lesen. Dann entweder über die Methode von Peta bzw. was ich unter distributed query verstehe oder aber ihr legt die Tabellen auf unterschiedliche Festplatten, so dass das DBMS seine Query parallelisieren kann (natürlich sofern es das DBMS kann).


So seh ich das aus, ausser es geht hier um komplett andere Host-Begrifflichkeiten (Meine Kollegen von der OS390-DB-Administration und ich können stundenlang aneinenader vorbeireden, ohne das wir gegenseitig nur ein Wort von dem verstehen, was der andere meint, bzw. es eben falsch verstehen ;) ).
Da kömmen wir aber nich weiter ohne Mainframler oder Asa :upara:

[CrazyIvan]

Wenn ich das richtig verstanden habe, dann möchte der TE einen ETL-Job o.ä. durch Parallelisierung beschleunigen. Warum die Daten anhand der Partition gehackstückt werden sollen, ist mir auch nicht klar. Man könnte die Quelldaten des Jobs auch nach beliebigen anderen Kriterien zerteilen und dann den Job parallel laufen lassen.

Aber ohne weitere Infos des TE ist das wohl alles Spekulatius ^^

[Gast]

Also irgend etwas von ETL habe ich hier überhaupt nicht rausgelesen.

[Gast]

^^ Wobei, wo ich gerade drüber nachdenke, vielleicht meint der TE ja doch ETL. Ich hatte jetzt eher an eine einzelne Query gedacht, die durch Daten Partitionierung beschleunigt werden sollte. Da sollte der TE jetzt mal uns erleuchten.

[Asaraki]

Hallo zusammen

Hui da hab ich was losgebrochen - sorry war die letzten 24h ziemlich im Saft *g*

Naja... ich bin eben garnicht der DB2 Mensch... bin eigentlich normaler Programmierer ohne besonderes Kenntnisse, daher weiss ich zum Teil jetzt garnicht was ihr diskutiert habt *g*

Also... mit Partition meine ich eine simple Partitionierung der Tabelle, erstellt durch Bereiche des PKEYs... also 0-999 auf P1, 1000-1999 auf P2... wobei die nicht ganz so linear sind (sind anhand der Verteilung auf ungefähr gleich grosse Partitionen ausgerichtet).

Ich habe nun Programm X mit Cursor A welcher aktuell alle Daten von allen Partitionen verarbeitet. Der Auftrag an mich war nur das Programm - läuft akt. als Singlejob - aufzusplitten und etweder 8x oder 16x zu parallelisieren. Natürlich bleibt die CPU-Zeit die gleiche, aber die elapsed time für den Extrakt wird sinken. Meine erste Idee war halt, dass man dem irgendeine Einschränkung auf Partitionen geben muss... also eben quasi dem Job A zu sagen er soll Partition 1-8 abarbeiten, Job B dann 9-16 und soweiter.

Anscheinend geht das aber am einfachsten über die Bereiche des Primary Keys die auf den entsprechenden Tabellen ja abgedeckt sind. Meine Idee war halt effektiv auf Partitionen zu setzen statt auf Keybereiche.. aber das ist eh blöd wie mir jetzt klar ist. Wenn nämlich mehr Partitionen erstellt werden (aktuell glaub ich sinds 128 auf der Tabelle), dann wären die Keybereiche noch 'gut' fürs splitten, die starre Allozierung auf Partitionen müsste aber angepasst werden.

Fragen :
Was ist ein ETL-Job? *g*
edit : Grad gelernt. Naja, E & T stimmen... aber Load wird ned gemacht. Ist ein klassischer SQL => File => per FTPS nach anderswo und dort wird dann geladen.


PeTa... jo Mainframe is immer noch en prähistorische Welt mit eigenen Regeln, eigenen Begrifflichkeiten *g* Man liebts oder man hassts... ;-)


mit dankenden grüssen,
Asa - der jetzt einen guten DB2 Kurs besuchen will... mal nett fragen ob mich die Firma zu IBM schickt ^^

[Asaraki]

Hab leider auch keine z/OS Erfahrung, so du von partitionierten Tabellen redest im Sinne von OSY-DB2, versteh ich auch nich so ganz wo da der Performancegewinn sein soll ;)

SQL-Syntax kannste dir für jedes z/OS, OS/390 hier aussführlichst anschauen
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp
Für V9.1 findet sich die Referenz z.B. hier http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.sqlref/db2z_sql_select.htm

Nur damit wir uns verstehen : Der Performancegewinn ist natürlich nicht vorhanden - wohl aber eine verkürzte elapsed time overall. Das ist eben wieder sowas... wenn ich hier mit dem Kollegen von "tunen" rede, dann nicht von weniger CPU-Zeit für die gleiche Arbeit, sondern die gleiche Arbeit in weniger Realtime. Wir haben halt nur ein Fenster von 9 Stunden jede Nacht und müssen in diesen 9h ne ziemliche Menge Daten verarbeiten.

(Hintergrund ist Bank und Zahlenjonglieren ;-)

[Gast]

Wenn nämlich mehr Partitionen erstellt werden (aktuell glaub ich sinds 128 auf der Tabelle), dann wären die Keybereiche noch 'gut' fürs splitten, die starre Allozierung auf Partitionen müsste aber angepasst werden.


Kannst du die Daten nicht sinnvoller partitionieren wie z.B. Monat/Jahr? Um wie viele Datensätze geht es denn? Wenn ihr schon 128 Partitionen habt, dann müssen das ja hunderte Millionen oder gar Milliarden von Datensätzen sein? Da ist dann IO der absolut limitierende Faktor, deswegen solltest du die Partitionen auf unterschiedliche Festplatten verteilen. Oder sowas wie Peta machen bzw. distributed queries. Wenn ihr aber eh schon einen Mainframe habt, dann werdet ihr sicher nicht noch zwei/drei weitere danebenstellen können?! Aber mit Mainframes kenne ich mich leider auch nicht aus bzw. weiß ich nicht, wie die technisch aufgebaut sind und was die so leisten können.

[CrazyIvan]

Nur so nebenbei: Klingt mir sogar verdammt nach ETL. Das L ist dann erstmal das Laden in ein Flatfile. Bei dem Rest bin ich allerdings raus. Verstehe beispielsweise nicht, wieso man dafür einen Cursor braucht. Und wieso die Query (oder was auch immer) nicht sowieso schon parallel arbeitet, wenn man schon so viele Partitionen hat. Auch stellt sich die Frage, wo eigentlich der Flaschenhals ist. Ist es I/O, da die Datenmenge hoch ist, oder ist es CPU-Zeit, da die Verarbeitung der Daten recht aufwändig ist.
Bei ersterem sollte die Partitionierung allein schon helfen, sofern die Partitionen physikalisch verteilt gespeichert werden. Bei Letzterem würde ich anhand des PK oder etwas ähnlichem (Datum ist auch immer gut) die Datenmenge in n-Teile teilen und den Job n-mal parallel aufrufen.

Gerade bei ETL sollte man allerdings auch manchmal an anderen Stellen ansetzen, um Optimierungen zu erreichen. Beispielsweise ist es fraglich, ob immer die Gesamtheit Eurer Daten extrahiert werden muss, oder ob man nicht vielleicht auch nur neue und geupdatete Datensätze identifizieren und ausleiten könnte. Das würde allerdings etwas mehr Aufwand und vor allem Kooperation mit Eurer Gegenstelle voraussetzen. Zeitgemäß ist es jedenfalls nicht mehr, täglich ALLE Daten auszuleiten.

[Asaraki]

Nur so nebenbei: Klingt mir sogar verdammt nach ETL. Das L ist dann erstmal das Laden in ein Flatfile. Bei dem Rest bin ich allerdings raus. Verstehe beispielsweise nicht, wieso man dafür einen Cursor braucht. Und wieso die Query (oder was auch immer) nicht sowieso schon parallel arbeitet, wenn man schon so viele Partitionen hat. Auch stellt sich die Frage, wo eigentlich der Flaschenhals ist. Ist es I/O, da die Datenmenge hoch ist, oder ist es CPU-Zeit, da die Verarbeitung der Daten recht aufwändig ist.
Bei ersterem sollte die Partitionierung allein schon helfen, sofern die Partitionen physikalisch verteilt gespeichert werden. Bei Letzterem würde ich anhand des PK oder etwas ähnlichem (Datum ist auch immer gut) die Datenmenge in n-Teile teilen und den Job n-mal parallel aufrufen.

Gerade bei ETL sollte man allerdings auch manchmal an anderen Stellen ansetzen, um Optimierungen zu erreichen. Beispielsweise ist es fraglich, ob immer die Gesamtheit Eurer Daten extrahiert werden muss, oder ob man nicht vielleicht auch nur neue und geupdatete Datensätze identifizieren und ausleiten könnte. Das würde allerdings etwas mehr Aufwand und vor allem Kooperation mit Eurer Gegenstelle voraussetzen. Zeitgemäß ist es jedenfalls nicht mehr, täglich ALLE Daten auszuleiten.

Ok dann ist es ETL :-) Eben halt Flatfile, dachte das gilt nur wenn man wieder DBs ladet.

Hmm muss ich mich irgendwo ungenügend präzis ausgedrückt haben. Es ist natürlich eine Teilmenge der Daten, konkret die für diesen Tag relevanten Rows (Geschäftsfälle) die mit einem nicht ganz unkomplizierten Select ermittelt wird.

@ Gast : Eine Partitionierung nach Zeit macht keinen Sinn bei uns, da wir die Tabellen alle und überall nach demselben Primarykey (quasi deine Kontonummer) partitionieren. Das hat viele viele viele gute Gründe, so dass wir gelegentliche Nachteile auch in Kauf nehmen dafür. Und ja die Tabelle ist gross, aktuell knapp 600 Millionen rows.

Unser Mainframe is... ziemlich gross. Es gibt aber imho in unserem DB2 eine Beschränkung dass ein einzelner Job nur eine gewisse Zahl parallerer Threads kriegt (imho 16). So dass bei einem Job dann ein Thread mehr als eine Partition bearbeitet. Wenn wir nun 8 Jobs fahren die intern von DMBS auf 16 threads gefahren werden ergibt das... tada... 128 Threads für 128 Partitionen und damit das maximal mögliche an Performance.

Und nein wir stellen nicht noch zwei, drei daneben... wir haben schon dutzende *g* So gesagt, die Leistung ist da, wir müssen sie nur noch nutzen.

[Asaraki]

Und wieso die Query (oder was auch immer) nicht sowieso schon parallel arbeitet, wenn man schon so viele Partitionen hat. Auch stellt sich die Frage, wo eigentlich der Flaschenhals ist. Ist es I/O, da die Datenmenge hoch ist, oder ist es CPU-Zeit, da die Verarbeitung der Daten recht aufwändig ist.


Ersteres dürfte sich ja erklärt haben.

Flaschenhals ist das I/O, eben deswegen weil ein Thread mehr als eine Partition lesen muss. Aktuell dauert das mit 1 Job => 8 Threads zwischen 10 bis 15 Minuten. In der Theorie müssten wir das mit Splitten auf <2-3 Minuten kriegen und das wär ne Zeitersparnis von min. 5 Minuten jede Nacht.... hurra :D

[peta@Urlaub]

Unser Mainframe is... ziemlich gross. Es gibt aber imho in unserem DB2 eine Beschränkung dass ein einzelner Job nur eine gewisse Zahl parallerer Threads kriegt (imho 16). So dass bei einem Job dann ein Thread mehr als eine Partition bearbeitet. Wenn wir nun 8 Jobs fahren die intern von DMBS auf 16 threads gefahren werden ergibt das... tada... 128 Threads für 128 Partitionen und damit das maximal mögliche an Performance.


Okili, damit wird die Sache klarer und ja, wie du schon selbst festegestellt hast, ist es sinnvoller, den einzelnen Jops einfach SQL Einschränkungen auf den PK mizugeben statt (falls das überhaupt auf z/oS-DB2 möglich sein sollte) da fest verdrahtet bestimmte Partitionen Einzuschränken (Partitrionierungen können sich ja doch auch mal ändern ;) )
Aber wenn der botttleneck das I/O ist, liegt denn da auch eine Einschränkung pro Job vor, bzw. ist das I/O in der Mainframewelt an Threads gekoppelt?
In der OSY-Welt würd ich jetz sagen: Wenn die Plattenphysik net mehr hergibt, ists da Wurscht mit wievielen Threads parallel ich die Platten rotieren lass ;)