Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Chapter 14: Transactions and Locks Behind the scenes, something like this is happening: UPDATE checking SET Balance = Balance - 1000 WHERE Account = ‘Sally’ UPDATE savings SET Balance = Balance + 1000 WHERE Account = ‘Sally’ This is a hyper-simplification of what’s going on, but it captures the main thrust of things: You need to issue two different statements — one for each account. Now what if the first statement executes and the second one doesn’t? Sally would be out a thousand dollars! That might, for a short time, seem OK from your perspective (heck, you just made a thousand bucks!), but not for long. By that afternoon you’d have a steady stream of customers leaving your bank — it’s hard to stay in the bank business with no depositors. What you need is a way to be certain that if the first statement executes, the second statement executes. There really isn’t a way that we can be certain of that — all sorts of things can go wrong, from hardware failures to simple things, such as violations of data integrity rules. Fortunately, however, there is a way to do something that serves the same overall purpose — we can essentially forget that the first statement ever happened. We can enforce at least the notion that if one thing didn’t happen, then nothing did — at least within the scope of our transaction. In order to capture this notion of a transaction, however, we need to be able to define very definite boundaries. A transaction has to have very definitive beginning and end points. Actually, every SELECT, INSERT, UPDATE, and DELETE statement you issue in SQL Server is part of an implicit transaction. Even if you issue only one statement, that one statement is considered to be a transaction — everything about the statement will be executed, or none of it will. Indeed, by default, that is the length of a transaction — one statement. But what if we need to have more than one statement be all or nothing, as in our preceding bank example? In such a case, we need a way of marking the beginning and end of a transaction, as well as the success or failure of that transaction. To that end, there are several T-SQL statements that we can use to mark these points in a transaction. We can: ❑ BEGIN a transaction: Set the starting point. ❑ COMMIT a transaction: Make the transaction a permanent, irreversible part of the database. ❑ ROLLBACK a transaction: Say essentially that we want to forget that it ever happened. ❑ SAVE a transaction: Establish a specific marker to allow us to do only a partial rollback. Let’s look over all of these individually before we put them together into our first transaction. BEGIN TRAN 428 The beginning of the transaction is probably one of the easiest concepts to understand in the transaction process. Its sole purpose in life is to denote the point that is the beginning of a unit. If, for some reason,
we are unable or do not want to commit the transaction, this is the point to which all database activity will be rolled back. That is, everything beyond this point that is not eventually committed will effectively be forgotten, as far as the database is concerned. The syntax is: BEGIN TRAN[SACTION] [|] [ WITH MARK [ ]] I won’t dwell on the WITH MARK option here, as it is a topic having to do with very advanced point in time transaction work, which tends to be more administrator oriented and is well outside of the scope of this book. COMMIT TRAN The committing of a transaction is the end of a completed transaction. At the point that you issue the COMMIT TRAN, the transaction is considered durable. That is, the effect of the transaction is now permanent and will last even if you have a system failure (as long as you have a backup or the database files haven’t been physically destroyed). The only way to undo whatever the transaction accomplished is to issue a new transaction that, functionally speaking, is a reverse of your first transaction. The syntax for a COMMIT looks pretty similar to a BEGIN: COMMIT TRAN[SACTION] [|] ROLLBACK TRAN Whenever I think of a ROLLBACK, I think of the old movie The Princess Bride. If you’ve ever seen the film (if you haven’t, I highly recommend it), you’ll know that the character Vizzini (considered a genius in the film) always says, “If anything goes wrong, go back to the beginning.” That is some mighty good advice. A ROLLBACK does just what Vizzini suggests — it goes back to the beginning. In this case, it’s your transaction that goes back to the beginning. Anything that happened since the associated BEGIN statement is effectively forgotten. The only exception to going back to the beginning is through the use of what are called save points, which we’ll describe shortly. The syntax for a ROLLBACK again looks pretty much the same as a BEGIN or COMMIT, with the exception of allowance for a save point. ROLLBACK TRAN[SACTION] [|| |] SAVE TRAN Chapter 14: Transactions and Locks To save a transaction is essentially to create something of a bookmark. You establish a name for your bookmark (you can have more than one). After this bookmark is established, you can reference it in a rollback. What’s nice about this is that you can roll back to the exact spot in the code that you want to just by naming a save point to which you want to roll back. 429
- Page 416 and 417: Chapter 12: Stored Procedures Now,
- Page 418 and 419: Chapter 12: Stored Procedures SQL S
- Page 420 and 421: Chapter 12: Stored Procedures 382 c
- Page 422 and 423: Chapter 12: Stored Procedures It wo
- Page 424 and 425: Chapter 12: Stored Procedures 386 r
- Page 426 and 427: Chapter 12: Stored Procedures 388 -
- Page 428 and 429: Chapter 12: Stored Procedures Note
- Page 430 and 431: Chapter 12: Stored Procedures 392 n
- Page 432 and 433: Chapter 12: Stored Procedures All t
- Page 434 and 435: Chapter 12: Stored Procedures Sproc
- Page 436 and 437: Chapter 12: Stored Procedures When
- Page 438 and 439: Chapter 12: Stored Procedures 400 @
- Page 440 and 441: Chapter 12: Stored Procedures I’d
- Page 442 and 443: Chapter 12: Stored Procedures match
- Page 444 and 445: Chapter 12: Stored Procedures There
- Page 446 and 447: Chapter 12: Stored Procedures 408 f
- Page 449 and 450: 13 User-Defined Functions Well, her
- Page 451 and 452: types!), except for BLOBs, cursors,
- Page 453 and 454: We get back the same set as with th
- Page 455 and 456: AS RETURN (SELECT BusinessEntityID,
- Page 457 and 458: in your relational database. These
- Page 459 and 460: AS BEGIN ( EmployeeID int NOT NULL,
- Page 461 and 462: So, as you can see, we can actually
- Page 463 and 464: Despite being schema-bound, this on
- Page 465: 14 Transactions and Locks This is o
- Page 469 and 470: Figure 14-1 Data needed Data in cac
- Page 471 and 472: Transaction 4 This transaction wasn
- Page 473 and 474: Oops — problem!!! Transaction 2 h
- Page 475 and 476: The only cure for this is setting y
- Page 477 and 478: Exclusive Locks Exclusive locks are
- Page 479 and 480: Also: ❑ The Sch-S is compatible w
- Page 481 and 482: The syntax for switching between th
- Page 483 and 484: As with most things in life, howeve
- Page 485 and 486: purchased. Process 2 records sales;
- Page 487: Chapter 14: Transactions and Locks
- Page 490 and 491: Chapter 15: Triggers the world’s
- Page 492 and 493: Chapter 15: Triggers WITH ENCRYPTIO
- Page 494 and 495: Chapter 15: Triggers FOR|AFTER The
- Page 496 and 497: Chapter 15: Triggers 458 To illustr
- Page 498 and 499: Chapter 15: Triggers 460 IF EXISTS
- Page 500 and 501: Chapter 15: Triggers ❑ Feeding de
- Page 502 and 503: Chapter 15: Triggers Trigger Firing
- Page 504 and 505: Chapter 15: Triggers Like regular t
- Page 506 and 507: Chapter 15: Triggers The COLUMNS_UP
- Page 508 and 509: Chapter 15: Triggers This is the sa
- Page 510 and 511: Chapter 15: Triggers 472 we have th
- Page 512 and 513: Chapter 16: A Brief XML Primer So,
- Page 514 and 515: Chapter 16: A Brief XML Primer Figu
we are unable or do not want to commit the transaction, this is the point to which all database activity<br />
will be rolled back. That is, everything beyond this point that is not eventually committed will effectively<br />
be forgotten, as far as the database is concerned.<br />
The syntax is:<br />
BEGIN TRAN[SACTION] [|]<br />
[ WITH MARK [ ]]<br />
I won’t dwell on the WITH MARK option here, as it is a topic having to do with very advanced point in<br />
time transaction work, which tends to be more administrator oriented and is well outside of the scope of<br />
this book.<br />
COMMIT TRAN<br />
The committing of a transaction is the end of a completed transaction. At the point that you issue the<br />
COMMIT TRAN, the transaction is considered durable. That is, the effect of the transaction is now permanent<br />
and will last even if you have a system failure (as long as you have a backup or the database files haven’t<br />
been physically destroyed). The only way to undo whatever the transaction accomplished is to issue a<br />
new transaction that, functionally speaking, is a reverse of your first transaction.<br />
The syntax for a COMMIT looks pretty similar to a BEGIN:<br />
COMMIT TRAN[SACTION] [|]<br />
ROLLBACK TRAN<br />
Whenever I think of a ROLLBACK, I think of the old movie The Princess Bride. If you’ve ever seen the film<br />
(if you haven’t, I highly recommend it), you’ll know that the character Vizzini (considered a genius in<br />
the film) always says, “If anything goes wrong, go back to the beginning.”<br />
That is some mighty good advice. A ROLLBACK does just what Vizzini suggests — it goes back to the<br />
beginning. In this case, it’s your transaction that goes back to the beginning. Anything that happened<br />
since the associated BEGIN statement is effectively forgotten. The only exception to going back to the<br />
beginning is through the use of what are called save points, which we’ll describe shortly.<br />
The syntax for a ROLLBACK again looks pretty much the same as a BEGIN or COMMIT, with the exception<br />
of allowance for a save point.<br />
ROLLBACK TRAN[SACTION] [||<br />
|]<br />
SAVE TRAN<br />
Chapter 14: Transactions and Locks<br />
To save a transaction is essentially to create something of a bookmark. You establish a name for your<br />
bookmark (you can have more than one). After this bookmark is established, you can reference it in a<br />
rollback. What’s nice about this is that you can roll back to the exact spot in the code that you want to<br />
just by naming a save point to which you want to roll back.<br />
429