「断片化なし」「不足インデックスなし」にもかかわらず、業務処理が遅くなっていく（パフォーマンストラブル）：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量を減らす対策を取れます。

*1：データの圧縮（Microsoft Developer Network）

　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)」に出力されます。

図34-1　「sp_estimate_data_compression_savings」を実行し、どれだけ圧縮効果があるかを確認する

目次に戻る