Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

SQL transaction and lock of the table for SELECT Expand / Collapse
Author
Message
Posted Friday, July 3, 2009 5:37 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 10, 2014 1:52 AM
Points: 6, Visits: 40
Hi to all

I am very new in SQL Server world. I was working with Oracle more of 10 years.
Now I have to do a small DBA also on one SQL Server 2005 EE database.

I have a following problem:

when I am using in T-SQL statement with transaction or when I changed default AUTO-COMMIT mode

===== start of code ====
BEGIN Tran
update table xx set rowname = 'new name' where id_name = xx
==== end of code =====

and I am not doing
ROLLBACK or COMMIT

Open a new separate session and I Try

select * from xx ;

the session is waiting until other session do ROLLBACK or COMMIT - the entire table is locked for SELECT? In ORACLE there is no problem to read from table in other session when table was being updated in another session.

Am I wrong or SQL Server 2005 is working in this way?

When I am working with default AUTO-COMMIT mode of course there is no rpoblem.

The table I am playing with is about 6-7 rows.

Post #746934
Posted Friday, July 3, 2009 5:57 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 8:25 AM
Points: 43,016, Visits: 36,177
SQL by default uses locks for transaction isolation, while Oracle uses a form of row-versions.

In SQL, if you issue an update within a transaction, the locks taken by that update will be held until the transaction commits or rolls back. It's an exclusive lock (for data modification) and is not compatible with shared locks needed for reads. Hence the select has to wait until the transaction is committed or rolls back before it can read a locked row.

SQL 2005 and higher do support the isolation method that Oracle uses, in the Snapshot and Read_Committed_Snapshot isolation levels. They do have a large impact on TempDB, but they will allow select queries to read the old version of rows locked for modification.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #746943
Posted Friday, July 3, 2009 6:04 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 10, 2014 1:52 AM
Points: 6, Visits: 40
Thanks for info
How to enable in SQL 2005 this "Oracle like" isolation mode ? Ii it per instance or per database?
Thanks
Post #746947
Posted Friday, July 3, 2009 6:08 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 8:25 AM
Points: 43,016, Visits: 36,177
I would suggest that you first get used to SQL's native locking mode, understand how it works, when there are problems with it and why. Snapshot isolation is not the default for a reason.

SQL Server is not Oracle and should not be treated like Oracle. They behave very differently.

Check out Books Online (the SQL help file), and read up on locking and isolation levels.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #746950
Posted Friday, July 3, 2009 6:26 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 10, 2014 1:52 AM
Points: 6, Visits: 40
Yes you are right.
I will not change defaults. I am just taking of clear picture :)
Thanks again.
Post #746958
Posted Tuesday, July 20, 2010 11:28 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, July 20, 2010 11:23 PM
Points: 1, Visits: 0
Hi, I have a similar problem. I introduced 'transaction' so as to enable atomicity in my application , but it is locking out the entire table, even for reads. The tables locked are frequently updated. And since these are locked, it is a problem in multiple user scenarios too. However we are not encountering these issues in oralce db.

Please advice a solution.




Regards,
http://blog.autumn.co.in
Post #956097
Posted Saturday, February 5, 2011 10:13 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, May 9, 2011 8:32 AM
Points: 1, Visits: 4
Hi all
I had the same problem, the solution I found is

1) set the transaction isolation level to be READ UNCOMMITTED
http://msdn.microsoft.com/it-it/library/ms173763.aspx

2) use WITH (NOLOCK) when querying:

select * from MyTable WITH (NOLOCK)

This works for me.
Alcide
Post #1059150
Posted Monday, May 7, 2012 12:04 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, June 6, 2014 11:42 AM
Points: 59, Visits: 197
I have the same problem.
While I am not updating a single row but instead I need to truncate the whole table and re-insert from a view, so in this case, if I use with (nolock), which doesn't work, because the entire table was truncated so everyrow is locked.

Ideas?
Post #1296023
Posted Wednesday, November 28, 2012 3:23 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, December 12, 2012 7:33 AM
Points: 1, Visits: 3
This might Help.
Set Isolation level to read uncommitted. Hope this solves your problems.

http://msdn.microsoft.com/en-us/library/ms173763.aspx
Post #1389614
Posted Wednesday, November 28, 2012 4:39 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Tuesday, September 9, 2014 2:06 AM
Points: 1,949, Visits: 8,318
Using uncommitted/nolock may well 'fix' the problem but please understand that you will be reading dirty data.
If the transaction is to be rolled back then what does that be for the process that has read the dirty data ?





Clear Sky SQL
My Blog
Kent user group
Post #1389638
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse