【SQL Server】初心者向け SQL Server 2017のインストール手順 - ITエンジニアの備忘録的技術ブログ【仮】

今回はMicrosoftのデータベースソフトの「SQL Server 2017」をインストールする手順を紹介しつつ、インストール時に設定すべき箇所の説明も併せて実施していきます。

SQL Serverに馴染みのない方や、IT系のキャリアの浅い方、データベースの構築経験の無い方向けの記事にしようと思っているため、そういった方は是非ご一読ください。

SQL Server 2017のインストール手順と解説
最後に

SQL Server 2017のインストール手順と解説

SQL Serverのインストーラー取得

もし製品版のインストールメディアを購入されていれば、メディア内にインストーラーが有りますし、MicrosoftのSQL Server 2017のウェブサイトから評価版をダウンロードも可能です。※評価版のインストーラーでもライセンスキーを購入して登録すれば正規版になります。

取り敢えず、まずはインストーラーを取得してください。

SQL Server 評価版ソフトウェア -SQL Server 2017 RTM

インストーラーの実行

以下の画面が表示されます。
少し待つとセットアップ対象を選択するメニュー画面(インストールセンター)が表示されます。

SQL Server インストールセンター起動

左側にメニュー項目が並び、実施する処理を選択します。

今回はSQLServer本体のインストールを行う為、左側の項目から「インストール」を選択し、右側の「SQL Server の新規スタンドアロンインストールを実行するか、既存のインストールに機能を追加」を選択します。

プロダクトキー入力または無償エディションを選択

今回のインストールが製品購入後のインストールであれば、手元にプロダクトキーがある為、そのプロダクトキーを入力します。
評価目的であれば「無償のエディションを指定する」にてEvaluationを選択し、小規模で無償データベースとして使用する場合はExpressを選択します。
※今回の当環境では製品購入なので、プロダクトキーを入力しています。

ライセンス条項に同意

SQL Serverを使用するうえでのライセンス条項を確認して問題が無ければ「ライセンス条項に同意します。」にチェックを付けて「次へ」で先に進みます。

Microsoft Updateの連携確認

Microsoft Updateにて、SQL Serverの更新分も含めてチェックするかを指定します。
SQL Serverの本番運用開始後はSQL Serverの更新プログラムの適用は慎重に行うべきですが、本番運用開始前であれば、可能な限り最新の状態まで更新プログラムを当てておいた方が良いかと思います。

セットアップファイルのインストール

新しい更新プログラムの有無をチェックしたり、今回のインストールで使用するセットアップファイルを展開します。
また、Windowsファイヤーウォールのポート開放のチェックも自動でしてくれます。
少し待ちます。

導入する機能の選択

SQL Serverをインストールする際に、SQL Serverの各機能のどれを含めてインストールするかを選択します。
併せてSQL Serverのインストール先ディレクトリも指定します。

「データベースエンジンサービス」はSQL Serverのデータベース本体機能なので、特に理由が無い限りは必ずチェックを付けます。

それ以外の機能については、今回使用する予定のあるもの、将来的に使用するかもしれない機能を選択しておきます。
今回のインストールでは必要最低限の機能構成で導入します。

インストール先のディレクトリについては、WindowsのシステムドライブとSQL Server本体とは分離しておいた方が良いと思うので、Cドライブ以外のディスクがあればそちらを推奨します。
ただ、SQL Serverの構成で最も重要なのはデータベースがどこに置かれるのかなので、インスタンスルートディレクトリや共有機能ディレクトリはWindowsのバックアップ方式なども考慮して決めてもらえらば良いです。

インスタンスの構成

インストールするSQL Serverのインスタンス構成を選択、設定します。
インストールしようとしているWindows ServerにまだSQL Serverがインストールされておらず、特にインスタンス名を指定する必要が無ければ、「既定のインスタンス」を選択します。

今回インストールしようとしているWindows Serverに、既にSQL Serverがインストールされている場合は「名前付きインスタンス」しか選べなくなります。
「既定のインスタンス」を選択した場合、特に変更する理由が無ければインスタンスIDは規定値の「MSSQLSERVER」のままで良いです。
同一のWindows Server内にインスタンスを分けて複数のSQL Serverを同居させる場合は、「名前付きインスタンス」を選択し、適切なインスタンス名を指定してください。

SQL Serverのインスタンスとは
SQL Serverでは一つのWindowsServerに複数のSQL Serverをインストールし、同居ができます。
そのSQL ServerをインストールしてできあがったSQL Serverの実行環境一つ一つを「インスタンス」と呼びます。
インスタンス毎にSQL Serverの実行環境は分離され、SQL Server本体のサービスもそれぞれ別れて存在できるため、あるインスタンスのサービスを停止しても、別のインスタンスは影響を受けません。
SQL Server内のシステムデータベースもインスタンス毎に存在できるため、同一のWindowsServerに同居はしていても、全く異なるDBサーバーとして利用することができる仕組みです。

サーバの構成

SQL Serverの各サービスのアカウント設定や照合順序の設定を行います。

「サービスアカウント」タブ

各SQL Serverのサービスごとの実行アカウントとの紐付けやサービスの起動設定を指定します。
ここで表示されるサービスのリストは、前述の「導入する機能の選択」で選択した機能によって増減します。
アカウントについては通常は変更しなくても良いです。
後からでも変更出来ますが、「SQL Serverエージェント」はSQL Serverのジョブ実行などに関するサービスです。
既定値だと「スタートアップの種類」は「手動」になっていますが、こちらは使用する可能性も高いので、自動にしておくことを推奨します。
また、「SQL Server Browser」はクライアントから名前でSQL Serverのインスタンスを探せるようにする為のサービスですが、特に必要が無ければ無効で問題ありません。

「照合順序」タブ

インストール対象のインスタンスで、データベース作成時に規定値とする照合順序を選択します。
日本語環境であれば、当画面での規定値は「Japanese_CI_AS」が選択されます。
この「照合順序」の設定ですが、実は非常に重要な設定項目なので、必ず意味を理解して選択することが必要です。
※データベース作成時にも照合順序は指定はできますが、ここで設定した項目が規定値になるため、この段階から適切に選択すべきです。

照合順序とは
データベースに格納した文字列の照合におけるルールです。
具体的には、”a”と”A”を同じ文字として扱うか区別するか(大文字小文字判別)、”は”と”ば”と”ぱ”の様に、濁点や半濁点付き文字と付かない文字を同じ文字として扱うか区別するか(アクセント判別)などの文字の扱いに関する設定です。※他にも平仮名カタカナの区別や全角半角の区別などもあります。
この照合順序を理解しないままSQL Serverのインストールを行い、データベースの作成をすると、SQL Serverの規定値の照合順序は「Japanese_CI_AS」なので、大文字と小文字をそれぞれテーブルに格納することはできますが、その文字をSELECT文の条件に指定してSQLを実行した場合、大文字も小文字も両方取れます。
開発者としては本来大文字と小文字は異なる文字として分けて扱ってほしいと思う人が大半だと思います。
また、濁点や半濁点の有無や、平仮名とカタカナについても別の文字として扱う方が自然です。
その場合は照合順序に「Japanese_BIN」を選択します。
もし私が新しくシステムを作り、専用のデータベースも新しく作成するといった案件のSEをやるなら、照合順序は必ず「Japanese_BIN」を使用します。

データベースエンジンの構成

システムデータベースの認証方式やアカウント、データベースの保存先、テンポラリデータベースの設定などを行います。

「サーバの構成」タブ

システムデータベースの認証モードを設定します。
SQL Serverでのユーザー認証は「Windows認証モード」と「混合モード」の2種類があります。
SQL Serverを業務システムのDBサーバとして使用する場合、一般的には「混合モード」を選択します。
「混合モード」では、”sa”というシステム管理ユーザーが自動で作られ、そのsaのパスワードを当画面から指定します。
また画面下部の「SQL Server管理者の指定」では、特にセキュリティ上の制約が無ければ、そのWindowsの管理者ユーザー(Administratorなど)を指定します。※もしAdministratorでWindowsにログインしているなら、「現在のユーザーの追加」ボタンを押下するだけで設定できます。

「データディレクトリ」タブ

データベースファイルの配置先ディレクトリやログファイルの配置先ディレクトリなどを設定します。
前項の導入する機能の選択時に「インスタンスルートディレクトリ」をC以外のドライブに変更していた場合、そのドライブ配下のディレクトリが当設定画面の規定値として表示されます。

「データルートディレクトリ」や「ユーザーデータベースディレクトリ」などのフォルダパスは、特に理由が無い限り規定値のままが無難です。
ドライブを変更する場合は、表示されているフォルダパスの先頭のドライブレターだけ書き換えることを推奨します。※スクリーンショットの例では「E:\Program Files\・・・」を「F:\Program Files\・・・」といった感じです。
尚、当「データディレクトリ」タブ内で設定する各データの配置先の物理的なディスク速度は、データベースのレスポンスに大きく影響を与えます。
大容量且つ可能な限り高速なディスク、又は読み取り速度改善が見込めるRAID構成のディスクを指定しましょう。

当設定は新しくデータベースを作成する際に、そのデータベースファイルの配置先の規定値として読み込まれる設定で、データベース作成時に適切なドライブやディレクトリに指定し直すことも可能です。
また、一般的にはインスタンス内に複数のデータベースを作成して使用するケースも多いかと思いますが、物理サーバでSQL Serverを使用する場合、データベース配置先の物理的なディスクは可能な限りデータベース毎に分けて配置することが望ましいです。
データベースのレスポンスに影響を与える要素として、「ディスクI/O」があります。
一つのディスクに複数のデータベースファイルを配置した場合、対象のディスクにアクセスが集中し、SQL Server側では「ディスク側の処理待ち」が発生します。
この状態は高負荷時のデータベースのレスポンスを大きく低下させます。
データベースを配置するディスクを物理的に分けて分散させることでディスクI/Oも軽減できます。

「TempDB」タブ

テンポラリーデータベースの各設定を行います。
当設定項目もデータベースのレスポンスに影響を与えます。

TempDBデータファイルのファイル数については、一般的にはインストール先サーバのCPUコア数と同数を設定することが推奨されています。※当画面では規定値でCPUコア数がファイル数として読み込まれます。
ただ、最近はCPUのコア数も増加している為、コア数が8以上搭載しているサーバ環境下であれば、コア数の半数程度でも良いかと思います。
またTempDBデータファイルの初期サイズや自動拡張のサイズについては、作成するデータベースの将来的に見込むデータ量や、使用頻度、参照するシステムの処理によっても変わってくる為、最適な設定はこれと一言では言えませんが、導入先の環境に別のSQL Server環境が既にあるなら、その環境内のTempDBの現在のサイズや設定を参考にすると良いかも知れません。

TempDBの注意点
現在のTempDBはSQL Serverが受け付けたSQL文を処理する際に使用される一時領域であり、例えばSELECTされたデータに対してORDER BYで並び替えるなどの処理をする場合、このTempDB内で表の展開して並び替えの処理をします。その表の行数やカラム数が大きくデータサイズが大きくなり、TempDBのサイズとして確保した分を超過する場合に、TempDBのデータサイズを自動的に拡張します。ただ、その自動拡張処理はSQL Serverにおいて負荷の掛かる処理であり、レスポンスの低下につながります。
サービス再起動時にはTempDBで拡張した領域は解放され、当画面で設定した「初期サイズ」に戻ります。
他にもTempDBは色々用途で活用される為、ある程度のデータサイズを初めから確保しておき、且つ頻繁に自動拡張が発生させないような値を設定する必要があります。

「FILESTREAM」タブ

FileStreamとは、ExcelやWordのファイルや画像ファイルなどのバイナリーデータをSQL Server内で管理できる仕組みです。
元々SQL Serverでも他のデータベース製品でも「BLOB」というデータ型を使用すれば、物理的なファイルをカラムに格納できたのですが、このFileStreamではBLOB型の様にカラムに直接バイナリデータを格納する訳ではなく、Windowsのシステムファイルとして効率的に管理する仕組みの様です。

個人的には過去にBLOB型でのバイナリデータ格納を扱ったことがありますが、FileStreamは使用したことはありません。
取り敢えず、バイナリデータをSQL Serverで管理する予定が無ければ当機能は無効のままで結構です。