Viele Full Table oder Full Index Scan

07/03/2008 - 08:53 von Paolo Taverna | Report spam
Hallo zusammen

Mit dem Perfomance Monitor (Perfmon) mit dem Leistungsindikator
"SQLServer:Zugriffsmethoden - Vollstàndige Scan/Sec" habe ich einen Wert
zwischen 100-180 Faktor 1.0 gemessen. Dieser Wert taucht immer wieder auf
wenn gewisse Programme ausgeführt werden. Es handelt sich um eine SQL Server
2005 Installation. Mit dem SQL Profiler habe ich auf die Select's gefunden
welche einen Full Table oder Full Index Scan verursachen. Es sind sehr viele
SQL Session offen ca. 11'000, und nun muss ich beweisen, welche Session die
Fulltable Scan verursacht. Über den Profiler habe ich es gesehen, aber für
den Beweis, brauche ch so etwas wie eine Auswertung die besagt, in den
moment sind 60 Full Table/Index scan am laufen verursacht von den Session
oder eine Ermittlung die einfach aussagt, diese "Select " werden im Moment
ausgeführt im Full Table/Index scan Modus.
Kennt ihr solche SQL Auswertungen oder auch Tools welche das können?

Gruss Paolo
 

Lesen sie die antworten

#1 Christoph Ingenhaag
07/03/2008 - 14:18 | Warnen spam
"Paolo Taverna" wrote:

Hallo zusammen

Mit dem Perfomance Monitor (Perfmon) mit dem Leistungsindikator
"SQLServer:Zugriffsmethoden - Vollstàndige Scan/Sec" habe ich einen Wert
zwischen 100-180 Faktor 1.0 gemessen. Dieser Wert taucht immer wieder auf
wenn gewisse Programme ausgeführt werden. Es handelt sich um eine SQL Server
2005 Installation. Mit dem SQL Profiler habe ich auf die Select's gefunden
welche einen Full Table oder Full Index Scan verursachen. Es sind sehr viele
SQL Session offen ca. 11'000, und nun muss ich beweisen, welche Session die
Fulltable Scan verursacht. Über den Profiler habe ich es gesehen, aber für
den Beweis, brauche ch so etwas wie eine Auswertung die besagt, in den
moment sind 60 Full Table/Index scan am laufen verursacht von den Session
oder eine Ermittlung die einfach aussagt, diese "Select " werden im Moment
ausgeführt im Full Table/Index scan Modus.
Kennt ihr solche SQL Auswertungen oder auch Tools welche das können?

Gruss Paolo




Hallo Paolo,

jedes Select Statement erzeugt Lesezugriffe. Scans erzeugen natürlich mehr
Lesezugriffe als z.B. ein Seek. Die Sessions die die meisten Lesezugriffe
haben, dürften auch diejenigen sein, die diese Selects ausführen.

Das kannst du dir ganz einfach hier anschauen:
select
session_id,
logical_reads
from sys.dm_exec_sessions

Ist nur die Frage, was dir das bringt. Das mit dem "Beweisen" hört sich so
nach Idee eines Vorgesetzten an, der ein Zahlenwerk braucht, um seine nàchste
Kurzschlussreaktion zu rechtfertigen.

Du musst die Statements identifizieren, die das System unter Last setzten
(das hat nichts mit der Prozessorlast zu tun, sondern mit I/O und ggf.
Locking).

Da hat der Torsten Schuessler in "CPU Auslastung pro SQL Session ermitteln
in SQL Server" schon in die richtige Richtung gezeigt.

Wichtig ist hier die Frage zu klàren, welche Statements dafür verantwortlich
sind. Relevant sind u.a. Statements die besonders viele Lesevorgànge
verursachen oder besonders oft aufgerufen werden (im schlimmsten Fall beides).


select top 10
execution_count,
max_physical_reads,
max_logical_reads,
substring(text,statement_start_offset/2,(case when
statement_end_offset = -1 then len(convert(nvarchar(max), text)) * 2 else
statement_end_offset end -statement_start_offset)/2) sql_stmt,
query_plan
from sys.dm_exec_query_stats S
cross apply sys.dm_exec_sql_text(sql_handle)
cross apply sys.dm_exec_query_plan(plan_handle)
order by
1 desc

je nach dem welche Sortierung du einkommentierst hast du
die 10 am hàufigsten ausgeführten Statements,
die 10 Statements mit maximalen physikalischen Lesevorgàngen und
die 10 Statements mit maximalen logischen Lesevorgàngen
mit SQL Statement und Ausführungsplan.

Anhand der Sessions mit den meisten Reads kannst du ja schon mal auf
bestimmte Anwendungen eingrenzen. Mit den SQL Statements kannst du, je
nachdem wieviel von der Applikation offenliegt feststellen, um welche
Workflows es sich handelt. Dann ist schon mal der Buhmann gefunden, auf den
sich alle stürzen können. Derweil hast du Ruhe und schaust dir die
Ausführungsplàne mal an (die XML Ausgabe kannst du mit der Endung .sqlplan
speichern und im SSMS öffnen und grafisch anzeigen lassen).

Wie du anhand der dir dort im Zusammenhang mit dem SQL Statement zur
verfügung stehenden Informationen weiter vorgehst, sprengt den Rahmen.

Vg
Christoph

Ähnliche fragen