SQLskillsは、基本的な知識を持つレコードを投稿するための新しいイニシアチブを開始しました。これをSQL101と呼びました。 よく見られるように、間違って行われていること、誤って使用されている技術、深刻な問題につながる多くの誤解について書きます。 このシリーズのすべてのエントリを検索する場合は、リンクSQLskills.com/help/SQL101 （英語）をご覧ください。
管理に潜む可能性のあるものの1つは、完全復旧モデルから別のモデルに一時的に切り替えることの影響です。 この記事では、3つの復旧モデルと、完全なモデルから単純なモデルへ、および完全なモデルから一括ログのあるモデルへの切り替え時に発生する可能性のある問題について簡単に説明します。
復旧モデル
次の3つの復旧モデルがあります。
- 完全復旧モデル（デフォルトで最も頻繁に使用されます）
- データベース内のすべての変更は完全に記録されます。 一部の操作はより少ないログエントリで書き込まれるため、これは各変更に個別のログエントリがあることを意味しませんが、操作の完全な効果がログに記録されます（たとえば、TRUNCATE TABLE操作-こちらの完全な説明を参照してください （英語））。
- トランザクションログは、トランザクションログがバックアップされるまでクリアされません（つまり、その一部は再利用できません）（詳細はこちら （英語）をご覧ください）。
- データベースが完全復旧モデルにある（および最後のバックアップが作成されてからデータベースにあった）場合、すべての復旧オプションを使用できます。
- データベース内のすべての変更は完全に記録されます。 一部の操作はより少ないログエントリで書き込まれるため、これは各変更に個別のログエントリがあることを意味しませんが、操作の完全な効果がログに記録されます（たとえば、TRUNCATE TABLE操作-こちらの完全な説明を参照してください （英語））。
- 不完全なログ復旧モデル
- 一部の変更（インデックスの再構築やバッチ読み込みなど、標準のINSERT / UPDATE / DELETEではない）は最小限に記録できるため、ログエントリの数が減り、これらの操作中にトランザクションログが大きくなりすぎません。 これにより、後続のトランザクションログバックアップのサイズは変更されないことに注意してください。 オペレーションのジャーナルを最小限にする方法の詳細な手順については、満たす必要のあるすべての条件について説明している「データロードパフォーマンスガイド （英語） 」を参照してください。
- トランザクションログのバックアップが作成されるまで、トランザクションログはクリアされません（つまり、その一部が再利用可能になりません）（完全復旧モデルと同じ方法で）。
- 不完全なログのある復旧モデルを使用すると、最小限のログ操作に関連するパフォーマンスの改善と引き換えに、一部の復旧オプション（ポイントインタイムリカバリと最終フラグメントのバックアップ）が失われます。
- 一部の変更（インデックスの再構築やバッチ読み込みなど、標準のINSERT / UPDATE / DELETEではない）は最小限に記録できるため、ログエントリの数が減り、これらの操作中にトランザクションログが大きくなりすぎません。 これにより、後続のトランザクションログバックアップのサイズは変更されないことに注意してください。 オペレーションのジャーナルを最小限にする方法の詳細な手順については、満たす必要のあるすべての条件について説明している「データロードパフォーマンスガイド （英語） 」を参照してください。
- 単純復旧モデル
- 一部の変更は最小限のログで記録できます（ログが不完全な復旧モデルとまったく同じです）。
- トランザクションログは、チェックポイント作成操作（CHECKPOINT）が実行されるまでクリアされません-通常は自動的に実行されます。
- トランザクションログをバックアップすることはできないため、回復オプションの数は最も限られています。
- 一部の変更は最小限のログで記録できます（ログが不完全な復旧モデルとまったく同じです）。
ほとんどの人は完全復旧モデルを使用して、トランザクションログをバックアップし、可能なすべての復旧オプションを購入できます。 データベースで完全復旧モデルまたはログの不完全なモデルを使用する場合に覚えておくべき主なこと-トランザクションログを定期的にバックアップする必要があります。そうしないと、トランザクションログが無期限に大きくなります。
状況によっては、単純な復旧モデルが望ましい場合があります。ある時点で復元し、トランザクションログバックアップを使用した復旧中の損失を最小限に抑える必要がない場合。 例としては、テストに使用されるデータベースがあります。これは1日に1回補充され、変更が失われたり、すぐに繰り返される可能性があります。
単純な復旧モデルに切り替える
多くの場合、バッチダウンロードやインデックスの再構築時にトランザクションログの増加を避けるために単純な復旧モデルに切り替えると聞いていますが、実際に必要なのは不完全なロギングのモデルです。 また、一部の通常の操作では*復旧モデルが単純である必要があるという永続的な神話もあります-それは（ハハ）真実ではありません。
単純な復旧モデルに切り替えると、トランザクションログバックアップのチェーンが切断され、トランザクションログバックアップをさらに作成する前に、完全バックアップまたは差分バックアップを作成する必要があります。
さらに、このようなスイッチでは、障害が発生した場合の機能が制限されます。これは、回復可能な完全バックアップが1つしかなく、最後に作成したものだけだからです。 それについて考えてください-回復のための可能なオプションは次のようになります：
- 単純復旧モデルへの切り替え後の完全バックアップ、この完全後の差分バックアップ（差分バックアップを使用する場合）、および単純モデルから切り替えた後のトランザクションログバックアップ。 または
- シンプルリカバリモデルに切り替える前の最新の完全バックアップと、シンプルプラストランザクションログバックアップから切り替えた後の最新の差分バックアップ。
この最新の完全バックアップ（単純復旧モデルへの切り替え前後）が破損している場合、復旧できません。 以前の完全バックアップを取得することはできません。単純な復旧モデルに切り替えるまでしか復旧できず、その後は復旧できないためです。 それはできると思いますが、単純な復旧モデルに切り替えた瞬間からすべての作業が失われます。
単純な復旧モデルへの切り替えは、自動または定期的に行うことではありません。 一時的にこれを行うことができるのは、トランザクションログがいっぱいで、単純な復旧モデルに切り替える場合を除いて、トランザクションログをクリアする機会が1回もない場合（たとえば、バックアップや別のログファイルの追加ができない場合）そして、チェックポイント作成操作を強制的に呼び出します。 この場合、データベースを操作できるようにするための抜本的な対策を講じており、現在の限られた回復オプションを完全に認識しています。
この緊急事態が発生するまで、継続的に単純な復旧モデルを使用するか、決して切り替えないでください。
部分的にログに記録された復旧モデルへの切り替え
トランザクションログの増大を防ぐため、インデックスのロードまたはメンテナンス中に不完全なログに切り替えることは許容されます。 実際、完全復旧モデルと不完全なログ機能を備えたモデルとの間で切り替えを行っても、トランザクションログのバックアップチェーンにはまったく影響がありません。 また、このような切り替えはログ配布またはレプリケーションに影響しませんが、データベースミラーリングまたはAlwaysOn可用性グループを使用する場合、完全復旧モデルを必要とするため、完全復旧モデルから切り替えることはできません。
ただし、ログが不完全な復旧モデルを使用すると、障害からの復旧に問題が発生する可能性があります。そのため、その機能のためにそのような復旧モデルを使用したい場合でも、一部の復旧機能を失うリスクを回避するために、その使用を拒否できます。
問題1：最小ログ記録操作を含むトランザクションログバックアップは、Point-in-Timeリカバリでは使用できません。 つまり、restoreコマンドのWITH STOPAT句で指定する時間は、このようなバックアップに属する時間にはなりません。 このようなバックアップをリカバリチェーンの一部として使用し、それ以降はいつでも停止できます（もちろん、このログが最小限のログ操作を含む別のバックアップを参照する場合を除きます）。ただし、このバックアップに属する時間中は停止できません。
問題2：データファイルにアクセスできないか破損しているときに、トランザクションログの最後のスケジュールバックアップ以降に作成されたすべてのトランザクションログエントリをキャプチャするために最終フラグメントをバックアップする必要があり、バックアップする必要があるトランザクションログレコードに最小限が含まれている場合ログに記録された操作、このようなバックアップを作成すると、SQL Server 2008 R2より前のバージョンでエラーが表示され、SQL Server 2008 R2のバージョンからは正常に作成されたバックアップが表示されますcat 破損すると、データベースが破損します。
したがって、大規模な操作時にトランザクションログの場所を保存するために不完全なログを使用するモデルを使用する場合は、a）最後と次のトランザクションログバックアップの間の時点で回復する可能性がないことを確認する必要があります。 ; b）障害が発生した場合に繰り返すことのできないデータベースの変更はなく、最終フラグメントの正しいバックアップコピーを作成することはできません。
完全なモデルとロギングが不完全なモデルの間で復旧モデルを切り替えることは、思ったほど安全ではない場合があります。
まとめ
担当するデータベースごとに、復旧モデルを変更することの意味を理解してください。そのような変更は、障害発生時に復旧の問題につながる可能性があるためです。