マイクロソフトは最近、物事を非難する習慣はありませんが、そうするとき、それは理由があります–そしてそれは確かに彼らがあなたの人生をより困難にしたいからではありません。それどころか、それはほとんどの場合、同じ問題を解決するためのより優れた、より現代的な方法を開発したためです。
しかし、習慣を破るのは難しいです。どうやって知っているのか聞いてください。より良い方法が存在するにもかかわらず、人々がいくつかのタスクを達成するための古い方法にしがみついているのをよく見かけます。
非推奨のSQLServer機能の使用がどのように私たちを苦しめ続けているかを説明するのに役立つ最近の例をいくつか共有したいと思います。この最初のパートでは、話したいのですが…
sysprocesses
システムテーブルsys.sysprocesses SQL Server 2005では、一連の動的管理ビュー（DMV）、特にsys.dm_exec_requestsに置き換えられました。 、sys.dm_exec_sessions 、およびsys.dm_exec_connections 。 sys.sysprocessesの公式ドキュメント 警告：
最近の例
最近、私たちのチームの1つが、ログリーダーの遅延の問題を調査していました。ここでは、可用性グループやトランザクションレプリケーションなど、ログリーダーを使用するテクノロジーへのダウンストリームの影響があるため、長時間実行されるトランザクションとともに、レイテンシーに多くの注意を払っています。最初の警告は通常、トランザクション期間に対してログリーダーのレイテンシーをプロットするダッシュボードに表示されます（t0 およびt1 まもなく）：
彼らは、たとえばt0 、特定のセッションで、ログリーダープロセスをブロックするオープントランザクションがあったこと。彼らは最初にDBCC INPUTBUFFERの出力をチェックしました 、このセッションが最後に何をしたかを判断しようとしましたが、結果は、トランザクション中に他のバッチも発行したことを示しています：
event_type parameters event_info -------------- ---------- --------------- Language Event 0 SET ROWCOUNT 0;
DBCC INPUTBUFFERに注意してください また、最新バージョンでは、より有能な代替品があります：sys.dm_exec_input_buffer 。また、明示的な非推奨の警告はありませんが、DBCCの公式ドキュメント コマンドにはこの穏やかな微調整があります：
入力バッファから何も取得しなかった後、彼らはsys.sysprocessesにクエリを実行しました ：
SELECT spid, [status], open_tran, waittime, [cpu], physical_io, memusage, last_batch FROM sys.sysprocesses WHERE spid = 107;
結果は、少なくともトランザクションを開いたままにしてログリーダーを中断するためにセッションが何をしていたかを判断するという点では、同様に役に立たなかった：
physical_ioを強調しています この値は、彼らが眠っているセッションを殺す危険を冒したいかどうかについての議論を引き起こしたからです。これらすべての物理I/Oが書き込みである場合、トランザクションを強制終了すると、長くて破壊的なロールバックが発生し、問題がさらに悪化する可能性があると考えられていました。これについては実際の時間を記載するつもりはありませんが、これが長時間の会話になり、t0 時間t1 上のグラフで。
これが問題になる理由
この特定のケースの問題は、彼らが不完全な情報に基づいて決定を熟考することにその時間を費やしたことです。それらのI/Oは読み取りまたは書き込みですか？ユーザーが開いているトランザクションを持っていて、単に大量のデータを読み取っただけの場合、変更した場合よりも、そのトランザクションをロールバックすることによる影響ははるかに少なくなります。 たくさんのデータ。したがって、sys.sysprocessesの代わりに 、最新のDMVであるsys.dm_exec_sessionsを見てみましょう。 、このセッションについて教えてください：
SELECT session_id, [status], open_transaction_count, cpu_time, [reads], writes, logical_reads, last_request_start_time, last_request_end_time FROM sys.dm_exec_sessions WHERE session_id = 107;
結果：
ここでは、sys.dm_exec_sessionsが表示されます。 物理I/Oを読み取りと書き込みに別々に分割します。これにより、t1 - t0 、潜在的なロールバックの影響について。 I / Oがすべて書き込みであり、その数によっては、もう少し躊躇し、おそらくユーザーを見つけるために時間を費やす可能性があります（そのため、ナックルを叩いたり、オープントランザクションがある理由を尋ねたりすることができます） ）。ほとんどが読み取りであることがわかっている場合は、代わりにセッションを強制終了してトランザクションを強制的にロールバックすることに傾倒することができます。
確かに、sys.sysprocesses dbidがあります およびwaittime 。ただし、dbid 特にクロスデータベースクエリの場合、信頼性が低く、とにかくわずかに役立ちます。 sys.dm_tran_locksにはもっと良い情報があります 。待機情報（時間と最後の待機タイプ）は、sys.dm_exec_requestsにあります。 、ただし、より詳細な情報はsys.dm_exec_session_wait_statsで提供されます。 （SQL Server 2016で追加）。私がよく耳にする言い訳は、sys.dm_exec_sessionsでした open_tranがありませんでした 、ただしopen_transaction_count SQL Server 2012で追加されました。したがって、sys.sysprocessesの使用について考える理由はほとんどありません。 今日。
sys.sysprocessesの頻度を知りたい場合 SQL Serverが最後に再起動してから参照されている場合は、パフォーマンスカウンターDMVに対してこのクエリを実行できます：
SELECT instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE N'%:Deprecated Features%'
AND instance_name = N'sysprocesses'
ORDER BY cntr_value DESC;
今夜の睡眠を本当に避けたい場合、または心配事の洗濯物リストに絶えず追加したい場合は、instance_nameに対する述語を削除してください。 。これにより、インスタンスが実行しているもののうち、最終的に変更する必要があるものの数について、恐ろしい高レベルのアイデアが得られます。
それまでの間、sp_WhoIsActiveをダウンロードしてください。 、SQLServerプロセスをリアルタイムで監視およびトラブルシューティングするためのAdamMachanicの非常に便利なストアドプロシージャ。このストアドプロシージャは、環境内のすべてのインスタンスにデプロイされています。他に使用している可能性のあるハイエンドの監視ツールに関係なく、このストアドプロシージャもデプロイする必要があります。
次回
パート2では、SQL Server Profilerについて少し説明します。SQLServerProfilerは、何よりも親しみやすさのために、どれほど危険であるかを理解することなく、人々が使用するアプリケーションです。