トランザクションログバックアップのシリアルまたはパラレル？

SQL Server 2012 Standard Editionを使用しています。また、Ola Hallengrenのスクリプトを使用して、バックアップとメンテナンスを行うための簡単で柔軟なフレームワークを提供することもあります。

この質問は、オラのスクリプトに関するものではなく、ベストプラクティスに関するものです。究極の答えは「あなたの会社の要件に依存する」ことです。しかし、私は会社の要件について理解したことをどのように実現するのが最善かについて、コミュニティのアドバイスを求めています。

15分ごとにトランザクションログのバックアップを設定したい。このようにして、15分以内のデータが失われることを願っています。ALL_DATABASESを使用する1つのジョブをセットアップする必要がありますか？または、データベースごとに1つのジョブを設定し、それらをすべて並行して開始する方が良いでしょうか？私は、バックアップがシリアルで開始されるというオラのスクリプトの機能をどのように見ているかに基づいているので、私は尋ねます。シリアルの欠点は、連続する各バックアップが他のバックアップが完了するまで待機することです。これにより、バックアップ間の時間が長くなる可能性があります（15分以上）。さらに、1つのバックアップで障害が発生すると、他のバックアップが停止するのではないかと心配になります。そのようなことはしたくありません。他の人にバックアップを続けてほしい。

それでは、Olaのスクリプトがシリアルで実行され、失敗が連続したバックアップを停止するというのは本当ですか？

そして、データベースごとに仕事をする方が良いでしょうか？またはすべてを行う単一のジョブですか？私の傾向は、別々の仕事に向かうことですが、SQL Server DBAの一般的な傾向を理解したいと思います。

ALL_DATABASESを使用する1つのジョブをセットアップする必要がありますか？または、データベースごとに1つのジョブを設定し、それらをすべて並行して開始する方が良いでしょうか？

トランザクションログを（連続して）バックアップする1つのジョブをセットアップすることをお勧めします。また、データベースのバックアップを1つずつ実行しているため、バックアップによってI / Oが大幅に使用されることはありません。

並列実行で起こりうる欠点

1. 50個のデータベースがあり、すべてのデータベースのトランザクションログバックアップをスケジュールし、それらがすべて並行して実行を開始すると、これは間違いなく多くのI / Oを利用することになります。また、ファイルをバックアップしているディスクに他のデータファイルが含まれていると、速度が低下します。大量のI / Oを要求する質の悪いクエリがバックアップジョブとともに実行されると、バックアップが遅くなるのを見ました。

2. 繰り返しますが、データベースが50個あるとすると、SQL Serverエージェントで50個のジョブを管理するのは難しくなく、100〜200個のデータベースがある場合の状態はどうでしょうか。単純にしてください。同じことがあなたにも当てはまると思います。

シリアルの欠点は、連続する各バックアップが他のバックアップが完了するまで待機することです。これにより、バックアップ間の時間が長くなる可能性があります（15分以上）。

トランザクションログのバックアップは大部分が小さく、大量のログレコードを生成するビジーなデータベースがある場合は、バックアップ頻度を変更する必要があります。ほとんどの場合、頻度が15分の場合にトランザクションログのバックアップが正常に完了します。心配する必要はないと思います。

加えて、1つのバックアップで障害が発生すると他のバックアップが停止するのではないかと心配になります。

心配しないでください。トランザクションログのバックアップは、ミスをしない限り失敗することはありません。間違いは

1. ジョブを実行している所有者はADから削除されます

2. 誰かがデータベースの復旧モデルを変更しました。

3. ディスク容量が不足しています

上記とは別に、トランザクションログのバックアップが失敗する理由はありません。非常に堅牢で、信頼できます。

一般的に、T-logバックアップは常にシリアルで実行してください。私のインスタンスの多くには数十のデータベースがあり、いくつかのデータベースは非常にアクティブであり、トランザクションログのバックアップにかかる時間はわずか数秒です。特に混雑している場合は、最大で30分ほどかかります。

次の条件がすべて満たされている場合にのみ、バックアップを並行して実行することが本当に有益です。

• データベースとログファイルはすべて、一意の独立したスピンドル上にあります（または任意の組み合わせでソリッドステートディスク上にあります）

  • T-logバックアップの場合、ログファイルのみがこの要件を満たす必要があります。

• 各データベースのバックアップターゲットは、別々のスピンドルにあります。

• SQL Serverインスタンスとメディア間で共有SAN HBAまたはiSCSIまたはその他の帯域幅を使用していません。

• つまり、データベースAの読み取りとバックアップAの書き込みからのIOPSは、データベースBの読み取りとバックアップBの書き込みと同じディスクを使用しないでください。

これらすべてが当てはまる場合、ある程度の並列処理により、合計カレンダー時間が減少する可能性があります。これらのすべてが当てはまらない場合、1つまたは複数のディスクセットがスラッシングする可能性が高く、並列バックアップは実際にはシリアルよりも多くのカレンダー時間を要しますが、OSファイルシステムまたはストレージレベルの断片化を引き起こす可能性もありますバックアップAとバックアップBを同時に書いています！

1つのバックアップが失敗し、残りが成功することを心配しないでください。失敗した場合は、とにかくすべてを確認する必要があります。バックアップが失敗したのは、次の原因のみです。

• ディスク障害

• Hyperbac / Litespeed /サードパーティの圧縮ソフトウェアの障害（SQLと障害のあるディスクの間にソフトウェアがある場合）

  • 警告として、失敗は終了しないバックアップジョブの形をとる場合があるため、アラートを送信する「予想よりも長く実行されるジョブ」をチェックすることは有益です。

• 暗号化製品の障害（SQLと障害のあるディスクの間にソフトウェアがある場合）

• ネットワーク障害（データベースファイル、またはより可能性の高いバックアップファイルがネットワーク上にある場合）

• 許可

  • 真新しいインストールで最も一般的

  • または新しいバックアップ場所

  • SQL Serverサービスユーザーの変更（通常のバックアップにアクセス許可が必要なもの）

  • 複数のSQL Serverインスタンスで使用されているため、SQL Serverサービスユーザーをロックアウトする

• 構成エラー

• 停電

• OSクラッシュ

上記の条件が満たされない限り、それらの大部分は他に影響を与えません。

追加するために、Olaは、何らかのデータベースバックアップが何らかの理由でバックアップに失敗した場合、次のデータベースバックアップが試行されるスクリプトを設計します。前に述べたように、すべてのデータベース（1つのデータベースをバックアップしていると仮定して、1つのデータベースバックアップのみがすべてのユーザーデータベースから失敗した場合でも、バックアップジョブは失敗するため、ジョブの失敗を通知するアラートを設定できますすべての仕事）。