Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
What are the risks or performance degradation when using SET TRANSACTION ISOLATION LEVEL REPEATABLE READ?
We have some SP that are called from BizTalk services. We are getting deadlock sometimes. If we change the isolation level, what are the risks and possible perfomance degradations?
Repeatable Read will put locks on all rows that have
been fetched. In situations where you are working with
cursors fetching large amounts of data this can cause
contention with other users because they cannot
obtain locks to update any of the rows read by cursors
with Repeatable Read until the cursor is closed.
The risk of performance degradation is that transactions may
suffer an increased number of timeouts and/or deadlocks. This risk
is proportional to the probability that two transactions need to
read/update the same rows at the same time. Another factor that
can impact your application is the size of lock taken. If locks are
taken at a page level then contention may occur if the data different
transactions need to access lie on the same page – not necessarily the same row.
On the other hand, when you use a lower isolation level,
cursor stability for example, you leave open the possibility
that rows you have previously fetched during your transaction may be
updated by other transactions before your unit of work has
completed.