70866
Jan 09, 2013
2771
4
0
SQL Server 2008 R2 50 Daten gelöscht, 15-fache Query-Laufzeit hinterher
hab eine Datenbank in der Mangel, die 6 GB an Daten enthalten hat. Nach dem Löschen von ca. 50% des Datenbestandes benötigt die Query 240 Sekunden und nicht mehr 15 Sekunden
Ich bin mit meinem Latein am Ende....
Ich hab eine Datenbank in der Mangel, die 6 GB an Daten enthalten hat. Nach dem Löschen von ca. 50% des Datenbestandes benötigt die Query 240 Sekunden und nicht mehr 15 Sekunden.
Anhand des geschätzten Ausführungsplanes sehe ich, daß in der verkleinerten Datenbank ein ganz anderer Plan benutzt wird, obwohl die Resultate-Menge der Query gleich bleibt.
Ich habe erst einzelne Indizes mit hohen IO Kosten neu erstellt, dann die Statistiken aktualisiert, und zuguterletzt in einem Wartungsplan ALLE Indizes neu erstellt und danach ALLE Statistiken.
Was kann dazu führen, daß bei gesunkenem Datenbestand die Abfragezeit sich so dramatisch verändern kann obwohl das Resultat an sich gleich bleibt?
Es sind lediglich Daten gelöscht worden, die schon vorher nicht benötigt wurden. Selbst ein "Verkleinern der Datenbank" mit "Neuberechnung des freien Speicherplatzes 10%" hat nichts gebracht.
Über Tips wäre ich sehr dankbar.
Ich hab eine Datenbank in der Mangel, die 6 GB an Daten enthalten hat. Nach dem Löschen von ca. 50% des Datenbestandes benötigt die Query 240 Sekunden und nicht mehr 15 Sekunden.
Anhand des geschätzten Ausführungsplanes sehe ich, daß in der verkleinerten Datenbank ein ganz anderer Plan benutzt wird, obwohl die Resultate-Menge der Query gleich bleibt.
Ich habe erst einzelne Indizes mit hohen IO Kosten neu erstellt, dann die Statistiken aktualisiert, und zuguterletzt in einem Wartungsplan ALLE Indizes neu erstellt und danach ALLE Statistiken.
Was kann dazu führen, daß bei gesunkenem Datenbestand die Abfragezeit sich so dramatisch verändern kann obwohl das Resultat an sich gleich bleibt?
Es sind lediglich Daten gelöscht worden, die schon vorher nicht benötigt wurden. Selbst ein "Verkleinern der Datenbank" mit "Neuberechnung des freien Speicherplatzes 10%" hat nichts gebracht.
Über Tips wäre ich sehr dankbar.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 196712
Url: https://administrator.de/contentid/196712
Printed on: April 19, 2024 at 22:04 o'clock
4 Comments
Latest comment
Hallo,
vl hast du Versehentlich Keys gelöscht?
Gruß
vl hast du Versehentlich Keys gelöscht?
Gruß
Hallo,
geringe Performance und ineffiziente Queries können viele Ursachen haben:
- "Schlechte" Indizes
- fragmentierte Datenbankdateien (oft verkleinert?? = logische Fragmentierung innerhalb der Dateien) -> Backup, löschen, Recovery
- geringere Serverperformance (virtueller Server? neue Dienste?) -> Performance counter (buffer cache hit ratio etc.)
- Durch Blockieren beeinträchtigte Abfragen -> einfach mal unten das Script ausführen
- Fehlerhafte Views -> alle mal mit Select * from Viewname aufrufen
Es macht durchaus auch Sinn, den Aktivitätsmonitor aktiv zu haben und schauen, ob die User sich nicht gegenseitig Transaktionen blockieren, indem sie Ressourcen sperren.
Wurde an den Isolation Leveln gespielt? Wurde testweise schon mal das Wiederherstellungsmodell auf Einfach gestellt?
Viel Erfolg!
SELECT TOP 10
[Average Time Blocked] = (total_elapsed_time - total_worker_time) / qs.execution_count
,[Total Time Blocked] = total_elapsed_time - total_worker_time
,[Execution count] = qs.execution_count
,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,
(CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)
,[Parent Query] = qt.text
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Average Time Blocked] DESC;
geringe Performance und ineffiziente Queries können viele Ursachen haben:
- "Schlechte" Indizes
- fragmentierte Datenbankdateien (oft verkleinert?? = logische Fragmentierung innerhalb der Dateien) -> Backup, löschen, Recovery
- geringere Serverperformance (virtueller Server? neue Dienste?) -> Performance counter (buffer cache hit ratio etc.)
- Durch Blockieren beeinträchtigte Abfragen -> einfach mal unten das Script ausführen
- Fehlerhafte Views -> alle mal mit Select * from Viewname aufrufen
Es macht durchaus auch Sinn, den Aktivitätsmonitor aktiv zu haben und schauen, ob die User sich nicht gegenseitig Transaktionen blockieren, indem sie Ressourcen sperren.
Wurde an den Isolation Leveln gespielt? Wurde testweise schon mal das Wiederherstellungsmodell auf Einfach gestellt?
Viel Erfolg!
SELECT TOP 10
[Average Time Blocked] = (total_elapsed_time - total_worker_time) / qs.execution_count
,[Total Time Blocked] = total_elapsed_time - total_worker_time
,[Execution count] = qs.execution_count
,[Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,
(CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)
,[Parent Query] = qt.text
,DatabaseName = DB_NAME(qt.dbid)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Average Time Blocked] DESC;
danke für den Tip ...
1) ich war alleine
2) physischer SErver 16 CPUs 16 GB RAM
3) Indizes können nicht schlecht sein weil komplett neu erstellt
4) Statistiken sind neu erstellt
die Abfrage war aber mit als auch ohne aktualisierte Statistiken gleich langsam, der Grad der Indexfragmentierung war im Prozentbereich vor dem Neuaufbau, und erst ab 50% gibts Performanceverlust.
1) ich war alleine
2) physischer SErver 16 CPUs 16 GB RAM
3) Indizes können nicht schlecht sein weil komplett neu erstellt
4) Statistiken sind neu erstellt
die Abfrage war aber mit als auch ohne aktualisierte Statistiken gleich langsam, der Grad der Indexfragmentierung war im Prozentbereich vor dem Neuaufbau, und erst ab 50% gibts Performanceverlust.
Hallo,
dann probiere doch folgendes:
Vor die Query:
Set statistics time on;
set statistics io on;
Query ausführen und Ergebnisse anschauen: Viel mehr physical reads / logical reads?
Ausführungsplan posten, dann sehen wir auch, um welche Indizes es sich handelt.
In wie weit hat sich der Plan verändert? Wurden Index Seeks durch Scans ersetzt? Kann normal sein bei "wenigen" Datensätzen. Hat sich die Struktur verändert? Dann hat der SQL Server einen womöglich schlechten Ausführungsplan gespeichert. Was hilft, ist Indizes zu löschen, die im Moment verwendet werden.
Es gibt auch Systeme, die zu häufig gewartet werden:
DBCC Best Practices Implementations
There are few DBCC commands to be avoided and few very crucial for system. Understand the usage of DBCC FREEPROCCACHE, DBCC SRHINKDATABASE, DBCC SHRINKFILE, DBCC DROPCLEANBUFFER, DBCC REINDEX, as well as the usage of few system stored procedures like SP_UPDATESTATS. If you are currently using any of the above mentioned and a few other DBCC maintenance task commands carefully review their usage.
Zusätzlich mal schauen, ob nicht zufällig irgendeine Auditierung, Filestream, oder andere, externe Prozesse auf den Server zugreifen.
Aus der Ferne ist immer ein wenig Glaskugel bei dem komplexen Thema - mehr Infos wären nicht schlecht.
Gruss
Grinskeks
dann probiere doch folgendes:
Vor die Query:
Set statistics time on;
set statistics io on;
Query ausführen und Ergebnisse anschauen: Viel mehr physical reads / logical reads?
Ausführungsplan posten, dann sehen wir auch, um welche Indizes es sich handelt.
In wie weit hat sich der Plan verändert? Wurden Index Seeks durch Scans ersetzt? Kann normal sein bei "wenigen" Datensätzen. Hat sich die Struktur verändert? Dann hat der SQL Server einen womöglich schlechten Ausführungsplan gespeichert. Was hilft, ist Indizes zu löschen, die im Moment verwendet werden.
Es gibt auch Systeme, die zu häufig gewartet werden:
DBCC Best Practices Implementations
There are few DBCC commands to be avoided and few very crucial for system. Understand the usage of DBCC FREEPROCCACHE, DBCC SRHINKDATABASE, DBCC SHRINKFILE, DBCC DROPCLEANBUFFER, DBCC REINDEX, as well as the usage of few system stored procedures like SP_UPDATESTATS. If you are currently using any of the above mentioned and a few other DBCC maintenance task commands carefully review their usage.
Zusätzlich mal schauen, ob nicht zufällig irgendeine Auditierung, Filestream, oder andere, externe Prozesse auf den Server zugreifen.
Aus der Ferne ist immer ein wenig Glaskugel bei dem komplexen Thema - mehr Infos wären nicht schlecht.
Gruss
Grinskeks
