DBサーバを一台新設する事になりました。
要件をヒアリングしたところ”基本的な設定は既存DBと同じで”との事。
ﾌﾑﾌﾑそれじゃ簡単かな？と思ってドキュメントを探してみたら・・・・・・ない。
インストール時の選択内容しか残されていない。
「え、もしかして全部デフォで動いてるの？？まさか(笑)(笑)」
と実機を確認した所、どうやらファイルサイズ以外はホントにデフォみたいで・・・
そういう訳で、一般的にはどういうポイントがあるのだろう？と調べて見ることにしました。
■メモリ
まずは既存DBで逼迫しているメモリについて。
min server memory の既定の設定は 0 MB で、max server memory の既定の設定は 2,147,483,647 MB (中略) 詳細については、「動的メモリ管理」を参照してください。
いやいや最大2ペタて。無制限に確保する感じかな…詳細についてはこっちか。
メモリを動的に使用する場合、 SQL Server はシステムに定期的にクエリして、メモリの空き容量を確認します（中略）空きメモリが少ない場合、 SQL Server は OS に対してメモリを解放します。
今回は、構築時にSQLServer入れる直前のメモリ使用状況を確認して、
安全率だけちょっと見込んで設定する方向で進めようと思います。
もうひとつ、これは各所で「絶対やるべき」とオススメされていました
プロセスを使用して物理メモリにデータを保持できるアカウントを指定し、ディスク上の仮想メモリへのデータのページングを防止します。 メモリ内のページをロックすると、ディスクへのメモリのページングが発生した際に、サーバーの応答性を維持できます。
が、
という事みたいです。下手に設定するとマズイという事でしょうか。
SQLserverのプロセスが使用するメモリを物理メモリにロックするという事は、
別のプロセスが使える物理メモリは当然減少する訳で、
そしてSQLserverが使用するメモリはデフォルトで２ペタである訳で。
動的メモリ管理でちゃんと増減してくれるようですが、こういう言う風にも書いてある訳で。
Lock Pages in Memory ユーザー権利を使用するとき、上記のように max server memory の上限を設定することが推奨されます。
LPIMだけ有効にするのは危ないようですね。
■ファイル
データファイルの配置はそれぞれ環境毎の要件があるかと思うので割愛。
それ以外で、知らなかったけど有効そうなものを見つけました。
一般的には、tempdb データファイルの数は、SQL Server が使用可能な CPU の数に一致させた方が高負荷時のパフォーマンス劣化を防ぐことができるとされています。
tempdb 負荷が高いのか低いのか分からないのであれば、やっておいた方が無難でしょう。
はい。やってみます。スケジューラ（＝CPUコア数）に合わせましょう、という事らしいです。
ちなみにtempdbがどういう時に使われるのかというと。
SQL Serverインスタンスが内部で利用する一時領域「TEMPDB」とはhttps://www.atmarkit.co.jp/ait/articles/1610/06/news013.html
サブクエリとかインラインビュー、ORDERBYの結果とかが含まれるのでしょうか。
そのほか、実効性は状況次第と思われるが試してみたい手法がいくつかありました。
- データとインデックスのデータファイルを分ける
- ログファイルは分割しない
- ファイルの自動拡張は基本ナシ。するならサイズベースで、同時拡張。
１は、物理レコード削除が頻繁に発生するなら効果がありそうに思います。
２と３はお作法のようです。ファイルI/Oの効率向上が見込めるようです。
■MaxDOP
並列処理可能な実行プランの最大値、だそうです。これだけ読んでもよく解りませんでした。
max degree of parallelism サーバー構成オプションの構成
並列プラン実行で使用するプロセッサの数を制限できます。 SQL Server では、クエリ、インデックス データ定義言語 (DDL) の操作、並列挿入、オンライン列変更、並行統計コレクション、静的およびキーセット ドリブン カーソルの作成の場合に並列実行プランが検討されます。
ますますわからん…ですが、注意事項の記載内容を見ると
セットアップで実施するようになったという事は、重要なオプションという事なのでしょうね。
このオプションは詳細設定オプションであるため、熟練したデータベース管理者または認定された SQL Server プロフェッショナルだけが変更するようにしてください。
あまりほいほいと弄るものでもないようです。
とあるサイトではCPUコアの1/4が推奨とされていたのですが、弊社環境だと1になってしまいます。
並列処理しない、というのはとてもとてもマズイ事に思えるので、今回は見送り。
2019の試用版インストーラを起動してみて推奨値だけ確認してみる、というのもアリでしょうか。
これらを元に、来週（忙しかったら再来週）に環境構築予定です。
■今回拝見させて頂いたサイト様
いつも勉強させて頂いてます。ありがとうございます。
■読み飛ばしてもいい感想文
メモリ制限は、一応OSの邪魔はしないように、っていう方針ではある様子。
とはいえ、ギリギリまで確保しては「ごめんなさい！お返しします！」っていうのも、
却ってオーバーヘッドになりそうな感じがします。
世の皆様も明示を推奨されている項目でした。
ディスクに関していうと、昔は特に物理ディスクを意識したI/O性能検討
（内周と外周、アクセスヘッドの移動）がなされてました。
今でも構成によっては有効だと思います（テスト用の単体物理サーバとか）が、
昨今のエンタープライズ用DBサーバはだいたいFCでストレージと繋がっていると思います。
その場合はいきなりディスクに書くのではなく、入り口の大きなキャッシュメモリとやり取りしますし、
実際のディスク書き込みでもRAID構成、それらを束ねて論理的に見せる仮想ボリュームなど、
物理ディスクの事はほぼ気にしなくていいのが現状かと思います。
インストール先とかデータファイルパスをCドライブにしない、とかは当たり前と言われてますが。
今やシステムソフトウェアインストール用のドライブ分けに意味を持たせるには、
個別でリストア可能という利点を活かせる運用が前提です。
OSやミドルの設定をいじってもバックアップしないのであれば、（そしてそういう会社は多い）
最初から全部Cドライブでいいんじゃない？と思います。
前述のように昔はI/O分散の意味もあったでしょうが、SANブート環境では無意味ですし。
どれをとってみても感じるのは、内部動作を深く掘り下げないと効果的なチューニングは難しい、
という事ですね。まだまだ学びの道は続きます。