SQL Server 2008的文件流位置

1. 不能。Afaik文件流数据存储在本地,SQL将拒绝从/向UNC读/写。
2. 完整备份将包含整个文件流数据。难以驾驭?无疑是一个非常严重的挑战。

我的问题是,您希望从文件流中提取什么好处?通常的好处来自BLOB与数据库操作的集成,同时保持基于win32文件句柄的操作的可用性:

即使文件流技术 很多吸引人的特征,可能不是 做最理想的选择 情况。如前所述, blob数据的大小和访问 模式是最重要的 决定是否存储时的因素 BLOB数据完全在 数据库或使用文件流。

大小影响以下内容:

• BLOB数据的效率 可以使用任一存储访问 机制。如前所述, 大blob数据的流访问是 使用文件流效率更高,但是 部分更新是(可能很多) 更慢的。
• 备份的效率 组合结构化和BLOB数据 使用任一存储机制。一 结合了SQL Server的备份 数据库文件和大量 文件流文件将比 仅备份SQL Server数据库 总大小相等的文件。 这是因为额外的开销 备份每个NTFS文件(每个 文件流数据值)。此开销 当 文件流文件较小(如 时间开销变得更大 备份总时间的百分比 每MB数据)。

从纯性能的角度来看,在文件系统级别上可以执行许多步骤来提高性能。您当前的问题是什么?为什么您的系统吞吐量受介质大小的影响?这意味着您在某个地方有一个阻塞点,可能是一个目录枚举,或者其他一些障碍,这些障碍会导致您根据媒体大小来调整响应时间。你对媒体的访问应该是O(1),也许是O(logn),但绝对不是O(n)。

我建议你看一下SQL白皮书 FILESTREAM Storage in SQL Server 2008 ,在这里我找到了关于用例的引用。

我不得不不同意@remusrusanu在UNC问题上的看法。尽管如此,@remusrusanu在 为什么 您将选择使用文件流。

无论如何,您可以将UNC用于文件流——否则它不会有太大的用处。目前,我构建了一个站点,该站点使用Web场中服务器的UNC功能从SQL文件流读取文件。

关于使用UNC文件流的一些要点…

• SQL Server禁止访问UNC。世界跆拳道联盟?文件流的重点是合并文件系统的优点(良好的流)和SQL Server的优点(良好的元数据、事务和查询能力)。SQL如何确保文件访问是事务性的?您必须打开事务,并在事务内部向SQL Server请求文件句柄。

• 换句话说,您不能从Windows资源管理器导航到文件流UNC。

• 如果您将二进制文件存储在SQL Server中,那么通常情况下~1.2MB是您应该优先选择FILESTREAM而不是varbinary的断点。 Here MS建议1 MB,但在研究论文中还有一篇我目前找不到的文章建议1.2是盈亏平衡点。

• 启用UNC访问需要分布式事务,因此SQL Server和UNC路径的使用者都需要启用分布式事务。

下面是一个代码段,演示如何检索文件流的句柄。有一个 大告诫 : 此代码段中的事务未关闭。您将需要读取二进制文件,然后关闭事务。 离开未结交易显然是一个禁忌。

    public FileStream GetStream(string FilePath){
        FileStream FStream = null;

        Conn = new SqlConnection( MyConnectionStringHere );
        Conn.Open();
        txn = Conn.BeginTransaction();

        using (SqlCommand cmd = new SqlCommand("SELECT GET_FILESTREAM_TRANSACTION_CONTEXT()", Conn, txn)){

            Object obj = cmd.ExecuteScalar();
            TransContext = (byte[])obj;
        }

        SafeFileHandle SHandle =  NativeSqlClient.GetSqlFilestreamHandle (FilePath, NativeSqlClient.DesiredAccess.Read, TransContext);
        FStream = new FileStream(SHandle, FileAccess.Read);

        return FStream;
    }