「断片化なし」「不足インデックスなし」にもかかわらず、業務処理が遅くなっていく(パフォーマンストラブル):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)」に出力されます。
関連記事
- 「SQL Server 2016」に搭載される新たなセキュリティ対策を追う
パブリックプレビューが公開されているマイクロソフトのRDB次期版「SQL Server 2016」。特徴の1つとするセキュリティ対策機能のポイントと目指すところをキーパーソンに聞いた。 - そもそも、リレーショナルデータベースとは何か?
データベースを基礎から勉強し理解を深めていくことは簡単なことではありません。本連載では、データベースに対するハードルを少しでも低くするために、初心者の方に必要なデータベースの基本から、障害対策やチューニングといった実践に即した内容までを幅広く解説していきます。今回は、データベースの役割と、それを管理するソフトウェアであるDBMSの基本機能について解説します。【更新】 - データの登録を行うINSERT文
- 複数の条件を指定してSELECT文を実行する
前回は、SELECT文の初歩の初歩を解説しました。今回は、複数の条件を指定して、目的のデータを取り出す方法を解説します(編集部) - Oracle運用の基本「ログ」を理解しよう
本連載では、Oracle Database運用の鍵となるトラブル対処法について紹介していきます。第1回、第2回では情報収集の要となるログについて見ていきます。ログの出力情報は10gと11gとでは大きく異なる点がありますので、それぞれについても確認しておきましょう。
Copyright © ITmedia, Inc. All Rights Reserved.