12
Datenbank Abfrage sehr langsam! Bitte um Hilfe
Hallo,
Ich habe hier leider ein etwas komisches "Problem" ... Wir haben von der Firma "Mesonic" ein ERP Programm Namens "Winline". Die Datenbank liegt auf einem Server 2012 R2 (MSSQL). Jetzt habe ich für meine Firma ein Statistik/Auswertungsprogramm programmiert welche durch div. SQL-Abfragen Ergebnisse/Statistiken liefert.
Ich Join mit meiner Abfrage 6 Tabellen -> Es ist also eine etwas größere Abfrage. Mein Problem: Bei meiner Abfrage gibt es unter WHERE einen Filter wo ich sagen kann von wann bis wann er die Lieferscheine berechnen soll. Jedes Wirtschaftsjahr liegt in der selben Tabelle und ist nur durch eine spalte "Mesoyear" zu unterscheiden.
Führe ich nun meine Anfrage durch wo ich sage WHERE Ldatum Between '20160201' AND '20170331' AND mesoyear = 2016 dann läuft er hier ca. 1.200.000 Zeilen durch und ist innerhalb von 13 Sekunden fertig. Setze ich aber den Filter auf ein nah gelegenen Zeitraum WHERE Ldatum Between '20170101' AND '20170131' AND mesoyear = 2017 dann dauert diese abfrage ganze 4 MINUTEN für ca. 400.000 Zeilen!!!! es ist 1 zu 1 die selbe abfrage und auch die Tabelle ist 1 zu 1 die selbe! - es unterscheidet sich nur "mesoyear = 2016 oder mesoyear =2017"
Darauf hin habe ich dann einen Wartungsplan am Sql Server angelegt welches die Indexe neu erstellt und Organisiert - jedoch ist es nun schlimmer geworden! Die Abfragen im akuellen zeitraum dauern nun sogar 5 Minuten statt 4 Minuten
... Bitte um Hilfe ... es scheint ein Problem mit den Indizien zu geben... oder?
Bei der SQL-Abfrage-Analyse steht, dass er 95% der Zeit für einen Table-Scan benötigt - wieso benötigt er dies für das alte jahr aber nicht? beim Wartungsplan kann man ja nichts falsch machen oder?
danke
Ich habe hier leider ein etwas komisches "Problem" ... Wir haben von der Firma "Mesonic" ein ERP Programm Namens "Winline". Die Datenbank liegt auf einem Server 2012 R2 (MSSQL). Jetzt habe ich für meine Firma ein Statistik/Auswertungsprogramm programmiert welche durch div. SQL-Abfragen Ergebnisse/Statistiken liefert.
Ich Join mit meiner Abfrage 6 Tabellen -> Es ist also eine etwas größere Abfrage. Mein Problem: Bei meiner Abfrage gibt es unter WHERE einen Filter wo ich sagen kann von wann bis wann er die Lieferscheine berechnen soll. Jedes Wirtschaftsjahr liegt in der selben Tabelle und ist nur durch eine spalte "Mesoyear" zu unterscheiden.
Führe ich nun meine Anfrage durch wo ich sage WHERE Ldatum Between '20160201' AND '20170331' AND mesoyear = 2016 dann läuft er hier ca. 1.200.000 Zeilen durch und ist innerhalb von 13 Sekunden fertig. Setze ich aber den Filter auf ein nah gelegenen Zeitraum WHERE Ldatum Between '20170101' AND '20170131' AND mesoyear = 2017 dann dauert diese abfrage ganze 4 MINUTEN für ca. 400.000 Zeilen!!!! es ist 1 zu 1 die selbe abfrage und auch die Tabelle ist 1 zu 1 die selbe! - es unterscheidet sich nur "mesoyear = 2016 oder mesoyear =2017"
Darauf hin habe ich dann einen Wartungsplan am Sql Server angelegt welches die Indexe neu erstellt und Organisiert - jedoch ist es nun schlimmer geworden! Die Abfragen im akuellen zeitraum dauern nun sogar 5 Minuten statt 4 Minuten
... Bitte um Hilfe ... es scheint ein Problem mit den Indizien zu geben... oder?Bei der SQL-Abfrage-Analyse steht, dass er 95% der Zeit für einen Table-Scan benötigt - wieso benötigt er dies für das alte jahr aber nicht? beim Wartungsplan kann man ja nichts falsch machen oder?
danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 329600
Url: https://administrator.de/contentid/329600
Ausgedruckt am: 24.11.2024 um 20:11 Uhr
12 Kommentare
Neuester Kommentar
Kannst du mal die Tabellendefinition und die Definition von deinem Index posten? Das kannst du im Management Studio erzeugen.
kann man hier keine Dateianhänge hinzufügen?
Das ist mir lieber als Text. Überflüssige Spalten kannst du auch weglassen.
Moin,
lass doch die Abfrage mal im Performance Analyser / Profiler (kA wie das in deiner MSSQL Version gerade genannt wird
) laufen, dann siehst du genau was wie lange braucht.
lg,
Slainte
lass doch die Abfrage mal im Performance Analyser / Profiler (kA wie das in deiner MSSQL Version gerade genannt wird
) laufen, dann siehst du genau was wie lange braucht.lg,
Slainte
Hallo Ukulele,
TableName IndexName IndexId ColumnId ColumnName object_id name index_id type type_desc data_space_id ignore_dup_key is_primary_key is_unique_constraint fill_factor is_padded allow_row_locks allow_page_locks object_id index_id index_column_id column_id key_ordinal object_id name column_id system_type_id user_type_id max_length precision scale collation_name
t026 index_c000main 8 1 c000 517576882 index_c000main 8 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 8 1 1 1 517576882 c000 1 231 231 100 0 0 Latin1_General_CI_AS
t026 index_c003 6 1 c003 517576882 index_c003 6 2 NONCLUSTERED 1 0 0 0 90 1 1 1 517576882 6 1 2 1 517576882 c003 2 231 231 60 0 0 Latin1_General_CI_AS
t026 index_c025 11 1 c025 517576882 index_c025 11 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 11 1 23 1 517576882 c025 23 61 61 8 23 3 NULL
t026 index_c044 3 1 c044 517576882 index_c044 3 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 3 1 38 1 517576882 c044 38 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c044c045 38 1 c044 517576882 index_c044c045 38 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 38 1 38 1 517576882 c044 38 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c044c045 38 2 c045 517576882 index_c044c045 38 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 38 2 39 2 517576882 c045 39 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c044c045 38 3 c000 517576882 index_c044c045 38 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 38 3 1 3 517576882 c000 1 231 231 100 0 0 Latin1_General_CI_AS
t026 index_c045 4 1 c045 517576882 index_c045 4 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 4 1 39 1 517576882 c045 39 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c062 5 1 c062 517576882 index_c062 5 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 5 1 56 1 517576882 c062 56 56 56 4 10 0 NULL
t026 index_c064 10 1 c064 517576882 index_c064 10 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 10 1 58 1 517576882 c064 58 231 231 2 0 0 Latin1_General_CI_AS
t026 index_c067 9 1 c067 517576882 index_c067 9 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 9 1 61 1 517576882 c067 61 231 231 60 0 0 Latin1_General_CI_AS
t026 index_c103 13 1 c103 517576882 index_c103 13 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 13 1 97 1 517576882 c103 97 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c105 12 1 c105 517576882 index_c105 12 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 12 1 103 1 517576882 c105 103 61 61 8 23 3 NULL
t026 index_c110 14 1 c110 517576882 index_c110 14 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 14 1 108 1 517576882 c110 108 231 231 100 0 0 Latin1_General_CI_AS
t026 index_mesocomp 7 1 mesocomp 517576882 index_mesocomp 7 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 7 1 99 1 517576882 mesocomp 99 231 231 8 0 0 Latin1_General_CI_AS
TableName IndexName IndexId ColumnId ColumnName object_id name index_id type type_desc data_space_id ignore_dup_key is_primary_key is_unique_constraint fill_factor is_padded allow_row_locks allow_page_locks object_id index_id index_column_id column_id key_ordinal object_id name column_id system_type_id user_type_id max_length precision scale collation_name
t026 index_c000main 8 1 c000 517576882 index_c000main 8 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 8 1 1 1 517576882 c000 1 231 231 100 0 0 Latin1_General_CI_AS
t026 index_c003 6 1 c003 517576882 index_c003 6 2 NONCLUSTERED 1 0 0 0 90 1 1 1 517576882 6 1 2 1 517576882 c003 2 231 231 60 0 0 Latin1_General_CI_AS
t026 index_c025 11 1 c025 517576882 index_c025 11 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 11 1 23 1 517576882 c025 23 61 61 8 23 3 NULL
t026 index_c044 3 1 c044 517576882 index_c044 3 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 3 1 38 1 517576882 c044 38 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c044c045 38 1 c044 517576882 index_c044c045 38 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 38 1 38 1 517576882 c044 38 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c044c045 38 2 c045 517576882 index_c044c045 38 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 38 2 39 2 517576882 c045 39 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c044c045 38 3 c000 517576882 index_c044c045 38 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 38 3 1 3 517576882 c000 1 231 231 100 0 0 Latin1_General_CI_AS
t026 index_c045 4 1 c045 517576882 index_c045 4 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 4 1 39 1 517576882 c045 39 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c062 5 1 c062 517576882 index_c062 5 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 5 1 56 1 517576882 c062 56 56 56 4 10 0 NULL
t026 index_c064 10 1 c064 517576882 index_c064 10 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 10 1 58 1 517576882 c064 58 231 231 2 0 0 Latin1_General_CI_AS
t026 index_c067 9 1 c067 517576882 index_c067 9 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 9 1 61 1 517576882 c067 61 231 231 60 0 0 Latin1_General_CI_AS
t026 index_c103 13 1 c103 517576882 index_c103 13 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 13 1 97 1 517576882 c103 97 231 231 40 0 0 Latin1_General_CI_AS
t026 index_c105 12 1 c105 517576882 index_c105 12 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 12 1 103 1 517576882 c105 103 61 61 8 23 3 NULL
t026 index_c110 14 1 c110 517576882 index_c110 14 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 14 1 108 1 517576882 c110 108 231 231 100 0 0 Latin1_General_CI_AS
t026 index_mesocomp 7 1 mesocomp 517576882 index_mesocomp 7 2 NONCLUSTERED 1 0 0 0 90 0 1 1 517576882 7 1 99 1 517576882 mesocomp 99 231 231 8 0 0 Latin1_General_CI_AS
Zitat von @SlainteMhath:
Moin,
lass doch die Abfrage mal im Performance Analyser / Profiler (kA wie das in deiner MSSQL Version gerade genannt wird ) laufen, dann siehst du genau was wie lange braucht.
lg,
Slainte
Moin,
lass doch die Abfrage mal im Performance Analyser / Profiler (kA wie das in deiner MSSQL Version gerade genannt wird
) laufen, dann siehst du genau was wie lange braucht.lg,
Slainte
hallo SlainteMhath,
habe ich doch geschrieben. Der Table-Scan von t026 nimmt 95% der Zeit in Anspruch... Wieso ist dies aber für die Vergangenheit nicht der Fall??
Also erstmal sind das schon ziemlich viele Indexe. Wenn du testen kannst solltest du einmal alle entfernen und nur den für dich wichtigen Index auf mesoyear erstellen. Damit müssten sich beide Abfragen ähnlich verhalten.
Auserdem dachte ich auch an etwas lesbares wie:
CREATE TABLE [dbo].[tabelle_log](
[pk] [uniqueidentifier] NOT NULL,
CONSTRAINT [tabelle_log_pk] PRIMARY KEY CLUSTERED
(
[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
...für die Tabelle und:
ALTER TABLE [dbo].[ruf_log] ADD CONSTRAINT [ruf_log_pk] PRIMARY KEY CLUSTERED
(
[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
...für Indexe. Beides kannst du im SQL Management Studio über Rechtsklick auf das Objekt \ Skript als \ CREATE in erstellen.
Auserdem dachte ich auch an etwas lesbares wie:
CREATE TABLE [dbo].[tabelle_log](
[pk] [uniqueidentifier] NOT NULL,
CONSTRAINT [tabelle_log_pk] PRIMARY KEY CLUSTERED
(
[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
...für die Tabelle und:
ALTER TABLE [dbo].[ruf_log] ADD CONSTRAINT [ruf_log_pk] PRIMARY KEY CLUSTERED
(
[pk] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO
...für Indexe. Beides kannst du im SQL Management Studio über Rechtsklick auf das Objekt \ Skript als \ CREATE in erstellen.
habe ich doch geschrieben. Der Table-Scan von t026 nimmt 95% der Zeit in Anspruch.
Tatsächlich - muss ich wohl übersprungen haben Existieren den Indizies für Ldatum und mesoyear? Kann ich aus deiner Index Aufstellung nicht ganz rauslesen
Zitat von @SlainteMhath:
Existieren den Indizies für Ldatum und mesoyear? Kann ich aus deiner Index Aufstellung nicht ganz rauslesen
habe ich doch geschrieben. Der Table-Scan von t026 nimmt 95% der Zeit in Anspruch.
Tatsächlich - muss ich wohl übersprungen haben Existieren den Indizies für Ldatum und mesoyear? Kann ich aus deiner Index Aufstellung nicht ganz rauslesen
Hallo
Also ein Index für mesoyear und für Ldatum existiert nicht, da ich diese nur im WHERE filtere und für keinen Join benötige... Komisch oder? ich verstehe es irgendwie nicht UND der SQL-Server sagt mir folgendes:
/*
Fehlende Indexdetails von SQLQuery5.sql - SLSQL01.SL (meso (170))
Der Abfrageprozessor schätzt, dass durch das Implementieren des folgenden Indexes die Abfragekosten um 87.4576 % verbessert werden können.
*/
/*
USE [SL]
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[t026] ([mesoyear],[c003],[c055])
INCLUDE ([c000],[c004],[c005],[c031],[c068],[c072])
GO
*/
Aber ein Index auf c000 exisitert beispielsweiße bereits? Ich glaube, dass genau beim Index von c000 ein problem vorliegt ... komisch die Sache...
Also ein Index für mesoyear und für Ldatum existiert nicht, da ich diese nur im WHERE filtere und für keinen Join benötige
Ein Index dient dazu einen Racord schneller zu finden... egal ob per Where oder per Join Aber ein Index auf c000 exisitert beispielsweiße bereits? ...
Das TSQL von dir erstellt einen Index mit den angegebenen Bestandteilen in der angegebenen Reihenfolge. Leg den Index mal so an, dann wird dann Query flutschen Zitat von @SlainteMhath:
Also ein Index für mesoyear und für Ldatum existiert nicht, da ich diese nur im WHERE filtere und für keinen Join benötige
Ein Index dient dazu einen Racord schneller zu finden... egal ob per Where oder per Join Aber ein Index auf c000 exisitert beispielsweiße bereits? ...
Das TSQL von dir erstellt einen Index mit den angegebenen Bestandteilen in der angegebenen Reihenfolge. Leg den Index mal so an, dann wird dann Query flutschen vielen Dank für die Antwort. Da die Software eine ERP Software ist, würde ich gerne wissen ob ich mir den Index einfach so anlegen darf oder könnte ich der Software damit schaden? Dies ist dann natürlich ein Eingriff von mir ... ?
Ausser das dein Query den SQL belastet kann eigentlich nichts passieren... allerdings würde ich das trotzdem mit dem Hersteller der ERP abklären, nicht das die im Supportfall dann zicken
