SQL transaction and lock of the table for SELECT

Question

SQL transaction and lock of the table for SELECT

kiro1234

SSC-Addicted

Points: 412
More actions
July 3, 2009 at 5:37 am

#155909

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.

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 1

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, MVP, M.Sc (Comp Sci)
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

kiro1234 SSC-Addicted Points: 412 More actions · Answer 2

Thanks for info 🙂

How to enable in SQL 2005 this "Oracle like" isolation mode ? Ii it per instance or per database?

Thanks

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 3

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, MVP, M.Sc (Comp Sci)
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

kiro1234 SSC-Addicted Points: 412 More actions · Answer 4

Yes you are right.

I will not change defaults. I am just taking of clear picture 🙂

Thanks again.

sarath.snape SSC Enthusiast Points: 109 More actions · Answer 5

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

alcide.burato SSC Journeyman Points: 85 More actions · Answer 6

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

princa SSCommitted Points: 1819 More actions · Answer 7

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?

sriharsha.kolluru Valued Member Points: 55 More actions · Answer 8

This might Help.

Set Isolation level to read uncommitted. Hope this solves your problems.

http://msdn.microsoft.com/en-us/library/ms173763.aspx:-)

Dave Ballantyne SSC-Dedicated Points: 33566 More actions · Answer 9

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[/url]

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 10

Please note: 3 year old thread.

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
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

drierelou Valued Member Points: 70 More actions · Answer 11

drierelou

Valued Member

Points: 70

December 2, 2012 at 7:49 pm

#1564722

Hi,guys.I am new here.