What is a Transaction
Imagine you need to perform several related database operations that must either all succeed or all fail together. For example, transferring money from one bank account to another. This involves two main steps:
1. Deduct the amount from the source account.
2. Add the amount to the destination account.
If step 1 succeeds but step 2 fails (maybe due to a network error or server crash), you'd end up with money disappearing from the source account but not appearing in the destination account! That's a disaster.
A SQL Server transaction groups these multiple steps into a single, logical unit of work. You tell SQL Server "Start a transaction here (BEGIN TRAN)", perform all the steps, and then say "Okay, everything worked, make it permanent (COMMIT TRAN)". If something goes wrong during the steps, you say "Cancel everything since I started (ROLLBACK TRAN)", and SQL Server undoes any changes made within that transaction.
You might already hear about ACID properties of a transaction. ACID properties are the 4 pillars of a transaction, which allows SQL Server (and other relational databases) to implement the feature correctly.
So what are these ACID properties. ACID stands for:
- A - Atomicity
- C - Consistency
- I - Isolation
- D - Durability
Atomicity
• Think of it: "All or Nothing."
• What it means: An atomic transaction is treated as a single, indivisible unit. Either all the operations within the transaction complete successfully and are permanently recorded in the database, or none of them are. If any part of the transaction fails, the entire transaction is cancelled, and the database is returned to the state it was in before the transaction started. This is called rolling back the transaction.
• Why it's important: Prevents partial updates that could leave your data in an inconsistent or incorrect state.
• SQL Server: SQL Server uses the transaction log to keep track of all changes made within a transaction. If a transaction needs to be rolled back, SQL Server uses the log to undo those changes. If an error occurs during a transaction, SQL Server will often automatically initiate a rollback, or you can explicitly issue a ROLLBACK TRAN command.
• Example (Bank Transfer):
○ You start the transfer transaction (BEGIN TRAN).
○ You successfully deduct $100 from Account A.
○ BUT before you can add $100 to Account B, the database server crashes.
Because of Atomicity, when the server restarts and recovers, it sees that the transaction wasn't completed (it wasn't COMMITted). It will use the transaction log to undo the deduction from Account A. Account A's balance will be back to what it was before the transaction. It's as if the transaction never happened.
Consistency
• Think of it: "Valid State to Valid State."
• What it means: A transaction brings the database from one valid state to another valid state. This doesn't mean the transaction logic itself is perfect (you could accidentally transfer the wrong amount!), but it ensures that the transaction adheres to all defined database rules and constraints. These rules include things like:
○ Constraints: PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK constraints (e.g., Balance must be >= 0).
○ Data Types: Ensuring you don't try to put text into a number column.
○ Triggers: Database logic that automatically runs on inserts, updates, or deletes.
If a transaction would violate any of these rules, it cannot be committed, and it will be rolled back.
• Why it's important: Maintains the integrity of your data and enforces the structure and business rules defined within the database schema.
• SQL Server: SQL Server automatically checks for constraint violations and executes triggers as part of the transaction. If a violation occurs, the transaction fails.
• Example (Bank Transfer):
○ Let's say you have a CHECK constraint on the Balance column of your Accounts table that says Balance >= 0.
○ You try to transfer $200 from Account A, which only has $150.
○ You start the transaction (BEGIN TRAN).
○ You deduct 200 from Account - A. Account A′s balance temporarily becomes −50 within the transaction's scope.
○ When you try to COMMIT TRAN, SQL Server checks all constraints. It sees that Account A's balance is negative, which violates the CHECK constraint.
○ Because of Consistency (and the constraint), the COMMIT fails, and the transaction is automatically rolled back. Account A's balance returns to $150. The database remains in a valid state where no account has a negative balance.
Isolation
• Think of it: "Transactions Don't Step on Each Other's Toes."
• What it means: Multiple transactions running at the same time should not interfere with each other. From the perspective of one transaction, it should appear as if it is the only transaction running on the database. This prevents various concurrency problems (like one transaction reading data that another transaction is changing but hasn't committed yet, or two transactions trying to update the same data simultaneously in a conflicting way).
• Why it's important: Allows multiple users or applications to access and modify the database concurrently without causing errors or returning incorrect results.
• SQL Server: SQL Server provides different Isolation Levels (like READ COMMITTED, SNAPSHOT, etc.) which control how much isolation you get. Higher isolation levels provide stronger guarantees but can sometimes impact performance because SQL Server might need to use more locks or versioning to keep transactions separate. The default level in SQL Server is READ COMMITTED, which prevents reading data that another transaction has modified but not yet committed (known as "Dirty Reads").
• Example (Bank Transfer):
○ Transaction 1 starts to transfer $100 from Account A to Account B. (BEGIN TRAN, deducts from A, prepares to add to B).
○ At the exact same time, Transaction 2 starts to read the balances of Account A and Account B to generate a report.
○ Because of Isolation, Transaction 2 will typically not see the temporary state where Account A has been debited but Account B hasn't been credited yet (especially with the default READ COMMITTED isolation level). Transaction 2 will likely see the balances as they were before Transaction 1 started, or it might wait until Transaction 1 is fully committed before reading. This ensures Transaction 2 gets a consistent view of the data, even though it's running concurrently with a transaction that's modifying that data.
Durability
• Think of it: "Changes are Permanent, Even After a Crash."
• What it means: Once a transaction has been successfully committed, its changes are permanent and will survive even if the database server crashes, loses power, or restarts immediately after the commit. The committed data is stored in a way that guarantees it won't be lost.
• Why it's important: Ensures that once a user or application gets confirmation that a transaction is complete (e.g., "Your transfer is successful"), they can trust that the changes have truly been saved and won't disappear.
• SQL Server: When you COMMIT TRAN, SQL Server ensures that the record of the transaction's changes is written to the transaction log on disk. Writing to the log is typically faster than writing the actual data pages to disk. Even if the server crashes after the log record is safely written but before the changes are written to the main data files, SQL Server can use the transaction log during startup recovery to redo the committed transaction and ensure the data files reflect the committed state.
• Example (Bank Transfer):
○ You successfully complete the transfer: $100 is deducted from Account A, and $100 is added to Account B.
○ You issue COMMIT TRAN. SQL Server confirms the commit back to your application.
○ Immediately after receiving the confirmation, the power goes out, and the server shuts down.
○ Because of Durability, when the server is restarted, SQL Server performs a recovery process. It reads the transaction log, sees that your transfer transaction was committed, and ensures that the changes (deducting from A and adding to B) are fully applied to the actual data files on disk. When you next check the balances, they will correctly reflect the transfer.
Next
ACID properties are the backbone of reliable database systems like SQL Server
Out of all 4 of these properties, Isolation is the property we can configure mostly on SQL Server.
Atomicity and Durability is automatically implemented in the SQL server core code to make sure all transactions are adhere to them (otherwise no proper transaction). Although we define rules (business rules via constraints and triggers) for Consistency, enforcing them (once defined and enabled) is automatic (no intervention required from us).
However, Isolation property is much more configurable. This is because there is a trade-off between high Isolation and performances. Therefore, SQL server allows user to choose several pre-defined Isolation levels based on performance requirements.
So let's explore more on Isolation levels in our next module.
