-
Man sollte auch nicht vergessen dass es NUR eine Empfehlung ist.
Es kann sein, dass diese Empfehlung keine Auswirkung hat wenn du den Index entsprechend erstellst.
Nur wenn die DB auch einen MTI (temporären Index) erstellt, dann hat die "Empfehlung" wirklich hohes Gewicht.
Ansonsten ist es besser wenn man die Datenbank und den Inhalt der Tabellen entsprechend Analysiert und darauf aufbauend seine Indexstrategie wählt.
Je nach dem um was für Daten es sich handelt und wie oft die Tabelle bearbeitet wird (INSERT, DELETE, UPDATE) könnte ein EVI Index oder eine MQT besser sein.
-
Könnte auch sein dass die Größe der Felder eine Auswirkung hat.
Key 1 ist ja größer. da möchte er vielleicht zuletzt suchen weil er länger braucht.
Außerdem möchte er vielleicht bestimme casts aus der Abfrage so selten wie möglich ausführen.
-
MQTs sind quasi physische views auf mehrere Tabellen. Sie updaten sich je nach einstellungen entweder zu einem bestimmten Zeitpunkt oder immer sobald sich eine der Tabellen ändert.
Vorteil: Bei abfragen schneller, da das select auf mehrere Tabellen nicht neu ausgeführt werden muss.
Nachteil: Verbrauchen natürlich Speicher.
-
... meine Glaskugel ist gerade defekt und Kaffeesatz habe ich auch gerade keinen zur Hand. Aus dem hohlen Bauch:
- erst mal alle Debug Messages durcharbeiten, was ihr an den vorhandenen Indexen nicht schmeckt.
- zuweilen kann ein Order by ihr auf die Sprünge helfen
- ausprobieren, was sie mit den vorgeschlagenen Indexen hinkriegt (oder ob sie sich für ein anderes Paar Schuhe entscheidet...)
D*B
PS: EVIs sind für join und group by (wie in den meisten anderen Fällen) völlig nutzlos - ein typisches Gag Feature des Marketings.
-
Man(n) müsste sich den Zugriffsplan anschauen den die DB derzeit verwendet.
Du kannst dir im Navigator mit Rechts-Klick auf "Datenbanken" den Job anschauen der die Abfrage durchführt --> dann Details --> und auf Visual Explain.
Dann könntest du vielleicht erkennen warum er diese Reihenfolge vorschlägt.
Alles was > ein paar Sekunden und überhaupt bei über 1 Stunde braucht, liegt das Problem entweder an der Abfrage selbst.
Oder an gewissen Datenbankeinstellungen (SRTSEQ=*HEX?, QAQQINI, Logische File im FROM statt Phyische usw.)
Und was MQTs betrifft ist es so wie Obv gesagt hat.
Nur dass es derzeit auf der IBM i noch nicht möglich ist ein automatisches Refresh zu machen. Das gibt es nur bei DB2 LUW.
MQTs sind optimal, wenn die benötigten Daten auch ein paar Stunden oder Minuten alt sein dürfen.
Du kannst sie sowohl über eine als auch mehrere Tabellen anlegen.
Damit verlagerst du die Zeit für das Sammeln der Daten auf einen eigenen JOB der je nach Interval die Vorselektion startet.
-
Nur dass es derzeit auf der IBM i noch nicht möglich ist ein automatisches Refresh zu machen.
REFRESH IMMEDIATE funktioniert nicht?
-
Ok,
die Leitung zum Kunden war eben weg, das Statement ist abgebrochen.
also hab ich es in eine Source kopiert,
create table davor, with data dahinter und einen runsqlstm submittet.
nach 4 Minuten hatte ich eine richtig gefüllte datei!!!
also strsql
select ... group ...
Nix geht, aber auch gar nix .
Ich verstehe das nicht.
Die analyse mit v.expl. werd ich versuchen (einmal hab ich das ja schon für ein anderes prob. gemacht ... )
@Dieter
die geforderten indices kann (darf) ich nicht 'mal eben' anlegen.
Der Grund warum er die existierenden Pfade nicht nimmt ist lt Joblog: dauer zu lange
Order by werd ich versuchen, dachte das macht sql automatisch intern bei group by. die key1, 2, 3 Felder sind übrigens nicht die group Felder)
@glaskugel
ja das kenn ich, meine ist auch dauern defekt.
danke und Gruß
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Wenn es im Batch schneller läuft, schau dir die Einstellungen im STRSQL an.
Sortierfolge . . . . . . . . . *HEX
Datenkopie zulässig . . . . . *YES
-
 Zitat von andreaspr@aon.at
Wenn es im Batch schneller läuft, schau dir die Einstellungen im STRSQL an.
Sortierfolge . . . . . . . . . *HEX
Datenkopie zulässig . . . . . *YES
Steht beides so, das ist es also nicht.
Robi
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
versuch es doch so
Code:
CREATE TABLE MQT2
AS (
select statement
) DATA INITIALLY IMMEDIATE REFRESH DEFERRED
ENABLE QUERY OPTIMIZATION MAINTAINED BY USER
...
refresh table MQT2
...
SELECT Sp1, ... FROM MQT2 WHERE ... GROUP BY Sp1 ...
-
 Zitat von Obv
Code:
CREATE TABLE MQT2 AS (
select statement
) DATA INITIALLY IMMEDIATE REFRESH DEFERRED ENABLE QUERY OPTIMIZATION MAINTAINED BY USER
Das DATA INITIALLY IMMEDIATE führt quasi gleich nach dem CREATE TABLE auch gleich das REFRESH TABLE aus.
-
ich war jetzt komplett bei deferred 
das refresh table nachher ist also hinfällig.
Similar Threads
-
By ILEMax in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 20-03-12, 10:24
-
By Frank Ziegler in forum IBM i Hauptforum
Antworten: 14
Letzter Beitrag: 10-12-06, 10:21
-
By deni87991 in forum IBM i Hauptforum
Antworten: 21
Letzter Beitrag: 07-08-06, 16:42
-
By HPKahn in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 17-05-06, 20:22
-
By pwrdwnsys in forum IBM i Hauptforum
Antworten: 10
Letzter Beitrag: 16-08-05, 08:56
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks