概要

この資料では、Microsoft SQL Server の tempdb データベースを圧縮するさまざまな方法について説明します。 ここで説明している方法で tempdb データベースを圧縮する前に、次のことに注意してください。

  • tempdb データベースのサイズは、SQL Server を再起動するたびに、前回構成したサイズ (既定のサイズ、または ALTER DATABASE で最後に指定したサイズ) にリセットされます。 したがって、上記と異なるサイズにするか、緊急措置を講じなければならない場合を除き、この資料で説明している方法で圧縮する必要はありません。 次回 SQL Server サービスが再起動するまで待ってください。 tempdb データベースのサイズが大きくても、SQL Server のパフォーマンスには影響しません。

  • SQL Server 2005 以降のバージョンでは、tempdb データベースの圧縮は、SQL Server のインスタンスが再起動するたびに tempdb が前回構成されたサイズにリセットされることを除き、ユーザー データベースの圧縮と同じです。

  • tempdb の処理の進行中に tempdb を圧縮しても安全です。 ただし、ブロッキングやデッドロックなどの別のエラーが発生して、圧縮が完了しないことがあります。 そのため、tempdb データベースを確実に圧縮できるように、サーバーがシングル ユーザー モードのときか、tempdb の処理をすべて停止してから圧縮してください。

tempdb に関する情報

tempdb データベースは一時的なワークスペースです。 SQL Server はさまざまなタスクで tempdb を使用します。 次に、その用途をいくつか示します。

  • 明示的に作成した一時テーブルの記憶領域

  • クエリの処理中および並べ替え中に作成された中間結果を格納する作業テーブル

  • 静的カーソルの結果セットの格納

  • スナップショット分離レベル、または Read Committed のスナップショット分離レベルが使用された場合のバージョン レコードの記憶領域

SQL Server が tempdb のトランザクション ログに記録するのは、トランザクションのロールバックに必要な情報だけです。データベースの復元時にトランザクションをやり直すための情報ではありません。 そのため、tempdb の INSERT ステートメントのパフォーマンスが向上します。 さらに、トランザクションをやり直すための情報をログに記録する必要はありません。というのは、SQL Server を再起動するたびに、tempdb が作成し直されるからです。 したがって、ロールフォワードするトランザクションもロールバックするトランザクションもありません。 SQL Server を起動すると、tempdb がモデル データベースのコピーを使って作成し直され、そのサイズは前回構成されたサイズにリセットされます。 この構成されたサイズとは、ALTER DATABASE (MODIFY FILE オプションを使用)、DBCC SHRINKFILE や DBCC SHRINKDATABASE ステートメントなど、ファイル サイズの変更コマンドで最後に明示的に設定されたサイズのことです。

既定では、tempdb データベースは、必要に応じて自動的に拡張するように設定されています。 そのため、時間が経つに従って、妥当なサイズよりかなり大きくなることがあります。 このような場合は、SQL Serverを再起動するだけで、tempdb のサイズを前回構成されたサイズにリセットできます。

SQL Server 2005 以降のバージョンでは、次の方法またはコマンドのいずれかを使って、tempdb のサイズを変更できます。

方法/コマンド

再起動の必要性

詳細情報

ALTER DATABASE

あり

既定の tempdb ファイル (tempdev と templog) のサイズを完全に制御できます。

DBCC SHRINKDATABASE

なし

データベース レベルで動作します。

DBCC SHRINKFILE

なし

個々のファイルを圧縮します。

SQL Server Management Studio

なし

GUI を使ってデータベース ファイルを圧縮する方法です。


注: SQL Server 2005 の SQL Server Management Studio では、tempdb ファイルを圧縮した後で、正しいサイズが表示されません。 [現在割り当てられている領域] には、常に、sys.master_files DMV ファイルある値が表示されますが、この値は tempdb データベースを圧縮しても更新されません。 tempdb データベースを圧縮した後で、そのファイルの正しいサイズを確認するには、SQL Server Management Studio で次のステートメントを実行してください。

use tempdb
go






select (size*8) as FileSizeKB from sys.database_files

ここでは、上の一覧にある最初の 3 つのコマンドについて説明します。

注: SQL Server 2000 では、SQL Server Management Studio ではなく、クエリ アナライザーを使用する必要があります。 また、DBCC コマンドを実行するには、データベースをシングル ユーザー モードにする必要があります。

tempdb データベースを、構成されたサイズより小さく圧縮するには、次の 3 通りの方法があります。

方法 1: Transact-SQL コマンドを使用する
注: この方法では、SQL Server の再起動が必要になります。

  1. SQL Server を停止します。

  2. コマンド プロンプトで、インスタンスを最小構成モードで起動します。 これを行うには、次の手順を実行します。

    1. コマンド プロンプトで、次のフォルダーに移動します。

    2. インスタンスが SQL Server の名前付きインスタンスの場合は、次のコマンドを実行します。

      sqlservr.exe -s InstanceName -c -f インスタンスが SQL Server の既定のインスタンスの場合は、次のコマンドを実行します。

      sqlservr -c -f 注: -c パラメーターと -f パラメーターは、SQL Server を最小構成モードで起動させるためのパラメーターです。最小構成では、tempdb のデータ ファイルが 1 MB、ログ ファイルが 0.5 MB になります。

  3. クエリ アナライザーで SQL Server に接続し、次の Transact-SQL コマンドを実行します。

       ALTER DATABASE tempdb MODIFY FILE
       (NAME = 'tempdev', SIZE = target_size_in_MB) 
       --Desired target size for the data file
    
       ALTER DATABASE tempdb MODIFY FILE
       (NAME = 'templog', SIZE = target_size_in_MB)
       --Desired target size for the log file
    
  4. SQL Server を停止します。 このためには、コマンド プロンプト ウィンドウで Ctrl キーを押しながら C キーを押します。SQL Server をサービスとして再起動して、Tempdb.mdf ファイルと Templog.ldf ファイルのサイズを確認します。

この方法の欠点は、tempdb の既定の論理ファイル (tempdev と templog) しか処理できないことです。 tempdb に別のファイルを追加している場合は、SQL Server をサービスとして再起動した後で、これらのファイルを圧縮してください。 すべての tempdb ファイルが起動時に再作成されます。 ただし、これらのファイルは空で、削除することができます。 tempdb の余分なファイルを削除するには、ALTER DATABASE コマンドと REMOVE FILE オプションを使用します。

方法 2: DBCC SHRINKDATABASE コマンドを使用する
DBCC SHRINKDATABASE コマンドを使用して、tempdb データベースを圧縮します。 DBCC SHRINKDATABASE には、target_percent パラメーターがあります。 これは、データベースを圧縮した後で、データベース ファイル内に残す空き領域の割合をパーセントで指定するパラメーターです。 DBCC SHRINKDATABASE を使用する場合は、SQL Server の再起動が必要になることがあります。

  1. tempdb の現在使用されている容量を確認するには、sp_spaceused ストアド プロシージャを使います。 次に、DBCC SHRINKDATABASE のパラメーターとして指定する、圧縮後に残る空き領域の割合を計算します。 この計算は、希望するデータベースのサイズに基づいて行います。

    注: 場合によっては、sp_spaceused @updateusage=true を実行して、使用されている容量を再計算し、更新された値を取得する必要があります。 sp_spaceused ストアド プロシージャの詳細については、「SQL Server オンライン ブック」を参照してください。


    次の例を参考にしてください。

    tempdb にサイズが 100 MB のプライマリ データ ファイル (Tempdb.mdf) と 30 MB のログ ファイル (Tempdb.ldf) があると仮定します。 sp_spaceused プロシージャを実行して、プライマリ データ ファイルに 60 MB のデータが含まれていることがわかったとします。 また、プライマリ データ ファイルを 80 MB に圧縮するとします。 圧縮後に残る空き領域を次のように計算します。 80 MB から 60 MB を引くと20 MB です。 この 20 MB を 80 MB で割ると 25 %になり、これが target_percent の値です。 この値に従ってトランザクション ログ ファイルが圧縮され、データベースの圧縮後に空き容量が 25 %、つまり 20 MB 残ります。

  2. クエリ アナライザーで SQL Server に接続し、次の Transact-SQL コマンドを実行します。

       dbcc shrinkdatabase (tempdb, 'target percent') 
       -- This command shrinks the tempdb database
    

DBCC SHRINKDATABASE コマンドを tempdb データベースで使用するときには、制限がいくつかあります。 データ ファイルとログ ファイルの目標のサイズは、データベースを作成したときに指定されたサイズ、または ALTER DATABASE (MODIFY FILE オプションを使用) や DBCC SHRINKDATABASE などのファイル サイズの変更コマンドで最後に明示的に設定したサイズより小さくすることはできません。 DBCC SHRINKDATABASE コマンドのもう 1 つの制限は、target_percentage パラメーターの計算が必要で、その値が現在使用されている容量に依存することです。

方法 3: DBCC SHRINKFILE コマンドを使用する
DBCC SHRINKFILE コマンドを使用して、個々の tempdb ファイルを圧縮します。 DBCC SHRINKFILE は、DBCC SHRINKDATABASE より柔軟性の高い方法です。というのは、同じデータベースに属する他のファイルに影響することなく、1 つのデータベース ファイルだけを処理できるからです。 DBCC SHRINKFILE コマンドには、target size パラメーターがあります。 これは、データベース ファイルの目標とする最終的なサイズを指定するパラメータです。

  1. プライマリ データ ファイル (tempdb.mdf)、ログ ファイル (templog.ldf)、および tempdb に追加した他のファイルの目標とするサイズを決めます。 ファイル内の使用されている容量が、目標とするサイズより小さいか等しいことを確認してください。

  2. クエリ アナライザーで SQL Server に接続し、圧縮したい特定のデータベース ファイルごとに、次のような Transact-SQL コマンドを実行します。

       use tempdb
       go
    
       dbcc shrinkfile (tempdev, 'target size in MB')
       go
       -- this command shrinks the primary data file
    
       dbcc shrinkfile (templog, 'target size in MB')
       go
       -- this command shrinks the log file, examine the last paragraph.
    

DBCC SHRINKFILE の長所は、ファイルのサイズを元のサイズより小さくできることです。 DBCC SHRINKFILE は、どのデータ ファイルやログ ファイルに対してでも実行できます。 DBCC SHRINKFILE の欠点は、データベースをモデル データベースよりも小さくできないことです。

データベースを圧縮するときにエラー 2501 またはエラー 8909 が発生する

tempdb を使用中に DBCC SHRINKDATABASE コマンドか DBCC SHRINKFILE コマンドで tempdb を圧縮しようとすると、使用している SQL Server のバージョンに応じて、次のようなエラー メッセージが表示されることがあります。

SQL Server 2005 以降

サーバー: メッセージ 8909、レベル 16、状態 1、行 1 テーブル エラー: オブジェクト ID 0、インデックス ID -1、パーティション ID 0、アロケーション ユニット ID 0 (型不明)、ページ ID (6:8040) のページ ヘッダー内に無効なページ ID が含まれています。 ページ ヘッダー内のページ ID = (0:0)。


SQL Server 2000

サーバー: メッセージ 2501、レベル 16、状態 1、行 1 テーブル'1525580473' が見つかりませんでした。 システム オブジェクトを調べてください。

サーバー: メッセージ 8909、レベル 16、状態 1、行 0 テーブルの破損: オブジェクト ID 1、インデックス ID 0、ページ ID %S_PGID。 ページ ヘッダー内のページ ID = %S_PGID。

注:

  • これらのエラーは、tempdb が実際に破損していることを示しているわけではありません。 ただし、エラー 8909 のような物理データの破損エラーの原因が、I/O サブシステムの問題など、データベース以外である可能性があります。 そのため、データベースの圧縮処理以外でエラー発生した場合は、さらに詳しく調査する必要があります。

  • SQL Server 2005 以降では、8909 のエラー メッセージがアプリケーション、または圧縮を実行しているユーザーに返されますが、圧縮処理が失敗することはありません。

  • 一方、SQL Server 2000 以前のバージョンでは、これらのエラーが発生すると、圧縮処理に失敗します。 そのため、tempdb データベースを圧縮するには、SQL Server を再起動して tempdb を作成し直す必要があります。

関連情報

データベースの圧縮

ヘルプを表示

スキルを磨く
トレーニングの探索
新機能を最初に入手
Microsoft Insider に参加する

この情報は役に立ちましたか?

翻訳品質にどの程度満足していますか?
どのような要因がお客様の操作性に影響しましたか?

フィードバックをお送りいただきありがとうございます!

×