This question may have been asked but from what I've read I still don't clearly understand what's happening. My question deals specifically with using the Read Uncommitted isolation level in SQL Server - via Entity Framework (i.e. setting the isolation level on the DB object in the contest when starting a transaction).
My question is - the documentation states that using read uncommitted will allow other transactions/queries to read the tables involved in the initial transaction. Now this works fine up until a write based operation is performed. At that point the table is locked. I've tested this out by starting a transaction in a project and stopping in a breakpoint after the update. Then tried to access the related table in SQL Server Management Studio. I am not able to do so. This makes me wonder what the purpose of read uncommitted is if you can't read uncommitted. I have read that people state that there are two types of locking behaviour and the second one which is not affected by the isolation level is what is locking the table. This still doesn't explain why the read uncommitted is not working - again it states that it allows reading of uncommitted operations (but seems to not allow it).
Peter
Related
Does DB2 for z/OS have isolation level similar to READ ONLY in Oracle?
I need to implement several big selects to DB2 and also I need to retrieve consistent data which was commited on time when queries were started, so I need something like 'snapshot isolation level'. As far as I know in Oracle it can be implemented by READ ONLY isolation level, but what about DB2 for z/OS?
DB2 for z/OS does not have "read only" isolation level (nor does Oracle, as "read only" is a transaction state, not an isolation level).
You can avoid lock waits by queries if you use the currently committed concurrent access resolution option, however, note that it does not implement "snapshot isolation" per se -- a query that uses this option will see the latest committed changes, even if those changes were committed after the query started.
There is a FOR READ ONLY clause in DB2 z/OS. You add it at the end of your query.
For tables in which updates and deletes are allowed, specifying FOR
READ ONLY can possibly improve the performance of FETCH operations as
DB2® can do blocking and avoid exclusive locks. For example, in
programs that contain dynamic SQL statements without the FOR READ ONLY
or ORDER BY clause, DB2 might open cursors as if the UPDATE clause was
specified.
Here is the Info Center article with more information.
If you're really looking for the DB2 version of "Serializable", then you are looking for Repeatable Read.
MSDN describes the JET transaction isolation for its OLEDB provider as follows:
Jet supports five levels of nesting in transactions. The only
supported mode for transactions is Read Committed. Setting lesser
levels of transactional separation implies Read Committed. Setting
higher levels will cause StartTransaction to fail.
Jet supports only single-phase commit.
MSDN describes Read Committed as follows:
Specifies that shared locks are held while the data is being read to
avoid dirty reads, but the data can be changed before the end of the
transaction, resulting in nonrepeatable reads or phantom data. This
option is the SQL Server default.
My questions are:
What is single-phase commit? What consequence does this have for transactions and isolation?
Would the Read Committed isolation level as described above be suitable for my requirements here?
What is the best way to achieve a Serializable transaction isolation using Jet?
By question number:
Single-phase commit is used where all of your data is in one database -- the activity of the transaction is committed atomically and you're done. If you have a logical transaction which needs to be spread across multiple storage engines (like a relational database for metadata and some sort of document store for a big blob) you can use a transaction manager to coordinate the activities so that the work is persisted in both or neither, if both products support two phase commit. They are just telling you that they don't support two-phase commit, so the product is not suitable for distributed transactions.
Yes, if you check the condition in the UPDATE statement itself; otherwise you might have problems.
They seem to be suggesting that you can't.
As an aside, I worked for decades as a consultant in quite a variety of environments. More than once I was engaged to migrate people off of Jet because of performance problems. In one case a simple "star" type query was running for two minutes because it was joining on the client rather than letting the database do it. As a direct query against the database it was sub-second. In another case there was a report which took 72 hours to run through Jet, which took 2 minutes when run directly against the database. If it generally works OK for you, you might be able to deal with such situations by using stored procedures where Jet is causing performance pain.
I am copying some data from sql server to firebird over the network. Because of integrity I need to use transactions, but I am transferring about 9k of rows. Has reading in opened transaction some negative influence on reading costs, against reading in non transaction mode?
"Non-Transaction mode" simply doesn't exists, there is always a transaction, whether you declare it or not. The question is really whether is there any difference between reading in an implicit transaction vs. reading in an explicit transaction. And the short answer is no, there is no difference.
There may be some difference if you use an explicit transaction under a higher isolation level, other than the default READ_COMMITTED. It also depends whether you do anything else in an explicit transaction, but all these details cannot be infered from the frugal information in your post.
The default transaction isolation level is READ COMMITTED. It will lock the table for others while querying it.
MSDN on transaction isolation level:
http://msdn.microsoft.com/en-us/library/ms173763.aspx
I've had the issue of an occasional strange error message concerning locking deadlock. This even happened to stackoverflow - see this great article by Jeff Atwood. I strongly recommend switching to 'read committed snapshot' which solved the error + my performance issues.
http://www.codinghorror.com/blog/2008/08/deadlocked.html
I've read that in older versions of SQL Server .. it had a pessimistic locking strategy. I.e. readers wait on writers for access to the same data (row or page level), unlike Oracle.
Is this still the case in newer versions ? I've read that the locking strategy has been changed in recent versions.
What you heard of is the SNAPSHOT ISOLATION, available since SQL Server 2005. Snapshot isolation, aka. row-versioning, is the default behavior in Oracle. You can make it default in SQL Server too, by enabling READ_COMMITTED_SNAPSHOT on the database:
ALTER DATABASE [<dbname>] SET READ_COMMITTED_SNAPSHOT ON;
With row versioning SQL Server does not acquire data locks during reads. If concurrent writes occur, the read will fetch the previous version of the row. For more details, read Row Versioning-based Isolation Levels in the Database Engine.
You should not confuse row versioning and snapshot with dirty reads. Dirty reads offer inconsistent data which makes programming a challenge, to say the least (ie. you should not use it!). Snapshot reads offer always a transactionally consistent image of the data.
by default SQL server uses READ COMMITTED isolation level, which means it will wait on uncommited changes before it tries to read them.
http://msdn.microsoft.com/en-us/library/ms173763.aspx
note that if you don't care about the accuracy of the data returned, you can always set you isolation level to Read Uncommitted this will give you all the records evening the ones that have binding changes
You can also use snapshot isolation level, which will give you all the record, including the latest known version of data that are currently being modified, without the current modification.
The locking strategy is something that is handled on connection by connection basis - this is something that can be set by the application and withing SQL Server itself.
Read about the Transaction Isolation Levels for more details.
When you create a SQL Server transaction, what gets locked if you do not specify a table hint? In order to lock something, must you always use a table hint? Can you lock rows/tables outside of transactions (i.e. in ordinary queries)? I understand the concept of locking and why you'd want to use it, I'm just not sure about how to implement it in SQL Server, any advice appreciated.
You should use query hints only as a last resort, and even then only after expert analysis. In some cases, they will cause a query to perform badly. So, unless you really know what you are doing, avoid using query hints.
Locking (of various types) happens automatically everytime you perform a query (unless NOLOCK is specified). The default Transaction Isolation level is READ COMMITTED
What are you actually trying to do?
Understanding Locking in SQL Server
"Can you lock rows/tables outside of transactions (i.e. in ordinary queries)?"
You'd better understand that there are no ordinary queries or actions in SQL Server, they are ALL, without any exceptions, transactional. This is how ACID-ness is achieved, see, for ex., [1]. If client tools or developer interactively do not specify transaction explicitly with BEGIN TRANSACTION and COMMIT/ROLLBACK, then implicit transactions are used.
Also, transaction is not synonym of locking/locks engagement. There is a plethora of mechanisms to control concurrency without locking (for example, versioning. etc.) as well as READ UNCOMMITTED transaction "isolation" (in this case, absence of any isolation) level does not control it at all.
Update2:
In order to lock something, must you always use a table hint?
As far as, transaction isolation level is not READ UNCOMMITTED or one of row-versioning (snapshot) isolation levels, for ex., default READ COMMITTED or set by, for ex.,
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
the locks are issued (I do not know where to start and how to end this topic[2]). Table hints, which can be used in statements, override these settings.
[1]
Paul S. Randal. Understanding Logging and Recovery in SQL Server
What is Logging?
http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx#id0060003
[2]
Insert trailing ) upon clicking this link
http://en.wikipedia.org/wiki/Isolation_(database_systems)
Update:
5 min ago I had reputation 784 (the same as 24h ago) and, now, without any visible downvotes, it dropped to 779.
Where can I ask this question if I am banned from meta.stackoverflow.com?