SQL Server 2016の新機能のダイジェストを見てみる
■はじめに
SQL Server 2008 R2のEOSL対応で、SQL Server 2017にアップグレードするので、
自習書のダイジェストをもとに2012からの新機能を勉強します。
SQL Server 2014は前回記事作ったので、SQL Server 2016の新機能を見てます。
www.microsoft.com 上記リンクから、「SQL Server 2016 の新機能の概要」をもとにしました。
下記の番号は自習書の目次の番号に合わせ、私の個人的なメモを記載します。
2.1 Operational Analysticsの概要～OLTPとデータ分析の両立～
インメモリOLTPで列ストアインデックスが利用できるようになったこと、非クラスタ化列ストアインデックスに対して更新ができるようになったことが強みのようでした。
3.2 動的データ マスクによる情報漏洩対策
一部の人にはマスキングしたデータを閲覧させたいという要件はどこにでもあります。
またプロダクション環境は全部見せていいが、そうではない環境はマスキングすることなど会社によってセキュリティポリシーもそれぞれかと思います。
マスキングする際はアプリケーションで毎回やっていたのが、DBで処理できるのはとても便利そうです。
3.3 行レベル セキュリティによるセキュリティ強化
接続するユーザに対して行単位で閲覧可否を制御する仕組みとのことです。
ニッチな機能の感じですが、使う機会はどこかにありそうで、これはユーザ定義関数とセキュリティポリシーを作らないといけないが難しそうでした。
3.4 Always Encryptedによる列データの暗号化
テーブルの列データを暗号化する機能で、セキュリティ規定が厳しい環境ではとても便利そうです。
暗号化には内部で証明書を利用しているとのことで、他サーバから接続する場合はその証明書を複製する必要があるとのことです。
3.5 TDE（透過的なデータ暗号化）の性能向上、インメモリOTLP対応
データベースファイルの暗号化を行う機能がすでにSQL Server 2008から提供されていたとのことで、この機能の性能向上とのことでした。いまの現場だとそんな要件がないのですが、もっとセキュリティがちがちなところだとファイル自体も暗号化せよといわれるの言われるのでしょうか。
3.6 テンポラル テーブルによるAudit（監査証跡）
テンポラルテーブルが登場したのはSQL Server 2016からのようです。
過去の履歴を追う時に使いやすいとのことでちょっと気になっています。
マスタデータを別テーブルに過去のバックアップとしてSELECT INTOで複製するという手法を提案する方が多いので、テンポラルテーブルがあると無造作にDB上にテーブルが増えることもなく、過去の特定時点のデータを参照できるのでよさそうです。
4.1 SQL Server R Services（R統合）
Transact-SQLステートメントを利用してRスクリプトが記述できるとのことで、時代の流れに乗っていそうな機能です。 利用するにはインストール時に「R Services（データベースエンジン内）」をチェックしてインストールするとのこと。
4.2 JSON対応（FOR JSON、OPENJSON、JSON_VALUEなど）
各アプリケーションでJSON形式のデータを扱うことが多くなりましたので、この機能は個人的にとてもありがたいですね。
いままでd3.jsでグラフ作っていたのですが、いったんCSV形式に吐き出して、JSONに加工してみたいなことを一部やっていたのでいきなりJSON形式でデータ作れたらその中間処理の手間がなくなります。
4.3 Stretch Databse ~アクセス頻度の低いデータをクラウドへ~
この機能を使うとテーブルのデータをAzureへ配置することができるとのことです。
テープなどの安価な媒体がない場合にデータを長期間保持せよとなると、保管場所に困るので便利な機能かもしれません。
4.4 Azure バックアップURLの性能向上（ブロックBLOB対応）
AzureのブロックBLOB領域にデータを格納できるとのこと。
4.5 PolyBaseでHadoopアクセス（Hortonworks、HDInsight）
PolyBase は、Hadoop ファイル システム （HDFS ： Hadoop File System）上にあるデータを、 SQL Server からアクセスできる機能です
とのことで、なるほど。Hadoop利用している人は目からうろこの機能なのでしょうか。 この機能を利用したいときは「外部データ用 PolyBase クエリサービス」をインストールするとのことです。
5.1 SQL Server 2014からの主な変更点
他にも機能が追加されているとのことでした。気になったのは下記です。
- tempdbの拡張
- MAXDOPやCE（基数推定）をDB単位で設定可能に（DBスコープ構成）
- INSERT ... SELECT のパラレル処理
tempdbの拡張はインストール後にパラメータシートに基づき設定変更していましたが、インストール画面で設定ができるようになったとのことで便利そうです。
MAXDOPについてはサーバスコープ構成でしたが、DBスコープ構成になったので負荷を制限したいときには便利そうですね。
5.2 ライブクエリ統計（Live Query Statistics）
これはとても便利な機能で利用頻度は高そうです。いままでクエリを実行しているときにどこの処理まで動いているのかを追うのは職人技でした。これを使うと入門者でも簡単に実行状況がみれるのはうれしいですね。
利用方法は、Management Studioのツールバーの「ライブクエリ統計を含む」をクリックするだけとのことです。
5.3 クエリストアで性能監視、プラン固定
いままでdm_exec_query_statsでプランハンドルなど取得できクエリのプラン変更を確認できましたが、
クエリストアという機能で永続的に保管できるとのことです。
クエリストアを有効かするには、DBのプロパティから設定を行うとのことです。
クエリストアの最大容量に達すると、読み取り専用モードになり新しい情報は登録されなくなるとの点は注意が必要そうです。
5.4 Transact-SQL（T-SQL）の強化
DROP…IF EXISTSが登場したのがこのバージョンとのことです。
そのほか、DBCC CHECKDBなどにMAXDOPオプションを利用可能になったとのことで、停止できないシステムでもメンテナンス作業がしやすくなったのではないかと思います。
5.5 AlwaysOn 可用性グループの拡張
StandardエディションでもAlwaysOnが2台で組めるようになったなど、AlwaysOnの拡張がされているようです。
ログ転送速度が向上したとのことで、遅延云々言われるのがなくなったのではないかと思います。
5.6 BI関連の強化
SSRS、SSAS、SSISなどが強化されたとのことでBI系が便利になったようです。
Datazenの統合でSSRSのグラフ表示などがとてもきれいになったとのことで、BI系に興味出てきました。
■おわりに
SQL Server 2016の目玉はOperational Analysticsということは初めて知りました。 またセキュリティ関連機能が多く、重要なトレンドの機能を盛り込んでいる感じがうかがえました。
新しい機能を利用することで性能が向上するのは良いことなのですが、開発者のスキルが低いと悲惨なことになりそうです…
新しい機能が増えれば増えるほど便利にはなりますが、その分運用は複雑になってしまうのは難しい。
いまさらSQL Server 2014の新機能のダイジェストを見てみる
■はじめに
SQL Server 2008 R2のEOSL対応で、SQL Server 2017にアップグレードするので、
自習書のダイジェストをもとに2012からの新機能を勉強します。
SQL Server 2012は前回記事作ったので、SQL Server 2014の新機能を見てます。
www.microsoft.com 上記リンクから、「SQL Server 2014 の新機能の概要」をもとにしました。
下記の番号は自習書の目次の番号に合わせ、私の個人的なメモを記載します。
2.1 インメモリ OLTP 機能の概要
テーブルやストアドプロシージャの機能をメモリに載せてメモリ内で処理させる機能です。 ディスクアクセスがなくなる分、高速な処理が期待でしますがメモリが必要になるのでメモリ確保の仕組みが気になります。 下記ページを後でじっくり読みたいと思います。
インメモリ OLTP (インメモリ最適化) - SQL Server | Microsoft Docs
3.1 更新可能な列ストアインデックスの概要
SQL Server 2012では読み取り専用だったのが、更新可能になったとのことでした。
この更新可能な列ストア インデックスは、「クラスター化列ストア インデックス」（CCSI: Clustered Column-store Index）と呼ばれ、従来ながらの読み取り専用の列ストア インデック スは、「非クラスター化列ストア インデックス」と呼ばれます。
とのことで、新しい短縮用語が出てきたのはしっかり押さえておきたいところでした。
列ストアインデックスはデータの圧縮がかかっているのでディスクアクセスは減るが、
データの圧縮率によってCPUパワーを余計に消費する点は勉強になりました。
4.1 バッファプール拡張（SSDをバッファプールとして利用可能に）
ドライブの一部の領域をバッファプールに割り当てられるとのことです。
SSDなどを割り当てるとディスクを読み取るより早いので性能向上に役立つとのこと。
メモリに載せたいデータと、拡張領域に載せたいデータを明示的に分けるのは難しそうで、
性能事故の元になりそうなので利用することはなさそうですね…
4.2 Power View (パワービュー)機能の強化
SQL Server 2012から登場したPower Viewの機能強化がされました。
BIに力を入れていることがうかがえます。
4.3 クラウド対応（Microsoft Azure 連携）
AzureへのバックアップやAzure上にmdfファイルを置けるようになったとのことで、 クラウド化が始まりました。
4.4 SQL Server AlwaysOnのパワーアップ
下記3つのパワーアップがあったそうです。
- セカンダリを最大8台まで作成可能に
- クォーラム損失時にも読み取り可能セカンダリへのアクセスが可能
- FCI（フェールオーバー クラスター インスタンス）で CSV（クラスター共有ボリュー ム）がサポート
2点目については、SQL Server 2012ではクォーラムが損失するとデータベースへのアクセスができなかったのがアクセスできるようになった点がグッドです。
4.5 クエリ処理エンジンの進化（SELECT INTOのパラレル処理など）
下記4つの機能が追加になったとのことです。
- SELECT INTO のパラレル処理
- 基数推定の進化（新しいアルゴリズム）
- 統計の増分更新
- リソース ガバナーでI/O数による制限が可能に
統計の増分更新は気になります。SQL Server 2016と2017でどんな処理しているのか詳細探してみたいと思います。
4.7 インデックス再構築時のロックの優先度変更
オンラインインデックス再構築時にロックの優先度が設定できるとのこと。オンラインリビルドの時は開始と終了時の時点のみロックがかかる仕組みだったかと思うのだけれど、何が変わったのだろうか…
■終わりに
SQL Server 2014といえば、インメモリOLTPですが他にもいろいろな機能があって勉強になりました。
DMVやデータコレクションなどの機能もしっかり見ていきたいと思いました。
いまさらSQL Server 2012の新機能のダイジェストを見てみる
■はじめに
SQL Server 2008 R2のEOSL対応で、SQL Server 2017にアップグレードするので、
自習書のダイジェストをもとに2012からの新機能を勉強します。
まずは、SQL Server 2012の新機能を見てます。
www.microsoft.com 上記リンクから、「SQL Server 2012 新機能ダイジェスト」をもとにしました。
下記の番号は自習書の目次の番号に合わせ、私の個人的なメモを記載します。
2.1 AlwaysOn 可用性グループによる可用性の向上
SQL Server 2012の一番有名な機能ではないかと個人的には思います。リアルタイムでデータ同期した読み取り可能なセカンダリサーバを作成することができる機能です。
- WSFCよりも早く、10秒～20秒でフェールオーバーを行えること
- リスナーを通して透過的にサーバにアクセスできること
などのメリットもあります。自習書には
共有ストレージが不要な分、コスト削減が可能
とあり、金銭的なメリットもあるようです。
2.2 AlwaysOn フェールオーバー クラスター インスタンス (FCI)
今までもありましたが、下記4つの新しい機能があるとのことでした。
- SMB接続（共有フォルダー）へのデータベース配置が可能に
- tempdbデータベースをローカルディスクへ配置可能
- 複数サイトフェールオーバークラスタリングのサポート
- 柔軟なフェールオーバーポリシー
特に2点目のtempdbデータベースをローカルディスクへ配置可能というのは2012年当時はきっと爆発的にパフォーマンスを向上させたのではないでしょうか。tempdbはSSDにするのがベストプラクティスでかつ、共有フォルダーだとファイバチャネルで接続していない限り、ストレージアクセスがどうしてもボトルネックになってしまうので。
2.3 Windows Server Core へのインストールがサポート
Widnows ServerをインストールしたときにWindows Server Coreを利用する方はどれぐらいいるのでしょうか。GUIこそWindowsだと思っているのですが…ただインストールできる対象が増えたのは一部の人はうれしかったのでしょうか。個人的にはあまり使わなさそうです。
2.4 包含データベース（CDB：Contained Database）
照合順序で悩まされた経験がないアプリケーションをずっと見ていたため、照合順序の問題があることを初めて知りました。エラーになっていたケースの方々は便利そうですね。
3.1 列ストア インデックスによる飛躍的な性能向上
この機能もとても素晴らしい機能のようです。ただ自習書の内容だけだといまいちわかりづらかったので、下記ページも参考にするとより理解が深まるので時間があったら見ていきたいと思います。SQL Server 2014や2016の新しいバージョンがでる際にも機能追加されているので利用するシーンが出てきたら検討してみたいです。
列ストア インデックス: 概要 - SQL Server | Microsoft Docs
3.2 BI 系の T-SQL 分析関数（Analytic Functions）のサポート
新しい関数が増えたのは便利そうです。機会があれば利用してみたいぐらいの機能でした。
3.3 SQL Server Data Tools による開発生産性向上
SQL Server Data Tools (SSDT)が登場したのはこのバージョンでした！？
いろいろ開発機能が増えたみたいですね。
3.4 Distributed Replay 機能による容易なストレス テストの実施
SQL Server Profilerで実行されているクエリを取得し、流し込むことは以前からできていたのですが、
流し込む際に複数のクライアントから実行できるようになったのがこの機能のようです。
いまの現場ではストレステストはJMeterやLoadRunnerなどのツールから行うので、「分散再生コントローラー」および「分散再生クライアント」はインストール不要と学習できました。
3.5 拡張イベント (XEvents)での GUI サポート
SQL Server Profilerではなく、拡張イベントを推し始めたのが、SQL Server 2012からと聞きました。
GUIで操作できるようになったのはとても便利そうです。
パフォーマンスも向上しているとのことで、今後は拡張イベントを利用したいと思います。
3.6 Transact-SQL の強化
Transact-SQLが増えたとのことです。
シーケンスやページングは使う機会があるのではないでしょうか。
3.7 新しいTransact-SQL関数のサポート
いろいろなTransact-SQL関数が増えたようです。
月末日の取得ができるEOMONTHなどは月次処理などで利用できそうです。
3.8 データベース リストア（復元）時のUI向上
グラフィカルに復旧地点を選べるのは、誤ってテーブルを削除した場合などに便利ですね。
これは使っていきたい。
3.9 起動オプションを設定するための新しいUI
SQL Serverの起動オプションの変更は頻度が少なく気にしたことなかったのですが、設定しやすいようにUIが変わったとのことです。
3.10 Visual Studio 2010 シェルの採用によるUI/操作性の向上
Management Studioも変わっているとのこと。
3.11 DQS(Data Quality Services)による容易なデータ品質の向上
名寄せなどを行う機能が追加されているとのことでした。
これを利用するには「Data Quality Services」と「Data Quality Client」、「Integration Services」をインストールしておく必要があるとのことで、インストールパラメータシートの読み方の勉強になりました。
3.12 FileTableによるWindowsファイルのサポート
そもそもこんな機能があることは初めて知りました。
特定業務や機能ではこの機能を重宝するのでしょうか。
3.13 Power Viewによる容易なデータ分析レポートの作成
Power ViewというBIツールが提供されたそうで、いまではPower BIに吸収されていそうです。
3.14 PowePivot for Excelの進化（バージョンアップ）
SQL Server 2008 R2を主に運用していますが、この機能を使っている人は私の周りにはいませんでした。 これもPower BIに吸収されていそうです。
3.15 Analysis Servicesでのテーブル モデル のサポート（xVelocity）
Analysis Servicesは興味があるものの、私の周りでは利用事例がなくどれぐらいすごいのかわかりません…
3.16 その他の新機能
他にもたくさんの機能があるようです。私が気になったのは下記でこれらはしっかり見ていきたいと思いました。
- メモリ マネージャーの変更（列ストア インデックスなど、ラージ オブジェクトの処理を効率化）
- 新しいパフォーマンス カウンターや DMO（動的管理オブジェクト）の追加
- Integration Services のユーザー インターフェース変更（操作性の向上）
また、Local DBはツール入れたりすると勝手に動き出すことがあるので勉強しておきたい点です。
■終わりに
AlwaysOn以外にも新しい機能があったことを知れたので改めて勉強になりました。 また細かい機能やGUIも結構変化しているのは驚きです。SQL Server 2014や2016も勉強します。
JMeterでJSON形式のデータをPOSTリクエストで送信する方法
■はじめに
前回の記事（下記）でJMeterでGETリクエストの送信方法を紹介しました。
今回は続編で、JMeterからJSONのデータをPOSTリクエストで送信するときの設定を紹介します。
■実行環境
1. リクエストを受け付けるWebサーバの構築
Webサーバの構築は前回の記事を参照いただければと思います。
今回はJSONのデータをやり取りするので、app.jsにJSONのデータをやり取りするための記述と、index.jsにPOSTリクエストを受信できるように記述を追加します。
/* ~~~省略~~~ */ var bodyParser = require('body-parser'); app.use(bodyParser.urlencoded({extended: true})); app.use(bodyParser.json()); //*~~~省略~~~ */
コード1: app.jsに追記したコード
/* ~~~ 省略 ~~~ */ /* POST REQUEST */ router.post('/', function(req, res, next) { console.log(req.body); res.send('POST request'); }); /* ~~~ 省略 ~~~ */
コード2: index.jsに追記したコード
今回はデバッグのため、POSTリクエストで送られてきたデータをコンソールに表示するようにしました。
2. JMeterでJSONのデータを送信するPOSTリクエスト設定する
前回同様にまずはスレッドグループを作ります。JMeter左側のウィンドウにある「テスト計画」を右クリックし、 「追加」＞「Threads(Users)」>「スレッドグループ」を選択します。
次にリクエストを行うHTTPリクエストの設定をしていきます。 作成したスレッドグループの名前を右クリックし、「追加」>「サンプラー」>「HTTP リクエスト」を選択します。そうするとスレッドグループの下に「HTTPリクエスト」という設定が追加されます。
HTTPリクエストを選択し、下記図の赤枠の項目をそれぞれ設定します。今回はPOSTメソッドなので、メソッドを「POST」にし、送信するデータのエンコーディングも「Content encoding」で指定しています。送信するデータは下部にある、「Body Data」のなかに直接記載します。
- Webサーバ
- HTTPリクエスト
今回JMeterからサーバに対して、JSON形式でデータを送信するので、サーバ側でJSON形式と判定できるようにHTTPヘッダに、"Content-type: application/json"を追加します。
追加の方法は、スレッドグループの名前を右クリックし、「追加」>「設定エレメント」>「HTTP ヘッダマネージャ」を選択します。そうするとスレッドグループの下に「HTTPマネージャ」という設定が追加されます。
作成した「HTTPヘッダマネージャ」を選択し、下部にある「追加」ボタンを押下することで、ヘッダの設定を追加することができます。1度「追加」ボタンを押下し、名前に"Content-type"と入力し、値に"application/json"と記載します。これでHTTPヘッダの追加ができました。
ここまででPOSTメソッドでJSON形式を送信する設定が完了しました。結果をみるために、「結果を表で表示」を追加して、「開始」ボタンを押下してみます。
サーバ側のログを見ると、POSTリクエストが来ていることと送信されたデータを確認することができます。
また、「結果を表で表示」を見てみると、送信できていて成功していることがわかります。
■終わりに
近年のWebAPIは、JSON形式のデータをやり取りすることが多くなってきているのでこの記事が参考になればと思います。 今回はPOSTメソッドでJSON形式の定型データをサーバに送信していました。ただ、決まった値を複数回送信することは少ないと思うので、次回の記事ではCSVファイルにパラメータを記載し、そのCSVファイルのパラメータをJSONのデータに設定して送信する記事を作成したいと思います。
とりあえずJMeterを触ってみたい人向けの記事
■はじめに
夏バテ気味でけだるさなのなか働いているひよです。久々の投稿はJMeterにかかわるものとなります。
これからJMeterを使ってみたいという方向けに、JMeterのインストール、テスト環境の構築、そしてJMeterの実行まで簡単に記載します。勉強の手助けになれば幸いです。
■実行環境
1. JMeterのインストール
JMeterのインストールはいろいろな方が用意してくださっているので簡略化します。
まず、Apache JMeter - Download Apache JMeterから対象のプログラムをダウンロードします。
私は「apache-jmeter-5.1.1.zip」をダウンロードしました。
今回ダウンロードしたapache-jmeter-5.1.1はページに記載されている通りJava 8+が必要になるので、Javaをインストールしていない環境ではJavaをインストールしないと動かないので注意が必要です。
ダウンロードしたフォルダ内の、「\bin\ApacheJMeter.jar」をダブルクリックで起動して画面が起動できたらインストールは完了です。
2. テスト環境の準備
JMeterの使い方の試験のため公開されているURLへアクセスを試みるのは迷惑行為なので、ローカル環境にテスト環境を構築します。
以前作成した下記記事にもとづいて、nodeでwebサーバを用意します。nodeの環境は上述の実行環境のもので実施しています。
今回はテスト用に、GETを受け付けられるように準備します。 デフォルトのindex.jsを下記の通り変更します。
var express = require('express'); var router = express.Router(); /* GET REQUEST. */ router.get('/', function(req, res, next) { res.send('GET request'); }); module.exports = router;
3. JMeterの設定と実行
最後にJMeterの設定と実行をしてみます。
下記図のようにJMeter左側のウィンドウにある「テスト計画」を右クリックし、
「追加」＞「Threads(Users)」>「スレッドグループ」を選択します。
次にリクエストを行うHTTPリクエストの設定をしていきます。
作成したスレッドグループの名前を右クリックし、「追加」>「サンプラー」>「HTTP リクエスト」を選択します。そうするとスレッドグループの下に「HTTPリクエスト」という設定が追加されます。
HTTPリクエストを選択し、下記図の赤枠の項目をそれぞれ設定します。
ここで作成したHTTPリクエストをどの程度実行するかを設定します。
左側メニューのスレッドグループを選択し、スレッドプロパティを設定します。
各設定した内容で総テスト回数や1秒当たりのリクエスト数が決まります。
| 項目 | 計算式 |
|---|---|
| 総テスト回数 | スレッド数xループ回数 |
| 1秒あたりのリクエスト数 | 総テスト回数 / Ramp-UP期間(秒) |
※引用元はこちら
負荷ツールのスレッド数・Ramp-Up期間・ループ回数の関係 - Carpe Diem
今回は、スレッド数を10、Ramp-Up期間(秒)を10、ループ回数を10と試しに設定してみました。 この設定では、総テスト数が100回、1秒当たりのリクエスト数が10回となります。 ※今回は小さな値に設定していますが、大きな値にした場合、クライアントマシンの性能等により予定通り実行できないことがあるため注意が必要です。
ここまで設定できたら画面上部の開始ボタン（緑の三角）を押下し実行します。
実行するとWebサーバ側を見ていると次々に来ていることがわかります。
4. 実行結果をわかりやすく表示するために
3まででJMeterからWebサーバに対しアクセスを実行できたことは確認できました。 ただ、実行結果の解析がしづらいので、JMeterに実行した統計などの情報を記録する設定を行います。
画面左側のスレッドグループを右クリックし、「追加」>「リスナー」>「統計レポート」を選択します。この設定だけで実行した統計が見れるようになります。そのほかにも「結果を表で表示」などを設定するとわかりやすくなります。
統計レポートの設定が終わったので、再度開始ボタンを押下しJMeterからリクエストを出してみます。
すると、下記図のように結果がわかりやすく表示されました。
■おわりに
よく負荷試験を行ったりするときに登場するのがJMeterです。世間一般に浸透しているツールであるために、少しITかじっている人からは、簡単にできるでしょというイメージを持たれがちです。しっかり使い方を勉強し、どや顔してやりましょう。
SQL ServerのためのOS設定ベストプラクティス
■はじめに
SQL Serverを構築する際のベストプラクティスのサイトを見つけました。
英語だったので勉強がてらブログにまとめたいと思います。記事が書かれたのが2018年2月1日とのことで割と最近と思います。
■ベストプラクティス
ベストプラクティスは下記8つあるそうです。それぞれコメントしていきたいと思います。
- アロケーションユニットサイズの指定
- インスタントファイル初期化設定
- 電源プランの設定
- ウィルスソフトの除外対象設定
- Lock pages in memoryの設定
- ページファイルサイズの設定
- Windowsセキュリティポリシーの設定
- Windows 2012/2012 R2クラスタの動的クォーラム設定
1. アロケーションユニットサイズの指定
これはWindows Server 2008の時代から言われていることです。
ドライブをフォーマットするときにアロケーションユニットサイズの指定を行うことができます。SQL Serverは1つのページが8KBとなり、エクステントは8つのページファイルから成り立つので64KBの隣接した領域を利用します。そのため、アロケーションユニットサイズは64KBに設定することが推奨されています。
2. インスタントファイル初期化設定
これはWindows Server 2008の時代から言われていることです。
デフォルトではデータベースファイルやログファイルの操作（追加など）が発生した場合に、ゼロ埋めが発生するためオーバーヘッドがかかります。このゼロ埋めを行わないように設定を行います。設定方法は参考サイトを参照ください。
3. 電源プランの設定
これはWindows Server 2008の時代から言われていることです。
OSインストール時のデフォルトの電源プラン設定は「バランス」となっています。これを「高パフォーマンス」に変更を行います。この設定を行うことでバッチ処理のパフォーマンスが10%以上向上するといわれています。設定後にはCPUのクロック数が高い値で固定されることも確認できます。
4. ウィルスソフトの除外対象設定
これはWindows Server 2008の時代から言われていることです。
ウィルスソフトを常駐させる場合は、SQL Serverが利用するディレクトリおよびファイルを除外するように設定します。この設定を行うことでファイルのパフォーマンスが向上します。詳しい設定は下記リンクが役に立ちそうです。
https://support.microsoft.com/en-us/help/309422/choosing-antivirus-software-for-computers-that-run-sql-server
5. Lock pages in memoryの設定
これはWindows Server 2008の時代から言われていることです。
sys.dm_os_wait_statsなどで、バッファーラッチの待機イベントが多い場合にこの設定を行うことでパフォーマンスが向上することがあります。SQL Serverのサービス再起動が必要になるため、本番稼働中のマシンに対して実行する場合は計画的に実施する必要があります。
6.ページファイルサイズの設定
この項目については今まで意識をしたことがありませんでした。ページファイルの設定ガイドラインがあるのでそれに従いページファイルサイズを設定すると良いようです。下記リンクがガイドラインとなっており、最終更新日が2019年5月22日とのことで内容は信頼できそうです。 https://support.microsoft.com/en-us/help/2860880/how-to-determine-the-appropriate-page-file-size-for-64-bit-versions-of
7. Windowsセキュリティポリシーの設定
この項目については今まで意識をしたことがありませんでした。SQL Serverのサービスアカウントに必要な権限セットなどが記載されています。ポイントは当たり前のことですがSQL Serverの構成マネージャや、Windowsファイアーウォールを手動で設定しないと外部からアクセスできないということでしょうか。権限についての詳細を知りたい場合は下記ドキュメントが参考になります。 Configure Windows Service Accounts and Permissions - SQL Server | Microsoft Docs
8. Windows 2012/2012 R2クラスタの動的クォーラム設定
簡単に言うとWindows Server 2012以降のクラスターでは動的クォーラム構成が有効にしましょうとのことです。この設定を有効にすることで、クォーラム監視投票などが動的に調整されるようになるとのことです。
■終わりに
Windows Server 2008の時代から10年ほど経っていますが、新しいような内容がないことに驚きを感じました。コアな仕様は一度作りあがったらなかなか変更しないということでしょうか。
このベストプラクティスにはありませんでしたが、最近は物理サーバより仮想サーバが多くなってきたため、クラスタ構成の場合heartbeatの間隔なども適切に設定した方がよいのではと感じています。記事自体はSQL Serverのためのものなので、クラスタ構成の場合の設定は別で記事があるのかもしれません。
■参考
下記サイトが元です。
SQL Server 2017の可用性グループでデータベースバックアップを取得する際の備忘録
■はじめに
SQL Server 2017の3つのノードからなる可用性グループに対してデータベースのバックアップを試みました。メンテナンスプランのレポートログ上は成功したみたいなのですが、実際はバックアップファイルができながらなかったので四苦八苦しながら解消するまでの流れを記載します。原因なども推測の域をでていないため、今後いろんなパターンで検証してみたいと思います。
■取得できていなかった時の状況と対応策
筆者が作成したメンテナンスプランのモードは下記となります。
データベースのバックアップ（完全）
- ローカルサーバー接続のデータベースのバックアップ
- 種類：完全
- バックアップ先：ディスク
- バックアップの圧縮(Default)
データベースのバックアップ（トランザクション ログ）
- ローカルサーバ接続のデータベースのバックアップ
- 種類：トランザクションログ
- バックアップ先：ディスク
- バックアップの圧縮(Default)
また、可用性グループのバックアップ設定は下記のようにしていました。
- バックアップを行う場所：セカンダリ優先(S)
レプリカのバックアップ優先度(I)
| サーバインスタンス | バックアップ優先度(最小=1、最高=100) | レプリカの除外 |
|---|---|---|
| WIN2016N01 | 50 | |
| WIN2016N02 | 50 | |
| WIN2016N03 | 50 |
これで何度もバックアップを行っていましたが失敗しました。失敗していた原因はいくつか複合していました。
原因1: セカンダリレプリカでメンテナンスプランを実行していたこと
バックアップのテストを行う時にメンテナンスプランは、可用性グループのバックアップ設定で「セカンダリ優先(S)」としていたので、セカンダリレプリカでメンテナンスプランを実行していました。
何度実行してもメンテナンスプランのレポートは成功しているのに、バックアップファイルができないなと悩んでいました。ここでまず1つ誤りを犯していることがわかり、それは完全バックアップはセカンダリレプリカでは取得できないということでした。
そのため、プライマリレプリカでバックアップを行うようにしました。
原因2:バックアップを行う場所が「セカンダリ優先(S)」となっていこと
原因1でプライマリレプリカでバックアップを取得していましたが、やはり完全バックアップは取得できませんでした。理由については、バックアップを行う場所が「セカンダリ優先(S)」となっていることと、優先度の値がすべて均一になっていたからだと思います。
そこで、バックアップを行う場所を「プライマリ(R)」に変更したところバックアップを無事に取得することができました。
■終わりに
完全バックアップはプライマリじゃないと取れなさそうでしたが、差分バックアップならばセカンダリからとることができそうでした。もう少しパターンを網羅して検証をしてみたいと思います。
■参考
下記サイトが参考になりました。
