ログ配布の制限

Question

SQL 2005では、ではなく、は、ログ配布が有効な（フル回復モデルで実行される）データベースに対して行うべきことは何ですか？

別のトランザクションログバックアップを別の場所にスケジュールすると、完全なログチェーンがセカンダリサーバーに到達しなくなるため、ログ配布が中断されます。

また、ログ切り捨てテーブルは（Sql 2000以降）ログ収集でもOKです。

避けるべき他の活動/コマンドはありますか？

編集：データベース縮退またはログ縮小OKですか？

Answer 1

あなたは正しいですか？自然なログシーケンスを確実に維持するために、Log Shipping構成以外のトランザクションログバックアップは定義しないでください。

たとえば、本番データベースでいくつかのライブ保守を実行しているため、Ad-Hocトランザクションのログバックアップを実行したくない場合は、ログシッピングがトランザクションを実行するために使用するSQL Serverジョブを呼び出すことができますログバックアップ。通常はLS_Backupと呼ばれます。これにより、LSNが維持されます。

私の理解では、この出荷可能な技術を使用することで、出荷されるデータベースの運用上の機能は制限されていません。合併症を引き起こす可能性があります

いくつかの点：

暗号化

あなたが別のサーバーへの出荷を記録し、SQL Serverのネイティブ暗号化を使用しているしているなら、あなたは、ログの中に暗号化されたデータにアクセスすることはできませんSQL Serverが同じサービスマスタキーを使用している場合を除き、出荷されたデータベース。

アセンブリ

あなたが信頼できるプロパティを有効にすることができないとしてあなたは、データベースを出荷し、ログの中に署名したアセンブリへのアクセス問題が発生することがあります。

権限

あなたはその後、SQL Serverのログインはログインが自動的に正しくマッピングするためには、ソースサーバーからのものと同じSIDを持っている必要がありますログ配布データベースへの読み取りアクセスを提供する場合。

これが役に立ちます。乾杯。

Answer 2

データベース/ログの成長/縮小は問題ありません。出荷され、スタンバイも拡大/縮小されます。私はそれを承知している唯一のものは壊れるものがあります：TRUNCATE_ONLY

WITH

バックアップログは、プライマリ・データベースのオフライン取るリカバリーモード

を変更する（これについてはよく分からないが、それを試したことがありません）

他のすべては問題ありませんが、大量のREINDEXESを実行すると、大規模なデータベースで扱いにくい非常に大きなログを作成できます。