web-dev-qa-db-ja.com

Store proc SQL Serverを長時間実行している理由を見つける

私は、プログラムによって2.5秒ごとに24〜7呼び出されるストアドプロシージャを持っています。このプロシージャは通常、10ミリ秒未満で実行されます。 1日に数回(3〜5回)実行するのに約42953ミリ秒かかります(常に42950〜42959ミリ秒)。

どうしてそんなに時間がかかるのか、その理由をどのように見つけたり、プロファイルしたりできますか

更新: SQL Serverバージョン2008 R2

手順:

select 
    [view_EventsToRaise].EventId,
    [view_EventsToRaise].EventStatus,
    [view_EventsToRaise].Tag,
    [view_EventsToRaise].SessieGebruikerId,
    Postbus.Persoon_Id_afz      as PersoonIdAfz,
    Postbus.Persoon_Id_adr      as PersoonIdAdr,
    Postbus.Persoon_Id_derde    as PersoonIdDerde,
    Postbus.Locatie_Id          as LocatieId,
    Postbus.Artikel_Id          as ArtikelId,
    Postbus.Onderwerp_Id        as OnderwerpId,
    Postbus.Bedrijf_Id_afz      as BedrijfIdAfz,
    Postbus.Bedrijf_Id_adr      as BedrijfIdAdr,
    Postbus.Bedrijf_Id_derde    as BedrijfIdDerde,
    Postbus.Document_Id         as DocumentId,      
    Postbus.Document            as Document,        
    DataKenmerk.Code            as PostbusDataCode,
    PostbusData.Inhoud          as PostbusDataInhoud,
    SimObj.Id                   as SimObjId,
    Eventsoort.Code             as Eventsoort
from 
    [view_EventsToRaise]
    left outer join Postbus
        left outer join PostbusData
            inner join DataKenmerk
            on PostbusData.DataKenmerk_id = DataKenmerk.id
        on PostbusData.Postbus_Id = Postbus.id
    on Postbus.Id = [view_EventsToRaise].PostbusId
    left outer join SimObjEvent                         
        inner join eventsoort
        on eventsoort.id = SimObjEvent.eventsoort_id
    on [view_EventsToRaise].SimObjEventId = SimObjEvent.Id
    left outer join SimObj
    on SimObj.Id = SimObjEvent.SimObj_Id
order by
    [view_EventsToRaise].Tijd,
    [view_EventsToRaise].EventId

2014年9月9日更新:プロファイラーを参照して上記の状況が発生した場合、次のことが注目されます。RPC:Completedイベントが登録されると、開始時刻は現在のシステム時刻になります。ログの瞬間ですが、終了時刻は将来の値です(現在のシステム時刻と期間、約43秒後)。

endtime列の値はどのように決定されますか?これは予測ですか?

4
pexxxy

これはおそらくブロッキングプロセスが原因です。 1日に3〜5回、これは40秒程度かかる更新またはその他の書き込みによってブロックされます。 SELECTは、続行できるまでブロックされます。これが事実である場合、問題は ブロックされたプロセスレポートイベント を使用して識別できます。このイベントを有効にし、しきい値を〜35秒に設定する必要があります。 blocked process threshold Server Configuration Option を参照してください。明らかに他のクエリでもイベントが発生する可能性がありますが、それらの問題についても議論の余地があります。

ブロッキングの簡単な回避策は、行バージョンの分離レベルを使用することです。 行のバージョン管理ベースの分離レベルについて理解する

それ以外の場合は、これをパフォーマンスの問題として調査する必要があります。 SQL Serverのパフォーマンスを分析する方法 をお読みください。

5
Remus Rusanu