May 20, 2010 at 7:03 am
To enable the FILESTREAM filegroups, you must set READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION to OFF.
Why?
Abhijit - http://abhijitmore.wordpress.com
May 22, 2010 at 6:27 am
@PaulRandal writes a excellent article..
http://msdn.microsoft.com/en-us/library/cc949109.aspx
Isolation Semantics
The isolation semantics are governed by database engine transaction isolation levels. When FILESTREAM data is accessed through the Win32 APIs, only the read-committed isolation level is supported. Transact-SQL access also allows the repeatable-read and serializable isolation levels. Furthermore, using Transact-SQL access, dirty reads are permitted through the read-uncommitted isolation level, or the NOLOCK query hint, but such access will not show in-flight updates of FILESTREAM data.
The file system access open operations do not wait for any locks. Instead, the open operations fail immediately if they cannot access the data because of transaction isolation. The streaming API calls fail with ERROR_SHARING_VIOLATION if the open operation cannot continue because of isolation violation.
May 30, 2010 at 1:03 am
The 'WHY' part is still a mystery and one possible reason could be the way SNAPSHOT isolation works. Under snapshot isolation level, your transaction should be able to read a snapshot of the database as of the time when the transaction starts. For the NON-FILESTREAM data, SQL Server implements this by keeping versions of the data in tempdb database.
When it comes to the FILESTREAM data, which is stored in the NTFS - not in the table - and which may be huge blob files, this may not be a trivial task to implement a similar versioning mechanism.
That '**could be**' be the reason why SNAPSHOT isolation is not supported with FILESTREAM.
.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply