Comments on: Correct Isolation level for SQL2005 Subscriber. http://itknowledgeexchange.techtarget.com/itanswers/correct-isolation-level-for-sql2005-subscriber/ Sun, 19 May 2013 03:14:28 +0000 hourly 1 By: mrdenny http://itknowledgeexchange.techtarget.com/itanswers/correct-isolation-level-for-sql2005-subscriber/#comment-58998 mrdenny Mon, 05 Jan 2009 21:35:20 +0000 #comment-58998 Snapshot isolation saves you from dirty reads but it gives you old data instead. It all depends which you would rather have.

Rather than changing the process it would be better find out what is causing the blocking, and correct the underlying issue.

It could simply be that you need to reduce the number of statements being replicated in each transaction and your blocking issue will go away.

]]> By: supercoolmoss http://itknowledgeexchange.techtarget.com/itanswers/correct-isolation-level-for-sql2005-subscriber/#comment-58990 supercoolmoss Sun, 04 Jan 2009 15:29:59 +0000 #comment-58990 Thanks Mr. D.

This is an upgrade to a current SQL 2000 solution. Current spec is 32 bit, 4 dual core cpus, 4gb memory on Transaction server, and 6gb AWE on query server, shared SAN disks. Stand-alone distributor.

The SQL 2005 Transaction server will co-locate the distributor.

We have around 300 connections at peak times on both clusters. I’ll try and get some transaction throughput figures.

We’ve had issues with blocking on the subscriber which were resolved by using no-lock hints on a majority of queries. I thought, as we’re moving to SQL2005 we may as well use 2005′s snapshot isolation to hopefully resolve all locking issues and not have to rely on dirty reads.

Management have decided to beef up the hardware whilst upgrading to SQL2005. They’ve decided on the memory and CPUs – I’m specifying the disk infrastructure and have decided to give them top spec with the expectation that it’ll probably be reduced due to costs.

Thanks, I’ll take on board your suggestion to not use Instant file initialisation to improve writes.

Regards,

SCM.

]]>