「断片化は発生していない」のに業務処理がだんだん遅くなっていく(パフォーマンストラブル):SQL Serverトラブルシューティング(46)(1/2 ページ)
本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「データベース処理がだんだん遅くなっていく事例とその対処方法の続編」を解説します。
本連載では、「Microsoft SQL Server(以下、SQL Server)」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。
トラブル 33(カテゴリー:処理遅延):「断片化は発生していない」のに業務処理がだんだん遅くなっていく
プライベートクラウド環境の「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。
トラブルの実例:設計当初からアプリケーションを多少変更したシステムを運用している。本番リリース当初は問題のないレスポンスが得られていたが、運用を続けていくうちに処理がだんだん遅くなり、実際にクレームも入るようになってきた。
なお、「テーブルの断片化が発生していない」ことは確認済み。
トラブルの原因を探る
「だんだん遅くなっていく」問題は、『トラブル32:業務のデータベース処理が「なぜか」だんだん遅くなっていく』と同じですが、この事例の原因だった「テーブルの断片化」はチェックの結果、発生していないようです。これ以外の原因を探りましょう。
リリース時はさまざまな観点を十分に考慮した設計となっていても、アプリケーションの追加や改修によってデータベースの使い方が変わると、インデックスなどへの考慮が漏れてしまうことが往々にして起こります。
そのためデータベースシステムにおいては、しばらく運用を続けたら「インデックスが足りているか」の確認が必要となります。以前に紹介した「DMV(Dynamic Management View)」で「dm_db_missing_index_details(*1)」を実行すると、SQL Serverが起動してからそのときまでに実行されたクエリで、不足しているインデックスを確認できます。
再起動した直後や不足しているインデックスがなければ、結果は1行も出力されません。もし何かが出力されたならば、「新たなインデックスを作成する」ことで速度が改善される処理が存在するということになります。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 「SQL Server 2016」に搭載される新たなセキュリティ対策を追う
パブリックプレビューが公開されているマイクロソフトのRDB次期版「SQL Server 2016」。特徴の1つとするセキュリティ対策機能のポイントと目指すところをキーパーソンに聞いた。 - そもそも、リレーショナルデータベースとは何か?
データベースを基礎から勉強し理解を深めていくことは簡単なことではありません。本連載では、データベースに対するハードルを少しでも低くするために、初心者の方に必要なデータベースの基本から、障害対策やチューニングといった実践に即した内容までを幅広く解説していきます。今回は、データベースの役割と、それを管理するソフトウェアであるDBMSの基本機能について解説します。【更新】 - データの登録を行うINSERT文
- 複数の条件を指定してSELECT文を実行する
前回は、SELECT文の初歩の初歩を解説しました。今回は、複数の条件を指定して、目的のデータを取り出す方法を解説します(編集部) - Oracle運用の基本「ログ」を理解しよう
本連載では、Oracle Database運用の鍵となるトラブル対処法について紹介していきます。第1回、第2回では情報収集の要となるログについて見ていきます。ログの出力情報は10gと11gとでは大きく異なる点がありますので、それぞれについても確認しておきましょう。