SQL-Abfrage Timeout problem

[Tommi]

Hi,

in deinem letzten Screenshot ist zu sehen, dass der Optimizer schon was gefunden hat (grüne Zeile oben).
Wenn man hier mit rechts draufklickt, kann man sich den Code für den fehlenden Index direkt in ein neues Fenster generieren lassen.
Dort muss dann nur noch ein schöner Name für den Index vergeben werden, ausführen und dann ist ein Index vorhanden, der die Abfrage optimieren sollte(!).

Viele Grüße,
Tommi

 

[P8310]

Hallo Tommi,

das klingt ja gut....habe mich an deiner Anweisung versucht aber leider kein erfolg. kann ich das in denn bestehenden select string verbauen die info

 

[P8310]

Guten Morgen,

Müsste das so aussehen?

USE [ASAD]
GO
CREATE NONCLUSTERED INDEX [idVar]
ON [dbo].[Date] ([D_S])
INCLUDE ([D_SER])
GO
SELECT Parts.*, D_S
FROM Label INNER JOIN Date
ON Label.H_SER = Date.D_SER INNER JOIN Parts
ON Label.H_SER = Parts.P_SER
WHERE Date.D_S BETWEEN CONVERT(datetime,  '" & von & "', 104) AND CONVERT(datetime,  '" & bis & "', 104) AND Label.H_TEST = '" & line & "' AND Parts." & spalte & " = "' & such & '"

 

[ukulele]

Also mit INCLUDE habe ich mich noch nicht befasst aber ich glaube das die Anwendung hier keinen Sinn ergibt. Probier lieber erstmal:

CREATE NONCLUSTERED INDEX [idVar]
ON [dbo].[Date] ([D_SER],[D_S])

 

[Tommi]

Hallo Tino,

Die Spalten, die in der ersten Klamme angegeben werden, stehen für den eigentlich zu sortierenden und somit schneller zugreifbar machenden Part, der den Index selber ausmacht.
Mit der INCLUDE-Klausel kann man zusätzlich Spalten in den Trigger einbinden, die im SELECT ausgewählt werden. So muss die Engine nicht mehr auf die Tabelle und die abgefragte Spalte verweisen und die Werte daraus noch ermitteln, sondern kann diese direkt aus dem Index beziehen. Grade bei breiten Tabellen kann man so erheblich Performance herausholen.

Somit ist also die Antwort von Ukulele vollkommen korrekt für die Erstellung des Triggers. Beide Spalten werden in der WHERE-Klausel oder in den JOIN-Bedingungen verwendet, gehören also in die Index-Spalten. Da du aus dieser Tabelle keine anderen Werte abfragst, brauchen diese auch nicht noch einer INCLUDE-Klausel verfügbar gemacht werden.

Viele Grüße,
Tommi

 

[P8310]

lieben dank für das erneute annehmen meines Themas.

habe es ohne Include gemacht (siehe Bild)

aber da kommt immer noch die grüne Zeile (Missing Index)

 

[ukulele]

Ist die Abfrage denn schneller als vorher?

 

[P8310]

hab es noch nicht laufen lassen, wollte noch kurz fragen ob die Index spalte nur für die abfrage erzeugt wird und dann wieder gelöscht wird? die DB wird permanent gefüllt, nicht das ich hier etwas zum Crashen bring

 

[P8310]

okay habe das mal laufen lassen, keine besserung

 

[Tommi]

Hallo Tino,

das liegt an deiner WHERE-Klausel. Darüber habe ich mir vorhin bereits Gedanken gemacht.
Ich nehme an, diese ist 1:1 aus deiner Programmierung übernommen und die Ausdrücke "line", "spalte" und "such" sind String-Variablen.

Der Index müsste nicht auf die "Date"-Tabelle sondern auf die "Label" und/oder "Parts"-Tabelle gesetzt werden.
Da über die Variable "such" aber auch verschiedene Spalten de Tabelle "Parts" ausgelesen werden, ist das mit einem ordentlichen Trigger schwierig.

Schau dir doch die Syntax des vom Optimizer vorgeschlagenen Index mal (wie gesagt - Klick auf die grüne Zeile und im Kontext-Menü den entsprechenden Punkt zum anzeigen des Trigger-Scrips auswählen) an oder poste diesen. Da kann man mehr erkennen.

Viele Grüße,
Tommi

 

[ukulele]

Die grüne Zeile schlägt ja den Index mit INCLUDE vor... Ich kann die Situation aber auch nicht aus dem Stehgreif nachvollziehen, so Index erfahren bin ich gar nicht :-/

wollte noch kurz fragen ob die Index spalte nur für die abfrage erzeugt wird und dann wieder gelöscht wird? die DB wird permanent gefüllt, nicht das ich hier etwas zum Crashen bring

Aber noch zum Verständnis:
Der Index bleibt (sofern er nicht gelöscht wird). Den Index nur für eine Abfrage zu erstellen macht auch keinen Sinn denn er benötigt genau die Zeit (oder mehr) zum erstellen, die du sparen willst. Der Index wird bei einem Schreibvorgang auf die Tabelle angepasst, braucht hier also etwas mehr Zeit. Beim Lesen hilft er der Datenbank dann nur das zu lesen, was sie auch sucht. Zeilen die sich ändern gibt es meist weniger als Zeilen, die gefunden oder sortiert werden müssen, daher ist ein Index für Abfragen viel mehr Wert als der Verlust an Zeit beim Schreiben.

 

[Distrilec]

Find ich schön... Wie ihr keinen Skrupel davor habt, einfach im Modell eines anderen rumzupfuschen... Ohne es vorher mal gesehen zu haben...

Leute gibts...

 

[ukulele]

Find ich schön... Wie ihr keinen Skrupel davor habt, einfach im Modell eines anderen rumzupfuschen... Ohne es vorher mal gesehen zu haben...

Deine Lösung wäre erstmal alle Tabellen-Definitionen durchzugehen?

 

[Distrilec]

Alles was man braucht:
Tabellendefinitionen der 3 Tabellen.
Alle Keys der 3 Tabellen
Alle Constraints der 3 Tabellen

Dann können wir dieses verhalten 1:1 nachstellen
(Es sei den es gibt andere Optimizer einstellungen... Da weiß ich nicht wie MS SQL Einstellungen zulässt)

Derzeit bewegt ihr euch im Blindflug in der DB eines anderen... Geht garnicht... Ist aber auch nur meine Meinung

 

[Tommi]

Hi,

hab grade gesehen, dass ich mich in meinem letzten Post verschrieben hatte (war gedanklich wohl noch in einem anderen Thread). Ich meinte natürlich nicht "Trigger" bzw." Trigger-Skript", sondern natürlich "Index" bzw. Index-Script" - Sorry. Hab auch den letzten Screenshot nicht genau gesichtet, da steht der CREATE-Vorschlag des Optimizers ja drin.
Was mich noch interessieren würde ist, ob du die SELECT-Abfrage mit der geposteten WHERE-Klausel abgesetzt hast.

Was das Anlegen eines Index innerhalb einer DB auf dem SQL-Server angeht:
Am Modell wird da grundsätzlich ja nicht "rumgepfuscht", ich kann auch nicht erkennen, dass irgendjemand hier Ratschläge gibt, die in die Kategorie "rumpfuschen" fallen.

Natürlich kann mit einem schlechten Index ein bereits bestehender Index, der bereits eine bestimmte Optimierungs-Aufgabe hat, übergangen werden. Das passiert auf dem SQL Server aber eher selten und eher dann, wenn der erste Index noch nicht lange besteht und es hier keine umfangreiche Statistik (wird auch vom SQL Server selbst angelegt) zu diesem gibt. Der SQL Server speichert sich den günstigsten Ausführungsplan. Dieser wird anhand von Statistiken berechnet.

Ich sehe nicht, dass das hier der Fall wäre. Ein Index ist die erste, einfachste und beste Methode um eine Abfrage zu beschleunigen, ich denke, da sind wir uns einig.
Auch der Optimizer des SQL Servers schlagt vor diesen Index anzulegen.

@Tino: leg den Index doch einmal so an, wie der Optimizer es vorschlägt. Du hast zuletzt nur einen Index auf die Spalte "D_S" angelegt.


Viele Grüße,
Tommi