SQLServerシステムデータベースのメンテナンス

SQL Serverのインストールでは、デフォルトで、インスタンスごとに複数のシステムデータベースが作成され、そのインスタンスを維持および管理します。この記事では、これらのシステムデータベースを調べ、それらの責任を理解します。

SQLServerシステムデータベース

SQL Serverでは、システムデータベースはインストールプロセス中に作成され、SQLServerインスタンス固有の構成の詳細を格納して正常に機能します。 SQL Serverをインストールするたびに、少なくとも5つのシステムデータベースと、 Distribution databaseという名前のレプリケーション関連のシステムデータベースが1つ作成されます。これは、レプリケーションがそのインスタンスで構成されている場合にユーザーによって作成されます。各システムデータベースには目的があり、これについてはこの記事の後半で詳しく調査します。

システムデータベースは次のとおりです。

マスター–デフォルトでインストールされます
Msdb –デフォルトでインストール
モデル–デフォルトでインストール
Tempdb –デフォルトでインストール
リソース–デフォルトでインストール 。 SQL Server 2005で導入され、それ以降のSQL Serverバージョンで使用できるため、SQLServer2000以前のバージョンでは使用できません。
配布 –ユーザーアクションによって作成 。ユーザーは、ディストリビューションデータベースを作成してレプリケーションを構成できます。

SQL Serverにインストールされているシステムデータベースを表示するには、SSMSを使用できます。

SQL Serverインスタンスに接続し、データベースを展開します >システムデータベース ：

リソースに気づきましたか上記のリストにデータベースがありませんか？重要なのは、リソースデータベースは、SSMSObjectExplorerにリストされていない特別なシステムデータベースです。ただし、 sys.sysaltfilesという名前のシステムDMVからリソースデータベースの詳細を照会することはできます。クエリを実行します：

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

結果では、システムデータベースを次の順序で確認できます： master、tempdb、model、msdb、distribution 、そして最後に、 dbid 32767 これはリソースデータベースです。ただし、このリソースデータベースには、 sys.databases にエントリがないため、データベース名は表示されません。。 dbid 5と11の間のいくつかのユーザーデータベースを除外し、 AdventureWorks_REPLを含めました。 DMVがユーザーデータベースも表示できることを示す例として。リソースデータベースとその他のシステムデータベースについては、後で詳しく説明します。

SQLシステムデータベースの制限

システムデータベースには重要なシステム構成の詳細が保持されているため、データが誤って削除されないように、適切なセキュリティ対策を講じる必要があります。したがって、システムデータベースには、ユーザーデータベースと比較して次の制限があります。

システムデータベースをオフラインにすることはできません

以下に示すように、ALTERDATABASEコマンドを使用してユーザーデータベースをオフラインにすることができます。

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

ただし、上記のコマンドを使用してシステムデータベースのいずれかをオフラインにしようとすると、次のようなエラーが発生します。

システムデータベースを削除できません

DROPDATABASEコマンドを実行することでユーザーデータベースを削除できますが

DROP DATABASE AdventureWorks

システムデータベースのいずれかを削除しようとすると、次のようなエラーが発生します。

システムデータベースの所有者は変更できません

システムデータベースの所有者はsa デフォルトでは。変更することはできません。システムデータベースの所有者の名前を変更しようとすると、エラーが発生します。

ただし、例外があります。 msdbの所有者を変更することができますデータベース。

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

システムデータベースのデータベース名は変更できません

システムデータベースの名前を変更しようとすると、次のようなエラーメッセージが表示されます。

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

システムデータベースの照合は変更できません

システムデータベースは、SQLServerのインストール時に選択した照合名で作成されます。インストールすると、システムデータベースの照合は変更できません。システムデータベースの照合を変更する唯一の方法は、SQLServerインスタンスを正しい照合で再インストールすることです。

システムデータベースのプライマリファイルグループをREAD_ONLYモードに設定できません

システムデータベースはSQLServerインスタンスに関連する重要な情報をキャプチャするため、SQL Serverでは、プライマリファイルグループにあるプライマリデータファイルを読み取り専用として設定することはできません。。

システムデータベースでデータキャプチャ機能の変更を有効にできない

この機能は、追跡対象テーブルのデータベースで発生するすべてのDML変更を追跡するために使用されます。システムデータベースでデータキャプチャの変更機能を有効にしようとすると、エラーが発生します：

use master
GO
exec sys.sp_cdc_enable_db

システムデータベースとユーザーデータベースの違いが明確になったので、各システムデータベースの目的をさらに詳しく調べることができます。

SQLServerのマスターデータベース

マスターシステムデータベース は、SQLServerインスタンスに関連する主要な構成の詳細を保持します 。 SQL Serverは、特定のインスタンスを起動するときにそれらに依存します。何らかの理由でマスターデータベースを起動できない場合、SQLServerインスタンスも起動できません。

マスターデータベースに保存されるこれらの重要な詳細には、ログインアカウント、リンクサーバーの詳細、エンドポイント、システム構成設定、およびすべてのユーザーデータベースに関する詳細が含まれます。

さて、質問が来ます。 SQL Serverサービスは、マスターデータベースのデータファイルとログファイルが利用できる場所をどのように認識しますか？その答えは、SQLServerサービスのスタートアップ構成パラメーターにあります。

SQL Serverインスタンスのスタートアップ構成パラメーターを表示するには、最初に SQLServer構成マネージャーという名前の組み込みツールについて知っておく必要があります。。特定のサーバーで利用可能なすべてのインスタンスのすべてのSQLServer関連サービスを管理するのに役立ちます。これらのデータを表示するには、SQL Server Configuration Managerを開くと、次のようなリストが表示されます。

SQLServerサービスをクリックしますこのサーバーまたはPCで利用可能なサービスのリストを表示するには：

ちょっと待って！ services.mscにはおなじみのようですサーバーで利用可能なすべてのサービスを一覧表示しますが、SQLServer関連のサービスのみを表示します。

services.mscを開きましょう外観を確認し、SQLServer構成マネージャーと services.msc の違いを確認しますどちらが優れているかを比較します。

SQL Server Configuration Managerは、現在実行中のサービスのプロセスIDを表示します。 services.mscでは見つかりませんでした。もちろん、この情報はWindowsタスクマネージャーから取得できますが、SQLServer構成マネージャーはこれを1か所で表示するのに役立ちました。

それでは、詳細を見てみましょう。 services.mscからSQLServerサービスを右クリックします。。以下のメニューが表示されます：一般、ログオン 、リカバリ 、および依存関係 。

SQL Server Configuration Managerから、 SQL Server（MSSQLSERVER）を右クリックします。サービス>プロパティ 。以下のメニューが一覧表示されます– ログオン、サービス。 FileStream、Advanced、AlwaysonOn高可用性 、および起動パラメータ 。

起動パラメータ マスターデータベースデータとログファイルの場所を保存するサービスのは、SQLServer構成マネージャーでのみ使用可能でした 。

スタートアップパラメータをクリックします詳細を表示するには–既存 パラメータ 。次の情報が表示されます：

マスターデータベースの物理的な場所データファイル
マスターデータベースの物理的な場所トランザクションログファイル
ErrorLogフォルダの物理的な場所 SQLServerサービスに関連するエラーが存在する場所。

シングルユーザーモード（-m）などのスタートアップパラメータを追加できますそのためには、スタートアップパラメータの指定で必要な値を指定する必要があります。 追加をクリックします 。

SQL Server Configuration Managerは高度な詳細を表示するだけでなく、SQLServerサービスに関連する多くの高度な構成を実行できることに気づきました。したがって、デフォルトのServices.mscオプションと比較して、SQLServer構成マネージャーを使用してSQLServer関連のサービスを停止/開始することを個人的にお勧めします。

マスターデータベースの推奨プラクティス

マスターデータベースにはSQLServerインスタンスに関する重要な詳細が格納されているため、そのデータベースを処理する際はベストプラクティスに従うことをお勧めします。

SQL Serverのインスタンスでのすべての構成変更は、マスターデータベースに保存されます。したがって、必要に応じて完全バックアップからマスターデータベースを復元する場合に備えて、最新のステータスに復元するには、常にマスターデータベースの完全バックアップを作成する必要があります。

SQL Serverではユーザーがマスターデータベースにユーザーテーブルやその他のオブジェクトを作成できますが、そうすることはお勧めしません。マスターデータベースは、シンプルでクリーンな状態を維持する必要があります。マスターデータベースにユーザーオブジェクトを作成する必要がある場合は、マスターデータベースのフルバックアップをより頻繁に作成する必要があります。

SQLServerは起動手順オプションをサポートしています SQLServerインスタンスの起動時に特定のストアドプロシージャを実行します。 sp_procoptionを使用します手順。このオプションを使用するときは注意してください。最適でないコードや再帰的なロジックがあると、SQLServerインスタンスの起動時間に影響を与える可能性があります。

マスターデータベースに問題があるためにSQLServerを起動できなかった場合は、最後に確認された正常なバックアップからマスターデータベースを復元する必要があります。

SQLServerのモデルデータベース

名前が示すように、モデルシステムデータベース ファイルパス、初期サイズ、自動拡張設定、リカバリモデル、およびその他の構成オプションに関して、ユーザーデータベースを作成するためのモデルまたはテンプレートとして機能します。。

モデルデータベースで作成されるテーブルやプロシージャなどのユーザーオブジェクトも、そのSQLServerインスタンスの新しいユーザーデータベース全体で自動的に作成されます。

モデルデータベースに新しいテーブルを作成して、これを確認しましょう。

このテーブルがモデルデータベースに存在するかどうかを確認しましょう：

モデルデータベースには、以下のデータベースプロパティに示すように、ユーザーデータベースのデフォルトのファイルパスも保存されます。 msdb データベース。

現在の構成によると、初期ファイルサイズ 両方のデータ およびログファイル は8MBに設定されており、自動拡張は両方とも64MBに設定されています。

モデルデータベースのファイルの場所ではなく、別のファイルパスにユーザーデータベースを作成する必要がある場合は、サーバーのプロパティで変更できます。そのSQLServerインスタンスの。

SSMSで、サーバーを右クリックします >プロパティ >データベース設定 。データベースのデフォルトの場所を表示する：

ファイルパスを目的のパスに変更し、 OKをクリックします 。ユーザーデータベースデータ およびログファイルは、指定した新しいパスに作成されます。

model_testという名前の新しいデータベースを作成しましょう新しいデータベースのデータとログファイルのパスを、初期ファイルと自動拡張ファイルのプロパティ、および model_verifyとともに確認します。新しいデータベースのテーブル。

model_testを確認しましょうデータとログのファイルパス。 model_testを右クリックしますデータベース>プロパティ >ファイル ：

ご覧のとおり、データ およびログ model_testのファイルデータベースは、モデルデータベースで使用可能なパスに従って作成されます。データファイルとログファイルの初期ファイルサイズの値は8MBです。自動拡張の値は64MBです。これらの値は、モデルデータベースの構成と一致します。

次に、 model_verifyかどうかを確認しますテーブルはmodel_testで作成されますデータベース。この新しいデータベースを見ることができます。

テーブルに加えて、これはビュー、ストアドプロシージャ、関数、およびモデルデータベースで作成されたすべてのオブジェクトに適用されます。

モデルデータベースの推奨プラクティス

モデルデータベースは、新しいユーザーデータベースを作成するためのテンプレートとして機能するため、モデルデータベースを処理する際には、以下の方法を実装する必要があります。

モデルデータベース構成に変更（初期ファイルサイズ、自動拡張サイズ、ユーザーオブジェクトの作成、変更、削除など）を実装する場合は、すぐにモデルデータベースの完全バックアップを作成してください。

モデルデータベースで作成されたユーザーオブジェクトはすべてのユーザーデータベースで作成されるため、必要なオブジェクトのみを追加するように注意してください。そうしないと、すべてのユーザーデータベースに多くの不要なオブジェクトが作成され、それらの並べ替えとデータベースのクリーンアップに多くの時間を費やすことになります。

データファイルとログファイルの初期ファイルサイズと自動拡張パラメータを設定します。これは、ユーザーデータベースのデータとログのファイルサイズをより適切に管理し、パフォーマンスを向上させるのに役立ちます。

MSDBデータベース

msdbシステムデータベース 以下の重要な情報をシステムテーブル全体に保存します。

ジョブ、ジョブ履歴、アラート、オペレーター、プロキシなどのSQLServerエージェント関連のアイテム
構成と履歴の詳細を含むServiceBrokerやDatabaseMailなどのSQLServerの機能。
SQLServerのバックアップと復元の詳細はmsdbデータベーステーブル内に保存されます。
ログ配布構成、レプリケーションエージェントプロファイル、およびデータコレクター構成。
メンテナンスプラン、SSISパッケージ、およびその他の詳細。

つまり、msdbシステムデータベースには、SQLServerエージェントサービスおよびその他の関連サービスに関連するすべての重要な情報が格納されます。

msdbデータベースの推奨プラクティス

msdbデータベース SQL Serverエージェント、ジョブ、およびデータベースメールに関連する多くの重要な構成情報を格納します。また、履歴の詳細も保存されます。したがって、msdbデータベースを処理するときは、以下のプラクティスを実装する必要があります。

多くのデータベースまたはジョブが構成されているSQLServerインスタンスでは、msdbデータベースのサイズは時間の経過とともに継続的に増加します。したがって、フルバックアップは他のユーザーデータベースと一緒にmsdbデータベースに毎日実装する必要があります。 msdbが多くの重要な情報を受け取った場合は、msdbデータベースのリカバリモデルをFullに変更してから、トランザクションログバックアップも実装できます。

SQL Serverではユーザーがmsdbデータベースにユーザーオブジェクトを作成できますが、msdbデータベースにユーザーテーブルやオブジェクトを作成せず、msdbデータベースのサイズをさらに大きくすることをお勧めします。

msdbシステムテーブルの定期的なクリーンアップを実行して、msdbデータベースのサイズを制御し、複数のテーブルに大量のデータがあることによるパフォーマンスへの影響を回避します。

Tempdbデータベース

tempdbシステムデータベース は、SQLServerインスタンスに接続しているすべてのユーザーがSELECTまたはその他の操作を実行するために利用できるグローバル作業領域と見なすことができます。。

Tempdbデータベースは、ユーザーが操作を実行している間、以下のオブジェクトタイプを保持します。

ユーザーによって明示的に作成された一時オブジェクトは、ローカルまたはグローバルの一時テーブルとインデックス、テーブル変数、テーブル値関数で使用されるテーブル、およびカーソルのいずれかです。
次のようなデータベースエンジンによって作成された内部オブジェクト：
- スプール、カーソル、ソート、および一時ラージオブジェクト（LOB）の中間結果に使用される作業テーブル
- ハッシュ結合またはハッシュ集計操作の作業ファイル
- SORT_IN_TEMPDBがONに設定されている場合、およびGROUP BY、ORDER BY、UNIONクエリなどの他の操作の場合、インデックスの作成または再構築を処理する際の中間ソート結果
行バージョン管理機能をサポートするバージョンストアは、共通バージョンストアまたはオンラインインデックスビルドバージョンストアのいずれかです。

SQL Serverサービスが開始または再起動するたびに、モデルデータベースを使用してtempdbデータベースが新たに作成されます。したがって、tempdbはバックアップできない唯一のシステムデータベースです 。

バックアップしようとすると、エラーが発生します：

ほとんどすべてのユーザー操作でtempdbを使用しているため、このデータベースは、SQLServerのいくつかのバージョンでパフォーマンスの重大なボトルネックになります。 SQL Server 2016以降、Microsoftによって実装されたいくつかの最適化手法がありました。それらについては後で説明します。

tempdbデータベースの推奨プラクティスに入る前に、以下に示すように、デフォルト構成でのデータファイルを簡単に見てみましょう。

現在のSQLServerインスタンスには、tempdbデータベース用に4つのデータファイルと1つのログファイルがあります。

SQL Server 2016以降、tempdbに複数のファイルを追加できるSQLServerインストーラーがあります。上記の4つのファイルは、初期サイズが8 MB、自動拡張サイズが64 MBで、以下に示すデフォルトのオプションを使用して作成されました。

tempdbデータベースに単一のデータファイルがある場合、サーバーで使用可能なすべての論理コアがtempdbの同じデータファイルにアクセスしようとするため、パフォーマンスのボトルネックが発生します。

複数のデータファイルがあると、特定のコアが1つのファイルに論理的に関連付けられます。したがって、tempdbデータファイルの競合は少なくなります。これにより、tempdbデータファイルのパフォーマンスへの影響が改善されます。

tempdbデータベースの推奨プラクティス

tempdbデータベースは、すべてのユーザーアクティビティのグローバル作業領域のようなものであるため、tempdbサイズはユーザーアクティビティに基づいて増加します。これは、SQLServerインスタンス全体のパフォーマンスのボトルネックになる可能性があります。

したがって、次のプラクティスを実装する必要があります。

tempdbデータファイルとログファイルを高性能ストレージに配置して、パフォーマンスを向上させるためにIOPSを高くします。
tempdbデータベースが複数のデータファイルに分割されていることを確認して、競合を減らし、tempdbデータベースのパフォーマンスのボトルネックを回避します。
- 論理コアの数が8未満の場合、論理コアごとに1つのtempdbデータファイルを作成できます。テストインスタンスでは、4つの論理コアがありました。したがって、tempdb上の4つのデータファイルで十分です。
- 論理コアの数が8を超える場合は、8つのデータファイルから始めて、tempdbデータベースで競合とパフォーマンスの問題が観察された場合は4つのデータファイルを増やします。
- サーバー内の論理コアの数が32または64の場合、8つのデータファイルから始めることができます。これは、4つのコアまたは8つのコアが1つのデータファイルに論理的に関連付けられていることを意味します。
  
  複数のtempdbデータファイルをより明確にするために、PaulRandalの優れた記事をお勧めします。
tempdbデータファイルが最適な初期ファイルサイズで構成されていることを確認します。理想的には、これは試行錯誤のアプローチによって達成されるべきです。最適な初期ファイルサイズのTempdbは、断片化につながる数倍に成長する傾向がある、より小さな初期ファイルサイズで構成されたtempdbと比較して、成長回数が少なくなる傾向があります。たとえば、現在の構成では、すべてのファイルが8 MBの初期ファイルサイズで構成されていますが、これはSQLワークロードを処理するには小さすぎます。したがって、試行錯誤のアプローチを適用し、初期ファイルサイズを512MBまたは1GB、あるいはその他の値に設定します。
すべてのtempdbデータファイルが同じファイルサイズに設定されていることを確認します。自動成長プロパティは等しく定義する必要があります。このシナリオでは、すべてのファイルが64MBの自動拡張に設定されています。自動拡張サイズを512MBまたは1GB、あるいはその他の適切な値に設定すると、tempdbデータファイルで頻繁に自動拡張されるのを減らすのに役立ちます。
tempdbログファイルの初期ファイルサイズと自動拡張が、tempdbデータファイルと同様に最適な値に構成されていることを確認します。 tempdbのリカバリモデルはデフォルトでSimpleに設定されており、変更できないため、tempdbログファイルの初期ファイルサイズとautogrowthプロパティを構成するだけで十分です。

Tempdbは、SQLServerインスタンスのパフォーマンスに不可欠です。 tempdbで頻繁に発生する問題と、それを最適に縮小する方法については、次の記事で詳しく説明します。

SQLServerのリソースデータベース

リソースシステムデータベース 前に見たように、SSMSのシステムデータベースの下にリストされていない唯一の読み取り専用システムデータベースです。

データベースID（dbid） すべてのインスタンスにわたるリソースデータベースの数は32767になります。これは、SQLServerインスタンス内でサポートされるデータベースの最大数でもあります。 sys.sysaltfilesから照会できます。システムDMV。 sys.sysaltfilesで以下のSELECTクエリを実行する 結果セットを返しますリソースデータベースのデータファイルとログファイルの場所を示します：

上記のパスで利用可能なリソースデータベースの物理ファイルを確認できます。変更された日付は、SQL Serverインスタンスのインストール時刻、またはこのインスタンスにService Pack（SP）または累積的な更新（CU）が最後に適用された時刻を示します。

リソースデータベースには、 sys.objectsなどのすべてのシステムオブジェクトが保持されます。、 sys.databases 、 sys.sysaltfiles 、など物理的にその中に。このデータベースは、インスタンスで使用可能なすべてのデータベースのsysスキーマの下にあるこれらすべてのオブジェクトを論理的に一覧表示します。リソースデータベースは読み取り専用であるため、ユーザーオブジェクトやデータを作成することはできません。

リソースシステムデータベースは、SQL Server 2005から導入され、SQLServerを新しいバージョンのSPまたはCUに高速にアップグレードできるようになりました。そのオプションを導入する前は、そのようなすべてのアップグレードと更新は、変更がすべてのデータベースに適用されることを意味し、アップグレードプロセスをより複雑で時間のかかるものにしました。これで、SQL ServerのバージョンアップグレードまたはSPまたはCUの更新は、リソースデータベースをアップグレードまたは置換するだけです。

リソースデータベースは読み取り専用であり、ユーザーには表示されないため、ユーザーの介入は必要ありません。高可用性または障害復旧計画にバックアップリソースデータベースを含める場合は、SQL Serverサービスを停止した後にmssqlsystemresource.mdfファイルとmssqlsystemresource.ldfファイルのファイルバックアップを作成するだけです（SQL Serverサービスでは、ファイルのコピーは許可されません。 SQL Serverサービスが稼働しています）、安全な場所に保存します。予期しない問題が発生する可能性があるため、異なるバージョンのSPまたはCUレベルで実行されているSQLServerのインスタンスで更新しないように十分に注意してください。

SQLServerのディストリビューションデータベース

ディストリビューションシステムデータベースは、レプリケーションの中心です。ユーザーは、ディストリビューションの構成ウィザードまたはパブリケーションの作成ウィザードを使用して、レプリケーションセットアップの一部としてディストリビューションデータベースを作成または構成できます。 SQL Server Transactional Replication Internalsに関する前回の記事の一部として、ディストリビューションデータベースの作成手順について詳しく説明しました。

ディストリビューションデータベースの推奨プラクティス

ディストリビューションデータベースはレプリケーション機能に不可欠であるため、次の方法を実装する必要があります。

配布パフォーマンスの問題を回避するために、配布データベースのデータファイルとログファイルをIOPSが良好なドライブに移動します。

断片化の問題を回避するために、ディストリビューションデータベースの初期ファイルサイズと自動拡張プロパティをより適切な値に構成します。

データベースフルバックアップメンテナンスジョブにディストリビューションデータベースを含めます。

断片化とパフォーマンスの問題を回避するために、インデックスメンテナンスジョブに配布データベースを含めます。

SQL Server Transactional Replicationの内部に関する私の記事には、他の効率的な方法に関する推奨事項もあります。

結論

別のパワー満載の記事を読んでくれてありがとう！

SQL Serverシステムデータベースの本質と目的を明確にし、これらのデータベースのパフォーマンスの問題を回避するためのベストプラクティスを学ぶのに役立つことを願っています。