3

In SQL Server the default isolation level is READ_COMMITTED but in SQL Azure the default level is READ_COMMITTED_SNAPSHOT.

Suppose I change the default level in my SQL Azure server to READ_COMMITTED_SNAPSHOT (using SET TRANSACTION ISOLATION LEVEL) so that it behaves like SQL Server.

What negative consequences should I expect?

sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • The short answer is that you can't do this in SQL Azure: http://stackoverflow.com/questions/2036986/sql-azure-and-read-committed-snapshot – twoleggedhorse Jan 10 '13 at 13:07
  • @twoleggedhorse: This can't be done per database, but it can be done per connection, can't it? – sharptooth Jan 10 '13 at 13:35

1 Answers1

3

Your application logic may break. Really, it depends a lot on what you're doing. Overall, some pointers:

  • True SNAPSHOT has a lot less 'surprises' than RCSI. As the 'snapshot' rows version is clearly defined in the true SNAPSHOT as the moment the transaction started, it does not suffer from RCSI issues of seeing different row versions inside the same transaction (which leads to very subtle and difficult to understand issues)
  • You will get update conflicts instead of deadlocks, but one exactly 'instead-of'. There are some differences, and definetely the app may not expect the new error code 3960.

I would recommend going over Implementing Snapshot or Read Committed Snapshot Isolation in SQL Server: A Guide.

Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569