SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
Search:  
 
 
        
Home       Members    Calendar    Who's On



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

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, July 03, 2009 6:25 AM
Points: 3, Visits: 4
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 03, 2009 5:57 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 9:28 AM
Points: 14,526, Visits: 10,415
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

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

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

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, July 03, 2009 6:25 AM
Points: 3, Visits: 4
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 03, 2009 6:08 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 9:28 AM
Points: 14,526, Visits: 10,415
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

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

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

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, July 03, 2009 6:25 AM
Points: 3, Visits: 4
Yes you are right.
I will not change defaults. I am just taking of clear picture :)
Thanks again.
Post #746958
« Prev Topic | Next Topic »


Permissions Expand / Collapse