Laufzeit von Stored Procedure verkürzen

[Andidreas]

Zitat:

Zitat von Furtbichler (Beitrag 1186259)

Pass mal auf Jungelchen. Ich habe explizit geschrieben, das -wenn Du der Verzapfer der Stored Procedure bist- die Bezeichnung Cretin und Vollpfosten nicht auf dich gemünzt ist. Habe ich?

Wo ist den der unterschied ob ich das war oder einer meiner Kollegen/Vorgänger.
Niemand ist perfekt... Aber anscheinend bist Du der Meinung das Du es bist...

Zitat:

Zitat von Furtbichler (Beitrag 1186259)

Ich habe geschrieben, das ich für diese Arbeit 1-2 Tagessätze ansetzen würde.

Vielen Dank für das Angebot, aber für nen "Berater" (oder was auch immer Du darstellst) der schon so Arrogangt hier rumschreibt werden wir kein Geld ausgeben...

[Blup]

Stored Procedure 1 & 2

SQL-Code:

Right((ALL_MaterialGrid + '_' + ALL_LowestPLC_SKU), 2) 
.

Da der Unterstrich nicht im Case berücksichtigt wird, könnte man hier einkürzen:

SQL-Code:

Right(ALL_LowestPLC_SKU, 2)
.

Ich würde eine View einsetzen, damit die beiden Abfragen übersichtlicher werden:

SQL-Code:

Select *,
       CASE WHEN Right(ALL_LowestPLC_SKU, 1) = '#' OR
                 Right(ALL_LowestPLC_SKU, 2) IN ('00', '10', '20') THEN 1 ELSE 0 END as PLC_Lower25,
       CASE WHEN Right(ALL_LowestPLC_SKU, 2) = '25'                THEN 1 ELSE 0 END as PLC_25,
       CASE WHEN Right(ALL_LowestPLC_SKU, 2) = '30'                THEN 1 ELSE 0 END as PLC_30,
       CASE WHEN Right(ALL_LowestPLC_SKU, 2) = '40'                THEN 1 ELSE 0 END as PLC_40,
       CASE WHEN Right(ALL_LowestPLC_SKU, 2) IN ('50', '55')       THEN 1 ELSE 0 END as PLC_50_55,
       CASE WHEN Right(ALL_LowestPLC_SKU, 2) = '60'                THEN 1 ELSE 0 END as PLC_60,
       CASE WHEN Right(ALL_LowestPLC_SKU, 2) = '70'                THEN 1 ELSE 0 END as PLC_70,
                                                                        1            as PLC_total
From [inventory].[dbo].[inventory.inv_test]

Stored Procedure 3 - 6

Ebenfalls eine View:

SQL-Code:

Select *,
       CASE WHEN ALL_PLC IN ('#', '00', '10', '20') THEN 1 ELSE 0 END as PLC_Lower25,
       CASE WHEN ALL_PLC = '25'                     THEN 1 ELSE 0 END as PLC_25,
       CASE WHEN ALL_PLC = '30'                     THEN 1 ELSE 0 END as PLC_30,
       CASE WHEN ALL_PLC = '40'                     THEN 1 ELSE 0 END as PLC_40,
       CASE WHEN ALL_PLC IN ( '50', '55')           THEN 1 ELSE 0 END as PLC_50_55,
       CASE WHEN ALL_PLC = '60'                     THEN 1 ELSE 0 END as PLC_60,
       CASE WHEN ALL_PLC = '70'                     THEN 1 ELSE 0 END as PLC_70,
                                                         1            as PLC_total
From [inventory].[dbo].[inventory.inv_test]

Am Beispiel Procedure 3:

SQL-Code:

Select SUM(PLC_Lower25 * ALL_AvailableStock) as PLC_Lower25,
       SUM(PLC_25      * ALL_AvailableStock) as PLC_25,
       SUM(PLC_30      * ALL_AvailableStock) as PLC_30,
       SUM(PLC_40      * ALL_AvailableStock) as PLC_40,
       SUM(PLC_50_55   * ALL_AvailableStock) as PLC_50_55,
       SUM(PLC_60      * ALL_AvailableStock) as PLC_60,
       SUM(PLC_70      * ALL_AvailableStock) as PLC_70,
       SUM(PLC_TOTAL   * ALL_AvailableStock) as PLC_Total
From   MyView2
Where  ALL_Brand       In (SELECT Value FROM [inventory].[dbo].[fnSplit](@Brand, ';')) And
       ALL_ProductLine In (SELECT Value FROM [inventory].[dbo].[fnSplit](@Productline, ';'))

[mkinzler]

Zitat:

Zitat von Andidreas:
Das man hier als Cretin oder Vollpfosten bezeichnet wird hat mich jetzt nicht so gestört, es ist ja niemand Allwissend (naja manche meines es vielleicht)...
Pass mal auf Jungelchen. Ich habe explizit geschrieben, das -wenn Du der Verzapfer der Stored Procedure bist- die Bezeichnung Cretin und Vollpfosten nicht auf dich gemünzt ist. Habe ich?

:warn: Es macht keinen Unterschied, wer der Urheber der Datenbank(-struktur) ist. Diese ist nicht optimal (man könnte auch sagen schlecht); dies rechtfertigt aber nicht dazu, den Urheber als Vollpfosten oder als Cretin zu beschimpfen!:wall:

Zitat:

Zitat von Furtbichler:
Dann: Schäm dich und frag nächstes Mal.

Auch das wird ihm bei seinem Problem nicht helfen.

Zitat:

Ja, ne. Also. Das gilt auch für dich, Daniel 'OberAdmin'. Lesen ist wichtig. Verstehen noch mehr.

Ich hatte deinen Beitrag an Daniel gemeldet, weil ich nicht in den Verdacht geraten wollte, dass das hier als Retourkutsche für deinen Meinungsäusserung bezüglich den Aufgaben von uns Moderatoren hier im Forum ( "Raushalten und Schauze halten") ist.
Und mich kotzt es nun natürlich an, dass er deshlab von dir in deiner eigen Art mit Hohn überschüttet wird!
Daniel ist hier der Admin un bezahlt die Rechnungen für Hosting usw. und haftet u.U. Deshalb hat er das Recht festzulegen, welcher Umgangston hier als angemessen gilt und wenn er der Meinung ist ( wie viele andere inkl. mir auch), dass deine Ausdrucksweise nicht angemessen ist, dann hast du dich dem zu fügen!

[Andidreas]

Wir haben die letzten Tage die Queries / Stored Procedures und das Datenbank Design getestet...
Hierbei ist uns etwas aufgefallen was wir uns nicht ganz erklären können...

Normalerweise ist es bei Datenbanken ja so das komplexe Abfragen durch das anlegen von Indexen (gemäß den Where Klauseln) performanter gemacht werden können.
Bei der MS SQL ist uns aber aufgefallen das die Abfragen (in Summe) ohne Indexe ca. 20 Sekunden schneller ausgeführt werden!

Eine Ursache könnte sein das die Datenbank durch das prüfen welcher Index verwendet werden soll Zeit verliert.

Aber selbst wenn im SQL Statement die zu verwendenden Indexe mitgegeben werden (über WITH) sind die Abfragen in Summe ca. 3 - 4 Sekunden langsamer als wenn keine Indexe auf der Tabelle liegen.

Woran kann das liegen?

[p80286]

hast Du denn mal einen Blick in den Query plan geworfen?
Ist schon etwas her, daß ich praktisch mit MS-SQL gearbeitet habe, aber des MS-Client sollte das eigentlich hergeben.

Gruß
K-H

[Andidreas]

Ja, den haben wir uns angeschaut und der macht das ganze noch unverständlicher.

1. Query über den Ausführungsplan geprüft --> Ergebnis, es wird ein Index vorgeschlagen.
2. Vorgeschlagenen Index angelegt --> Ergebnis, Query minimal schneller.
3. Vorgeschlagenen Index wieder gelöscht und Query erneut über den Ausführungsplan geprüft --> Ergebnis, Es wird kein Index mehr vorgeschlagen!!!

Edit
Nachdem wir den von der MS SQL vorgeschlagenen Index wieder gelöscht haben, sollte doch wieder der fehlende Index vorgeschlagen werden oder sehe ich das falsch?

[Bummi]

Hattet Ihr einen clustered Index erstellt?

[jobo]

Hast Du noch Converts o.ä. Funktionen in den joins? Das ist nicht schön für Indizes. Die gesamte Abfrage sieht sowieso nach FullScan aus, Index hilft da nichts.
Bin kein MSSQL Meister, aber vielleicht gibts da auch sowas wie Statistics Tabellen, die der Query Optimizer zur Berechnung heranzieht. Wenn die nicht passend aktuell sind, kommt Murx raus (kann).

Ein Index würde m.E. Sinn machen, wenn eine zeitabhängige Dimension in der Tabelle und den Abfragen wäre.

[Blup]

Index und Abfrage müssen zusammen passen. Eine Abfrage die für eine Tabelle zugleich mehrere Indexe nutzt, ist in der Regel ineffektiv. Von der Laufzeit ist "In" meist sehr teuer.

Ich würde die Abfrage von Oben im Prinzip so umstellen (hab grad kein MS-SQL):

SQL-Code:

CREATE INDEX IDX_Brand_ProductLine ON [inventory].[dbo].[inventory.inv_test] (ALL_Brand, ALL_ProductLine);

select SUM(PLC_Lower25 * ALL_AvailableStock) as PLC_Lower25,
       SUM(PLC_25 * ALL_AvailableStock) as PLC_25,
       SUM(PLC_30 * ALL_AvailableStock) as PLC_30,
       SUM(PLC_40 * ALL_AvailableStock) as PLC_40,
       SUM(PLC_50_55 * ALL_AvailableStock) as PLC_50_55,
       SUM(PLC_60 * ALL_AvailableStock) as PLC_60,
       SUM(PLC_70 * ALL_AvailableStock) as PLC_70,
       SUM(PLC_TOTAL * ALL_AvailableStock) as PLC_Total
from
      [inventory].[dbo].[fnSplit](@Brand, ';') a,
      [inventory].[dbo].[fnSplit](@Productline, ';') b
left join MyView2 c on (c.ALL_Brand = a.Value) and (c.ALL_ProductLine = b.Value);

Hier wird eine Art Kreuztabelle aus den Werten aus "Brand" und "Produktline" erstellt.
Mit jeder Kombination erfolgt dann jeweils eine Abfrage der eigentlichen Datentabelle.
Durch den Index müssen dabei nur die Datensätze gelesen werden, die der jeweiligen Kombination entsprechen.

Sind nur zwei getrennte Indexe (einer über ALL_BRAND und ein anderer über ALL_ProductLine) vorhanden, ist die Abfrage um ein vielfaches langsamer.

[Andidreas]

Zitat:

Zitat von Bummi (Beitrag 1187304)

Hattet Ihr einen clustered Index erstellt?

Nein, sind Clustred Indexe schneller?

Zitat:

Zitat von jobo (Beitrag 1187307)

Hast Du noch Converts o.ä. Funktionen in den joins? Das ist nicht schön für Indizes. Die gesamte Abfrage sieht sowieso nach FullScan aus, Index hilft da nichts.

Nein, ich habe mir mittlerweile eine Test Tabelle angelegt in der alle Felder die richtigen Feldtypen haben!

Zitat:

Zitat von Blup (Beitrag 1187344)

Sind nur zwei getrennte Indexe (einer über ALL_BRAND und ein anderer über ALL_ProductLine) vorhanden, ist die Abfrage um ein vielfaches langsamer.

Gilt das auch wenn z.B. Index1 und Index2 jeweils die Felder ALL_Brand und ALL_Productline beinhalten?