samet22
Goto Top

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 Minutenface-sad ... 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

Content-Key: 329600

Url: https://administrator.de/contentid/329600

Ausgedruckt am: 28.03.2024 um 10:03 Uhr

Mitglied: ukulele-7
ukulele-7 16.02.2017 um 08:30:09 Uhr
Goto Top
Kannst du mal die Tabellendefinition und die Definition von deinem Index posten? Das kannst du im Management Studio erzeugen.
Mitglied: samet22
samet22 16.02.2017 um 09:05:31 Uhr
Goto Top
kann man hier keine Dateianhänge hinzufügen?
Mitglied: ukulele-7
ukulele-7 16.02.2017 um 09:08:37 Uhr
Goto Top
Das ist mir lieber als Text. Überflüssige Spalten kannst du auch weglassen.
Mitglied: SlainteMhath
SlainteMhath 16.02.2017 um 09:22:35 Uhr
Goto Top
Moin,

lass doch die Abfrage mal im Performance Analyser / Profiler (kA wie das in deiner MSSQL Version gerade genannt wird face-smile ) laufen, dann siehst du genau was wie lange braucht.

lg,
Slainte
Mitglied: samet22
samet22 16.02.2017 um 09:44:34 Uhr
Goto Top
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
Mitglied: samet22
samet22 16.02.2017 um 09:54:07 Uhr
Goto Top
Zitat von @SlainteMhath:

Moin,

lass doch die Abfrage mal im Performance Analyser / Profiler (kA wie das in deiner MSSQL Version gerade genannt wird face-smile ) 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??
Mitglied: ukulele-7
ukulele-7 16.02.2017 um 09:55:10 Uhr
Goto Top
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.
Mitglied: SlainteMhath
SlainteMhath 16.02.2017 um 10:03:08 Uhr
Goto Top
habe ich doch geschrieben. Der Table-Scan von t026 nimmt 95% der Zeit in Anspruch.
Tatsächlich - muss ich wohl übersprungen haben face-smile

Existieren den Indizies für Ldatum und mesoyear? Kann ich aus deiner Index Aufstellung nicht ganz rauslesen face-smile
Mitglied: samet22
samet22 16.02.2017 um 10:15:45 Uhr
Goto Top
Zitat von @SlainteMhath:

habe ich doch geschrieben. Der Table-Scan von t026 nimmt 95% der Zeit in Anspruch.
Tatsächlich - muss ich wohl übersprungen haben face-smile

Existieren den Indizies für Ldatum und mesoyear? Kann ich aus deiner Index Aufstellung nicht ganz rauslesen face-smile

Halloface-smile

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...
Mitglied: SlainteMhath
SlainteMhath 16.02.2017 um 13:50:28 Uhr
Goto Top
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 face-smile

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 face-smile
Mitglied: samet22
samet22 16.02.2017 um 14:02:51 Uhr
Goto Top
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 face-smile

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 face-smile

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 ... ?
Mitglied: SlainteMhath
SlainteMhath 16.02.2017 um 14:17:31 Uhr
Goto Top
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