連載
» 2017年05月08日 05時00分 UPDATE

SQL Serverトラブルシューティング(45):業務のデータベース処理が「なぜか」だんだん遅くなっていく(パフォーマンストラブル) (1/2)

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「データベース処理が、なぜかだんだん遅くなっていく事例とその対処方法」を解説します。

[椎名武史,ユニアデックス株式会社]

連載バックナンバー

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

トラブル 32(カテゴリー:処理遅延):業務処理が「なぜか」だんだん遅くなっていく

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

トラブルの実例:かなり前に本番リリースしたシステムを運用中で、アプリケーションやシステム環境はリリース以来、全く変更はしていない。

 リリース当初は問題のないレスポンスが得られていたのに、運用を続けていくうちに処理がだんだん遅くなり、実際にクレームも入るようになってきた。

トラブルの原因を探る

 データベースには日々、さまざまなデータが蓄積されます。テーブルによっては、売上データのように最終行へ順に追加していくデータがあれば、商品データのように、行の途中へ挿入したり、インデックスのキー値を変更したりするデータもあります。

 そのため、テーブルによっては「データの物理的な順序」や「論理的な順序」がバラバラになります。順序がバラバラになる「断片化」が発生すると、連続してデータを読み込む際に余計な時間がかかってしまうことがあります。PCのストレージにおける「フラグメンテーション」と同じ現象です(これを解消する作業が「デフラグ」と呼ばれます)。

 そこで、連続して読み込むスキャンが必要なテーブルに対して、以前に紹介した「DMV(Dynamic Management View)」で、「dm_db_index_physical_stats(*1)」を実行すると、データの断片化率を確認できます(図32-1)。

photo 図32-1 DMVで「dm_db_index_physical_stats」を実行したところ、「99.9%断片化している」と表示された

 値を確認すると、table1のindex1が「99.9%断片化している」と出力されました。この断片化を解消すれば、処理遅延も解消する可能性があります。

       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。