首页 文章

SQL Server文件流 - 删除“速度”

提问于
浏览 次
8

我第一次使用filestream数据类型（SQL Server 2008），当我做一些快速插入/删除时，我遇到了问题 . 基本上，文件实际从文件系统中删除的速度比插入/删除速度慢，即使我手动调用垃圾收集器（据我所知，CHECKPOINT应该调用垃圾收集器） .

下面的代码说明了问题 - 执行大约需要30秒，但是你需要等待几分钟才能从文件系统中删除最后一个文件（当我查找C：\ FSTest \ Files文件夹时）

有没有办法加快垃圾收集器？ （它似乎每10秒大致删除20个文件 - 这让我相信，如果我每秒存储/删除超过2条记录，我最终会最终填满硬盘）

谢谢

CREATE DATABASE FSTest ON PRIMARY
    (NAME = FSTest_data, FILENAME = N'C:\FSTest\FSTest_data.mdf'),
FILEGROUP FSTestFileGroup CONTAINS FILESTREAM
    (NAME = FSTestFiles,FILENAME = N'C:\FSTest\Files')
LOG ON 
    (NAME = 'FSTest_log', FILENAME = N'C:\FSTest\FSTest_log.ldf');
GO

USE FSTest;
GO

CREATE TABLE FSTest (
    Guid UNIQUEIDENTIFIER ROWGUIDCOL NOT NULL UNIQUE DEFAULT NEWSEQUENTIALID(),
    Name VARCHAR (25),
    Data VARBINARY(MAX) FILESTREAM);
GO

ALTER DATABASE FSTest SET RECOVERY SIMPLE;
GO

SET NOCOUNT ON
DECLARE @test int
SET @test=0
WHILE @test<1000 BEGIN
    INSERT INTO FSTest(Name,Data) VALUES('test',CAST('abc' AS VARBINARY(MAX)))
    DELETE FROM FSTest WHERE Name='test'
    CHECKPOINT
    SET @test = @test+1
END

更新：

我尝试了相同的更长时间，插入/删除速度更接近我的需要，并且在执行30分钟后，可观察到相同的情况：文件创建方式更快然后被删除 .

SET NOCOUNT ON
DECLARE @test int
SET @test=0
WHILE @test<100000 BEGIN
    INSERT INTO FSTest(Name,Data) VALUES('test',CAST('abc' AS VARBINARY(MAX)))
    DELETE FROM FSTest WHERE Name='test'
    WAITFOR DELAY '00:00:00:200'
    CHECKPOINT
    SET @test = @test+1
END
sql sql-server filestream

3 回答

  • 1

    经过一些更多的研究（感谢Paul Randal的博客 - 关于文件流和垃圾收集的大量非常详细的信息），一旦删除行并执行检查点，文件就会被放入系统表（Tombstone表）中，然后每个10秒进程（Ghost清理）运行并从该表中删除一些项目（准确地说是20） . 所以基本上我们只限于2次删除/秒，似乎没有办法（尚）改变这种行为 .

    由于我每秒持续4次删除，我需要找到文件流的替代方案 .

    感谢大家的投入 .

    回复于
  • 2

    事情比简单的检查点复杂一点 . 当包含有关文件创建的最后一个包含日志记录的VLF处于非活动状态时，可以删除该文件 . 见FILESTREAM garbage collection .

    回复于
  • 5

    正如Remus所说，如果你使用的是完全恢复模型，那么事情就很复杂了 . 但即使在简单的恢复模型下，您也需要记住CHECKPOINT调用垃圾收集器（GC），但它并不能保证GC会在一次传递中删除所有文件 . GC目前对单个调用中可能进行的操作数量有限制 . 此外，使用FILE_DELETE_ON_CLOSE选项删除文件，因此只要有文件的打开句柄，您仍然可以看到它，即使GC可能已经删除了它 . 这种打开的句柄可以由防病毒程序或其他文件系统过滤器驱动程序保存 .

    最后，除非您对过时文件有太多担心，否则它们最终会被自动数据库检查点删除 . 我相信（尽管相信是这里的关键词），即使它可能有慢的"startup time"，如果您在较长时间内（分钟？）稳定地运行测试，GC将跟上物理删除文件的步伐 .

    如果您关心性能，将文件流容器保留在系统驱动器上可能不是一个好主意 . 有关文件流性能提示，请参阅here .

    回复于

相关问题