データベースがRESTORING状態で止まっている根本的な原因を特定する

データベースがスタックRESTORING状態になるという問題を解決する質問があることを知っており、それらのソリューションを使用してデータベースを手動でオンラインに戻しましたが、私のシナリオは多少異なります。

本番環境のコピーをDEVインスタンスに復元するPowershellスクリプトを使用した自動復元があります。スクリプトは約1年間変更されず、復元プロセスが終了するRESTORINGこともありますが、復元されたデータベースが停止した状態になることがあります（スクリプトが正常に機能することもあれば、このように失敗することもあります）。

プロセスを手動で再実行するか、SSMSのユーザーインターフェイスまたはT-SQLを使用してデータベースを手動で復元するたびに、問題なく完了します。

CHECKDB復元されたDBで実行することを推奨する回答を見つけましたが、この問題の原因として何も出てきませんでした。

復元スクリプトはデータベースの完全バックアップを復元し、"WITH RECOVERY"オプションを使用するため、実際にはを使用して復元しているのに、復元プロセスを停止している可能性があるものを見つけようとしています"WITH RECOVERY"。

私はこれが時々起こっている理由を理解しようとすることに行き詰まっているので、どんな提案も本当に感謝しています。

症状を治療するのではなく、問題の根本的な原因を解決したいと思います。つまり、手動でDBを再度復元することです。

更新：

@Brentが推奨するGithub Gist- こちら。

Occamのかみそりは明白から始めることを提案します：

スクリプトによってデータベースが復元中の状態になることがある場合は、スクリプトをデバッグします。

まず、テーブルまたはファイルに何をしているのかを記録します。次に、データベースが復元状態になったら、ログをさかのぼって問題の原因を確認します。（コミュニティから2つ目の目が欲しい場合は、スクリプトをGithub Gistとしてアップロードしてみてください。ただし、大きすぎると、バグを見つけるのが難しくなる可能性があることに注意してください。）

それを実行したくない場合は、プロファイラーまたは拡張イベントのトレースを実行して復元イベントを追跡してみてください。ただし、見た目よりもはるかに困難です。（彼らが試して失敗した読者のアイデアについては、その投稿のコメントを読んでください。）