Theory
आधे-अधूरे Banking की आपदा
कल्पना कीजिए आपका university billing portal आपकी semester examination fee process कर रहा है। आपका script एक update statement trigger करता है जो सफलतापूर्वक आपके bank account table से ₹5,000 घटाता है। पर ठीक जब server दूसरा update statement execute करने वाला होता है ताकि आपका student status 'Paid' चिह्नित करे, college campus को एक अचानक power failure या internet crash झेलना पड़ता है। अगर database updates आधे-अधूरे रह जाते हैं, आपका पैसा हवा में ग़ायब हो जाता है, पर college system फिर भी आपको admit card download करने से रोकता है! databases यह कैसे guarantee देते हैं कि एक multi-step sequence या तो पूरी तरह ख़त्म हो या पूरी तरह ख़ुद को un-execute करे, शून्य टूटा data पीछे छोड़ते हुए?
Theory
Notepad Draft बनाम स्थायी Marker
एक database में data changes लिखने को एक high-stakes group project पर काम करने की तरह सोचिए। जब आप standard DML commands (INSERT या UPDATE) type करते हैं, आप एक draft pad पर एक हल्की धूसर pencil से लिख रहे हैं। आपके group में कोई और अभी वे notes नहीं देख सकता, और अगर आप एक calculation typo करते हैं तो आप उन्हें आसानी से मिटा सकते हैं। एक COMMIT execute करना उन pencil lines को एक न-मिटने-वाले स्थायी ink marker से ट्रेस करने और sheet को साझा group cabinet में सबके देखने के लिए ले जाने जैसा है। एक ROLLBACK execute करना एक विशाल eraser लेने और draft pad को पूरी तरह साफ़ करके वापस वैसा करने जैसा है जैसा दिन शुरू होने पर दिखता था।
Theory
TCL Architecture और Transaction States औपचारिक रूप से
Relational Database Management Systems में, एक Transaction processing की एक तार्किक इकाई है जो एक या ज़्यादा data modification operations को एक अकेले अविभाज्य block के रूप में करती है। Transaction Control Language (TCL) commands इन blocks को manage करते हैं ताकि database systems के Atomicity और Consistency गुण लागू करें। जब तक एक transaction स्पष्ट रूप से अंतिम रूप न दिया जाए, सारे updates volatile session memory buffers के अंदर अलग रहते हैं, अन्य concurrent database users से पूरी तरह छिपे।
At a glance
Table 1: Transaction Control Language commands और उनके architectural प्रभाव का structural mapping।
| TCL Command | Operational System Behavior | Data Visibility and Permanence Scope |
|---|---|---|
| COMMIT | सारे active buffer changes को स्थायी रूप से physical disk storage blocks में लिखता है। | transaction block बंद करता है। Changes तुरंत सारे अन्य जुड़े database sessions को दिखने लगते हैं। |
| ROLLBACK | transaction रद्द करता है, session शुरू होने से हुआ हर uncommitted change undo करते हुए। | records को पूरी तरह उनके अंतिम ज्ञात stable state में बहाल करता है, buffer memory साफ़ करते हुए। |
| SAVEPOINT name | मौजूदा active transaction सीमाओं के भीतर एक अस्थायी, लेबल किया sub-checkpoint चिह्नित करता है। | पहले के सफल changes त्यागे बिना एक ख़ास milestone तक एक चयनात्मक rollback देता है। |
| ROLLBACK TO name | data changes को समय में पीछे नामित checkpoint location तक rewind करता है। | transaction सक्रिय रखता है, बाद के SQL statements को उस milestone से जारी रखने देते हुए। |
Theory
Worked Example: Fee Ledger Recovery का Blueprint
आइए एक exam-style तार्किक समस्या को कदम-दर-कदम ट्रेस करें। हम एक campus ledger table पर एक transaction block खोलेंगे, अस्थायी records insert करेंगे, explicit checkpoints लगाएँगे, और एक चयनात्मक rewind execute करेंगे ताकि storage में पीछे छूटे बिल्कुल row balances देखें।
Practical
Campus Wallet Transaction Pipeline
-- Step 1: Initialize the session state with an empty base tracking ledger
CREATE TABLE wallet_ledger (
tx_id INT PRIMARY KEY,
item_name VARCHAR(30),
amt INT
);
-- Step 2: Begin the sequence by logging the baseline breakfast charge
INSERT INTO wallet_ledger VALUES (1, 'Chai & Samosa', 50);
SAVEPOINT after_breakfast;
-- Step 3: Log subsequent library fine and print shop entries
INSERT INTO wallet_ledger VALUES (2, 'Library Overdue Fine', 100);
INSERT INTO wallet_ledger VALUES (3, 'Lab Printouts', 20);
SAVEPOINT after_studies;
-- Step 4: Accidentally execute a broken double-entry charge
INSERT INTO wallet_ledger VALUES (4, 'Accidental Duplicate Charge', 500);
-- Step 5: Execute structural rewinds and commit the final stable records
ROLLBACK TO after_studies;
ROLLBACK TO after_breakfast;
COMMIT;This example runs in Gri-Learn on the web, where you can edit it and see the output.
Think first
बचे हुए Database Rows को ट्रेस करें
rollbacks के क्रमिक प्रवाह का ध्यान से विश्लेषण कीजिए। Step 5 अपने double rollback commands के बाद एक अंतिम COMMIT statement execute करने के बाद, स्थायी wallet_ledger table के अंदर बिल्कुल कौन से records रहेंगे?
Show the answer
table में बिल्कुल एक ही row होगी: (1, 'Chai & Samosa', 50)।
क्यों? आइए घड़ी को पीछे ट्रेस करें: पहला rollback command (ROLLBACK TO after_studies) ने सफलतापूर्वक ₹500 का आकस्मिक duplicate charge मिटा दिया। पर, तुरंत अगला command (ROLLBACK TO after_breakfast) ने database state को समय में और भी पीछे rewind किया, 'Lab Printouts' और 'Library Overdue Fine' दोनों records undo करते हुए! चूँकि अंतिम COMMIT उसके तुरंत बाद execute हुआ, केवल breakfast record मिटाव से बचा।
Quiz
अगर एक developer एक वैकल्पिक command sequence चलाता है: INSERT, फिर SAVEPOINT A, फिर UPDATE, फिर एक 'TO' clause बिना एक standard bare ROLLBACK statement, database state का क्या होता है?
- केवल UPDATE statements undo होते हैं; शुरुआती INSERT सुरक्षित रूप से pending रहता है।
- पूरे active transaction block के दौरान हुआ हर एक change, INSERT और UPDATE दोनों समेत, पूरी तरह मिट जाता है।
- system एक तुरंत SyntaxError फेंकता है क्योंकि एक bare ROLLBACK statement savepoints को disable कर देता है।
- transaction checkpoint A तक auto-commit हो जाता है।
Show the answer
पूरे active transaction block के दौरान हुआ हर एक change, INSERT और UPDATE दोनों समेत, पूरी तरह मिट जाता है।
एक standard bare ROLLBACK; statement internal milestones नहीं खोजता। यह एक पूर्ण command cancel के रूप में काम करता है, transaction block खुलने से हुआ हर uncommitted row change मिटाते हुए, सारे active savepoints पूरी तरह घोलते हुए।
Quiz
एक database table के अंदर हुई data भिन्नताओं की स्थायित्व स्थिति क्या है अगर एक developer स्पष्ट रूप से COMMIT या ROLLBACK में से कोई execute किए बिना अपना terminal session साफ़-सुथरे समाप्त करता है?
- modifications public uncommitted records के रूप में globally प्रसारित होते हैं।
- ज़्यादातर enterprise RDBMS engines एक साफ़ exit को एक implicit COMMIT statement के रूप में व्याख्या करेंगे।
- ज़्यादातर standard relational database management systems data consistency की रक्षा के लिए एक automatic implicit ROLLBACK करते हैं।
- target tables भ्रष्ट हो जाती हैं और पूरी तरह memory space से गिर जाती हैं।
Show the answer
ज़्यादातर standard relational database management systems data consistency की रक्षा के लिए एक automatic implicit ROLLBACK करते हैं।
data safety लागू करने के लिए, RDBMS architectures एक 'fail-safe' protocol के तहत operate करते हैं। अगर एक connection अचानक बंद होता है, crash होता है, या एक explicit finalization command बिना exit करता है, engine active session को मृत मानता है और data को अखंडित रखने के लिए एक implicit ROLLBACK trigger करता है।
Watch out
Classic जाल: DDL Auto-Commit घात
semester laboratory examinations में सबसे आम मार्क-गँवाऊ जाल एक INSERT statement लिखना, फिर एक CREATE TABLE या DROP TABLE command, और फिर ROLLBACK से insert row undo होने की उम्मीद करना है। सावधान: CREATE, DROP, या ALTER जैसे Data Definition Language (DDL) statements पर्दे के पीछे एक automatic implicit COMMIT दागते हैं। यह आपकी सारी पिछली pencil rows को स्थायी रूप से storage में lock कर देता है, एक बाद के rollback को पूरी तरह बेकार बनाते हुए!
Theory
Transactions को Semester 3 PL/SQL से जोड़ना
transaction boundaries पर महारत secure enterprise software logic लिखने की एक ज़रूरी बुनियाद के रूप में काम करती है। Semester 3 Database Administration (BCA301) और backend development pipelines में, आप TCL statements को automated PL/SQL exception-handling blocks (EXCEPTION WHEN OTHERS THEN ROLLBACK;) के अंदर रखेंगे ताकि ऐसी applications बनाएँ जो अप्रत्याशित server crashes के दौरान भी ठोस रहें।
Summary
Key takeaways
- Transaction Control Language DML statements के समूहों को manage करता है ताकि databases एकीकृत और सुसंगत रहें।
- एक transaction एक all-or-nothing operation है जो अंतिम रूप दिए जाने तक row updates अलग रखता है।
- COMMIT command active buffer records को स्थायी रूप से physical storage disk पर lock करता है।
- ROLLBACK command uncommitted session memory changes को पूरी तरह साफ़ कर देता है।
- SAVEPOINT अस्थायी तार्किक milestones बनाता है जो चयनात्मक query rollbacks का समर्थन करते हैं।
- Memory Hook: COMMIT इसे हमेशा के लिए inks करता है, ROLLBACK draft slate साफ़ करता है, और DDL commands अपने-आप commit होते हैं!