ぬつさん
だめでしたか、、
再起動前後で何かが変わっているはずです。僕が考えつくのは
A:再起動の前後で実行プランが変わる
B:再起動の前後でサーバーリソースの占有状況が変わる
の2つの可能性です。Aに関しては、with recompileをつけて都度コンパイルされるようにすれば解消されるはずです。（再起動により統計情報が更新されることは無いと思うので）
ただし、下記の記事の内容は少し気になるので、ご一読してみて使用されているストアドに該当箇所があれば、修正を検討してみてはいかがでしょうか。
■DO’s&DONT’s #6: 絶対にやってはいけないこと – ストアドプロシージャ内でのパラメータ値の変更
https://blogs.msdn.microsoft.com/jpsql/2011/03/25/dosdonts-6-1/
こちらに該当しないか、ストアドプロシージャを確認してみてください。
該当しない場合でも、遅い時と速い時で実行プランが変わっているかチェックしてみてください。
また、Bに関しても気になっています。クエリが遅い時に、下記DVMクエリを実行してみてください。
select top 100 der.session_id
,DB_NAME(der.database_id) as database_name
,des.host_name
,des.program_name
,der.status -- Status of the request. (background / running / runnable / sleeping / suspended)
,dest.text as command_text
,SUBSTRING(dest.text, der.statement_start_offset / 2, (case when der.statement_end_offset = - 1 then LEN(CONVERT(nvarchar(MAX), dest.text)) * 2 else der.statement_end_offset end - der.statement_start_offset) / 2) as current_running_stmt
,datediff(s, der.start_time, GETDATE()) as time_sec
,wait_resource --ロックされているリソース名
,last_wait_type --最後または現在の待機の種類の名前
,der.wait_time as wait_time_ms
,der.blocking_session_id
,der.open_transaction_count
,der.command
,der.percent_complete --一部コマンドの進捗状況を表示してくれるらしい
,der.cpu_time
,(case der.transaction_isolation_level when 0 then 'Unspecified' when 1 then 'ReadUncomitted' when 2 then 'ReadCommitted' when 3 then 'Repeatable' when 4 then 'Serializable' when 5 then 'Snapshot' else cast(der.transaction_isolation_level as varchar) end) as transaction_isolation_level
,der.granted_query_memory * 8 as granted_query_memory_kb --キロバイト単位
,deqp.query_plan -- 実行プラン
from sys.dm_exec_requests der
join sys.dm_exec_sessions des on des.session_id = der.session_id
outer apply sys.dm_exec_sql_text(sql_handle) as dest
outer apply sys.dm_exec_query_plan(plan_handle) as deqp
where des.is_user_process = 1 and datediff(s, der.start_time, GETDATE()) >= 1 -- 例：1秒以上実行中のクエリに限定
and dest.text like '%%' -- クエリの中身でlike検索したいときはここを編集
order by datediff(s, der.start_time, GETDATE()) desc
このクエリは、サーバーで実行中のクエリリストを取得できます。
これを実行すること、該当のストアドが実行中である様子が確認できると思います。
確認できたら、下記手順で問題となっているlast_wait_typeを特定してみてください。
1.クエリが実行中の場合は、last_wait_typeカラムをチェック。
2.何度かクエリを実行し直してみて、last_wait_typeカラムがずっと同じ値のままであれば、そのwait_typeが原因でクエリの完了を待っているという判断を下す。
→ 1回のクエリ実行でさまざまな待ち状態が発生するのは普通のことなので、↑のクエリ実行のたびにlast_wait_typeが変化している場合は気にしなくてよい場合が多い。
以上を調査のうえで、
1.特定できたlast_wait_type
2.遅い時と速い時で実行プランが違うかどうか
の2点を教えていただければ、もう少し対応策を考えられるかもしれません。
