web-dev-qa-db-ja.com

メンテナンス期間中にトランザクションログのバックアップを停止する理由はありますか？

最近、トランザクションログが大きくなり、ストレージスペースがいっぱいになるという問題が発生しました。これは、メンテナンスウィンドウ中に発生しました（Ola Hallengrenインデックスオプティマイズスクリプトが使用されています）。何らかの理由で、過去の誰かがトランザクションログのバックアップを3時間停止するように設定しました。これは、インデックス作成ジョブの実行中のようです（ 3時間実行するように設定します）。

私の組織は最近、2008r2からSQL Server 2016に移行しました。移行に携わった人は、トランザクションログを実行しない時間帯を30分短くしたため、午前5時30分に開始します。完全バックアップのために停止されていたと彼は信じていたと思います。しかし、インデックスのメンテナンスを実行するために停止されたと思います。どちらの場合も必要ですか？ tlogのバックアップを停止することは、助けるよりも害を及ぼすようです。

SQLサーバー2008r2のスケジュールは：

  • 3:00 am：トランザクションログのバックアップが停止されます
  • 午前3時：週次インデックス
    ジョブの最適化が開始されます（ログが原因で2時間30分後に失敗しました）
    スペース）
  • 4:00 am：完全バックアップ
  • 午前6時/午前5時30分に変更：トランザクションログのバックアップが開始されます（ただし、ログはフルのままです）

追加情報：

私の組織は最近、2008r2から2008r2にSQLサーバー2016にアップグレードしました。これは、これまで経験したことのないものです（どちらもエンタープライズ版です）。それは単なる偶然でしょうか、それともアップグレードによって何かが変わったのでしょうか？原因について何を確認するかについてのアドバイスはありますか？サーバー管理者がジョブを元のスケジュールに戻しました。インデックスのメンテナンスとトランザクションログのバックアップの重複が問題の原因であると信じて、午前3時から午前6時までトランザクションログがバックアップされていません。それは本当ですか？トランザクションログの問題についてより多くの調査を行うほど、このメンテナンスウィンドウでログのバックアップを実行し、シャットダウンしないようにする必要があるようです。そもそもなぜ彼らが停止されているのかについて少し混乱していますが、元の管理者はもう会社にいません。移行後に問題となる理由について、私はさらに混乱しています。

sql-serverbackupsql-server-2016transaction-logmaintenance
4
Tracy M

あなたは絶対的に正しいです。インデックスのメンテナンス期間中にトランザクションログのバックアップを停止する理由はありません。あなたがすでに経験したように、それは物事を悪化させるだけです。小さいサイズのインデックスでメンテナンスを行っているケースがあり、トランザクションログのバックアップを通常のスケジュールよりも頻繁に行っていました。

大きなインデックスを再構築する場合は、トランザクションログが大きくなるのに十分なストレージがあることを確認する必要があります。インデックスの再構築中にトランザクションログのバックアップを作成しても、長くアクティブなトランザクションがある場合、ログは切り捨てられません。単一のインデックスの再編成中にログが途中で切り捨てられる可能性があるため、インデックスを再編成する場合はそうではありません。

Ola HallengrenのFrequently Asked Questionsページでも、これが言及されています：

IndexOptimizeジョブを実行すると、トランザクションログが非常に大きくなります。どうすればいいですか？

トランザクションログバックアップジョブが正常に実行されていることを確認します。

トランザクションログに必要なストレージがあることを確認します。トランザクションログファイルは圧縮しないでください。これを行うと、リソースを縮小して後でファイルを再成長させる必要があります。

完全バックアップ中に、トランザクションログのバックアップを停止する必要はありません。 Erik Darlingによるこの記事を読んでください。

フルバックアップ中にトランザクションログバックアップはどうなりますか？

5
SqlWorldWide

SqlWorldWideは正しいですが、私はさらに一歩戻って次のように質問します。 インデックスを最適化することは、何かに役立つことさえあります ？

インデックスを再構築する人々には、かなり大きなプラセボ効果があります。統計も更新されます。更新された統計により、El Optimizeroはインデックス内のデータのより良い説明を提供し、キャッシュから不良または非効率的なクエリプランを追跡することさえできます。

ほとんどの人はデフォルトでOlaのスクリプトを実行します。問題は、MicrosoftがWindows Server 2003の誕生とほぼ同時期にそのガイダンスを公開したことです。それ以来、コンピュータハードウェアは大きな進歩を遂げました。サーバーに回転する大皿が付いているドライブの束がまだある場合、それはそれから降りることに取り掛かる時間です。

Enterprise Editionを使用している場合、Olaのスクリプトを実行するより賢明な方法は次のとおりです。

EXEC master.dbo.IndexOptimize @Databases = 'USER_DATABASES',
                              @FragmentationMedium = 'INDEX_REORGANIZE',
                              @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REORGANIZE',
                              @FragmentationLevel1 = 50,
                              @FragmentationLevel2 = 80,
                              @MinNumberOfPages= 5000,
                              @UpdateStatistics = 'ALL',
                              @OnlyModifiedStatistics = 'Y',
                              @LogToTable = 'Y';

Standard Editionを使用している場合は、オンラインで再構築できないため、これを使用できます。

EXEC master.dbo.IndexOptimize @Databases = 'USER_DATABASES',
                              @FragmentationMedium = 'INDEX_REORGANIZE',
                              @FragmentationHigh = 'INDEX_REBUILD_OFFLINE,INDEX_REORGANIZE',
                              @FragmentationLevel1 = 50,
                              @FragmentationLevel2 = 80,
                              @MinNumberOfPages = 5000,
                              @UpdateStatistics = 'ALL',
                              @OnlyModifiedStatistics = 'Y',
                              @LogToTable = 'Y';

これらは何を買うのですか？

  1. より大きなスキャンで表示を開始する可能性がある断片化レベルを持つインデックスでのみ作業する
  2. インデックスを最適化して、読み取る必要のあるページ数を大幅に削減できるサイズのインデックスでのみ作業する
  3. 変更された統計の管理

これらの設定でメンテナンスの実行を開始し、誰も大騒ぎしない場合は、それらの実行を毎晩から毎週に切り替えることができます。または毎月。

ただし、統計を定期的に更新したい場合は、次のコマンドを使用して更新できます。

EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES',
                          @FragmentationLow = NULL,
                          @FragmentationMedium = NULL,
                          @FragmentationHigh = NULL,
                          @UpdateStatistics = 'ALL',
                          @OnlyModifiedStatistics = 'Y',
                          @StatisticsSample = NULL,
                          @LogToTable = 'Y';

インデックスのメンテナンスは面倒で混乱します-- 以前はかなり愚かでした 。 OCDを乗り越えて、インデックスをできるだけ断片化しないようにする必要があり、実際にパフォーマンスに役立つことに集中し始めたとき、私のサーバーははるかに良好な状態になりました。 DBCC CHECKDBのような重要な事柄にも多くの時間を費やしました。

お役に立てれば！

4
Erik Darling