トランザクションログバックアップシリアルまたはパラレル？
たまたまSQL Server 2012 Standard Editionを使用しています。また、Ola Hallengrenのスクリプトを使用して、バックアップとメンテナンスを行うための簡単でより柔軟なフレームワークを提供しています。
この質問は、Olaのスクリプトに関するものではなく、ベストプラクティスに関するものです。最終的な答えは「あなたの会社の要求次第」だと私は理解しています。しかし、私は私が会社の要件について私が理解していることを実現するための最善の方法についてコミュニティの助言を求めています。
15分ごとにトランザクションログのバックアップを設定したいと思います。このようにして、うまくいけば15分以下のデータが失われます。 ALL_DATABASESを使用する1つのジョブを設定する必要がありますか？または、データベースごとに1つのジョブを設定し、それらすべてを並行して開始する方が良いでしょうか？私が尋ねるのは、バックアップがシリアルで開始されるというOlaのスクリプトがどのように機能しているのかを確認することに基づいているからです。シリアルの欠点は、連続する各バックアップが他のバックアップが完了するまで待機することです。これにより、バックアップ間の時間が長くなる可能性があります（つまり、15分を超える）。さらに、私の懸念は、1つのバックアップで障害が発生すると、他のバックアップが実行されなくなることであり、私はそうはなりたくありません。他の人たちにバックアップを続けて欲しい。
では、Olaのスクリプトがシリアルで実行され、障害が発生すると、後続のバックアップが停止するというのは本当ですか。
そして、各データベースの仕事を持っている方が良いですか？またはすべてを行う単一の仕事？私の傾向は別の仕事に向いていますが、SQL Server DBAの一般的な傾向を理解したいと思います。
ALL_DATABASESを使用する1つのジョブを設定する必要がありますか？または、データベースごとに1つのジョブを設定し、それらすべてを並行して開始する方が良いでしょうか？
トランザクションログを（シリアルに）バックアップする1つのジョブをセットアップすることをお勧めします。また、データベースのバックアップを一度に1つずつ実行しているため、バックアップによってI/Oの負荷が大きくなることがなくなります。
並列実行の場合に考えられる欠点
50個のデータベースがあり、すべてのデータベースのトランザクションログバックアップをスケジュールし、それらすべてが並行して実行を開始するとします。これは間違いなく多くのI/Oを利用することになります。また、ファイルをバックアップしているディスクに他のデータファイルがある場合、速度が低下します。多くのI/Oを要求する質の悪いクエリがバックアップジョブと共に実行されると、バックアップが遅くなるのを見てきました。
繰り返しますが、50個のデータベースがある場合、SQL Serverエージェントで50個のジョブを管理することは難しくありません。100個から200個のデータベースがある場合、SQL Serverエージェントを開いて多くのジョブが表示されるときに、データベースが気に入らない場合はどうでしょうか。単純にしてください。きっとあなたと同じことになるでしょう。
シリアルの欠点は、連続する各バックアップが他のバックアップが完了するまで待機することです。これにより、バックアップ間の時間が長くなる可能性があります（つまり、15分を超える）。
トランザクションログのバックアップはほとんどであり、データベースがビジー状態で大量のログレコードを生成している場合は、バックアップの頻度を変更する必要がある場合があります。頻度が15分の場合、トランザクションログのバックアップが正常に完了するのがほとんどです。気にする必要はないと思います。
加えて、私の懸念は、1つのバックアップで障害が発生すると、他のバックアップが発生しなくなることであり、私はそうはなりたくありません。
心配しないでください。トランザクションログのバックアップは、何らかの間違いがない限り失敗することはありません。間違いは
ジョブを実行している所有者がADから削除されます
誰かがデータベースの復旧モデルを変更しました。
ディスク容量不足
上記以外に、トランザクションログのバックアップが失敗する理由は確認していません。非常に堅牢で信頼できます。
一般的に、Tログのバックアップは常にシリアルで実行してください。私のインスタンスの多くには数十のデータベースがあり、いくつかは非常にアクティブで、トランザクションログのバックアップは合計で数秒しかかかりません。特に混雑している場合は最大30分程度。
次の条件がすべて当てはまる場合にのみ、バックアップを並行して実行することが本当に有益です。
データベースとログファイルはすべて、一意の独立したスピンドル上にあります（または任意の組み合わせでソリッドステートディスク上にあります）
- Tログバックアップだけの場合、ログファイルのみがこの要件を満たす必要があります。
各データベースのバックアップターゲットは、別々のスピンドルにあります。
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インスタンスで使用されるため、SQL Serverサービスユーザーをロックアウトする
構成エラー
停電
OSクラッシュ
上記の条件が満たされている場合を除いて、そのほとんどは影響を受けません。
追加するために、Olaはスクリプトを設計し、1つのデータベースバックアップが何らかの理由でバックアップに失敗した場合に、次のバックアップが試行されるようにします。前述のように、すべてのデータベース（1つのデータベースをバックアップしている場合）すべての仕事）。