SQL Serverの歴史を振り返るとSQL Server 2000、2005、2008/2008R2、2014、2016、2017というように、近年はリリースサイクルが加速し、関連してSQL Server 2017からは新しいサービスモデルが適用され従来のサービスパックという概念がなくなりました。 そのSQL Server 2017もリリースされてから半年以上が経過し、徐々にみかけることが多くなってきました。なお、こうしたリリースサイクル加速の動きはOracleも同様の模様で、11g、12cのように数年ごとの従来リリースモデルが、Oracle Database 18c以降は年次のリリースモデルに刷新されているようです。
これまでの連載ではDMVを通じてHW、SW、動作パラメータ、データベース配置、データ量、など、SQL Serverの一連の構成情報を確認し一区切りがついたので、今回はDMVから少し脱線し、SQL Serverのデータベース配置におけるベストプラクティスを紹介します。
紹介の前にまずは物理設計に関わる用語とその位置関係について下記イメージに整理したので、一通りおさらいしてから読み進めてみてください。



データベースの物理設計ではこのようなスタックを意識することがとても重要です。それでは、SQL Serverの物理設計のベストプラクティスをそれぞれ解説していきます。
1.ストレージへのデータベース配置はファイルごとのI/O特性や性能要件を踏まえて分散配置する
一番の優先事項はトランザクションログファイル(ログファイル)を可能な限り独立させたPoolへ配置することです。データベースを構成するデータファイルとログファイルは前者がランダムアクセス、後者がシーケンシャルアクセスの異なるI/Oパターンでアクセスされるため、それらが同じ物理デバイスに配置されると、磁気ヘッド移動の効率が劣化するためです。また、ログファイルのI/O性能はデータベース性能に大きく影響するため、性能の観点でも独立配置が望ましいです。
-- データファイルとログファイルを異なるボリュームへ配置 CREATE DATABASE [UserDB] ON PRIMARY (NAME = N'data', FILENAME = N'Y:\datafile.mdf') LOG ON (NAME = N'log', FILENAME = N'Z:\xlogfile.ldf') GO

補足:広く一般的に利用されるようになったフラッシュデバイスの場合は、磁気ヘッドを持たないその仕組み上、異なるI/Oパターンが混じることでのI/O効率劣化の問題は大きく低減されています。
次にtempdbを分けることです。データベースにはユーザが作成するデータベースのほかにSQL Serverが内部的に利用するシステムデータベース(tempdb、msdb、model、master)があり、中でもtempdbについては一時テーブルやテーブル変数などのユーザオブジェクトの格納、作業用(結合、集計、ソート、index再構築など)の内部オブジェクト格納、バージョンストアの格納、などグローバルな共有リソースとして様々な用途で使用されることから、より高速なI/Oデバイスに配置することが望ましいです。
-- 1. tempdbを既定の場所から異なるボリュームへ移動 ALTER DATABASE tempdb MODIFY FILE (NAME = N'tempdev' ,FILENAME = N'T:\tempdb.mdf') ALTER DATABASE tempdb MODIFY FILE (NAME = N'templog' ,FILENAME = N'L:\templog.ldf') GO -- 2. SQL Serverを再起動 -- 3. 元の場所にあったデータファイルとログファイルをファイルシステムから手動で削除
この記事は参考になりましたか?
- SQL Server管理者のための動的管理ビュー入門編連載記事一覧
-
- SQL Server 物理設計のベストプラクティス(後編)
- SQL Server 物理設計のベストプラクティス(前編)
- データベースの配置と大きさを確認しよう(後編)
- この記事の著者
-
太田智行(オオタトモユキ)
NECソリューションイノベータ株式会社
2002年入社以来、SQL Server、Oracle、MySQL、PostgreSQLを活用したSIを多数経験。
2013年Microsoft社と「In-Memory OLTP機能」の徹底検証を実施。
以来、SQL Server...※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア