Sql Server 2008からSql Server 2016にアップグレードした後、高速だったストアドプロシージャが遅くなりました。

Question

ジオスペース領域内にあるすべてのレコード（「地理」）を返すストアドプロシージャがあります。 CTE（with）、いくつかの共用体、いくつかの内部結合を使用してデータをXMLとして返します。何も議論の余地がない、あるいは最先端ではありません。

このストアドプロシージャは、SQL Server 2008で長年役に立ちました。比較的遅いサーバーでは1秒以内に実行されています。大量のメモリと超高速SDDを備えた超高速サーバー上で、SQL Server 2016に移行しました。

データベース全体と関連付けられているアプリケーションは、この新しいサーバー上でという非常に高速のになります。非常に満足しています。ただし、この1つのストアドプロシージャは、正確に同じパラメータとまったく同じデータセットに対して、1秒ではなく16秒で実行されます。

このデータベースのインデックスと統計情報を更新しました。また、データベースの互換性レベルを100から130に変更しました。

興味深いことに、一時テーブルを使用してCTEを使用するのではなく、「挿入」するストアドプロシージャを書き直しました。これにより、時間が16秒から4秒に短縮されました。

実行計画では、ボトルネックの発生箇所を明確に把握することはできません。

私たちは少し考えています。私たちは次に何をすべきですか？前もって感謝します。

-

私は認めざるを得ない気よりも、私は今この問題に多くの時間を費やしてきました。私は問題を示すために、ストアドプロシージャを次のクエリに煮詰めました。ストアドプロシージャで

drop table #T 

declare @viewport sys.geography=convert(sys.geography,0xE610000001041700000000CE08C22D7740C002370B7670F4624000CE08C22D7740C002378B5976F4624000CE08C22D7740C003370B3D7CF4624000CE08C22D7740C003378B2082F4624000CE08C22D7740C003370B0488F4624000CE08C22D7740C004378BE78DF4624000CE08C22D7740C004370BCB93F4624000CE08C22D7740C004378BAE99F4624000CE08C22D7740C005370B929FF4624000CE08C22D7740C005378B75A5F4624000CE08C22D7740C005370B59ABF462406F22B7698E7640C005370B59ABF462406F22B7698E7640C005378B75A5F462406F22B7698E7640C005370B929FF462406F22B7698E7640C004378BAE99F462406F22B7698E7640C004370BCB93F462406F22B7698E7640C004378BE78DF462406F22B7698E7640C003370B0488F462406F22B7698E7640C003378B2082F462406F22B7698E7640C003370B3D7CF462406F22B7698E7640C002378B5976F462406F22B7698E7640C002370B7670F4624000CE08C22D7740C002370B7670F4624001000000020000000001000000FFFFFFFF0000000003) 

declare @outputControlParameter nvarchar(max) = 'a value passed in through a parameter to the stored that controls the nature of data to return. This is not the solution you are looking for' 

create table #T 
    (value int) 

insert into #T 
select 136561 union 
select 16482 -- These values are sourced from parameters into the stored proc 

select 
     [GeoServices_Location].[GeographicServicesGatewayId], 
     [GeoServices_Location].[Coordinate].Lat, 
     [GeoServices_Location].[Coordinate].Long 

     from GeoServices_Location 

     inner join GeoServices_GeographicServicesGateway 
      on GeoServices_Location.GeographicServicesGatewayId = GeoServices_GeographicServicesGateway.GeographicServicesGatewayId 

     where 
     (
      (len(@outputControlParameter) > 0 and GeoServices_Location.GeographicServicesGatewayId in (select value from #T)) 
      or (len(@outputControlParameter) = 0 and GeoServices_Location.Coordinate.STIntersects(@viewport) = 1) 
     ) 
     and GeoServices_GeographicServicesGateway.PrimarilyFoundOnLayerId IN (3,8,9,5) 

GO 

はこれに煮詰め、それは2016

http://www.filedropper.com/newserver-slowexecutionplan

http://www.filedropper.com/oldserver-fastexecutionplan

のWindows Server 2016がSQL Server上でSQL Server 2008および5秒で0秒で実行されますGeospatial Intersectsの呼び出しでは、そこに費やされた時間の94％が呼び出されます。 Sql Server 2008は、ハッシュ・マッチングと並列処理などの標準的な処理を含む多くのステップで時間を費やしています。

これは同じデータベースであることを忘れないでください。 1つはSQL Server 2016マシンにコピーされ、互換性レベルが向上しました。

問題を回避するために、SQL Server 2016がチョークしないようにストアドプロシージャを実際に書き直しました。私は250msecで動作しています。しかし、これは最初に起きたはずではありません。以前は細かくチューニングされたクエリやストアドプロシージャが効率的に実行されていないことが懸念されます。

ありがとうございます。

-

さらに、私はサービスのパラメータを起動するトレース・フラグ-T6534を追加するための提案がありました。それはクエリ時間に何の違いもありませんでした。また、クエリの最後にオプション（QUERYTRACEON 6534）を追加しようとしましたが、もう一度違いはありません。

Answer 1

1. 古いサーバー（DBS）の構成対新しいサーバ（DBS）上のログファイルを/データの成長を確認してください。I/Oバッファのログを確認DBクエリが
2. + tempdbの上で実行されていますエラー
3. DBのチェックリカバリモデル - シンプルVSフル/バルク
4. これは一貫した動作ですか？プロセスが実行中に実行されている可能性がありますか？
5. 統計情報/インデックスについて - 正しいデータサンプルで実行されていますか？ （計画を見て）

さらに多くの事をチェック/実行できますが、この質問には十分な情報がありません。

Answer 2

提供したクエリプランから、新しいサーバーバージョンでは空間インデックスが使用されていないことがわかります。クエリオプティマイザは、空間インデックスとの計画を選んだことを確認するために 使用空間インデックスヒント：

select 
    [GeoServices_Location].[GeographicServicesGatewayId], 
    [GeoServices_Location].[Coordinate].Lat, 
    [GeoServices_Location].[Coordinate].Long 
from GeoServices_Location with (index ([spatial_index_name]))... 

私がヒントに問題があるOR演算クエリ述語に、そのヒントと私の提案は、実際に中に助けにはなりませんことを確認この場合。 しかし、私は述部が@outputControlParameterに依存しているので、これらの2つのケースを分離するためにクエリを書き直すと、私の提案を参照してください。 また、クエリプランから、SQL 2008上のクエリプランはSQL 2016がシリアルである間はパラレルであることがわかります。並列プランを強制するには、オプション（recompile、querytraceon 8649）を使用します（新しい超高速サーバーに古いコアよりも多くのコアがある場合に役立ちます）。うまく

if (len(@outputControlParameter) > 0) 
    select 
    [GeoServices_Location].[GeographicServicesGatewayId], 
    [GeoServices_Location].[Coordinate].Lat, 
    [GeoServices_Location].[Coordinate].Long 

    from GeoServices_Location 

    inner join GeoServices_GeographicServicesGateway 
    on GeoServices_Location.GeographicServicesGatewayId = GeoServices_GeographicServicesGateway.GeographicServicesGatewayId 

    where 
    GeoServices_Location.GeographicServicesGatewayId in (select value from #T)) 
    and GeoServices_GeographicServicesGateway.PrimarilyFoundOnLayerId IN(3,8,9,5) 
    option (recompile, querytraceon 8649) 
else 
    select 
    [GeoServices_Location].[GeographicServicesGatewayId], 
    [GeoServices_Location].[Coordinate].Lat, 
    [GeoServices_Location].[Coordinate].Long 

    from GeoServices_Location with (index ([SPATIAL_GeoServices_Location])) 

    inner join GeoServices_GeographicServicesGateway 
    on GeoServices_Location.GeographicServicesGatewayId = GeoServices_GeographicServicesGateway.GeographicServicesGatewayId 

    where 
    GeoServices_Location.Coordinate.STIntersects(@viewport) = 1 
    and GeoServices_GeographicServicesGateway.PrimarilyFoundOnLayerId IN (3,8,9,5) 
    option (recompile, querytraceon 8649)