web-dev-qa-db-ja.com

SQL Server可用性グループのデータベースのファイルストリームデータファイルのスペースを再利用するにはどうすればよいですか?

SQL 2016 Entがあります。 3ノードのエディションAG。 AGには、5つのファイルストリームテーブルを持つデータベースがあります。各テーブルは、独自のファイルストリームデータファイルにあります。今日、インデックスを再構築することによってすべてのファイルが1つのファイルストリームデータファイルに保存されていたバグを修正しました。

開発者には、AGがなく、データベースは単純に回復しています。スペースは再利用されました。変更前と変更後は次のようになります。

enter image description here

AGで同じコードを実行すると、すべてのノードは次のようになります。 enter image description here

ファイルは正しいfilestreamデータファイルに移動されましたが、スペースは元のデータファイルから回復されませんでした。

最初はガレージコレクションだと思ったので Paul Randalのブログ投稿 を読みました。ログファイルを縮小してから、ジャンクテーブルを作成し、明示的なトランスを介して大量の行を追加し、ログバックアップとチェックポイントをすべてプライマリノードで実行しました。ログファイルは大きくなり、以前アクティブだったVLFは非アクティブとしてマークされました。

問題を複雑にするために、バックアップはセカンダリノードの完全なコピーのみの\ログバックアップです。

このシナリオでスペースを再利用する正しい方法は何ですか?

編集:彼のブログでアンディの手順を実行した後、スペースが再利用されました。各AGノードは次のようになります:

reclaimed_filestream_file_space

4
sqlpadawan

こちら で説明されているバグに関連して、少し違ったシナリオが発生していると思います。正式に報告された こちら です。

ファイルストリームテーブルが削除された場合(または、再構築されて移動された場合)、データベースがAGにある場合、ガベージコレクションはクリーンアップされません。

バグを回避するには、次のことを行う必要があります。

  • AGからデータベースを削除する
  • ログのバックアップを取る
  • ガベージコレクションを手動で実行する
  • ログバックアップをセカンダリレプリカに適用するWITH NORECOVERY
  • データベースをAGに再結合します(ログバックアップを適用することで、完全な再同期を回避できます)
5
AMtwo