<n>日間呼び出されていないプロシージャを見つける
古いストアドプロシージャとテーブルを削除しています。
最近呼び出されていないプロシージャを確認するにはどうすればよいですか？
dm_exec_procedure_statsおよびdm_exec_query_statsは、プランキャッシュ内のプロシージャのみを返すため、信頼できません。
sys.dm_exec_procedure_statsは信頼できません（おそらく、情報が再起動後もプランキャッシュに関係するよりも存続しないため、SQLサーバーはこれを他の方法で追跡しません）。
これを行う唯一の方法は、ストアドプロシージャ（または、実行可能で包括的であれば、それらを呼び出すアプリ）にログを追加するか、非常に対象を絞ったサーバー側トレースを永続的に実行してトレースを確認することです。
また、プロシージャが1週間呼び出されなかったからといって、明日呼び出されないわけではないことにも注意してください。月次または年次でのみ呼び出されるレポート手順や、あまり頻繁には発生しないあいまいな操作が発生する場合があります。このストアドプロシージャを削除すると、数日または数週間後、その時点でのバックアップを超える可能性があります（また、ベストプラクティスに従ってソースプロシージャにストアドプロシージャを保存していない場合）。
最も安全な方法、IMHOはrenameストアドプロシージャ（多分zzz_プレフィックスを付けると、リストの一番下に並べ替えられます）。他の方法で「古すぎる」可能性のある候補としてすでに特定されている場合-少なくとも、うっかりそれを行って何かが壊れた場合は、十分簡単です。再度名前を変更して、バックアップ内の古いコードを探し回ることなく機能を復元します。 delete完全なビジネスサイクルが終了し、誰も文句を言っていない場合の手順のみ。
Ifプロシージャを変更できる場合は、それぞれの先頭に行を追加します（これは自動化がかなり簡単です）。
exec sp_trace_generateevent 82, N'<procedure__name>';
sp_trace_generateevent は問題がなく、プロシージャの実行フロー、結果、結果に影響を与えません。最も重要なのは、現在のトランザクションとの相互作用がないことです。読み取り専用の手順をデータ書き込みの手順に変更するのではなく、すべてのロギングとロックの影響があります。トレース監視イベント82がない場合、exec呼び出しは基本的に無料です（何もしません）。
次に サーバー側のトレース を作成し、イベント82（最初のuser_event）をキャプチャします。 n日後、生成されたトレースを収集し、使用状況を集計します。十分なスペースと十分なIO bandwithを備えたディスクにトレースが書き込むことを確認してください。追加のクレジットとして、定期的にトレースを検査し、そこにある手順からexec呼び出しを削除することもできます。 、と呼ばれることが証明されているので。
最近何が呼び出されたかを知ることは、頻繁に呼び出されるものにのみ役立ち、複雑なデータベース内の多くのオブジェクトはそれほど頻繁には呼び出されませんが、依然として必要です。使用されていないものを特定する簡単な方法はわかりません。
私がやろうとしていることは、私の開発またはqaボックスでプロファイラーを起動し、それをヒットするすべてのアプリケーションを取得して機能を実行することです。 （正式なQAがある場合は、一連の優れた回帰テストが役立ちます）。テーブルに書き込むようにトレースを設定します。これで、少なくともアプリケーションが呼び出すprocがわかり、リストからそれらを削除できます。
Prodサーバー上のすべてのジョブがテストサーバー上で同等のジョブを持っていることを確認し、それらを実行します。もう少し見つける必要があります。
現在、潜在的なspのリストははるかに小さくなっています。
アクティブなテーブルのリストには、監査テーブルのように必要なことがわかっているprocとテーブルの1つで言及されているもののみを含める必要があります。 YoOuは、そこから排除する可能性のあるリストを作成できます。
これで、除去する可能性のあるリストを取得すると、usp_my_proc_Old（dbにUSP_My_procがある場合）などのかなり明白なものが表示される可能性があります。それらは私の最初の候補者です。データのないテーブルは、この時点で明らかな別のセットです。削除されていることがわかっている機能を明確に参照しているテーブル/プロシージャは、次のものになります。最近、調査結果を保存する機能を新しいデザインに置き換えたとします。テーブルを保持したい場合があります（データが必要な場合があります）が、そのテーブルを呼び出すプロシージャはおそらくすべて古くなっており、実行できます。
法的制約によっては、データを含むテーブルを削除したくない場合があります。私たちは規制対象業界に属しており、監査人、規制当局、弁護士にデータを提供するよう求められることがあるので、もはや存在しないクライアントのクライアント固有のデータがあります。ただし、実際の本番データベースをクリーンアップする場合は、これらのテーブルを別のアーカイブデータベースに移動できます。
次に、彼らが何をしているのかを見始めます。特に、参照するテーブルのいずれかがもう存在しない場合は、実行されないprocを排除できます。テーブルに日付フィールドがある場合、最近の日付はありますか？データフィールドに最後に日付が入力されたのが2008年だった場合、これは不要になったテーブルの候補として最適です。
削除する可能性のあるいくつかのオブジェクトのリストを取得したら、そのリストをすべての開発者に送信し、テーブル/プロシージャを使用するか、それが何であるかを彼らに尋ねます。 1000のオブジェクトの膨大なリストでこれを行わないでください。一度に10〜20を超えないように送信し、それらをグループ化して、関連するトピックを明確に伝えるようにします。
除外される可能性がある場合は、ログプロセスをプロシージャに追加するか、ログトリガーをテーブルに追加し、その日付までにエントリがない場合にオブジェクトを削除する日付を設定できます。
次のようなものでトレースを実行します。
- SP：完了
- SP：StmtCompleted
- RPC：完了
- SQL：BatchCompleted
- SQL：StmtCompleted
データベースIDによるフィルタリングを検討してください。十分なデータを収集したら、決定を下すことができます。もちろん、トレースにはパフォーマンスヒットがあることに注意してください。このヒットが操作上の問題を引き起こさないようにしてください。
私のクライアントの1つにまったく同じ問題がありますが、これは私がこれまでに見た中で最悪のインスタンスです。不正な開発者の中には、何千ものストアドプロシージャ（6k以上）を生成しましたが、そのほとんどは使用されていません。
5分ごとにsys.dm_exec_cached_plansをポーリングし、追跡のためにテーブルに挿入します。テーブルにまだ存在しないストアドプロシージャ名のみが挿入されます。
他の人が述べたように、四半期/年次のビジネスサイクルを経ることを強くお勧めします。
問題は、DMVの信頼性が低いことではなく、必要な情報がキャプチャされないことです。定期的に実行するジョブを作成し、それらを使用して必要な情報を取得します。データが24時間で失われる場合は、1日に2回実行します。 DMVは本当に集中的ではないことを考えると、必要に応じて1時間ごとにさえもです。