it-swarm.com.de

Der Bediener verwendete Tempdb, um Daten während der Ausführung mit Überlaufstufe 2 zu verschütten

Ich habe Probleme, die Kosten für die Sortieroperation in einem Abfrageplan mit der Warnung Operator used Tempdb to spill data during execution with spill level 2 Zu minimieren.

Ich habe mehrere Beiträge gefunden, die sich auf Überlaufdaten während der Ausführung mit Überlaufstufe 1 beziehen , aber nicht auf Stufe 2. Stufe 1 scheint durch veraltete Statistiken verursacht zu werden , was über Level 2? Ich konnte nichts im Zusammenhang mit level 2 Finden.

Ich fand diesen Artikel sehr interessant im Zusammenhang mit Sortierwarnungen:

Ignoriere niemals eine Sortierwarnung in SQL Server

Mein SQL Server?

Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64) 17. Juni 2016 19:14:09 Copyright (c) Microsoft Corporation Enterprise Edition (64-Bit) unter Windows NT 6.3 (Build 9600 :) (Hypervisor)

Meine Hardware?

führen Sie die folgende Abfrage aus, um die Harware zu finden:

- Hardwareinformationen von SQL Server 2012

SELECT cpu_count AS [Logical CPU Count], hyperthread_ratio AS [Hyperthread Ratio],
cpu_count/hyperthread_ratio AS [Physical CPU Count], 
physical_memory_kb/1024 AS [Physical Memory (MB)], affinity_type_desc, 
virtual_machine_type_desc, sqlserver_start_time
FROM sys.dm_os_sys_info WITH (NOLOCK) OPTION (RECOMPILE);

enter image description here

aktuell zugewiesener Speicher

SELECT
(physical_memory_in_use_kb/1024) AS Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024) AS Locked_pages_used_Sqlserver_MB,
(total_virtual_address_space_kb/1024) AS Total_VAS_in_MB,
process_physical_memory_low,
process_virtual_memory_low
FROM sys.dm_os_process_memory;

enter image description here

wenn ich meine Abfrage mit einem Jahresumfang ausführe, erhalte ich keinerlei Warnung gemäß dem folgenden Bild:

enter image description here

Aber wenn ich es nur für einen Tag laufen lasse, erhalte ich diese Warnung on the sort operator:

enter image description here

dies ist die Abfrage:

    DECLARE @FromDate SMALLDATETIME = '19-OCT-2016 11:00'
    DECLARE @ToDate   SMALLDATETIME = '20-OCT-2016 12:00'




    SELECT      DISTINCT
                a.strAccountCode ,
                a.strAddressLine6 ,
                a.strPostalCode ,
                CASE    WHEN a.strCountryCode IN ('91','92') THEN 'GB-Int'
                        ELSE a.strCountryCode
                        END AS [strCountryCode]
    FROM        Bocss2.dbo.tblBAccountParticipant AS ap
    INNER JOIN  Bocss2.dbo.tblBAccountParticipantAddress AS apa ON ap.lngParticipantID = apa.lngParticipantID
                                                                AND apa.sintAddressTypeID = 2
    INNER JOIN  Bocss2.dbo.tblBAccountHolder AS ah ON ap.lngParticipantID = ah.lngParticipantID
    INNER JOIN  Bocss2.dbo.tblBAddress AS a ON apa.lngAddressID = a.lngAddressID
                                            AND a.blnIsCurrent = 1
    INNER JOIN  Bocss2.dbo.tblBOrder AS o ON ap.lngParticipantID = o.lngAccountParticipantID
                                        AND o.sdtmOrdCreated >= @FromDate
                                        AND o.sdtmOrdCreated < @ToDate

OPTION(RECOMPILE)

der Abfrageplan ist da

der Abfrageplan mit pastetheplan

Fragen: 1) Im Abfrageplan sehe ich Folgendes:

StatementOptmEarlyAbortReason="GoodEnoughPlanFound" CardinalityEstimationModelVersion="70" 

warum 70? Ich benutze SQL Server 2014

2) Wie entferne ich diesen Sortieroperator (wenn überhaupt möglich)?

3) Ich habe eine ziemlich niedrige Lebenserwartung der Seite gesehen, abgesehen davon, dass diesem Server mehr Speicher hinzugefügt wurde. Gibt es noch etwas, das ich mir ansehen kann, um zu sehen, ob ich diese Warnung verhindern kann?

prost

Update nach der Antwort von Shanky und Paul White

Ich habe meine Statistiken gemäß dem folgenden Skript überprüft und sie scheinen alle korrekt und aktualisiert zu sein.

dies sind alle Indizes und Tabellen, die in dieser Abfrage verwendet werden.

DBCC SHOW_STATISTICS ('dbo.tblBAddress','IDXF_tblBAddress_lngAddressID__INC')
GO
DBCC SHOW_STATISTICS  ('dbo.tblBOrder','IX_tblBOrder_sdtmOrdCreated_INCL')
GO
DBCC SHOW_STATISTICS ('dbo.tblBAccountHolder','PK_tblAccountHolder')
GO
DBCC SHOW_STATISTICS ('dbo.tblBAccountParticipant','PK_tblBAccountParticipants')
GO
DBCC SHOW_STATISTICS ('dbo.tblBAccountParticipantAddress','IDXF_tblBAccountParticipantAddress_lngParticipantID')
GO

das habe ich zurückbekommen:

enter image description here

enter image description here

Dies ist ein Teilergebnis, aber ich habe sie alle erneut besucht.

Für das Statistik-Update habe ich derzeit Ola Hallengren

der Indexoptimierungsjob - soll einmal pro Woche ausgeführt werden - sonntags

EXECUTE [dbo].[IndexOptimize] 
@Databases = 'USER_DATABASES,-%Archive', 
@Indexes = 'ALL_INDEXES' , 
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = NULL,
@PageCountLevel=1000,
@StatisticsSample =100
,@UpdateStatistics = 'Index', 
@OnlyModifiedStatistics = 'Y',
@TimeLimit=10800, 
@LogToTable = 'Y'

Obwohl die Statistiken aktualisiert zu sein schienen Nachdem ich das folgende Skript ausgeführt habe, wurde der Sortieroperator nicht mehr gewarnt.

UPDATE STATISTICS [Bocss2].[dbo].[tblBOrder]  WITH FULLSCAN
--1 hour  04 min 14 sec

UPDATE STATISTICS [Bocss2].[dbo].tblBAddress  WITH FULLSCAN
-- 45 min 29 sec

UPDATE STATISTICS  [Bocss2].[dbo].tblBAccountHolder WITH FULLSCAN
-- 26 SEC

UPDATE STATISTICS  [Bocss2].[dbo].tblBAccountParticipant WITH FULLSCAN
-- 4 min

UPDATE STATISTICS  [Bocss2].[dbo].tblBAccountParticipantAddress WITH FULLSCAN
-- 7 min 3 sec
18

was ist mit Level 2? Ich konnte nichts in Bezug auf Level 2 finden.

Gemäß dieses alte MS-Dokument gibt die Zahl in Tempdb-Überlauf an, wie viele Durchgänge über Daten erforderlich sind, um die Daten zu sortieren. Spill 1 bedeutet also, dass es 1 Mal passieren muss, um die Daten zu sortieren, und 2 bedeutet, dass es 2 Mal passieren muss.

Zitat aus dem Blog:

Wenn eine Abfrage mit einer Sortieroperation eine Ereignisklasse für Sortierwarnungen mit einem Überlaufpegelwert von 2 generiert, kann die Leistung der Abfrage beeinträchtigt werden, da zum Sortieren der Daten mehrere Durchgänge über die Daten erforderlich sind. Im folgenden Beispiel sehen wir einen Überlaufpegelwert von 1, was bedeutet, dass ein Durchlauf über die Daten ausreichte, um die Sortierung abzuschließen.

warum 70? Ich benutze SQL Server 2014

Dies liegt daran, dass die Kompatibilitätsstufe der Datenbank im Bild NICHT 120 beträgt (was die Kompatibilitätsstufe der Datenbank von 2014 bedeutet), da die Abfrage nicht 120 ist und unter Verwendung des alten CE-Modells (Cardinality Estimation) verarbeitet wird, das als CardinalityEstimationModelVersion="70" Bezeichnet wird. . Ich bin sicher, Sie wissen, dass wir ab SQL Server 2014 ein neues CE haben.

wie werde ich diesen Sortieroperator los (wenn überhaupt möglich)?

Der eindeutige Befehl, den Sie verwenden, verursacht die Sortieroperation. Die Daten, die sortiert werden, passen nicht in den Speicher, sodass sie in Tempdb übertragen werden. In diesem Fall wird im Ausführungsplan eine Sortierwarnung mit gelbem Ausrufezeichen angezeigt. Sortierwarnungen sind nicht immer ein Problem.

Sie können im Ausführungsplan sehen, dass die geschätzte Anzahl der zu sortierenden Zeilen 1 beträgt, aber zur Laufzeit 16.353 gefunden werden. Die für die Sortierung reservierte Speichermenge basiert auf der erwarteten (geschätzten) Größe der Eingabe und kann während der Ausführung (in diesem Fall) nicht wachsen.

Die geringe Speicherzuweisung für die Abfrage (1632 KB) wird auch auf gleichzeitig ausgeführte speicherintensive Operatoren aufgeteilt (sortieren und 'optimierte' Schleifenverknüpfungen). In Ihrem Plan bedeutet dies, dass 33,33% (544 KB) für die Sortierung beim Lesen von Zeilen verfügbar sind (Eingabespeicheranteil). Dies ist nicht genug Speicher, um die 16.353 Zeilen zu sortieren, daher wird es auf tempdb übertragen. Eine Verschüttung auf einer Ebene reicht nicht aus, um die Sortierung abzuschließen. Daher ist eine zweite Verschüttungsstufe erforderlich (weitere Informationen zu Verschüttungsstufen finden Sie in der Referenz am Ende).

(Sort properties

Sortieren Sie die Eigenschaften wie im SQL Sentry Plan Explorer angezeigt

Das Aktualisieren von Statistiken wird wahrscheinlich beim Problem der Kardinalitätsschätzung helfen. Möglicherweise tritt das Problem mit aufsteigenden Schlüsseln auf, insbesondere in Tabelle tblBOrder. Eine einfache Auswahl aus dieser Tabelle mit den Literaldaten aus Ihrer Frage wird wahrscheinlich jetzt eine Zeile schätzen.

Ich habe festgestellt, dass die Lebenserwartung der Seiten ziemlich niedrig ist, abgesehen davon, dass diesem Server mehr Speicher hinzugefügt wurde. Gibt es noch etwas, das ich mir ansehen kann, um festzustellen, ob ich diese Warnung verhindern kann?

PLE ist ein Hinweis auf das Ausmaß der E/A-Aktivität. Hat es zugenommen? Dies geschieht häufig oder nur dann, wenn Sie eine bestimmte Abfrage ausführen oder dies erst heute geschehen ist. Vermeiden Sie Knie-Ruck-Reaktionen. Zuerst müssen wir sicherstellen, dass Sie wirklich einem Speicherdruck ausgesetzt sind oder dass eine unerwünschte Abfrage, die zu viel E/A erzeugt, dies verursacht. Auf jeden Fall ist SQL Server bereits 97 G Speicher zugewiesen.

Weitere Informationen zu Verschüttungswerten und dem aufsteigenden Schlüsselproblem finden Sie unter:

17
Shanky