大規模環境でのvCenterサーバデータベースベストプラクティス
ここでは、vSphere 5.1で強化ポイントを最大限利用するためのデータベース設計のベストプラクティスをご紹介します。この中には、Oracle Database(以下 Oracle)やSQL Serverのディスクのレイアウトや、様々なテーブルに存在する統計情報の整理の方法、パフォーマンス向上のためのテーブルやインデックスの分離方法、OracleやSQL Serverのパラメータのチューニング方法、例えばSQL Serverのcost threshold for parallelismに関する内容が含まれます。その他一般的なvCenter Serverのベストプラクティスは、Performance Best Practices Guide for VMware vSphere 5.1をご確認ください。
Oracle、SQL Serverのディスクレイアウト
vCenter Serverはデータベースサーバに多くのDisk I/Oを発生させる可能性があります。これらのI/Oは複数のLUN及びディスクスピンドルに分散させることが推奨です。次に示すのがそのガイドラインです。
Oracle
以下の7個に分散させることが推奨です。
・ /u01 – system01.dbf, undotbs01.dbf
・ /u02 – sysaux01, temp01.dbf
・ /u03 – vpxdata01.dbf
・ /u04 – vpxindx01.dbf
・ /oralog – redo01a.log, redo02a.log, redo03a.log
・ /oralog_mirror – redo01b.log, redo02b.log, redo03b.log
・ /oraarch – archive destination.
SQL Server
以下の4個に分散させることが推奨です。
・mssql01 – master and msdb databases(.mdf, .ldf)
・mssql02 – tempdb(.mdf, .ldf), also set the initial size to 10GB
・mssql03 – VCDB(.mdf, .ldf)
・mssql04 – VCDB Backup location
更新量の多いテーブルに対するインデックス統計情報の更新
SQL Server
SQL Serverにおけるコストベースオプティマイザーは、SQL文の効率的な実行計画を作成する際、テーブルとインデックスに関する統計情報を利用します。コストとは、処理に必要なCPU、メモリ、Disk I/O等のリソース消費量のことで、統計情報とはテーブルのレコード数などが該当します。SQL Serverでは、AUTO_UPDATE_STATISTICSオプションの定義に従い、統計情報のインデックスが自動的にアップデートされます。この設定はデフォルトで有効となっています。この統計情報の自動更新は、最後の自動更新以降に実行されたインサート、アップデート、デリートの数がしきい値に達した際に実行されます。このしきい値はテーブル内のレコード数に依存しますが、例えば、100万を超えるような大きなテーブルを持っている場合、自動更新は数千から場合によっては100万のインサート、アップデート、デリート処理の実施後ということになり、SQL Serverの動作に影響を与える可能性が出てきます。
vCenter Serverによって、vCenter Serverスキーマの中のいくつかのテーブルが非常に速いペースで更新され、これらのテーブル上のインデックス統計情報はどんどん古くなっていきます。これが原因で、データベースのパフォーマンスが落ちてしまいます。例えば、VPX_PROPERTY_BULLETIN、 VPX_ALARM、 VPX_EVENT、 VPX_EVENT_ARGは、vCenter Serverのデータベーススキーマの中で最も変化の激しいテーブルですが、先のテーブルサイズの問題により、これらの自動更新が適切なタイミングで実行されない可能性があります。この問題に対処するため、これらの更新の激しいテーブル上のインデックス統計情報を以下の方法で手動更新することも可能です。
データベースの統計情報更新：sp_updatestats VCDB;
テーブルの統計情報更新：UPDATE STATISTICS “table_name”;
例えば、UPDATE STATISTICS VPX_PROPERTY_BULLETIN
となります。
Oracle
コストベースオプティマイザーはデータアクセスに対する最適な方法を提供しますが、先のSQL Server同様、最新の統計データであるかどうかに依存します。古い統計情報はデータベースのレスポンスに悪い影響を及ぼす可能性があります。Oracle Database 10g/11gのデフォルト設定では、データベースは自動的に統計情報を収集します。この統計情報の自動収集機能は、それほど頻繁な更新を行わない多くのデータベースオブジェクトにおいては十分機能しますが、統計情報の収集がメンテナンス時間に行われ、かつ非常に大きなテーブルが頻繁に更新される様な環境では適切には動作しない可能性があります。このようなテーブル上の統計情報はすぐに古くなってしまいます。
vCenter Serverの動作により、データベースの内容は短時間で書き換わります。このため、統計情報がデータベースオブジェクトの特性を正確に表す事の出来る間隔で統計情報の収集を行うことが推奨となります。
テーブル、インデックス、テーブル内の個別コラム上の統計情報を収集するために、OracleのDBMS_STATSパッケージを利用することが可能です。
テーブルやインデックス上の統計情報が更新される間、OracleはテーブルやインデックスにアクセスしているSQL状態も無効にしますが、次に同じようなSQL実行された場合には、利用可能となった新しい統計情報に基づき自動的に新しい実行プランを自動的に選択、実行します。Oracle Database 10g以降でテーブルやインデックス統計情報を更新するためには、OracelパッケージのDBMS_STATSを使います。スキーマレベルで統計情報を集めるためには、GATHER_SCHEMA_STATSプロシジャを使います。以下をご参照ください。
exec.dbms_stats.gather_schema_stats
(ownname = ‘VCDB’,
estimate_percent = 20,
method_opt = ‘for all columns size auto’,
options = ‘gather’,
cascade = true);
パフォーマンス向上のための、テーブルおよびインデックスの分割方法
SQL Server
サイズが大きく、高いトランザクションデータベースのために、非クラスタ化インデックス、tempdbを独自のファイルグループ内に移動する事も出来ます。これはVMwareとしてはテストを行っていませんが問題なく動作可能です。しかしながら、この方法は試験的な手法かつ、データベースファイルの変更を伴いますので、ご了承の上ご利用いただくのと同時に、実施前に必ずデータベースのバックアップを取得いただくようお願いいたします。
Oracle
上記した推奨のDisk配置に加え、/U03 (data file)からインデックスを分けることも可能です。
SQL Serverエンタープライズエディションの機能を利用する方法
SQL ServerはマルチCPU上のパフォーマンスを最大限利用するため、クエリの並列処理を行います。この方法では、マルチプロセッサで複数のスレッドを処理することにより、クエリとインデックスの処理を改善することが可能です。パラレル実行は、一つ以上のスレッドの利用が可能で、シリアル実行は一つのスレッドのみの実行が可能です。
SQL Serverでは、’max degree of parallelism’値で、並列処理の最大値を指定し、並列実行の数を制限することが出来ます。この値によりクエリの並列実行のためのスレッドリソースの指定を行います。
’cost threshold of parallelism’オプションは、クエリの並列プランが実行される際の閾値をしています。シーケンシャルにクエリを実行したときのコストがこの値よりも大きい場合にクエリの並列実行を実施します。
SQL Serverエンタープライズディションの機能
1.max degree of parallelism値の設定例
sp_configure ‘max degree of parallelism’, ((n-1)/2) -1;
※”n” はプロセス数
2. cost threshold of parallelism値の設定例
sp_configure ‘cost threshold for parallelism’, 15;
※推奨値は15ですが、これ以上の値（最大25まで）に設定することも可能です。
まとめ
3回に渡ってvCenter Serverのデータベースのベストプラクティスに関してご説明させていただきました。このような最適化を行うことにより、以下が可能となります。
・より大きな環境への対応
・データベース上のリソースのオーバーヘッドの削減
・効率的で高い能力を持った統計情報の収集、処理
御拝読、誠にありがとうございました！
関連記事はこちら（その1、その2）をご覧ください。
