Sys.databasesをチェックして、LOGバックアップが必要なデータベースを見つけました。かなりの数のlog_reuse_wait_desc=LOG_BACKUP
意味、これらのデータベースでLOGバックアップを実行するように設定したJOBは、実際にはLOGバックアップファイルを作成していません。
いくつかの検索を行った後、データベースモードをFULLからSIMPLEに変更してから、FULLに戻してリセットすることが推奨されていました。これを行った後も、LOGバックアップを正常に実行することができません。
私はSQL Server 2005を使用していて、ここにあるバックアップのola hallengren方法 http://ola.hallengren.com/sql-server-backup.html を使用しています。
ありがとうございました
更新:わかりました!
Ola hallengrenスクリプトは、ログ配布の役割を確認し、いずれかで現在のデータベースが見つかった場合はログのバックアップをスキップするため
msdb.dbo.log_shipping_primary_databases
または
msdb.dbo.log_shipping_secondary_databases
また、最近使用しているデータベースDIDには、適切にクリーンアップされていない古いログ配布エントリがあるため、このスクリプトはLOGバックアップを作成できませんでした。これですべてがクリーンアップされました。 、行ってよさそうです。
チャイムをしてくれたすべての人に感謝します! -ジョシュ
データベースの復旧モデルを完全から単純に変更し、再び完全に戻したため、データベースは「疑似単純」モードで実行されています。ログのバックアップが意味のある作業を行う前に、データベースのバックアップを取る必要があります。詳細については here を参照してください。要約する:
ログバックアップが復元に役立つためには、データベースバックアップと、そのデータベースバックアップ以降のすべてのLSNをカバーするログバックアップが必要です。
復旧モデルをシンプルに変更すると、SQL Serverはログバックアップチェーンを解除します。その後、フルに戻すと、データベースバックアップを実行して新しいログバックアップチェーンが作成されるまで、データベースはシンプルモードのように動作し続けます。これは、疑似単純モードと呼ばれます。これがこの方法で実装される理由は、データベースバックアップで始まるログバックアップチェーンの一部ではないために、回復に使用できないログバックアップを誰かが取得できないようにするためです。
データベースのバックアップが作成されると、新しいログバックアップチェーンが開始され、データベースは完全復旧モデルで機能し始めます。この時点で、ログのバックアップは機能するはずです。または、少なくとも別の理由で説明的なエラーで失敗します。
これが、ログバックアップが現在機能していない理由の少なくとも1つです。