none
FileTable and block level copies

    Frage

  • Since I don't currently have a SAN to test this on, I'm wondering what effect SAN level block copies have on FileTable.

    If I have a FileTable created and someone enables block level copies on the volume that contains the files stored in the FileTable, but not on the database that the FileTable is part of, what would I see on the other system if I had a backup of the database restored to that secondary system?

    a. Would I have entries being populated into the FileTable on the secondary system due to the block copy?
    b. Would the FileTable data remain static while the block copy changes the contents of the folder structure that the FileTable is built on?

    Before anyone asks or writes a bunch of comments as to why you would want to do that, I'm not looking for whether or not you should do this.  I already know this is a really bad idea and a really bad configuration.  I'm not looking to have a debate on system configuration, managing systems, or how you should architect something with a FileTable involved.

    I'm trying to figure out what kind of effect it would have.  More specifically, will the SAN level block copy trigger the write interception by SQL Server in the same way that a write through the Windows file handling API will?


    Mike Hotek mhotek@mssqlserver.com

    Mittwoch, 11. April 2012 22:29
    Moderator

Antworten

  • Hi Mike,

    I think you need to do a test on SAN system.


    Best Regards,
    Peja

    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Als Antwort markiert Peja Tao Mittwoch, 18. April 2012 06:50
    Freitag, 13. April 2012 03:12

Alle Antworten

  • Hi Mike,

    I think you need to do a test on SAN system.


    Best Regards,
    Peja

    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Als Antwort markiert Peja Tao Mittwoch, 18. April 2012 06:50
    Freitag, 13. April 2012 03:12
  • Mike,

    As requested, not discussing the sense/non-sense of attempting this. The answer is that FileTable storage is actually FILESTREAM storage. If you start dumping files in the FILESTREAM location, as defined by the FILESTREAM database file location, DBCC CHECKDB will treat this as a database corruption. Also you wouldn't be able to make any sense of the files, because the filenames shown by FileTables are not the names of the files in the NTFS file system. What's actually stored in NTFS is the LSN of the transaction that created/modified them.

    Let us know if you need some alternatives.

    SA.

    Sonntag, 22. April 2012 20:20