none
tempdbのオンライン圧縮 RRS feed

  • 質問

  • お疲れ様です。

    ある本番環境にて、過大な負荷をかけてしまった影響でtempdbが肥大化
    してしまいました。
    現状のままですと、ディスクドライブの容量監視に引っかかり
    無用なアラートが上がってしまうため、圧縮したいと思います。

    これにあたり、下記サイトを確認しましたが、SQL Server再起動か、
    tempdbを使っていない状況でshrinkfileくらいしか手がないようです。

    http://support.microsoft.com/kb/307487/ja


    実際、日中帯にshrinkfileを実行してみましたが、
    (1)tempdbを使うジョブにブロックされる
    (2)さらに、shrinkfileが別のジョブをブロックしてしまう
    といった事象が発生し、shrink出来ない状態になっております。

    再起動しないで、うまくオンライン圧縮する方法はないでしょうか?
    本番環境なのでいろいろ試すのはリスクが高く、
    かといって試験環境ではジョブが動作していないため手順の確認ができません
    一般的意見で結構ですので皆様の実運用での経験をお聞きしたいです

    なおtempdbのドライブのサイズは500GB程度で、満杯状態です。
    現在は別のドライブに一時的にファイルを追加ししのいでいます。

    宜しくお願いいたします。
    2012年11月6日 1:47

すべての返信

  • 追記します。

    たとえば、tempdbに小さいファイルを追加して、肥大化してしまったファイルを削除する、というオペレーションを

    ファイル数分繰り返す、というのは有効でしょうか?

    (shrinkfileとそんなに変わらない気もします)

    2012年11月6日 5:11
  • 本番環境なので警告を消したい程度の理由で再起動できないというのはわかりますが、テスト環境なのでジョブが動作していないというのは、テスト環境でもジョブを流せばいいだではないですか?

    新しいプライマリとなるファイルグループを追加して tempdb の使用中のテーブルが全て旧プライマリから新プライマリに移動することができれば、肥大化したファイルを削除できるのではないかと思うのですが、tempdb はファイルグループの追加もできないですし、ReadOnly ファイルグループの設定もできないと記載がある特殊なデータベースなので、物理ファイルのオンライン切り替えは難しそうですね。

    2012年11月8日 3:56
  • K. Takaokaさん、ご回答ありがとうございます

    >テスト環境でもジョブを流せばいいだではないですか?

    おっしゃるとおりですが、ファイルトリガーベースのジョブが動いたりするため、同一条件の再現に非常に手間がかかるので、できればやりたくない、という事情です

    今のところ、オンライン圧縮はあきらめ、やはりSQL Serverを再起動できるタイミングを作り、そこで作業する方向で準備を始めました。

    引き続き、皆様の経験値をお聞かせいただければ幸いです

    2012年11月8日 5:15