
10月2日(米国時間)SQL Server 2017がGAとなりました。Linux対応によるプラットフォームの選択肢の広がりに加え、GraphデータやMachine Learning Servicesなどの新しい機能による対応可能なユースケースが拡大したことで、今後さらに活用が広がりそうです。そのSQL Serverを運用管理していくためには、やはり動的管理ビューの把握はとても大事なことであるため、この連載も粛々と続けていきたいと思っています。
前回はデータベースの配置と大きさを動的管理ビューを通じて確認しました。
ファイル配置 | データベースを構成するファイル(データファイルとトランザクションログファイル)が配置されたボリュームとファイルパスを確認します。 | |
大きさ | ファイルサイズ | データベースを構成するファイル(データファイルとトランザクションログファイル)のファイルサイズを確認します。このファイルサイズとは、ファイルのプロパティから確認できる”サイズ”に等しくなります。 |
実データサイズ |
データベースを構成するファイル(データファイルとトランザクションログファイル)は将来見込まれる大きさで作成します。このようにあらかじめ大きく確保されたファイルの中でデータベースが実際に使用している領域のサイズを実データサイズとして確認します。 | |
レコード件数 | データベースに作成されたテーブルのレコード件数を確認します。 |
実際の運用では、動的管理ビューへ定期的にアクセスし監視を行うケースが挙げられますが、それには若干の作りこみが必要となるため、OSが標準装備しているパフォーマンスカウンタを通じて、例えば論理ディスクの空き容量やデータベースを構成するファイルのサイズなどを監視されているケースは多いのではないでしょうか。
オブジェクト | カウンタ | 解説 |
LogicalDisk | % Free Space | 論理ディスクの空き領域の割合 |
Free Megabytes | 論理ディスクの空き領域のサイズ | |
SQL Server:Databases | Data File(s) Size (KB) | データファイルのサイズ |
Log File(s) Size (KB) | トランザクションログファイルのサイズ |
しかし、データベースのファイルは将来見込まれる大きさで作成する(大きなファイルとしてあらかじめ確保する)ことが性能の観点で重要であるため、そうすると本来監視すべきは、論理ディスクの空きやOSから見えるファイルのサイズではなく、そのファイルの中の記録済みのデータサイズ(実データサイズ)の大きさということになります。ですが、パフォーマンスカウンタにはこれに該当するカウンタがありません!
そこで、今回は前回の後編として「実データサイズの割合をパフォーマンスカウンタから監視する方法」を紹介します。加えて、トランザクションログファイルについては実データサイズのほかに監視項目として欠かせない「仮想ログファイル(VLF)の監視」、さらにその仮想ログファイルの理解の補足として、「トランザクションログファイルのアーキテクチャ」の計3点を解説します。
なお、紹介する実行例はSQL Server 2017 on Windows Server 2016環境での実行結果になります。お使いの環境によって相違がでる可能性に留意ください。

この記事は参考になりましたか?
- SQL Server管理者のための動的管理ビュー入門編連載記事一覧
-
- SQL Server 物理設計のベストプラクティス(後編)
- SQL Server 物理設計のベストプラクティス(前編)
- データベースの配置と大きさを確認しよう(後編)
- この記事の著者
-
太田智行(オオタトモユキ)
NECソリューションイノベータ株式会社
2002年入社以来、SQL Server、Oracle、MySQL、PostgreSQLを活用したSIを多数経験。
2013年Microsoft社と「In-Memory OLTP機能」の徹底検証を実施。
以来、SQL Server...※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア