「ベストプラクティス」は実行されるワークロードによって異なりますので、どの環境にもすべて適用できるものではないと思います。
個人的には、「~ の情報にこのように書かれていた」というのは、正直どうでもよいです。
「その設定 / 構成にすることでどのような変化が発生し、それが稼働させる環境にどのような効果をもたらす可能性があるのかを検証し、理解 / 把握する」ことが重要ではないでしょうか。
SQL Server の基本アーキテクチャについては SQL Server ガイド に記載されています。
これらのドキュメントから動作を把握し、設定変更によりどのように挙動が変わるのかを理解することが重要です。
しかし、「どのような考慮点があるか」を把握するためには、ベストプラクティスは重要な情報源となると考えています。
最近 twitter の TL で GCP の SQL Server のベストプラクティスのドキュメントを見かけたのですが、そういえば、各社ベストプラクティスや、それに類する (検討が必要な項目) についての情報を公開していたなと思い、公開情報をまとめてみました。
細かなものは追加できていないので、時間があるときに本投稿は追記していこうと思いますが、最初に確認をした方がよいドキュメントとしては、このようなものがあるのではないでしょうか。
Contents
Microsoft
SQL Serve は MS の製品ですので、まずは MS から公開されている情報を見てみましょう。
環境構築
基本設定
- Azure Virtual Machines 上の SQL Server のパフォーマンスに関するガイドライン
- クラスター構成のベスト プラクティス (Azure VM 上の SQL Server)
- Azure Stack Hub におけるパフォーマンスを最適化するための SQL Server のベスト プラクティス
- SQL Serverを実行しているコンピューターで実行するウイルス対策ソフトウェアを選択する方法
- Balanced 電源プランを使用する場合の Windows Server のパフォーマンス低下
オンプレミスの SQL Server に特化した SQL Server の全体的なベストプラクティスのドキュメントは、最近見たことがないのですが、Azure 仮想マシン (Azure VM) 上で動作せる場合のベストプラクティスについては、次のようなドキュメントが公開されています。
ディスクの構成などに Azure VM 固有の用語がありますが、基本的な考え方については、どのようなインフラストラクチャ上で実行する場合にも、踏襲 (または検討) できる内容が多く含まれています。
昨今の Windows Server は、ウイルススキャンソフトがデフォルトで導入されていますので、スキャン対象の除外についても考慮が必要となります。
電源プランについても設定のよっては低いクロックで動作しますので、安定したクロックで動作しているかの制御のために電源プラン (Power Plan) を高パフォーマンスにすることもポイントとなるかと。パフォーマンスモニターで Processor Information\Processor Frequency を確認してみるのもよいのではないでしょうか。
導入時にベース環境として最適な構成とするためには、どのような設定の変更を検討するかについては、上記のドキュメントから確認することができるのではないでしょうか。
ディスク構成
Azure VM で実行する場合のディスク構成については、個別にドキュメントも用意されていますので、フォーマット時のアロケーションサイズについては、Azure 以外で実行する場合にも同様の考えとなりますので、ディスクの設定を検討する場合は、このドキュメントも確認すると良いかと思います。
SQL Server on Linux
SQL Server on Linux (SoL) については、SoL 固有のベストプラクティスがありますので、Linux 上で動作させる場合は、Linux 用のドキュメンも合わせて確認しましょう。
SQL Server の設定
「環境構築」に記載したリンクの内容が基本的な情報となりますが、この情報内には SQL Server の設定についての記載があり、「その設定によってどのような動作の変更がもたらされるのか」については、各設定のドキュメントを確認する必要があります。
SQL Server の設定には「インスタンスレベル」「データベースレベル」「テーブルレベル」の設定があり、これらの設定は次のドキュメントから確認できます。
- インスタンスレベル
- データベース エンジンのインスタンス (SQL Server)
- DBCC TRACEON – トレース フラグ (Transact-SQL)
- データベース エンジン サービスのスタートアップ オプション
- ALTER SERVER CONFIGURATION
- データベースレベル
- テーブルレベル
SQL Server は初期の設定でも汎用的なパフォーマンスを発揮できるようになっていますので、設定の変更を行わなくてもある程度の、パフォーマンスを出すことはできます。
高負荷なワークロードの実行や、現在発生している問題に対してのアプローチとして、細かな設定の変更の検討を行うことになるかと。
Microsoft から提供されているホワイトペーパーの中では、詳細に設定変更を実施した際の影響の解説が行われていますが、まずは docs の各ドキュメントを確認するのが良いのではないでしょうか。
インスタンスレベルの設定
- データベース エンジンのインスタンス (SQL Server)
- DBCC TRACEON – トレース フラグ (Transact-SQL)
- データベース エンジン サービスのスタートアップ オプション
インスタンスレベルの設定は、SQL Server の全体的な動作に対して影響を及ぼすものとなり、インスタンス内に作成している全 DB に対して影響を与えることになります。
代表的な設定としては、次のようなものがあるのではないでしょうか。
ベストプラクティスのドキュメントには、これらの情報が記載されていることが多いので、各設定がどのような効果をもたらすのかを把握しておく必要があります。
- サーバー メモリの構成オプション
- Lock Pages in Memory オプションの有効化 (Windows)
- データベースのファイルの瞬時初期化
- 構成のツリーの中に記載されているものではありませんが、データファイルの拡張が発生した場合の処理性能を改善するために有効な設定です。
SQL Server では、上記のような設定以外に、「トレースフラグ 」という設定もありますが、SQL Server のバージョンによっては、トレースフラグを有効にしなくても、デフォルトで有効になることがあります。
トレースフラグを有効化する場合には「目的」(デッドロックの追加情報の取得 / ロックエスカレーションの停止 / 推定モデルの制御 等) を正しく設定する必要があるかと思いますので、トレースフラグについては有効にするかどうかは目的次第ではないでしょうか。
最新の SQL Server であれば、以前はトレースフラグだった設定もデフォルトで有効になっている / データベーススコープのオプションに変更されていることがありますので、既定の状態でも有効化されているケースがいくつかあります。
データベースレベルの設定
SQL Server では、DB 単位で設定できる項目もあります。
SQL Server 2016 以降、一部の設定については、ALTER DATABASE の SET ではなく、ALTER DATABASE SCOPED CONFIGURATION のデータベーススコープの構成から変更が必要となるものもあります。
テーブルレベルの設定
テーブルレベルの設定もあり、ロックエスカレーションの設定は、インスタンスレベルだけでなく、テーブルレベルで制御することもできます。
tempdb のベストプラクティス
PFS / GAM / SGAM のページラッチの競合を減らすために tempdb のデータファイルを CPU コア数分作成することは有名ですが、Many Core の時代に、どのようにデータファイルを分割すればよいかの指標が公開されています。
ベースライン作成
設定の変更前後の状態を確認するためのベースライン作成を作成する際には、パフォーマンスモニターで取得した情報を確認することになります。
この際、どのような項目を確認すればよいか / 各項目により把握できる状態については、このドキュメントから確認することができます。
ホワイトペーパー類
- Microsoft SQL Server I/O subsystem requirements for the tempdb database
- SQL Monitoring and I/O
- SQL Server 2008 : SQLCAT Articles
- SQL Server 2008 : Microsoft White Papers
- SQL Server 2008 R2 : Microsoft White Papers
- SQL Server 2008 R2 : SQLCAT Articles
- SQL Server 2012 : SQLCAT Articles
- SQL Server 2012 : Microsoft White Papers
旧い情報にはなってしまいますが、構成については、このようなドキュメントもあります。
今の SQL Server の動作に読み替えて、内容を整理する必要がありますが、これらのドキュメントも参考になる箇所があるのではないでしょうか。
SQL Server を利用する製品のドキュメント
- System Center Operations Manager : SQL Server の設計に関する考慮事項
- SharePoint Server ファーム内の SQL Server のベスト プラクティス
- BizTalkServer : データベースパフォーマンスの最適化
このドキュメントは SQL Server のドキュメントではありませんが、SQL Server を利用する MS 製品として、ベストプラクティスが公開されています。
アプリケーションから SQL Server を使用する場合にどのような考慮点があるのかという観点については、これらのドキュメントを参考にするとよいかと思います。
AWS
AWS の EC2 で SQL Server を最適に動作させるためのベストプラクティスのドキュメントが公開されています。
可用性を持たせた環境として構築する際の参考になります。
環境構築
- Best Practices for Deploying Microsoft SQL Server on AWS
- AWS クラウドでの SQL Server: クイックスタートリファレンスデプロイ
- EC2 での SQL Server クラスタリングに関するベストプラクティスと推奨事項
- Implementing Microsoft Windows Server Failover Clustering (WSFC) and SQL Server 2012 AlwaysOn Availability Groups in the AWS Cloud
AWS で SQL Server を展開する際のベストプラクティスが公開されています。
EC2 上での構築の話ですが、一般的な内容も含まれていますので、クラウド上で環境を構築する際のポイントを把握することができるかと。
- [Microsoft SQL Server on Amazon RDS] (https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html)
RDS でどのような機能が使用できるか等の情報が公開されているドキュメントです。
SQL Server の各機能がどうして RDS for SQL Server で使用できないのかを考えてみると、構成の推測やクラウド化したときのポイントが把握できるのではないでしょうか。
GCP
本投稿を書こうと思ったきっかけですね。
環境構築
- SQL Server インスタンスのベスト プラクティス
- 高パフォーマンスの SQL Server インスタンスの作成
- Compute Engine での Microsoft SQL Server のパフォーマンス調整
GCP のドキュメントはオンプレミスの SQL Server に適用できるものがあり、どのインフラストラクチャ上で実行した場合にも検討が必要な内容が多数含まれていますので、GCP 以外で実行する場合も一読してみると良いかと思います。
このドキュメントツリーの情報は汎用的に利用できるものが多く含まれています。
PaaS の Cloud SQL for SQL Server については、このドキュメントから確認できます。
Oracle
SQL Server のメトリックの情報を確認していると、Oracle Enterprise Manager System Monitoring Plug-in のページがヒットすることがあるのですが、この情報もかなり役に立ちます。
ベースライン作成
Nutanix