View Full Version : Optimale SQL Lösung für Zugriff PF mit 12+xx Millionen Sätze
Hallo zusammen,
ich muss via SQL den optimalsten Weg für den Zugriff auf eine PF mit > 12 Mill. Sätze realisieren.
Grundsätzlich möchte ich die Daten in 3 Gruppen trennen, dazu das Jahr aus einem timestamp-Feld mit Timestamp - aktuelles Jahr -1, -2 und -3 abfragen
Was ist die beste Lösung:
a) 3 Views mit where-Klausel
....where year(timestamp_feld) >= (year(CURRENT_DATE)-1) (für 1 Jahr)
b) 3 Indizies mit where-Klausel
...wobei mir hier ehrlich gesagt nicht ganz klar ist, ob die DB aufgrund des abgesetzen
SQL Befehl den optimalen Index automatisch erkennt (glaube ich so gelesen zu haben)
c) über LF ...ich weiß SQL und LF ??? gehts noch ???..Gott o Gott ...nichts verstanden :=(
...ich wüßte jetzt auch nicht wie ich die Abfrage timestamp mit akt.Jahr -1 bis -3
im DDS codieren sollte
Bin gespannt auf eure Vorschläge...Brigitta, etwas für dich als Vollprofi ???
Danke vorab an alle !
12 Millionen ist nicht viel und rentiert kaum Gehirnschmalz zu verbraten, bevor man macht. Einfach machen und sehen ob es schnell genug ist => fertig. Nicht schnell genug? STRDBG und im Joblog nachsehen welche Indexe vorgeschlagen werden und diese anlegen. Immer noch zu langsam? Erst ab hier rentiert es sich nach schnelleren Lösungen zu suchen.
D*B
Danke Dieter Bender !
Ich habe jetzt erst einmal 3 verschiedene Views gemacht, läuft schon recht fix.
Jetzt schaue ich mal in IndexAdvisor/DBMon, was die DB dazu sagt.
Vg.
Views maskieren Komplexität und machen deshalb das Leben einfacher, weswegen man sie auch unbedingt einsetzen sollte, tragen jedoch nichts zur Performance-Verbesserung bei.
Eine View ist lediglich ein gesichertes SQL-Statement, das bei der Ausführung des tatsächlichen Statements aufgelöst und ausgeführt wird.
Ich würde auf alle Fälle einen Encoded Vector Index (EVI( mit dem Schlüssel-Feld Year(Timestamp_Feld) anlegen.
Create Index YOURSCHEMA.YOUREVI01
On YOURSCHEMA.YOURTABLE
(Year(YourTimestamp) As YOURYEAR Asc)
Je nach dem welche Spalten du noch brauchst, oder ob Du an dieser Stelle z.B. Summen oder andere Aggregate bildest, kann der EVI erweitert werden.
Evtl. würde auch ein normaler (Binary Radix Tree) Index ausreichen, ich gehe jedoch davon aus, dass pro Jahr mehr als ca. 15% der Daten verarbeitet werden (wenn nicht noch andere Selektions-Kriterien verwendet werden), und damit hat ein Binary Radix Tree Index ausgedient.
... und noch was: STRSQL und auch STRDBG wurden mindestens seit Release V5R3 nicht mehr erweitert. Die Nachrichten die auf diese Weise ausgegeben werden, sind schon lange nicht mehr vollständig.
Zur Analyse von SQL-Statements sollte man wirklich Visual Explain verwenden.
Mit Run AND Explain bekommt man auch die aktuellen Daten bzw. den aktuellen Access Plan angezeigt und KEINE Schätzwerte.
Birgitta
Ich würde auf alle Fälle einen Encoded Vector Index (EVI( mit dem Schlüssel-Feld Year(Timestamp_Feld) anlegen.
Birgitta
Glaskugel defekt: Timestamp Felder liefern in der Regel distincte Werte, für die ein EVI keinen Sinn macht!
D*B
andreaspr@aon.at
27-04-18, 18:35
Glaskugel defekt: Timestamp Felder liefern in der Regel distincte Werte, für die ein EVI keinen Sinn macht!
Birgitta hat es eigentlich schön beschrieben. Es soll nicht der Timstamp im Index gespeichert werden, sondern lediglich das Jahr und das sollte halbwegs überschaubar sein ;-)
Glaskugel defekt: Timestamp Felder liefern in der Regel distincte Werte, für die ein EVI keinen Sinn macht!
D*B
Vielleicht solltest du deine Glaskugel mal abstauben, damit sie dir auch mal derived Indices und EVIs (mit und ohne Include Anweisungen) und auch sonst noch einige Neuerungen anzeigt.
Die Welt hat sich weitergedreht über STRSQL und STRDBG hinaus.
Es gibt neue und bessere Tools auch für die Auswertung der gesammelten Daten.
Und gerade im Bereich der Performance-Optimierung passiert einiges in Rochester.
Birgitta
Und gerade im Bereich der Performance-Optimierung passiert einiges in Rochester.
Birgitta
... man muss nur fest dran glauben! Ich bleibe dabei: jede[r], der ohne Messung Patentrezepte hat, ist ein Scharlatan!
D*B
Vielen Dank an alle.
@Birgitta
Ich habe bis zur 1.Antwort hier schon einmal 3 Views gemacht, mittlerweile hat sich herausgestellt, dass ich in Monatsschritten abfragen muss/soll....also 3 Views für 3, 6 und 12 Monate.
In den Views habe ich die where-Klausel wie folgt codiert:
"where timestampdiff(64, Cast(current_timestamp-dmstimsn as Char(22))) <=3"
Feld dmstimsn ist das timestamp-Feld.
Sollte der Index dann so aussehen ???
Create Index lib.indexname On lib.pfname ( dmstimsn Asc)
Ich habe zwar schon einige andere Indizies erstellt, meist schaue ich in den Index-Advisor (mit dem DB-View) oder DBMonitor und hole mir da die "Index-Empfehlungen" mit den meisten Vorkommen/Verwendungen.
Jetzt möchte ich mein Wissen mal ein wenig ausbauen und einen Profi wie dich fragen :=)
(habe leider bisher kein Budget für eine Schulung bei euch bekommen, soll aber bald kommen und dann aber :=))
Eine Frage bitte noch zu Visual Explain..
Wenn ich das richtig gesucht habe ist das eine Funktion im Navigator for i ??
Ich habe leider kein PDF/Link zu einem Tutorial für DB2/i gefunden, nur für andere DB2.
Hast du da vielleicht einen Link, wo ich mich "schlau" machen kann ??
Vielen Dank nochmals !!
Peet
andreaspr@aon.at
28-04-18, 11:55
Eine Frage bitte noch zu Visual Explain..
Wenn ich das richtig gesucht habe ist das eine Funktion im Navigator for i ??
Ich habe leider kein PDF/Link zu einem Tutorial für DB2/i gefunden, nur für andere DB2.
Hast du da vielleicht einen Link, wo ich mich "schlau" machen kann ??
Hier z.B.: https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzajq/rzajqpdf.pdf
lg Andreas