SQL Serverシステムデータベース–Tempdbのメンテナンス

SQL Serverシステムデータベースに関する前回の記事では、SQLServerのインストールの一部として提供される各システムデータベースについて学習しました。現在の記事では、tempdbデータベースに関して頻繁に直面する問題と、それらを正しく解決する方法に焦点を当てます。

SQL Server TempDB

このシステムデータベースの名前が示すように、 tempdb 一時的なオブジェクトを保持します SQLServerによって作成されました。これらはいくつかの操作に関連しており、SQLServerインスタンスに接続するすべてのユーザーのグローバル作業領域として機能します。

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

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

Tempdbデータベースは、SQLServerサービスが開始するたびに作成されます。したがって、tempdbデータベースの作成時間は、SQLServerサービスのおおよその起動時間と見なすことができます。 sys.databases DMVから識別できます。以下に示すクエリを使用します：

SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'

ただし、SQL Serverサービスを実際に起動するには、すべてのシステムデータベースを特定の順序で起動する必要があります。 tempdbの作成時間より少し早く発生する可能性があります。 sys.databases DMVを使用して値を取得できます sys.dm_os_sys_info DMVで以下のクエリを実行します。。

SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info

ms_ticks 列は、コンピューターまたはサーバーが起動してからのミリ秒数を指定します。 sqlserver_start_time_ms_ticks 列は、 ms_ticksからのミリ秒数を指定します SQLServerサービスが開始されたときの番号。

SQLServerサービスの開始中に起動したデータベースの順序に関する詳細はSQLServerエラーログで確認できます。

SSMSで、管理を展開します > SQLServerエラーログ > currentを開きますエラーログ。 開始を適用します アップデータベース フィルタして日付をクリックします 昇順で並べ替えるには：

SQL Serverサービスの開始時に、マスターデータベースが最初に開始されたことがわかります。次に、すべてのユーザーデータベースと他のすべてのシステムデータベースが続きました。最後に、tempdbが開始されました。 xp_readerrorlog を実行して、この情報をプログラムで取得することもできます。システム手順：

注：SQL Serverサービスが最近再起動されなかった場合、上記の両方のアプローチで必要な情報が表示されない可能性があり、SQL Serverエラーログが再利用されたため、古いエラーログが古いファイルにプッシュされた可能性があります。その場合、アーカイブされたSQLServerエラーログファイル全体でデータをスキャンする必要がある場合があります。

SQLTempDBデータベースで頻繁に直面する問題

tempdbは、すべてのユーザーセッションまたはアクティビティにグローバルな作業領域を提供するため、慎重に構成しないと、ユーザー操作のパフォーマンスのボトルネックになる可能性があります。前回の記事では、tempdbデータベースに実装するための推奨されるベストプラクティスについて説明しました。ただし、それらを実装した後でも、問題が頻繁に発生する可能性があります：

tempdbデータファイル全体でのファイルの不均一な増加。
Tempdbデータファイルは非常に大きな価値に成長しており、Tempdbを縮小する必要があります。

TempDBデータファイル全体でのファイルの不均一な増加

SQL Server 2000以降、デフォルトの推奨事項は、サーバーで使用可能な論理コアの数に基づいて複数のデータファイルを用意することです。

複数のデータファイルがある場合、たとえば、次の画像のように4つのtempdbデータファイルがある場合、tempdbデータファイルの自動拡張は、 tempdev> temp2> temp3>temp4>tempdevから始まるラウンドロビン方式で64MBずつ発生します。> など。

何らかの理由でファイルサイズの1つが自動拡張できない場合、他のファイルと比較して特定のファイルのサイズが大きくなります。巨大なファイルに追加の過負荷がかかり、tempdbデータベースのパフォーマンスに悪影響を及ぼします。

SQL Server 2014までの競合やパフォーマンスの問題を回避するために、すべてのtempdbデータファイルのサイズがいつでも手動で均等になるように手動で確認する必要があります。Microsoftは、SQL Server 2016以降のバージョンから、いくつかの機能を実装することでこの動作を変更しました。この記事の後半で説明します。

上記のパフォーマンスの問題を克服するために、SQLServerは2つのトレースフラグを導入しました名前付き1117 および1118 tempdbに関する競合の問題を回避するため。

トレースフラグ1117 –単一のファイルグループ内のすべてのファイルの自動拡張を有効にします
トレースフラグ1118 –tempdbのUNIFORMFULLEXTENTSを有効にします

トレースフラグ1117

トレースフラグ1117が有効になっていない場合、tempdbが均等なサイズの複数のデータファイルで構成され、データファイルを自動拡張する必要がある場合、SQL Serverはデフォルトで、すべてのファイルがラウンドロビン方式でファイルサイズを増加させようとします。データファイルのサイズが均等でない場合、SQL Serverはtempdbの最大のデータファイルのサイズを大きくしようとし、この大きなファイルをほとんどのユーザー操作に使用して、tempdbの競合の問題を引き起こします。

この問題を解決するために、SQL Serverはトレースフラグ1117を導入しました。有効にすると、ファイルグループ内の1つのファイルを自動拡張する必要がある場合、そのファイルグループ内のすべてのファイルが自動拡張されます。 tempdbの競合の問題を解決します。ただし、トレースフラグ1117を有効にすると、すべてのユーザーデータベースに対しても自動拡張が構成されるという問題があります。

トレースフラグ1118

トレースフラグ1118は、UNIFORMFULLEXTENTSを有効にするために使用されます。 SQLServerが基本からのデータをどのように保存するかを理解するために一歩後退しましょう。

ページ は、8キロバイト（KB）のサイズのSQLServerのストレージの基本単位です。

範囲は、64KB（8 * 8KB）のサイズの物理的に隣接する8ページのセットです。エクステント内にデータを保存するオブジェクトまたは所有者の数に基づいて、エクステントは次のように分類できます。

均一な範囲 単一のオブジェクトまたは所有者が使用またはアクセスする8つの連続したページです。
混合範囲 –最小2つから最大8つのオブジェクトまたは所有者が使用またはアクセスする8つの連続したページです

トレースフラグ1118を有効にすると、tempdbのエクステントが均一になり、パフォーマンスが向上します。

トレースフラグ1117および1118を有効にする方法

トレースフラグは、いくつかの方法で有効にできます。以下のオプションから適切な方法を定義できます：

SQLServerサービスの起動パラメーター

SQLサービスの再起動後も永続的に使用できます。 推奨される方法は、SQLServerサービスの起動パラメーターを介してトレースフラグ1117および1118を有効にすることです。 。

SQLServer構成マネージャーを開きます SQLServerサービスをクリックしますそのサーバーで利用可能なサービスを一覧表示するには：

SQL Server（MSSQLSERVER）を右クリックします。 >プロパティ >起動パラメータ 。
タイプ– T 空のフィールドに入力して、トレースフラグを示します。
値を提供する1117 および1118 以下に示すように。
[追加]をクリックします スタートアップパラメータとしてトレースフラグを追加します。

次に、[ OK]をクリックします SQLServerのこのインスタンスにトレースフラグを永続的に追加します。変更を反映するには、SQLServerサービスを再起動します。

DBCC TRACEON（<トレースフラグ番号>、-1）

トレースフラグをグローバルに有効にします。 SQL Serverサービスは、サービスの再起動時にトレースフラグを失います。トレースフラグをグローバルに有効にするには、新しいクエリウィンドウで次のスクリプトを実行します。

DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);

DBCC TRACEON（<トレースフラグ番号>）

セッションレベルでトレースフラグを有効にします。これは、ユーザーが作成した現在のセッションにのみ適用されます。セッションレベルでトレースフラグを有効にするには、新しいクエリウィンドウで次のスクリプトを実行します。

DBCC TRACEON(1117);
DBCC TRACEON(1118);

SQL Serverのインスタンスで有効になっているトレースフラグのリストを表示するには、 DBCC TRACESTATUSを使用できます。コマンド：

DBCC TRACESTATUS();

ご覧のとおり、トレースフラグ1117および1118は、セッションとともに私のインスタンスでグローバルに有効になっています 。

トレースフラグをオフにするには、次のようなDBCCTRACEOFFコマンドを使用できます。

DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);

SQL Server2016TempDBの機能強化

SQLServerのバージョンSQLServer2000からSQLServer2014全体で、tempdbの競合の問題を回避するために、tempdbの完全な監視とともにトレースフラグ1117および1118を有効にする必要があります。 SQL Server 2016以降のバージョン以降、トレースフラグ1117および1118がデフォルトで実装されています。

ただし、私の個人的な経験に基づいて、tempdbを巨大なサイズに事前拡張して、複数回の自動拡張の必要性を回避し、SQLServerで広く使用されている不均一なファイルサイズや単一ファイルを排除することをお勧めします。。

トレースフラグ1117および1118がSQLServer2016でどのように実装されているかを確認できます。

トレースフラグ1117 ファイルグループ内のすべてのファイルの自動拡張を設定するものが、ファイルグループのプロパティになりました。。新しいファイルグループを作成するとき、または既存のファイルグループを変更するときに構成できます。

ファイルグループの自動拡張プロパティを確認するには 、 sys.filegroups DMVから以下のスクリプトを実行します：

SELECT name Filegroup_Name, is_autogrow_all_files 
FROM sys.filegroups

AdventureWorksデータベースのプライマリファイルグループの自動拡張プロパティを変更するには 、以下のスクリプトをAUTOGROW_ALL_FILESで実行してすべてのファイルを均等に自動拡張するか、AUTOGROW_SINGLE_FILEを使用して単一のデータファイルのみを自動拡張できるようにします。

ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE 
-- AUTOGROW_ALL_FILES is the default behavior
GO

トレースフラグ1118 データファイルのUniformExtentプロパティを設定しますtempdbおよびSQLServer2016以降のすべてのユーザーデータベースでデフォルトで有効になっています 。 tempdbのプロパティは、UniformExtentオプションのみをサポートするようになったため変更できません。

ユーザーデータベースの場合、このパラメーターを変更できます。システムデータベースのマスター、モデル、およびmsdbは、デフォルトで混合エクステントをサポートしており、変更することもできません。

ユーザーデータベースの混合ページ割り当てプロパティ値を変更するには、次のスクリプトを使用します。

ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON 
-- OFF is the default behavior
GO

混合ページ割り当てプロパティを確認するために、 is_mixed_page_allocation_onにクエリを実行できます。 sys.databases DMVの列値は0で、均一なエクステントページの割り当てを示し、1は混合エクステントページの割り当てを示します。

SELECT name, is_mixed_page_allocation_on
FROM sys.databases

TempDBデータファイルが巨大な値に成長し、TempDBの縮小が必要

SQL Server 2014以前のバージョンでは、トレースフラグ1117および1118が、tempdbデータベース用に作成された複数のデータファイルとともに適切に構成されていない場合、これらのファイルの一部は必然的に巨大になります。それが発生した場合、DBAは通常tempdbデータファイルを縮小しようとします。しかし、それは不適切 このシナリオを処理するためのアプローチ。

tempdbを縮小するために利用できる他のオプションがあります。

Shrink tempdbで使用できるDBCCコマンドと、これらの操作を実行した場合の影響について考えてみましょう。

DBCC SHRINKDATABASE

DBCC SHRINKDATABASE consoleコマンドは、 Data \LogFilesの終わりを縮小することで機能します。

データベースを正常に縮小するには、コマンドのファイルの最後に空き領域が必要です。ファイルの最後にアクティブなトランザクションがある場合、データベースファイルを縮小することはできません。

DBCCSHRINKDATABASEの実行による影響 これは、テーブルデータの将来の拡張のために予約されている可能性のあるすべてのデータファイルまたはログファイルの最後にある使用可能な空き領域をクリアしようとすることです。したがって、このコマンドを実行すると、ファイルサイズが不均一になり、tempdbの競合の問題が発生する可能性があります。

たとえばAdventureworksデータベースなどのユーザーデータベースを縮小する構文は次のようになります

DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);

DBCC SHRINKFILE

DBCC SHRINKFILE consoleコマンドはDBCCSHRINKDATABASEと同様に機能しますが、指定されたデータベースデータまたはログファイルを縮小します 。

特定のtempdbデータファイルが巨大であることがわかった場合は、以下に示すように、DBCCSHRINKFILEを使用してその特定のアイテムを縮小してみることができます。

tempdbでこのコマンドを使用するときは注意してください。ファイルが他のデータファイルよりも低い値または高い値に縮小されると、その特定のデータファイルが効果的に使用されなくなります。または、より頻繁に使用され、tempdbの競合の問題が発生します。

AdventureWorksデータファイルに対してDBCCSHRINKFILE操作を1GB（1024 MB）まで実行するための構文は次のようになります。

DBCC SHRINKFILE (AdventureWorks, 1024);  
GO

DBCC DROPCLEANBUFFERS

DBCC DROPCLEANBUFFERS consoleコマンドは、バッファプールからすべてのクリーンバッファをクリアし、列ストアオブジェクトプールから列ストアオブジェクトをクリアするために使用されます。

以下のコマンドを実行するだけです：

DBCC DROPCLEANBUFFERS

DBCC FREEPROCCACHE

DBCC FREEPROCCACHE コマンドは、すべてのストアドプロシージャ実行プランのキャッシュをクリアします 。

プロシージャ実行プランキャッシュは、SQLServerが同じプロシージャ呼び出しをより高速に実行するために使用されます。 DBCC FREEPROCCACHEを実行した後、プランキャッシュはクリアされます。したがって、SQL Serverは、インスタンスでストアドプロシージャが実行されるときに、そのキャッシュを再度作成する必要があります。本番DBインスタンスで実行すると、深刻な悪影響が残ります。

本番データベースインスタンスでDBCCFREEPROCCACHEを実行することはお勧めしません！

DBCCFREEPROCCACHEを実行するための構文は次のとおりです。

DBCC FREEPROCCACHE

DBCC FREESESSIONCACHE

DBCC FREESESSIONCACHE コマンドは、SQLServerインスタンスから配布クエリ接続キャッシュをクリアします 。特定のSQLServerインスタンスで実行されている分散クエリが多数ある場合に役立ちます。

DBCCFREESESSIONCACHEを実行するための構文は次のようになります。

DBCC FREESESSIONCACHE

DBCC FREESYSTEMCACHE

DBCC FREESYSTEMCACHE コマンドすべてのキャッシュからすべての未使用のキャッシュエントリをクリアします 。 SQL Serverはデフォルトでこれを実行して、新しい操作に使用できるメモリを増やします。ただし、次のコマンドを使用して手動で実行できます。

DBCC FREESYSTEMCACHE

ご存知のとおり、tempdbは、実行プランキャッシュ、バッファプールデータ、セッションキャッシュ、システムキャッシュなど、すべての一時的なユーザーオブジェクトまたは内部オブジェクトを格納します。したがって、上記の6つのDBCCコマンドを実行すると、通常の縮小プロセスを妨げるtempdbデータファイルをクリアするのに役立ちます。

さまざまなアプローチでtempdbを縮小する方法について説明しましたが、tempdbデータベースを処理するための推奨されるベストプラクティスを以下に示します。

a。可能であればSQLServerサービスを再起動して、tempdbデータファイルを均等に再作成します。潜在的な影響は、上記で説明したすべての実行計画とその他のキャッシュ情報を失うことです。

b。 tempdbデータファイルを保持しているドライブで利用可能な巨大なファイルサイズにtempdbデータファイルを事前に拡張します。これにより、SQLServerバージョン2014以前でSQLServerのファイルサイズが不均一に増加するのを防ぐことができます。

c。 RTOまたはRPOが原因でSQLServerサービスを再起動できない場合は、影響を明確に理解した上で、上記のDBCCコマンドを試してください。

d。 tempdbデータベースまたはデータファイルを縮小することは推奨されるアプローチではないため、他に選択肢がない場合を除いて、本番環境では決して縮小しないでください。

結論

tempdbでの競合の問題を回避するために、パフォーマンスを向上させるためにtempdbを構成できるように、tempdbがどのように機能するかについての内部について詳しく学びました。また、tempdbで頻繁に直面する問題、さまざまなバージョンでSQL Serverで利用可能な対策、およびそれを効率的に処理する方法についても説明しました。それに加えて、tempdbデータベースまたはデータファイルの縮小がtempdbデータベースを処理する際に推奨されるアプローチではない理由を調査しました。