SQL Schlüssel herausfinden

[BenderD]

Hallo nochmal,

ich würde die Datenbank ändern!!! KRT001 und KRTHST in eine Datei KRTALL zusammen werfen mit einem zusätzliche Feld Herkunft unterscheidbar machen, ob die jemand in KRT001 oder KRTHST sehen will. Und dann mit zwei Views die Anwendungen bedienen, die jetzt KRT001 oder KRTHST verarbeiten.
In diesem konkreten Falle, könnte man sogar Programme, die record level access verwenden bedienen, wie vorher.

Dieter Bender

[Fuerchau]

@Dieter

JETZT habe ich das auch verstanden

[Rincewind]

Hy,

das SQL würde somit bestimmt schneller laufen , also heissen Dank an euch 2,

aber die Antwort kam dann eigentlich mehr von Frau Hauser

Die Frage ist nur:
Kann ich das Verknüpfungskriterium TRFBCH weglassen oder muss ich es mit in den Schlüssel nehmen ? (Und wenn ja an welcher Stelle, vorne scheint nicht zu funktionieren)


Ich will eigentlich nur wissen wie ich diesen *MAP auflösen kann (Ops Navigator oder sonstige Tools)

Trotzdem danke für eure Mühen

Rince

[BenderD]

Hallo Rince,

der Schlüssel zum Verständnis liegt immer in der Original Frage:

Nun sagt er mir aber leider nicht einen Schlüssel zur Optimierung (wie er es sonst so gerne macht) sondern gibt mir nur ein
*MAP ASCEND
als Schlüsselwort für die temporäre Datei an.

sobald der Query Optimizer sich entscheidet eine temporäre Zwischendatei anzulegen, sind mit zusätzlichen Indexen an dieser Stelle alle Spatzen gefangen.

Du hast in Deinem Query auf oberster Ebene einen Union, den Du dann per ORDER BY nach Feldern aus den beiden Dateien sortieren willst, dass die was miteinander zu tun haben merkt der Query Optimizer nicht und damit kann er auch nichts anfangen.

Alle Tricks die temporäre Tabelle zu verhindern helfen nix, da die View wg. der Gruppierung read only ist, alle Tricks einen bestimmten Zugriffspfad durch eine erweiterte ORDER BY Klausel zu favorisieren, scheitern letztlich daran, dass Zugriffs relevante Felder nicht im ResultSet sind.

Ich würde von der Analyse her im ersten Schritt den Union rausnehmen und die beiden resultierenden Queries unter debug ansehen, was der Optimizer macht - respektive empfiehlt. (das muss natürlich im Produktions Umfeld erfolgen: Datenmenge Batch oder interaktiv). Wenn hier keine Indexe mehr fehlen, dann den Union untersuchen - meine Erfahrung sagt mir aber, dass DB2/400 keinen Union kann; bis V5R1 nicht und das Marketing Getöse von der neuen 5.2er Query Engine sollte man mit Vorsicht genießen, die ist vielleicht mit V6 halbwegs fertig.

mfg

Dieter Bender

[Rincewind]

Bei Trennung verarbeitet er nach Eingangsfolge *grummel*

Guter tip allerdings

Naja mit dem Union scheint er so seine Probleme zu haben.

Aber egal ich habs jetzt mit guten alten Read gelöst und das ist superschnell.


Dank euch für euer nachdenken

Der Rince