トランザクションログをバックアップすることがなぜそれほど重要なのですか？
現在クライアントのバックアップソリューションを実装しており、クライアントのERPソリューションはSQL Serverを使用しています。
ERPソリューションは別の会社によってセットアップされました。そしてtheyは、トランザクションログをバックアップして切り捨てることが非常に重要であることを教えてくれます。
私はこのトランザクションログを少し読んでいますが、なぜこれがそれほど重要であるのかわかりませんとにかくマシン全体をすでにバックアップしている場合（ArcServe UDPを使用しています。 SQL Serverを認識し、VSSを使用します）。 SQL ServerでのクリーンアップタスクVMは既にログの切り捨てを処理していますが、UDPではSQL Serverのログの切り捨ても可能です。
トランザクションログはすべてのトランザクションのログであるため、破損したデータベースの復元に使用できることは理解しています。しかし、私はすでにデータベース全体の1時間ごとのバックアップを持っているので、なぜ気にするのでしょうか？
これを行う必要があるのは、DBリカバリモードが「フル」に設定されている場合のみです。 「シンプル」に設定されている場合、トランザクションログのバックアップを作成する必要はありません。ただし、これら2つのオプションの違いに注意してください。
まず、DBを特定の時点に復元できるようにするには、「フル」モードを使用する必要があります。 （タイミングを非常に正確に調整できるため、復元ポイントにミリ秒を指定することもできると思います）「シンプル」モードでは、最後の完全バックアップにのみ戻ることができます。
トランザクションログのバックアップ/切り捨てを行わない場合、（フルモードで）全体の時間が長くなります。 .trnファイルがデータベース自体の2倍以上の大きさのデータベースを見ました。これは、DBに変更が加えられた頻度によって異なります。
もう1つのポイントは、ログバックアップは通常、フルバックアップより高速であることです。
したがって、1時間ごとに完全バックアップを作成するバックアップ計画は最適ではないと思います。しかし、それはあなたの状況に依存します：
あなたが言うなら：さて、DBを過去1時間に復元できれば、問題はありません。 -> 1時間ごとに完全バックアップを保持する場合は、リカバリモードを「シンプル」に設定することも検討できます。
私の意見では、より良いアイデアは、早朝に完全バックアップを作成し、その後1時間ごとにトランザクションログバックアップを実行することです。はるかに高速で、必要な時点に復元できます。そして、あなたの.trnファイルはあまり大きくなりません...
お役に立てれば。
上手。復旧モデルを完全に設定していて、SQLのバックアップ（サーバーのバックアップではない）を使用してトランザクションログをバックアップしない場合、トランザクションログは、利用可能なすべてのディスク領域を消費するまで増加し続けるため、気にする必要があります。 （以前は、同僚がSQL Serverをシステムドライブにインストールし、トランザクションログをバックアップしていないことを確認しました。ate Windowsです。）
はい、特定の時点にも復元されます。分まで。トゥインクルスが言うように、はい、人々はテーブルなどを落としています。
データベース全体の1時間ごとのバックアップに何を使用しているか、およびそれがマシン全体に使用しているものと同じ製品かどうかはわかりません。その場合、SQLに対応していないバックアップソリューションはリストアでサポートされません。 VSSがMDFおよびLDFファイルをコピーするのにかかる時間は、たとえば、内部のタイムスタンプの不一致を引き起こす可能性があります。
私たちはいくつかのERP=システムも管理しています。そして問題は、多くの場合、夜間に他のシステムとデータを同期する長時間実行されるバッチジョブが存在することです。そして、1時間以上かかることもあります。クラッシュした場合に実行したいのは、一貫性のあるデータがあるポイントにジャンプすることです（これは、2つのバッチジョブ間で正しいことを意味します）。時間だけを見ると、常にデータのステータスが正確にわからない場合があります拠点はこの時でした。
しかし、もちろんそれは状況に依存します。自動化されたジョブなどをお持ちでない場合は、1時間ごとのバックアップで十分です。
これを行う理由はいくつかあります。
- データベースシステムは通常ビジーであり、1秒あたり数千のトランザクションを実行している可能性があります。データは、異なるファイルシステム上の複数のファイルに分散する可能性があります。復元後、データベースが一貫性のある（つまり、使用可能な）状態であることを確認するのは簡単ではありません。バックアップソリューションが適切に機能している場合はすばらしいですが、仕事に賭ける前に、このことを確認することをお勧めします。
- 例：誰かが重要なデータを含むテーブルを誤って削除した。ポイント・イン・タイム・リカバリー機能を備えたデータベース・バックアップがある場合は、システム全体を復元する必要なく、データを素早く復元できます。
- データベースが完全復旧モードの場合、SQL Serverのトランザクションログは増大します。トランザクションログのストレージスペースは、トランザクションログがバックアップされている場合にのみ再利用されます。トランザクションログを定期的にバックアップしないと、スペースがなくなるまでファイルシステムがいっぱいになります。この時点で、新しいトランザクションを開始できないため、すべてが即時停止になります。
データベースが1時間でバックアップできる範囲を超えて大きくなると、別のモデルが必要になります。
データベースの完全バックアップではログが切り捨てられますが、「SQL対応」である必要があります。このシナリオでは、SQLサーバーに何をバックアップし、何を切り捨てるかを指示するのはバックアップソフトウェアだからです。
他の人が言及しているように、「完全」復旧モデルのデータベースがある場合、完全なSQL対応のバックアップを作成するまで、そのトランザクションログは無制限に増大します。
リカバリは、バックアップではなく、実際にここで問題です。そしてそれは技術的な決定ではありません、それはビジネス決定！です
ビジネスオーナーがデータベーストランザクションを1時間以上失うことに問題がない場合（これはやり直すのが非常に難しいか不可能かもしれません！）、モデルは機能します。データベース全体をバックアップから復元している間にシステムが何時間もダウンしても問題がなければ、モデルは機能します。
ただし、ビジネスでERPシステムを運用の重要な資産と見なしている場合（すべてではありませんか？））、最大許容回復時間（別名RTO、回復時間目標）を重要なサービスはビジネス上の決定です。
また、ビジネスオーナーまたはシステムの利害関係者は、インシデント（RPO（Recovery Point Objective））で失われるリスクを喜んで受け入れるデータの量を定義する必要があります。
「データが失われる可能性はありません！ERPシステムは24時間年中無休で利用可能でなければなりません！」... -効果的です。このような完全に冗長なノンストップシステムの構築に関連するコストを提示すると、より合理的な数値になります。
重要なのは、トランザクションの損失を回避できれば、ビジネスが数百または数千の失われた労働時間を節約できることです。これは、どの企業でも大幅な節約になり、企業の規模に応じて大きくなります...
誰もがこれに対して素晴らしい反応を示しましたが、もう1つ重要な注記を追加したいと思います... 1、2.
SQL Server復旧モデルの詳細とデータ損失に関するビジネス要件を理解することは、どちらも非常に重要です。ただし、この場合、バックアップ製品がSQL Serverでどのように機能するかを理解することが不可欠です。 （上記のコメントに基づいて、VSSコピーを介してディスクボリュームをバックアップしているようです。これは、SQL Serverのバックアップが追加で必要になる場合と必要とされない場合があることを意味します。）
最近類似の製品を評価した後、質問する必要があるかもしれない重要なポイントのいくつかは次のとおりです。
- 完全復旧のデータベースの特定の時点への復元はどのように実行されますか？
- 完全復旧の新しいデータベースの初期バックアップはどのように処理されますか？
- バックアップ製品は、特定の時点に復元するためにSQL Serverログバックアップを必要としますか？ （私の場合、答えはイエスでした。）
- ストレージインフラストラクチャは、通常のSQL負荷に加えて、VSSコピー/差分のデータのボリュームを（一定の間隔で）処理できますか？
これがお役に立てば幸いです。
私のチームが最近の評価で経験したことは、上記の質問に対するいくつかの非常に興味深い答えを提供しました。 1つ確かなことは、VSSバックアップ製品を使用すると、バックアップがより複雑になることです。
トランザクションログは単なる回復メカニズムではないことを認識してください。適切なログメンテナンスは、データベースの全体的なパフォーマンス（つまり、トランザクションのスループット）においても重要な役割を果たす可能性があります。
ログファイルを頻繁にバックアップすると、次の2つのことが行われます。
- これは、物理ログファイルのVLFカウントを減らします。これは、パフォーマンスに優れています。
- データベースを回復する必要がある場合に備えて、ログバックアップを使用する準備を整えておきます。
- 完全バックアップよりもかなり高速です
1時間ごとに完全バックアップを実行できる場合は、より頻繁なログバックアップからどれほどの利益が得られるかわかりません。結局のところ、完全バックアップでは、完全な復元を確実にするために必要なだけのログもバックアップされます。
一方、アプリが1時間ごとの完全バックアップの間に大量のトランザクションを生成する場合、元の開発者がより詳細なログメンテナンスを提案した理由が説明されている可能性があります。トランザクションが多いと、ログのVLF=カウントが増加する可能性があり、ログが切り捨てられるまでパフォーマンスが低下する可能性があります。これは 'として表されます。クエリがタイムアウトしました 'アプリケーション内のエラー（ハングする直前）。
トランザクションログのメンテナンスに関連する推奨事項は、この記事 で詳しく説明されています。トランザクションログのスループットを向上させるための8つの手順 。さらに、この記事 効果的なデータベースメンテナンスのヒント は、やや恣意的なVLFを対象としたカウント（<200）について言及しています。私。
他の人々はすでにトランスログのバックアップなどの理由のほとんどを述べています。すでにサーバーをバックアップしているのに、これがなぜ良い戦略であるかについては疑問があるようです。
私には、上記にないいくつかの正当な理由が考えられます。サードパーティのアプリがバックアップの取得に失敗した場合、復元できますか？バックアップを復元しようとしましたか？テンプレートから作成したばかりの新しいサーバーについてはどうですか（DRと考えてください）。照合順序が異なるドメイン上の別のサーバーについてはどうですか？またはSQLインスタンス？
サードパーティのアプリが復元する最速の方法ではない場合があることを除いて、私は冗長なバックアップを取ります。サードパーティアプリが保存しているストレージも影響を受けるか、独自の理由で破損している場合があります。
他の多くの人がすでに述べたように、VMまたはストレージのいずれかをバックアップ/スナップショットするためにサードパーティツールを使用している場合は、有効なバックアップがないというリスクが依然としてあります。すべてのサードパーティSQL Serverバックアップを管理するツールは、VSSを使用してSQL Serverを実装および接続します。これは、SQL ServerがデータファイルへのすべてのI/Oを静止するように要求して、一貫したスナップショットを取得できるようにします。そうでない場合は、多くのトランザクションを実行できます。さまざまな状態では、これらのトランザクションをロールフォワードまたはバックロールできるかどうかはリストアでわかりません。
私はすべてのサードパーティと連携したわけではありませんVM /そこにあるストレージスナップショットツールですが、連携したものはシステムデータベースが配置されているストレージのスナップショットを取得できませんでした-SQL Serverはこれらのデータベースを静止できません。それらはすべて、ストリーム方式でこれらのデータベースをバックアップしました。つまり、... BACKUP DATABASEコマンドを発行してから、バックアップファイル自体をスナップします。
さらに、多くの人が言っているように、完全復旧モデルを使用していて、BACKUP LOGステートメントを定期的に発行しない場合、トランザクションログはディスクにスペースがなくなるまで増加し続けます。
あなたが尋ねる必要がある本当の質問、そして私は上でそれを逃したかもしれません...あなたは何度もこれらのバックアップから首尾よく復元しましたか、そしてそれらの復元のデータの一貫性に満足していますか？個人的には、それでも十分ではないかもしれませんが、それでもサイコロが転がっているように感じられます。これは、バックアップとリカバリに関して、DBAが決して得ないことです。