I understand how a transaction might be useful for co-ordinating a pair of updates. What I don't understand is wrapping single statements in transactions, which is 90% of what I've ever seen. In fact, in real life code it is more common in my experience to find a series of logically related transactions each wrapped in their own transaction, but the whole is not wrapped in a transaction.
In MS-SQL, is there any benefit from wrapping single selects, single updates, single inserts or single deletes in a transaction?
I suspect this is superstitious programming.
It does nothing. All individual SQL Statements, (with rare exceptions like Bulk Inserts with No Log, or Truncate Table) are automaticaly "In a Transaction" whether you explicitly say so or not.. (even if they insert, update, or delete millions of rows).
EDIT: based on #Phillip's comment below... In current versions of SQL Server, Even Bulk Inserts and Truncate Table do write some data to the transaction log, although not as much as other operations do. The critical distinction from a transactional perspective, is that in these other types of operations, the data in your database tables being modified is not in the log in a state that allows it to be rolled back.
All this means is that the changes the statement makes to data in the database are logged to the transaction log so that they can be undone if the operation fails.
The only function that the "Begin Transaction", "Commit Transaction" and "RollBack Transaction" commands provide is to allow you to put two or more individual SQL statements into the same transaction.
EDIT: (to reinforce marks comment...) YES, this could be attributed to "superstitious" programming, or it could be an indication of a fundamental misunderstanding of the nature of database transactions. A more charitable interpretation is that it is simply the result of an over-application of consistency which is inappropriate and yet another example of Emersons euphemism that:
A foolish consistency is the hobgoblin of little minds,
adored by little statesmen and philosophers and divines
As Charles Bretana said, "it does nothing" -- nothing in addition to what is already done.
Ever hear of the "ACID" requirements of a relational database? That "A" stands for Atomic, meaning that either the statement works in its entirety, or it doesn't--and while the statement is being performed, no other queries can be done on the data affected by that query. BEGIN TRANSACTION / COMMIT "extends" this locking functionality to the work done by multiple statements, but it adds nothing to single statements.
However, the database transaction log is always written to when a database is modified (insert, update, delete). This is not an option, a fact that tends to irritate people. Yes, there's wierdness with bulk inserts and recovery modes, but it still gets written to.
I'll name-drop isolation levels here too. Fussing with this will impact individual commands, but doing so will still not make a declared-transaction-wrapped query perform any differently than a "stand-alone" query. (Note that they can be very powerful and very dangeroug with multi-statement declared transactions.) Note also that "nolock" does not apply to inserts/updates/deletes -- those actions always required locks.
For me, wrapping a single statement in a transaction means that I have the ability to roll it back if I, say, forget a WHERE clause when executing a manual, one-time UPDATE statement. It has saved me a few times.
e.g.
--------------------------------------------------------------
CREATE TABLE T1(CPK INT IDENTITY(1,1) NOT NULL, Col1 int, Col2 char(3));
INSERT INTO T1 VALUES (101, 'abc');
INSERT INTO T1 VALUES (101, 'abc');
INSERT INTO T1 VALUES (101, 'abc');
INSERT INTO T1 VALUES (101, 'abc');
INSERT INTO T1 VALUES (101, 'abc');
INSERT INTO T1 VALUES (101, 'abc');
INSERT INTO T1 VALUES (101, 'abc');
SELECT * FROM T1
--------------------------------------------------------------
/* MISTAKE SCENARIO (run each row individually) */
--------------------------------------------------------------
BEGIN TRAN YOUR_TRANS_NAME_1; /* open a trans named YOUR_TRANS_NAME_1 */
UPDATE T1 SET COL2 = NULL; /* run some update statement */
SELECT * FROM T1; /* OOPS ... forgot the where clause */
ROLLBACK TRAN YOUR_TRANS_NAME_1; /* since it did bad things, roll it back */
SELECT * FROM T1; /* tans rolled back, data restored. */
--------------------------------------------------------------
/* NO MISTAKES SCENARIO (run each row individually) */
--------------------------------------------------------------
BEGIN TRAN YOUR_TRANS_NAME_2;
UPDATE T1 SET COL2 = 'CBA' WHERE CPK = 4; /* run some update statement */
SELECT * FROM T1; /* did it correctly this time */
COMMIT TRAN YOUR_TRANS_NAME_2 /* commit (close) the trans */
--------------------------------------------------------------
DROP TABLE T1
--------------------------------------------------------------
One possible excuse is that that single statement could cause a bunch of other SQL to run via triggers, and that they're protecting against something going bad in there, although I'd expect any DBMS to have the common sense to use implicit transactions in the same way already.
The other thing I can think of is that some APIs allow you to disable autocommit, and the code's written just in case someone does that.
When you start an explicit transaction and issue a DML, the resources being locked by the statement remain locked, and the results of statement are not visible from outside the transaction until you manually commit or rollback it.
This is what you may or may not need.
For instance, you may want to show preliminary results to outer world while still keeping a lock on them.
In this case, you start another transaction which places a lock request before the first one commits, thus avoiding race condition
Implicit transactions are commited or rolled back immediatley after the DML statement completes or fails.
SQL Server has a setting which allows turning autocommit off for a session. It's even the default for some clients (see https://learn.microsoft.com/en-us/sql/t-sql/statements/set-implicit-transactions-transact-sql?view=sql-server-2017)
Depending on a framework and/or a database client you use, not putting each individual command into its own transaction might cause them to be all lumped together into a default transaction. Explicitly wrapping each of them in a transaction clearly declares the intent and actually makes sure it happens the way the programmer intended, regardless of the current autocommit setting, especially if there isn't a company-wide policy on autocommit.
If the begin tran / commit tran commands are being observed in the database (as per your comment here), it is also possible that a framework is generating them on behalf of an unsuspecting programmer. (How many developers closely inspect SQL code generated by their framework?)
I hope this is still relevant, despite the question being somewhat ancient.
Related
I am aware that cursors (implicit or explicit) can be created for SELECT statements.
But does cursors (say implicit) also get created for INSERT, UPDATE and DELETE operations. If they do what is there purpose.
To be clear about the question: A SELECT statement can result in a million records and creating a insensitive(actual data is copied) cursor can be helpful to return results to the client as client scrolls forward or backward and can avoid sending all the data in a single network request. And any other benefits worth mentioning are welcome.
But with the write operations (INSERT, UPDATE and DELETE) is a cursor required, won't it be an overhead of resources even if concurrency is considered.? If the operation has to fail it would just fail early. Or is it that for transaction isolation they are required. So, atomicity and consistency are guaranteed through the creation of cursor. (concurrency could be handled through combination of other mechanism like 2PL or MVCC etc, but i am more focused about the role of cursors in transaction for the moment )
So as it seems like transactions also need to be considered, does every transaction result in the creation of a cursor (implicit). Or given other mechanisms exists to handle transactions (with and with out concurrency), cursor have no say at all or just limited role when dealing with transaction.
Almost every statement has to create/open a cursor (even DDL statements). A cursor is a pointer to a private SQL area that stores information about the processing of a SELECT or data manipulation language (DML) statement (INSERT, UPDATE, DELETE, or MERGE).
If you don't create an explicit cursor then an implicit cursor is used. The most useful and most-used attribute of an implicit cursor is the %ROWCOUNT attribute, it returns the number of affected rows.
Have a look at these documents to get more information.
Working with Cursors
SQL (Implicit) Cursor Attribute
Having trouble with locks on a related table via triggers.
I'm inserting into table tCatalog (this has a trigger to simply insert a record in another table tSearchQueue). The insert to tCatalog is inside a transaction that has a lot of other functions that sometimes takes several seconds. However, the tSearchQueue table is locked until the transaction can be committed. Is there a way to avoid this?
INSERT INTO [dbo].[tSearchQueue] (Processed, SQL, sys_CreateDate)
SELECT
0, 'Test ' + cast(CatalogID as varchar(10)), getdate()
FROM
inserted
BEGIN TRAN t1
DECLARE #catalogid int
INSERT INTO tCatalog (ProgramID, sys_CreatedBy, ItemNumber, Description, UOMID)
VALUES (233, 1263, 'brian catalog4', 'brian catalog4', 416)
SELECT #catalogid = SCOPE_IDENTITY()
INSERT INTO tCustomAttributeCatalog (CatalogID, CustomAttributeID, DefaultValue, DefaultValueRead, sys_CreatedBy)
VALUES (#catalogid, 299, 'No', 'No', 1263)
INSERT INTO tCustomAttributeCatalog (CatalogID, CustomAttributeID, DefaultValue, DefaultValueRead, sys_CreatedBy)
VALUES (#catalogid, 300, null, null, 1263)
COMMIT TRAN t1
It looks like you have a background process which wants to be notified of changes so it can do some sort of re-indexing. If that's the case it's not necessarily wrong that it is blocked, since if the transaction does not commit then it shouldn't index it anyway.
So the sequence is:
Begin transaction
insert tCatalog
trigger inserts tSearchQueue
Insert some other tables
Perform a long-running operation
Commit transaction.
And the problem is another process wants to read tSearchQueue but cannot since it is locked.
Option 1: Perform the background operation in batches.
If the process is getting behind because it has too few opportunities to read the table, then maybe reading multiple rows at a time would solve the issue. I.e. each time it gets a chance to read the queue it should read many rows, process them all at once, and then mark them all as done together (or delete them as the case may be).
Option 2: Perform the long running operation first, if possible:
begin transaction
perform long-running operation
insert tCatalog
trigger inserts tSearchQueue
insert some other tables
commit transaction
Other process now finds tSearchQueue is locked only for a short time.
Note that if the long-running operation is a file copy, these can be included in the transaction using CopyFileTransacted, or the copy can be rolled back in a "catch" statement if the operation fails.
Option 3: Background process avoids the lock
If the other process is trying primarily to read the table, then snapshot isolation may solve your problem. This will return only committed rows, as they existed at the point in time. Combined with row-level locking this may solve your problem.
Alternatively the background process might read with the NOLOCK hint (dirty reads). This may result in reading data from transactions which are later rolled back. However if the data is being validated in a separate step (e.g. you are just writing the identifier for the object which needs reindexing) this is not necessarily a problem. If the indexing process can cope with entries which no longer exist, or which haven't actually changed, then having spurious reads won't matter.
BEGIN TRAN
SELECT * FROM AnySchema.AnyTable
WHERE AnyColumn = SomeCondition
COMMIT
I know the transaction is not required here because it is just a select but just want to know how bad a programming it is and whether it is going to be an overhead on the DB engine.
You may use transaction on SELECT statements to ensure nobody else could update / delete records of the table of while the bunch of your select queries are executing.
Using WITH(NOLOCK):
Anyways, you may also use WITH(NOLOCK) for t_sql
SELECT * FROM AnySchema.AnyTable WITH(NOLOCK)
WHERE AnyColumn = SomeCondition
WITH (NOLOCK) is the equivalent of using READ UNCOMMITED as a transaction isolation level. Here stand the risk of reading an uncommitted row that is subsequently rolled back, i.e. data that never made it into the database.
So, while it can prevent reads being deadlocked by other operations, it comes with a risk.
TRANSACTION Block :
Using TRANSACTION block will not cause much of extra DB overload but if you keep the same type practice on, and suppose , at any SQL block you forget (you / your developers may forget, right ?) to close the transaction, then other processes can't work on the same table.
Anyways, it depends on what type of application you are using. If very frequent update and select things are there , it is advised not to use such transaction blocks. If medium level of updates and select are there, occurs next to each other, you may use transaction blocks for select (but ensure to close the transaction).
That's actually a good question. To understand what's going on, you need to know about SET IMPLICIT_TRANSACTIONS.
When ON, the system is in implicit transaction mode. This means that if ##TRANCOUNT = 0, any of the following Transact-SQL statements begins a new transaction. It is equivalent to an unseen BEGIN TRANSACTION being executed first:
When OFF, each of the preceding T-SQL statements is bounded by an unseen BEGIN TRANSACTION and an unseen COMMIT TRANSACTION statement. When OFF, we say the transaction mode is autocommit. [this is the default]
If your T-SQL code visibly issues a BEGIN TRANSACTION, we say the transaction mode is explicit.
https://msdn.microsoft.com/en-us/library/ms187807.aspx
Since the SQL Server would have created a transaction for you, manually doing doesn't actually change anything. The exact same thing would have happened either way.
Summary: What you are doing isn't 'wrong' because it has no effect, but unnecessary and confusing to the reader.
I think you would be taking a holdlock and most likely a tablock
table hints
That is not always a good thing as you would block any update or deletes (maybe even inserts)
It would be better to let SQL decide what level of of locks to take. Most likely pagelocks. I would stay away from nolock as bad stuff can happen.
On a select on a single table just let the optimizer do it's thing.
I'm improving the performance of queries in my app, I have several functions where I purely do inserts / updates, which adding begin / commit has greatly improved the speed.
However, my main function which runs when the app starts up, has conditional inserts / updates and selects, based on each other.
My worry is that I'll begin transaction, insert some data into table X conditionally, then select on table X, the query wouldn't find any the data, until commit transaction, I'm correct in my concern ?
As a workaround can I do my inserts / updates with begin / commit, then do my select, then do further transaction within begin / commit ?
PLEASE don't tell me to use FMDB or core data, I'm committed to this path, to provide some fixes.
y worry is that I'll begin transaction, insert some data into table X conditionally, then select on table X, the query wouldn't find any the data, until commit transaction, I'm correct in my concern ?
No. As the documentation for BEGIN TRANSACTION states, updates and inserts are always done in a transaction, so you would already be seeing this problem if it existed. This assumes, of course, that all of your SQL statements are being done with the same database connection.
I have a random question. If I were to do a sql select and while the sql server was querying my request someone else does a insert statement... could that data that was inputted in that insert statement also be retrieved from my select statement?
Queries are queued, so if the SELECT occurs before the INSERT there's no possibility of seeing the newly inserted data.
Using default isolation levels, SELECT is generally given higher privilege over others but still only reads COMMITTED data. So if the INSERT data has not been committed by the time the SELECT occurs--again, you wouldn't see the newly inserted data. If the INSERT has been committed, the subsequent SELECT will include the newly inserted data.
If the isolation level allowed reading UNCOMMITTED (AKA dirty) data, then yes--a SELECT occurring after the INSERT but before the INSERT data was committed would return that data. This is not recommended practice, because UNCOMMITTED data could be subject to a ROLLBACK.
If the SELECT statement is executed before the INSERT statement, the selected data will certainly not include the new inserted data.
What happens in MySQL with MyISAM, the default engine, is that all INSERT statements require a table lock; as a result, once an INSERT statement is executed, it first waits for all existing SELECTs to complete before locking the table, performs the INSERT, and then unlocks it.
For more information, see: Internal Locking Methods in the MySQL manual
No, a SELECT that is already executing that the moment of the INSERT will never gather new records that did not exist when the SELECT statement started executing.
Also if you use the transactional storage engine InnoDB, you can be assured that your SELECT will not include rows that are currently being inserted. That's the purpose of transaction isolation, or the "I" in ACID.
For more details see http://dev.mysql.com/doc/refman/5.1/en/set-transaction.html because there are some nuances about read-committed and read-uncommitted transaction isolation modes.
I don't know particulars for MySQL, but in SQL Server it would depend on if there were any locking hints used, and the default behavior for locks. You have a couple of options:
Your SELECT locks the table, which means the INSERT won't process until your select is finished.
Your SELECT is able to do a "dirty read" which means the transaction doesn't care if you get slightly out-of-date data, and you miss the INSERT
Your SELECT is able to do a "dirty read" but the INSERT happens before the SELECT hits that row, and you get the result that was added.
The only way you do that is with a "dirty read".
Take a look at MYSql's documentation on TRANSACTION ISOLATION LEVELS to get a better understanding of what that is.