ミラーリングを使用した単純な回復モード-それは可能ですか？
（通常、「私は本当のDBAではありませんが、どういうわけかこれを処理する必要があります」というディスクラマーがここにあります）
完全復旧モデルを実際に必要としない完全復旧モデルを備えたデータベースがあります。それだけが必要です。
最初にいくつかのコンテキスト：問題のデータベースには、毎晩のジョブスケジューラによって使用されるいくつかのデータが含まれています（サーバー接続パラメーター、キューの状態など）。データベース全体を最初から再作成する方がはるかに簡単であるため、このデータは、ポイントインタイムリカバリ、さらにはバックアップについても保証しません。同時に、ミラーリングが有効になっている本番データベースであるため、なんらかの理由でDRサーバーに切り替えた場合でもオンラインのままで利用できます。
つまり、Catch-22の状況にあります。シンプルに切り替えて自動フェイルオーバーの設定を失う（これは、私たちにとって必要なことです）か、フルを維持して、実際には不要な定期的なログバックアップをとります。それ以外の場合、トランザクションログファイルは増大し続けます（この場合も、実際には必要ないデータが含まれます）。
私が思いつく唯一の解決策は、すべてのトランザクションログデータを破棄する自動ジョブをスケジュールすることですが、これを処理するより健全な方法があるかどうか疑問に思っていました。
ミラーリングでは、トランザクションログを使用して、ミラーサイトですべてをやり直します。単純な復旧モデルでは、トランザクションログは事実上一時的なものであり、クラッシュの復旧中にデータベースの整合性を維持するために、元に戻す/やり直しのために十分な情報のみがログに保持されます。したがって、データベースミラーリングはサポートされていないため、シンプルリカバリモデルでは使用できません。
通常はお勧めしませんが、特定の状況ではこれでうまくいきます。 NULデバイスにログのバックアップを取ることができます。 NULデバイスは、書き込まれたすべてのデータを破棄するオペレーティングシステムのデバイスファイルですが、書き込み操作が成功したことを報告します。これは基本的なTSQL構文です（このデバイスのNULには1 Lしかないことに注意してください。NULLと混同しないでください）。
Backup log [TestDatabase] to Disk = 'NUL'
これをSQLエージェントジョブに入れ、それに従ってスケジュールすることができます。これを読んでいる人にとっては、これは「ポイントインタイム」リカバリを破壊することになるので、注意が必要です。一般的にはお勧めしません。