100個のデータベースを備えたサーバーがあり、バックアップ用の保守計画(MP)があります。バックアップフォルダーの宛先を確認しているときに、メンテナンスプランがすべてのデータベースをバックアップしないことに気付きました。50のデータベースの後で停止していることがわかります+-。ジョブはまだ実行モードです-停止しません。
そのため、一方では(最初の50以降)新しいバックアップファイルはなく、もう一方ではジョブが停止していないことがわかります。
ジョブがまだ実行中の場合は、Adam Machanicの優れた無料のストアドプロシージャ sp_WhoIsActive で現在実行されているコマンドを確認してください。これを(通常はマスターデータベースに)インストールした後、sp_WhoIsActiveを実行して実行中のクエリを一覧表示し、現在実行されているコマンドを確認できます。
バックアップと復元用に入力される[完了率]列もあります。
特に大きなデータベース(またはログファイル)がバックアップの最中にある場合があります。
詳細なフォローアップと説明のために、写真を撮るか、sp_WhoIsActiveの結果をコピー/貼り付けて、メンテナンスプランが現在何を行っているかを示してみてください。
これら2つのクエリを使用すると、ジョブが待機しているものを見つけることができます。
最初のクエリでは、実行中のすべてのユーザープロセスが一覧表示されます。ジョブのspidがわからない場合は、プログラムでフィルタリングされています。
2番目のクエリは、ジョブが待機しているものを示します。
select s.session_id, s.Host_name, s.login_name,
db_name(s.database_id) as db,
r.percent_complete,
s.login_time,
s.last_request_start_time,
r.status as r_status,
r.wait_type,
s.program_name,
s.cpu_time,
s.reads,
s.logical_reads,
c.num_reads,
c.num_writes,
cast(s.logical_reads / 1024. * 8/ 1024 as decimal(20,2)) as Gb ,
s.row_count,
s.writes,
c.last_read,
c.last_write,
r.command,
r.wait_time,
r.last_wait_type,
[individual query] = substring(t.text , r.statement_start_offset / 2 + 1, (
case
when r.statement_end_offset = - 1
then len(convert(nvarchar(max), t.text)) * 2
else r.statement_end_offset
end - r.statement_start_offset
) / 2),
t.text
--p.query_plan
from sys.dm_exec_sessions s
join sys.dm_exec_connections c
on s.session_id = c.session_id
/*left*/ join sys.dm_exec_requests r
on s.session_id = r.session_id
outer apply sys.dm_exec_sql_text(r.sql_handle) t
-- outer apply sys.dm_exec_query_plan(r.plan_handle) p
where s.is_user_process = 1 and s.session_id <> @@spid
--order by 2
select s.login_name,
wt.*
from sys.dm_os_waiting_tasks wt
join sys.dm_exec_sessions s
on wt.session_id = s.session_id
where s.is_user_process = 1 and s.session_id <> @@spid
order by wt.session_id;
開発環境なのでインスタンスを再起動しました。
問題が解決しました。