SQL Server誤區30日談 第18天 有關FileStream的存儲，渣滓收受接管和其它。本站提示廣大學習愛好者：（SQL Server誤區30日談 第18天 有關FileStream的存儲，渣滓收受接管和其它）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server誤區30日談 第18天 有關FileStream的存儲，渣滓收受接管和其它正文
誤區 #18:以下多個有關FileStream的誤區
全體毛病
18 a)FileStream數據可以在長途存儲
不克不及，因為FileStream數據容器(指的是寄存FileStream文件的NTFS文件夾，誣捏出來的術語)必需像數據文件或日記文件那樣相符當地存儲戰略-也就是說，這個數據容器必需放在關於運轉SQL Server的Windows Server是當地存儲（譯者注：也就是在‘盤算機'裡能看到的存儲，DAC固然是了，其實SAN這類不直接銜接辦事器的也算是）拜訪FileStream數據只需客戶端銜接到了SQL Server辦事器並獲得呼應的事務高低文後，便可以經由過程UNC途徑停止拜訪了。
18 b)FileStream的數據容器可以嵌套
不克不及，關於統一個數據庫的兩個分歧的FileStream容器能夠在統一個目次下，然則卻不克不及嵌套。而關於分歧數據庫的FileStream容器沒法在統一個目次下。我的一篇博文有一段代碼能解釋這一點:Misconceptions around FILESTREAM storage。
18 c)關於FileStream的更新可以部門更新
關於任何FileStream的更新都邑招致創立一個全新的FileStream文件,這個操作會被日記原本來本的記載上去。這也就是為何FileStream不克不及被用於數據庫鏡像。這麼多半據假如用於鏡像的話那效果的確弗成想象，只能願望將來的SQL Server版本可以修正這類機制以許可部門更新。
18 d)FileStream會在不須要的時刻連忙被渣滓收受接管
毛病。FileStream數據會在不再須要而且到了下一個Checkpoint的時刻停止渣滓收受接管。這點其實不是那末直接以致於許多人對FileStream的收受接管機制存在誤區。
18 f)FileStream寄存的目次和文件名是隨機獲得
其實否則，FileStream的文件名其實代表的是創立其操尴尬刁難應LSN號。表和列的GUID目次名是可以在體系表中獲得到。
我上面兩篇博文對此有了更具體的說明:
FILESTREAM directory structure 說明了若何從一個FileStream地點行來得知其稱號
FILESTREAM directory structure - where do the GUIDs come from? 可以望文生義的曉得這篇文章所講述的內容:-)
