1. Process Monitor v3.0.3
Thursday, October 25, 2012
Tuesday, October 23, 2012
Why cursor is a bad idea?
Cursor is a bad idea, since it lock a table used to populate a cursor while you loop through the cursor and do some operation on fetched records.
Here is some article about it http://www.sqlbook.com/SQL/Avoiding-using-SQL-Cursors-20.aspx
Here is some article about it http://www.sqlbook.com/SQL/Avoiding-using-SQL-Cursors-20.aspx
Monday, October 22, 2012
Read Committed and Repetable Read
Good article on it in StackOverflow
1) The default isolation level of Read Committed means that Dirty Reads will not occur (although phantom or non-repeatable reads might). It does not guarantee that single rows are locked.
A non-repeatable read can occur in the following situation:
1. Transaction 1 begins2. Transaction 1 read a row3. Transaction 2 begins4. Transaction 2 changes the value of the same row read by Transaction 1
5. Transaction 2 commits6. Transaction 1 reads the row again. Transaction 1 has inconsistent data.
2) Repeatable Read isolation level means the above situation cannot occur (though phantom reads still might). A phantom read can occur in the following situation:
1. Transaction 1 begins2. Transaction 1 read a row3. Transaction 2 begins4. Transaction 2 deletes the row read by Transaction 1
5. Transaction 2 commits. Transaction 1 can no longer repeat its initial read,
since the row no longer exists.
If you want to guarantee that data does not chnage while you read it, you would need the Serializable isolation level. I would strongly advise agianst not using the Serializable isolation level unless you absolutely have to, as concurrency will suffer.
Wednesday, October 10, 2012
Subscribe to:
Comments (Atom)