オペレーターがtempdbを使用して、実行中に流出レベル2でデータを流出させました

警告Operator usedtempdbを使用して、クエリプランでの並べ替え操作のコストを最小限に抑えるのに苦労していますto spill data during execution with spill level 2

流出レベル1で実行中に流出データに関連するいくつかの投稿を見つけましたが、レベル2ではありません。レベル1は古い統計に起因しているようですが、レベル2はどうですか？に関連するものは見つかりませんでしたlevel 2。

この記事はソート警告に関連して非常に興味深いものでした。

SQL Serverで並べ替え警告を無視しない

私のSQLサーバー？

Microsoft SQL Server 2014（SP2）（KB3171021）-12.0.5000.0（X64）2016年6月17日19:14:09 Copyright（c）Microsoft Corporation Enterprise Edition（64ビット）on Windows NT 6.3（Build 9600：）（Hypervisor）

私のハードウェア？

ハーウェアを見つけるために以下のクエリを実行します：

-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);

現在割り当てられているメモリ

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;

1年間のスコープでクエリを実行すると、次の図のように警告はまったく表示されません。

しかし、1日のスコープでのみ実行すると、次の警告が表示されますon the sort operator。

これはクエリです：

    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)

クエリプランはこちら

pastetheplanを使用したクエリプラン

質問：1）クエリプランに次のように表示されます。

StatementOptmEarlyAbortReason="GoodEnoughPlanFound" CardinalityEstimationModelVersion="70" 

なぜ70？私はSQL Server 2014を使用しています

2）ソート演算子を削除するにはどうすればよいですか（可能な場合）。

3）このサーバーにメモリを追加することは別として、ページの寿命はかなり短くなっていますが、この警告を防ぐことができるかどうかを確認することができるものは他にありますか？

乾杯

ShankyとPaul Whiteからの回答後の更新

以下のスクリプトに従って統計を確認しましたが、すべて正しく更新されているようです。

これらはすべて、このクエリで使用されるインデックスとテーブルです。

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

これは私が返したものです：

これは部分的な結果ですが、私はそれらすべてを再訪しました。

統計の更新のために、私は現在オラ・ハレングレンを持っています

インデックス最適化ジョブ-週に1回実行するようにスケジュール-日曜日

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'

次のスクリプトを実行した後、統計は更新されたように見えましたが、ソート演算子に関する警告は表示されませんでした。

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

レベル2はどうですか？レベル2に関連するものは見つかりませんでした。

ごとに この古いMSドクデータをソートするために、データ上で必要とされるどのように多くのパスtempdbの流出が意味の数字。したがって、流出1はデータをソートするために1回渡す必要があり、2は2回渡す必要があることを意味します。

ブログから引用：

並べ替え操作を含むクエリが、スピルレベル値2の並べ替え警告イベントクラスを生成する場合、データを並べ替えるにはデータを複数回渡す必要があるため、クエリのパフォーマンスに影響を与える可能性があります。以下の例では、流出レベルの値が1になっています。これは、データを1回渡すだけでソートを完了するのに十分であることを意味します。

なぜ70？私はSQL Server 2014を使用しています

これは、ピクチャ内のデータベースの互換性レベルが120ではないためです（2014データベースの互換性レベルを意味します）。これは、クエリと呼ばれる古いカーディナリティ推定（CE）モデルを使用して処理されるためCardinalityEstimationModelVersion="70"です。SQL Server 2014から新しいCEが導入されていることをご存知でしょう。

どうすればそのソート演算子を取り除くことができますか（可能な場合）。

使用している別個のコマンドがソート操作を引き起こしています。並べ替えられているデータはメモリに収まらないため、tempdbに流出し、これが発生すると、実行プランに黄色の感嘆符付きの並べ替え警告が表示されます。並べ替えの警告は必ずしも問題ではありません。

実行計画では、ソートされる推定行数は1ですが、実行時に16,353が検出されることがわかります。ソート用に予約されているメモリの量は、予想されるものに基づいています、入力（推定）サイズに実行中に増加することはありません（この場合）。

クエリの小さなメモリ許可（1632KB）は、同時に実行されるメモリ消費演算子間で共有されます（ソートおよび「最適化された」ループ結合）。プランでは、行の読み取り中に33.33％（544KB）がソートに使用できることを意味します（入力メモリの一部）。これは16,353行をソートするのに十分なメモリではないため、tempdbに流出します。単一レベルの流出ではソートを完了するのに十分ではないため、第2レベルの流出が必要です（流出レベルの詳細については、最後のリファレンスを参照してください）。

_{SQL Sentry Plan Explorerで表示されるようにプロパティを並べ替える}

統計を更新すると、カーディナリティの推定の問題に役立つ可能性があります。特にテーブル上で、上行キーの問題が発生している可能性がありますtblBOrder。質問からの文字通りの日付を含むそのテーブルからの単純な選択は、おそらく今すぐ1行を推定します。

このサーバーにメモリを追加することは別にして、ページの寿命はかなり短くなっていますが、この警告を防ぐことができるかどうかを確認するために他に見ることができるものはありますか？

PLEはI / Oアクティビティの量を示していますが、増加していますか？したがって、これは頻繁に発生するのか、特定のクエリを実行したときにのみ発生するのか、それとも今日だけ発生したのですか。ニージャークの反応を避けます。最初に、メモリのプレッシャーに直面しているか、I / Oを大量に生成している不正なクエリがこれを引き起こしていることを確認する必要があります。とにかく、SQL Serverには既に97 Gのメモリが割り当てられています。

流出レベルと重要な問題の詳細については、以下を参照してください。

• ポール・ホワイトによるレベル15,000までこぼれるソート
• Fabiano Amorimによる昇順列の統計