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

SQL Serverトラブルシューティング(47):「断片化なし」「不足インデックスなし」にもかかわらず、業務処理が遅くなっていく(パフォーマンストラブル) (1/2)

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

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

連載バックナンバー

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

トラブル 34(カテゴリー:処理遅延):「断片化なし」「不足インデックスなし」にもかかわらず、業務処理が遅くなっていく

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

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

 なお、「インデックスの断片化は発生していない」こと、「インデックスは不足していない」ことは確認済み。

トラブルの原因を探る

 だんだん遅くなるデータベースシステムにおいて、「インデックスの断片化」や「インデックス不足」以外の要因には何があるでしょうか。基本的に処理速度に大きく影響を与える要因として「ディスクI/O」が挙げられます。インデックスはディスクI/Oを減らす目的で作成するものですが、インデックスの付与だけで目標時間に到達しないならば、その他の方法でディスクI/Oを減らす方法を検討する必要が生じます。

 その一例として、アプリケーションを見直し、「必要なデータだけ操作するようにクエリの条件文などを改修する方法」があります。この他、SQL Server 2016 SP1以降、あるいはSQL Server他バージョンのEnterpriseエディションで運用しているならば、行ストアインデックス、テーブル行、ページの圧縮をサポートする「データ圧縮機能」(*1)でデータを圧縮し、ディスクI/O量を減らす対策を取れます。


 SQL Serverのデータ圧縮機能では、テーブルやインデックス単位で、行圧縮、ページ圧縮、Unicode圧縮といった処理を行い、実際に使うディスクI/Oが少なくなるように調整します。

 圧縮することで削減されるデータ量については、「DMV(Dynamic Management View)」にてストアドプロシージャ「sp_estimate_data_compression_savings」を実行することで確認できます。現在のサイズが「size_with_current_compression_setting(KB)」に、圧縮後のサイズが「size_with_requested_compression_setting(KB)」に出力されます。

photo 図34-1 「sp_estimate_data_compression_savings」を実行し、どれだけ圧縮効果があるかを確認する
       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

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

RSSについて

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

メールマガジン登録

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