問題タブ [recoverymodel]

リカバリ/バックアップに関するBooksOnlineをいくつか読んだのですが、1つのばかげた質問ですが、バックアップ操作自体に完全データベースバックアップ/完全リカバリモデルを使用すると、ソースデータベースサーバーへの追加のトランザクションログが生成されますか？完全復旧操作により、宛先データベースへの追加のトランザクションログが生成されますか？

SQL Server の復旧と一括復旧モードについて 2 つの混乱があります。

1. リカバリ プロセス自体がトランザクション ログを生成するかどうか (ここでログとは、リカバリ プロセスによって生成されたログであり、通常のデータベース DML/DDL 操作によって生成されたものではないことを意味します)。なんで？

2. 一括復旧モードで、A または B の理解が正しいかどうか (どちらも正しくない場合は、訂正してください。ここに 2 つの異なる理解があるため、混乱します)

A. 製品データベースでの通常の DML/DLL 一括操作 (復旧操作ではない) では、最小限の量のログが生成されます。B. 製品データベースでの通常の DML/DLL 一括操作では、通常どおり大量のログが生成されますが (非一括ログ リカバリ モードと同じ)、リカバリ プロセスはトランザクション ログ内の一括操作をリカバリの単位として扱います。回復プロセス自体の最小限のログ。

よろしく、ジョージ

データベースの復旧モデルは tempdb.mdf のサイズに影響しますか?

多くの処理と一括挿入を伴うデータベースがあります。tempdb ファイルが非常に大きなサイズ (70 GB 以上) になるという問題が発生しています。問題のデータベースは完全復旧に設定されています。単純復旧 (tempdb ではないすべてのトランザクションを含むデータベース上) に変更すると、これらの大規模な挿入や一括読み込みで tempdb を使用できなくなりますか?

当社の製品には、カスタム アプリケーションのセキュリティ情報を含むいくつかのテーブルが含まれています。これらの securityinfo テーブルには、場合によってはかなりの量の行 (あるケースでは 1,300 万行) が含まれる可能性があり、テーブルはクエリを高速化するために存在し、最初から再構築できる可能性がありますが、これは時間/処理能力などの点でコストがかかります。

アプリケーションが設計されている方法では、(プログラムの実行中に) セキュリティ セクションのレコードを削除してから新しいレコードを挿入する方が、保持/更新するレコードを特定して、まだ存在しないレコードを挿入するよりも効率的です。 .

残念ながら、データベース復旧モデルがフルに設定されている場合、このプロセスによって大量のトランザクション ログが生成される可能性があります。

SQL 2005+ で、復旧モデルがフルのデータベースにログに記録されていないテーブル (単純な復旧モード) を持つことは可能ですか?

復旧時に Web アプリケーション/データベースが最初に起動するときに、securityinfo テーブルを再構築できます。

または、単純な復旧モデルを備えた並列データベースを使用することが最善の解決策です。

乾杯ティム

このような状況でデータベースを復元したいとします。一方ではバックアップがなく、他方ではすべての変更がログ ファイルに保存されます。ログ ファイルから特定の日時にデータベースを復元できますか?

完全復旧モードの運用データベースがあります。

このデータベースは別のサーバーに複製されています。(トランザクション複製)

金曜日の夜には、インデックスの再構築を含むメンテナンス ジョブが実行されます。

このメンテナンス ジョブの後、トランザクション ログのバックアップ ファイルは巨大になります。

そのため、メンテナンス ジョブの開始前に復旧モデルを単純に変更し、メンテナンス ジョブの後に完全に戻すことを考えています。

この方法はレプリケーションに影響しますか?

レプリケーションはどの復旧モデルでも機能することはわかっていますが、復旧モデルを完全から単純に、次に単純から完全に切り替えると、レプリケーションに影響があるかどうかはわかりません。

ヘルプ/ガイダンスは大歓迎です。ありがとう。