M＆Aによるシステム統合でアプリケーションのレスポンスが悪くなった（パフォーマンストラブル）：SQL Serverトラブルシューティング（42）（1/2 ページ）

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「アプリケーションのレスポンスが悪くなった事例とその対処方法」を解説します。

[内ヶ島暢之，ユニアデックス株式会社]

連載バックナンバー

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。

　前回までは、SQL Serverのパフォーマンス問題に対応していくための情報収集の方法を解説してきました。今回からは実際のパフォーマンス問題対策のケーススタディに入ります。個々のトラブルはそれぞれ固有の条件下で起こりますが、大枠のストーリーは似たものが多いことから、典型的なパターンとして参考にしてください。

トラブル 29（カテゴリー：処理遅延）：アプリケーションのレスポンスが悪くなった

目次

• トラブルの実例
• トラブルの原因
• 解決方法

　「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。

トラブルの実例：自社が、ある企業を買収合併。それに伴い、新たなオフィスや営業所を自社システムに加えることになった。予定していたシステム更改のタイミングと併せて、新しく参加するオフィスを新システムに加えることにした。

　システム更改と増加のプロジェクトは無事完了。……したかのように見えたが、稼働直後から、特定のオフィスから「アプリケーションのレスポンスが悪くなった」「タイムアウトエラーが発生するようになった」といった苦情が上がってきた。

図29-1　今回の事例のシステム概要図

　新システムから旧システムへの切り戻しも検討された。しかし、既に新システムでは業務が稼働しており、データが更新されている。切り戻しを行うとしても、新システムで更新されたデータを旧システムに反映することは技術的に困難であることに加え、新システム稼働後のデータは既に捨てられない。稼働後の新システムで何とか対策する方針となった。

目次に戻る

トラブルの原因を探る

　この企業はこれまでも、営業所や支店の追加とともにアプリケーションサーバを追加して、アプリケーションリソース不足に対応していました。新システムでは、合併のタイミングで「既存のシステムを更改」しつつ、そのシステムへ「追加されたオフィスのシステムが参加」するという2つの大きなシステム変更が行われました。

　一般的にシステム更改プロジェクトは、不測の事態に備えて旧システムへ切り戻す方法を用意しているはずです。しかしそれは、「新システムで業務が稼働するまで」に起きる状況を想定していることがほとんどです。新システムが稼働してからしばらく時間が経過したデータを旧システムとマージするのは難しい作業となります。

　この事例では、データベース管理者は「新システムの稼働」と「新オフィスの参加」の状況を切り分けて問題解決をする必要があります。

　トラブルシューティングではまず、「正常時」と「異常時」で何が違うのかを比較します。ここで着目されたのは、パフォーマンス遅延のトラブルが発生しているのは「特定のオフィスから」ということです。遅延は、新しく参加したオフィスのみで発生していることが分かりました。このことから、新システムのデータベースが原因になっている可能性は低くなりました（図29-2）。

図29-2　切り分けの考え方を図示したところ。この状況から、新システムのデータベースが原因である可能性は低くなった

　念のため、データベースサーバの状況をチェックします。パフォーマンスログを確認しても、明確なリソース不足はなく、サーバリソースには問題がありませんでした。

　続いて、アプリケーションから「遅い処理を特定」し、トレースを使ってデータベース内部での処理時間を測定します（図29-3）。

図29-3　遅延発生時点のトレースログを確認

　トレースログのDuration列から、該当する処理が終了するまでに要した時間を確認できます。該当する「AdventureWorks」という名称のデータベースで行われた処理は、SQL Server内では122ミリ秒で終了しています。アプリケーションの動作は秒単位で遅いにもかかわらず、データベース側の処理は遅くはない。つまり、トラブルの要因はデータベースではなく、クライアント側にあることを特定できました。

目次に戻る