1. What is a Transaction?
A transaction is a single logical unit of work in a database.
It could be:
A single SQL command (like UPDATE, INSERT)
Or a series of commands (like transferring money between two bank
accounts)
Example:
Transferring $50 from Account A to Account B involves:
1. Read A
2. Subtract 50 from A
3. Write new A
4. Read B
5. Add 50 to B
6. Write new B
Commit(save changes to harddrive -pehly ram me kam ho rha tha)
All these steps together form one transaction.
(read-access,write -update)
2. The ACID Properties
Databases need to be reliable, especially when handling money, health
records, etc.
That’s why transactions must follow ACID rules:
Atomicity → All or nothing.
If any step fails, the whole transaction is rolled back (undone).
Consistency → The database must stay in a valid state before and after
the transaction.
Example: In a money transfer, the total money before and after must
be the same.
Isolation → Transactions should not interfere with each other.
If two transactions run at the same time, they shouldn’t see each
other’s partial results……….basically parallel (concurrent) schedule ko
Serializability me convert kr rhay(consistent)
Durability → Once a transaction is committed, it stays saved even if the
system crashes.-----lifetime save honi chayey info..(hard drive me save)
Consistency is the goal: ensuring the database stays in a valid state
where all data rules are followed.
Serializability is the mechanism: It ensures that even if transactions
are running concurrently (or in parallel), the final result is the same
as if they had run serially (one after another).
1. Schedule
A schedule is the order in which operations (read/write) of multiple
transactions are executed in a database system.
Simple Explanation:
It’s like a timeline or sequence that shows when each step of different
transactions happens.
A schedule can be serial (one after another) or concurrent (mixed
together).
2. Serial Schedule
A serial schedule means transactions run one after another, with no
interleaving of steps.
Characteristics:
Simple, safe, and easy to understand.
No concurrency — only one transaction at a time.
Always correct (preserves consistency) but very slow.
Example (from your slide):
Here, T1 finishes completely before T2 starts.
That’s a serial schedule.
3. Parallel Schedule (or Concurrent Schedule)
A parallel schedule means transactions run at the same time and their
operations interleave (mix together).
Characteristics:
Faster because multiple transactions use system resources
simultaneously.
But risky — can cause inconsistency if not controlled properly.
Needs concurrency control (like locking or timestamping) to ensure
correctness.
EG:
This is a concurrent (parallel) schedule.
Concurrency
Concurrency means multiple transactions are executed
simultaneously in the system.
Why we use it:
Better performance — uses CPU and disk time efficiently.
Shorter response times — users don’t wait long.
Higher throughput — more transactions per second.
But the problem:
If two transactions try to update the same data at the same time, we can
get:
Lost updates (one overwrites the other)
Dirty reads (reading uncommitted data)
Inconsistent analysis (seeing half-updated data)
That’s why we need:
Serializability — make concurrent execution look like serial execution.
Locking, Timestamping, etc. — to control concurrency.
4. How Do We Manage Concurrency?
Two main methods:
Shared Lock vs Exclusive Lock
Shared Lock (S)
Used for read operations
Multiple transactions can hold it simultaneously
Exclusive Lock (X)
Used for read+ write operations
Only one transaction can hold it
Two-Phase Locking (2PL)
Two-Phase Locking (2PL) is a concurrency control protocol used in
DBMS to ensure serializability of transactions.
Phases of 2PL
1. Growing Phase
o A transaction acquires locks (shared or exclusive).
o No locks are released in this phase.
2. Shrinking Phase
o A transaction releases locks.
o No new locks can be acquired after the first lock release.
Key Rules
Lock acquisition must happen before lock release.
Once a lock is released, the transaction cannot request new locks.
Advantages
Ensures conflict serializability.
Maintains data consistency.
Disadvantages
Can cause deadlocks.
May reduce concurrency.
(ik unlock kray ga to
dosra use kr pae ga)
Timestamping
Timestamping is a deadlock-free concurrency control method that
uses timestamps to order transactions and ensure serializability without
locks.
How It Works:
1. Each transaction gets a unique timestamp when it starts
2. Operations are executed based on timestamp order. .—jo pehlay aye
ga wo pehlay complete.
3. Older transactions get priority.
4. Every data item keeps:
o read-timestamp – last transaction that read it.
o write-timestamp – last transaction that wrote it.
5. A transaction can read/write only if the last update was by an older
transaction. (agr pehlay wali read/write kr chuki hogi phir hi dosray
wali ko allow krein gay)
6. otherwise transaction requesting read/write is restarted with a new
timestamp.(rollback)
Key Rule:
Access allowed → if last update’s timestamp ≤ transaction’s
timestamp.
Access denied → transaction is restarted.
Advantages:
No deadlocks (no waiting).
Simple order enforcement.
Disadvantages:
Frequent restarts if conflicts are common.
Not ideal for high-contention environments.
Timestamping is useful in low-conflict, read-heavy systems where restart
overhead is acceptable and deadlock avoidance is critical.
Timestamp Lock-Based
Protocol Protocol
No locks Uses locks
No deadlock Deadlock possible
More rollbacks Less rollback
When to Use Which?
Use Timestamping when: Use Locking when:
Conflicts are rare Conflicts are common
Restart cost is low Restart cost is high
You want deadlock-free system You can handle deadlock detection
Read-heavy workloads Write-heavy workloads
Action What the Database Does Impact on Your
Data
Transaction Runs your SQL/Code, checks logic, and Creates the
Execution calculates new values. change initially.
Redo Re-writes the already calculated new values Ensures durability
(Recovery) into the drive..(after commit) after a crash.
Undo Uses "before-images" to overwrite incorrect Reverts
(Rollback) changes with their original values.—remove uncommitted or
all active steps(occur if crash occur before failed actions.
commit)
Checkpoint is a snapshot moment where everything in memory is
saved to disk.
During recovery:
o Redo transactions committed after checkpoint.
o Undo transactions still active at crash.
logs save records of all changes (even those already written to disk), while
checkpoints don't "contain data"—they trigger writing unwritten changes to
disk and add a marker.
ORACLE Memory Components (in easy words)
1. Buffer Cache
Think of this as Oracle’s short-term memory.
It keeps copies of data that Oracle is currently using.
When you run a SQL query, Oracle first looks here instead of reading
from disk (which is slower).
It can store many rows of a table.
If you change data (INSERT, UPDATE, DELETE), the changes are kept
here first.
Later, Oracle saves these changes to the disk.
👉 In short:
Buffer Cache = place where data is read and changed temporarily for fast
work
2. Redo Log Buffer
Think of this as Oracle’s change diary.
It stores records of every change you make to the database.
These records are called redo entries.
Oracle writes these redo entries to disk (redo log files).
If the database crashes, Oracle uses this info to recover the data.
👉 In short:
Redo Log Buffer = records what changes happened, so Oracle can fix things
if there is a crash
ORACLE Basics – Database Recovery (very simple)
To recover a database, Oracle needs:
1. A backup of the database
2. Archived redo log files (these contain all changes since the last
backup)
Using these:
Oracle restores the backup
Then applies redo logs
The database is recovered up to the last committed transaction
👉 In short:
Backup + Redo Logs = database recovery
One-line summary 🧠
Buffer Cache → stores data being used
Redo Log Buffer → stores change history
Recovery → uses backup + redo logs