Maxtransfersizeが圧縮用に指定されたSQL TDEデータベースでのバックアップの失敗
最近、私の会社は2016年にアップグレードし、すべてのデータベースでTDEを有効にしました。さらに、高可用性サーバーに複製された本番データベースがあります。
私たちのバックアップはHAサーバーから取得され、バックアップを圧縮するためにmaxtransfersizeハックを使用します。
すべてのバックアップが成功し、1つを保存します。監視ソフトウェアによって次のエラーが出力されます。
エラー：3624、重大度：20、状態：1。
システムアサーションチェックが失敗しました。詳細については、SQL Serverエラーログを確認してください。通常、アサーションの失敗は、ソフトウェアのバグまたはデータの破損が原因で発生します。データベースの破損を確認するには、DBCC CHECKDBの実行を検討してください。セットアップ中にダンプをマイクロソフトに送信することに同意した場合、ミニダンプがマイクロソフトに送信されます。更新は、最新のサービスパックまたはテクニカルサポートのホットフィックスでMicrosoftから入手できる場合があります。
サーバーログには、障害発生時の詳細がいくつかあります。
入力バッファ70バイト
プロセスID：1884
SPID：200
式：m_inputQueue.head（）== null
場所：backuplog.cpp 1564
これは私のバックアップコマンドです：
backup database @DBName to disk = @Path
with noformat, noinit, name=@Name, skip, norewind, nounload,
compression, stats=10, copy_only, MAXTRANSFERSIZE = 65537
誰かが以前に同様の問題に遭遇したことがありますか？
Erik Darlingによる TDE and Backup Compression：Together At Last のチャートから選択して、少しランダムな方法ではありますが、maxtransfersizeにいくつかの異なる値を使用しました。
TDEには機密データが含まれているため、TDEを使用しないという選択肢はありません。ドライブスペースがある場合は、圧縮しないことも選択肢の1つです。
昼食から戻ったとき、maxtransfersizeが指定されていないときにバックアップが正常に完了しました。午前中にエラーが発生し、1つの圧縮されていないバックアップが成功したことを確認すると、ログファイルに到達したときにエラーが発生しているように見えます。
発生しているエラーは、vlfをすべて消費したかどうかの健全性チェック（と思われます）であるため、エラーが発生します。チェックに失敗した理由はわかりません。 – Sean Gallardy2017年1月3日
ヒントをありがとう。 VLFの数が私の問題の原因でした。この特定のデータベースにはCDCの問題があり、バックアップ時にトランザクションログが消去されていませんでした。 300 GBを超えていました。 CDCを無効にすると、ログをフラッシュして、より適切な成長計画を立てることができました。圧縮されたバックアップが再び機能します。