誤區(qū) #18:如下多個有關(guān)FileStream的誤區(qū)

全部錯誤

18 a)FileStream數(shù)據(jù)可以在遠程存儲

    不能，由于FileStream數(shù)據(jù)容器(指的是存放FileStream文件的NTFS文件夾，杜撰出來的術(shù)語)必須像數(shù)據(jù)文件或日志文件那樣符合本地存儲策略-也就是說，這個數(shù)據(jù)容器必須放在對于運行SQL Server的Windows Server是本地存儲（譯者注：也就是在‘計算機'里能看到的存儲，DAC當然是了，其實SAN這類不直接連接服務(wù)器的也算是）訪問FileStream數(shù)據(jù)只要客戶端連接到了SQL Server服務(wù)器并獲取響應(yīng)的事務(wù)上下文后，就可以通過UNC路徑進行訪問了。

18 b)FileStream的數(shù)據(jù)容器可以嵌套

    不能，對于同一個數(shù)據(jù)庫的兩個不同的FileStream容器可能在同一個目錄下，但是卻不能嵌套。而對于不同數(shù)據(jù)庫的FileStream容器無法在同一個目錄下。我的一篇博文有一段代碼能說明這一點:Misconceptions around FILESTREAM storage。

18 c)對于FileStream的更新可以部分更新

    對于任何FileStream的更新都會導(dǎo)致創(chuàng)建一個全新的FileStream文件,這個操作會被日志原原本本的記錄下來。這也就是為什么FileStream不能被用于數(shù)據(jù)庫鏡像。這么多數(shù)據(jù)如果用于鏡像的話那后果簡直不可想象，只能希望未來的SQL Server版本可以修改這種機制以允許部分更新。

18 d)FileStream會在不需要的時候立刻被垃圾回收

    錯誤。FileStream數(shù)據(jù)會在不再需要并且到了下一個Checkpoint的時候進行垃圾回收。這點并不是那么直接以至于很多人對FileStream的回收機制存在誤區(qū)。

18 f)FileStream存放的目錄以及文件名是隨機取得

    其實不然，F(xiàn)ileStream的文件名其實代表的是創(chuàng)建其操作對應(yīng)LSN號。表和列的GUID目錄名是可以在系統(tǒng)表中獲取到。

我下面兩篇博文對此有了更詳細的解釋:

• FILESTREAM directory structure 解釋了如何從一個FileStream所在行來得知其名稱

• FILESTREAM directory structure - where do the GUIDs come from? 可以望文生義的知道這篇文章所講述的內(nèi)容:-)