某所で調べてブログに書きますといったまま、手を付けていませんでした。
勉強会も終わって一息つけたので、調べてみたいと思います。
■File Table に格納できるファイルの上限
File Table の構造ですが以下のようになっています。
ファイルに関しては、 [varbinary (max) filestream] として格納がされるようです。
FILESTREAM ストレージに関しては varbinary (max) の上限の 2 GB ではなく、ファイルシステムのボリュームサイズが上限となります。
FILESTREAM ストレージは、データを BLOB としてファイル システムに格納する varbinary(max) 列として実装されます。BLOB のサイズはファイル システムのボリューム サイズによってのみ制限されます。ファイル システムに格納される BLOB には、標準の varbinary(max) の制限 (ファイル サイズ 2 GB) は適用されません。
■ファイル連携のテスト
それでは可用性グループが設定されている環境で大容量のファイルの連携テストを実施してみたいと思います。
今回は 2.7 GB の VHD をファイルテーブルに格納してテストを実施しています。
こちらが、プライマリの FileSTable の FILESTREAM を格納しているディレクトリの内容になります。
2.7GB のファイルが格納されているのが確認できますね。
セカンダリにもファイルが連携されているのが確認できます。
File Table のデータを INSERT 中にセカンダリが停止してしまった場合をテストしてみたところ、セカンダリ上へのファイルの保存のリトライもされるようでした。
# FILESTREAM のデータ格納はトランザクションログベースではないため、ファイルを最初からコピーしなおしているようです。
■File Table にファイル格納時のログの状況について
2.7 GB のファイルを File Table に格納した時のトランザクションログの状況を見てみたいと思います。
File Stream にデータを INSERT する際には、[LOP_FS_DOWNLEVEL_OP] という操作でログレコードが出力されるようです。
この時のログですが、2.7 GB のファイルを格納するからといって、2.7 GB 相当のログが書き込まれるということはないようですね。
# いままで、FILESTREAM をきちんと使っていなかったので、いまになって初めて知りました…。
こちらが Filet Table にデータを格納した際のログレコードの合計サイズなのですが、 3.2 MB 程度のログとなっています。
■テスト時の注意
今回は以下のようなクエリで File Table にファイルをアップロードしていました。
INSERT INTO FileTable1(name,file_stream) |
OPENROWSET でファイルを開いて INSERT しているため、一時的にデータがメモリ上に展開されるようで、データを INSERT している際には、Database Page (データキャッシュ) が大量に使用されます。
こちらが、INSERT している際の、Database Page の状態になります。
347,984 ページ × 8KB = 2,783,872 MB になりますので、ファイル分のメモリが消費されているようです。
AlwaysOn を使用して、大容量のファイルを連携することはできそうですね。
メモリの使用量は十分に考慮する必要がありそうですが。