DBMS — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 127 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
127 questions
91
EN + हिं Hard
GB What is the phantom problem in predicate-based concurrency control and why is row-level locking insufficient?
IN विधेय-आधारित समवर्ती नियंत्रण में प्रेत समस्या क्या है और पंक्ति-स्तरीय लॉकिंग अपर्याप्त क्यों है?
A
A problem with index corruption during concurrent access समवर्ती पहुंच के दौरान सूचकांक भ्रष्टाचार की समस्या
B
A problem specific to aggregate queries only केवल समग्र प्रश्नों के लिए विशिष्ट समस्या
C
A problem with deleted rows appearing in queries क्वेरीज़ में दिखाई देने वाली हटाई गई पंक्तियों के साथ एक समस्या
D
New rows satisfying a predicate can be inserted by other transactions after the predicate is evaluated causing re-evaluation to return different rows - row-level locking cannot prevent this because the new rows do not exist yet when locks are acquired (cannot lock non-existent rows) विधेय को संतुष्ट करने वाली नई पंक्तियों को विधेय के मूल्यांकन के बाद अन्य लेनदेन द्वारा डाला जा सकता है, जिससे पुनर्मूल्यांकन अलग-अलग पंक्तियों को वापस कर सकता है - पंक्ति-स्तरीय लॉकिंग इसे रोक नहीं सकती है क्योंकि ताले प्राप्त होने पर नई पंक्तियाँ अभी तक मौजूद नहीं हैं (गैर-मौजूद पंक्तियों को लॉक नहीं किया जा सकता है)
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Phantom problem: T1 locks all existing rows WHERE salary>50K (say 10 rows). T2 inserts a new row with salary=60K (no row lock exists for it yet - it is a new row). T1 re-queries and sees 11 rows. Row-level locks only lock EXISTING rows. Must use predicate/gap locks to prevent insertions matching the predicate.
व्याख्या (हिन्दी) प्रेत समस्या: T1 सभी मौजूदा पंक्तियों को लॉक कर देता है जहां वेतन>50K (मान लीजिए 10 पंक्तियाँ) है। T2 वेतन=60K के साथ एक नई पंक्ति सम्मिलित करता है (इसके लिए अभी तक कोई पंक्ति लॉक मौजूद नहीं है - यह एक नई पंक्ति है)। T1 पुनः प्रश्न करता है और 11 पंक्तियाँ देखता है। पंक्ति-स्तरीय ताले केवल मौजूदा पंक्तियों को लॉक करते हैं। विधेय से मेल खाने वाले सम्मिलनों को रोकने के लिए विधेय/गैप लॉक का उपयोग करना चाहिए।
92
EN + हिं Hard
GB What is two-version locking (2V2PL) and how does it improve read performance?
IN दो-संस्करण लॉकिंग (2V2PL) क्या है और यह पढ़ने के प्रदर्शन को कैसे बेहतर बनाता है?
A
A concurrency control combining 2PL with two versions of data: write transactions use 2PL to synchronize with each other but read transactions read older committed versions (not the newest possibly-being-written version) allowing reads to proceed without waiting for write locks डेटा के दो संस्करणों के साथ 2PL को संयोजित करने वाला एक समवर्ती नियंत्रण: लेनदेन लिखने के लिए एक दूसरे के साथ सिंक्रनाइज़ करने के लिए 2PL का उपयोग करें, लेकिन लेनदेन पढ़ें पुराने प्रतिबद्ध संस्करणों को पढ़ें (नवीनतम संभवतः लिखित संस्करण नहीं) जो लेखन लॉक की प्रतीक्षा किए बिना पढ़ने को आगे बढ़ने की अनुमति देता है
B
A locking protocol that allows two simultaneous versions of each transaction एक लॉकिंग प्रोटोकॉल जो प्रत्येक लेनदेन के एक साथ दो संस्करणों की अनुमति देता है
C
A locking protocol using two versions of the same lock एक लॉकिंग प्रोटोकॉल जो एक ही लॉक के दो संस्करणों का उपयोग करता है
D
Two-phase locking applied twice for extra safety अतिरिक्त सुरक्षा के लिए दो-चरण लॉकिंग दो बार लागू की गई
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) 2V2PL: maintains two versions: committed version (for readers) and tentative version (for current writer). Read transactions access committed version without waiting. Write transactions use 2PL among themselves. When writer commits, tentative becomes committed. Readers never blocked by writers - better read concurrency than standard 2PL.
व्याख्या (हिन्दी) 2V2PL: दो संस्करण बनाए रखता है: प्रतिबद्ध संस्करण (पाठकों के लिए) और अस्थायी संस्करण (वर्तमान लेखक के लिए)। प्रतीक्षा किए बिना लेन-देन पहुंच प्रतिबद्ध संस्करण पढ़ें। लेनदेन लिखें आपस में 2PL का उपयोग करें। जब लेखक प्रतिबद्ध होता है, तो अस्थायी प्रतिबद्ध हो जाता है। पाठकों को लेखकों द्वारा कभी भी अवरुद्ध नहीं किया गया - मानक 2PL की तुलना में बेहतर पठनीय समवर्तीता।
93
EN + हिं Easy
GB What is the multiversion timestamp ordering (MVTO) protocol?
IN मल्टीवर्जन टाइमस्टैम्प ऑर्डरिंग (एमवीटीओ) प्रोटोकॉल क्या है?
A
A protocol for ordering multiple versions of the database schema डेटाबेस स्कीमा के एकाधिक संस्करणों को ऑर्डर करने के लिए एक प्रोटोकॉल
B
A timestamp ordering protocol for distributed systems वितरित सिस्टम के लिए एक टाइमस्टैम्प ऑर्डरिंग प्रोटोकॉल
C
A concurrency control combining MVCC with timestamp ordering: each write creates a new version with the writing transactions timestamp; reads access the latest version with a timestamp less than or equal to the reading transactions timestamp without blocking; conflicts resolved through timestamp ordering rules टाइमस्टैम्प ऑर्डरिंग के साथ एमवीसीसी को संयोजित करने वाला एक समवर्ती नियंत्रण: प्रत्येक लेखन लेखन लेनदेन टाइमस्टैम्प के साथ एक नया संस्करण बनाता है; रीड्स बिना किसी अवरोध के रीडिंग ट्रांजेक्शन टाइमस्टैम्प से कम या उसके बराबर टाइमस्टैम्प के साथ नवीनतम संस्करण तक पहुंच प्राप्त करता है; टाइमस्टैम्प आदेश नियमों के माध्यम से विवादों का समाधान किया गया
D
A method for timestamping concurrent database connections समवर्ती डेटाबेस कनेक्शन को टाइमस्टैम्प करने की एक विधि
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) MVTO: each write creates version (value, W_ts=transaction timestamp). Read T accesses the version with the largest write timestamp that is still less than or equal to TS(T). Reads never blocked (always a valid version to read). Writes may conflict (abort if TS(T) < max_R_TS of the latest version). Combines MVCC flexibility with timestamp ordering conflict resolution.
व्याख्या (हिन्दी) एमवीटीओ: प्रत्येक लेखन संस्करण बनाता है (मान, W_ts = लेनदेन टाइमस्टैम्प)। रीड टी सबसे बड़े राइट टाइमस्टैम्प वाले संस्करण तक पहुंचता है जो अभी भी टीएस (टी) से कम या उसके बराबर है। पढ़ने को कभी भी अवरुद्ध नहीं किया जाता (हमेशा पढ़ने के लिए एक वैध संस्करण)। लेखन में विरोध हो सकता है (यदि नवीनतम संस्करण का TS(T) < max_R_TS है तो निरस्त करें)। टाइमस्टैम्प ऑर्डरिंग संघर्ष समाधान के साथ एमवीसीसी लचीलेपन को जोड़ता है।
94
EN + हिं Medium
GB What is serializable snapshot isolation (SSI) and how does it detect write skew?
IN क्रमबद्ध स्नैपशॉट अलगाव (एसएसआई) क्या है और यह लेखन विषमता का पता कैसे लगाता है?
A
A variant of snapshot isolation with stronger locks मजबूत तालों के साथ स्नैपशॉट अलगाव का एक प्रकार
B
A write-optimized version of snapshot isolation स्नैपशॉट अलगाव का एक लेखन-अनुकूलित संस्करण
C
A snapshot isolation that serializes all transactions एक स्नैपशॉट अलगाव जो सभी लेनदेन को क्रमबद्ध करता है
D
An algorithm that detects and prevents write skew anomalies while still using snapshot isolation for reads (avoiding lock-based blocking); it tracks anti-dependency (rw) edges in the transaction graph and aborts transactions that would create dangerous structures (concurrent cycles of rw-anti-dependencies) एक एल्गोरिथ्म जो पढ़ने के लिए स्नैपशॉट अलगाव का उपयोग करते हुए (लॉक-आधारित अवरोधन से बचते हुए) लेखन तिरछी विसंगतियों का पता लगाता है और रोकता है; यह लेन-देन ग्राफ़ में एंटी-डिपेंडेंसी (आरडब्ल्यू) किनारों को ट्रैक करता है और उन लेनदेन को निरस्त करता है जो खतरनाक संरचनाएं बनाते हैं (आरडब्ल्यू-एंटी-डिपेंडेंसी के समवर्ती चक्र)
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SSI (PostgreSQL 9.1+): uses snapshot isolation for reads (no read locks, no blocking). Detects write skew by tracking rw-anti-dependency edges: if T1 reads data written by T2 AND T2 reads data written by T1 (or modified by T1), one must abort. Detects dangerous double rw-anti-dependency cycles. Provides serializability without write locks: high concurrency with strong guarantees.
व्याख्या (हिन्दी) एसएसआई (पोस्टग्रेएसक्यूएल 9.1+): रीड्स के लिए स्नैपशॉट आइसोलेशन का उपयोग करता है (कोई रीड लॉक नहीं, कोई ब्लॉकिंग नहीं)। आरडब्ल्यू-एंटी-डिपेंडेंसी किनारों को ट्रैक करके राइट स्कू का पता लगाता है: यदि टी1 टी2 द्वारा लिखे गए डेटा को पढ़ता है और टी2 टी1 द्वारा लिखे गए डेटा को पढ़ता है (या टी1 द्वारा संशोधित), तो किसी को निरस्त करना होगा। खतरनाक डबल आरडब्ल्यू-एंटी-डिपेंडेंसी चक्रों का पता लगाता है। राइट लॉक के बिना क्रमबद्धता प्रदान करता है: मजबूत गारंटी के साथ उच्च संगामिति।
95
EN + हिं Hard
GB What is the distinction between recoverable and non-recoverable schedules in concurrency control?
IN समवर्ती नियंत्रण में पुनर्प्राप्ति योग्य और गैर-पुनर्प्राप्ति योग्य अनुसूचियों के बीच क्या अंतर है?
A
All schedules produced by 2PL are non-recoverable 2PL द्वारा निर्मित सभी शेड्यूल गैर-पुनर्प्राप्ति योग्य हैं
B
Non-recoverable schedules are only possible in distributed databases गैर-पुनर्प्राप्ति योग्य शेड्यूल केवल वितरित डेटाबेस में ही संभव हैं
C
Recoverable schedules require serializable isolation पुनर्प्राप्ति योग्य शेड्यूल के लिए क्रमबद्ध अलगाव की आवश्यकता होती है
D
A recoverable schedule ensures that if a transaction Ti reads data written by Tj then Tj must commit before Ti commits (preventing dirty read scenario from corrupting committed data). A non-recoverable schedule allows Ti to commit before Tj commits - if Tj then aborts Ti cannot be rolled back even though it read uncommitted data creating a permanent corruption एक पुनर्प्राप्ति योग्य शेड्यूल यह सुनिश्चित करता है कि यदि कोई लेनदेन Ti, Tj द्वारा लिखे गए डेटा को पढ़ता है तो Tj को Ti के प्रतिबद्ध होने से पहले प्रतिबद्ध होना चाहिए (गंदे रीड परिदृश्य को प्रतिबद्ध डेटा को दूषित होने से रोकना)। एक गैर-पुनर्प्राप्ति योग्य शेड्यूल Ti को Tj के प्रतिबद्ध होने से पहले प्रतिबद्ध होने की अनुमति देता है - यदि Tj फिर निरस्त हो जाता है तो Ti को वापस नहीं लाया जा सकता है, भले ही यह अप्रतिबद्ध डेटा को पढ़ता है जिससे स्थायी भ्रष्टाचार पैदा होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Recoverable schedule: if Ti reads value written by Tj (uncommitted), Ti cannot commit until Tj commits. This ensures: if Tj aborts, Ti can also be aborted (Ti had not committed yet). Non-recoverable: Ti commits before Tj commits -> if Tj aborts, Ti had committed data that never existed -> cannot undo committed transaction. Strict 2PL (no dirty reads) automatically makes schedules recoverable.
व्याख्या (हिन्दी) पुनर्प्राप्त करने योग्य शेड्यूल: यदि Ti, Tj (अप्रतिबद्ध) द्वारा लिखे गए मान को पढ़ता है, तो Tj के प्रतिबद्ध होने तक Ti प्रतिबद्ध नहीं हो सकता है। यह सुनिश्चित करता है: यदि Tj गर्भपात करता है, तो Ti को भी निरस्त किया जा सकता है (Ti ने अभी तक प्रतिबद्ध नहीं किया था)। गैर-पुनर्प्राप्ति योग्य: Tj के प्रतिबद्ध होने से पहले Ti प्रतिबद्ध होता है -> यदि Tj निरस्त हो जाता है, तो Ti ने ऐसा डेटा प्रतिबद्ध किया था जो कभी अस्तित्व में ही नहीं था -> प्रतिबद्ध लेनदेन को पूर्ववत नहीं किया जा सकता है। सख्त 2PL (कोई गंदा पाठ नहीं) स्वचालित रूप से शेड्यूल को पुनर्प्राप्त करने योग्य बनाता है।
96
EN + हिं Hard
GB What is the ACA (Avoids Cascading Aborts) property in concurrency control schedules?
IN समवर्ती नियंत्रण अनुसूचियों में ACA (कैस्केडिंग गर्भपात से बचाता है) संपत्ति क्या है?
A
A schedule avoids cascading aborts (ACA) if transactions only read values written by COMMITTED transactions - even if those committed transactions read from other uncommitted transactions. ACA is stronger than recoverability but weaker than strict schedules; ACA schedules never require cascading rollbacks यदि लेन-देन केवल प्रतिबद्ध लेन-देन द्वारा लिखे गए मानों को पढ़ता है, तो एक शेड्यूल कैस्केडिंग एबॉर्ट (एसीए) से बचता है - भले ही वे प्रतिबद्ध लेन-देन अन्य अप्रतिबद्ध लेन-देन से पढ़े जाते हों। एसीए पुनर्प्राप्ति से अधिक मजबूत है लेकिन सख्त शेड्यूल से कमजोर है; एसीए शेड्यूल को कभी भी व्यापक रोलबैक की आवश्यकता नहीं होती है
B
A property that prevents all transaction aborts एक संपत्ति जो सभी लेन-देन को रोकती है, निरस्त हो जाती है
C
A property specific to distributed database schedules वितरित डेटाबेस अनुसूचियों के लिए विशिष्ट संपत्ति
D
A property that limits the number of aborts in a schedule एक संपत्ति जो एक अनुसूची में गर्भपात की संख्या को सीमित करती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) ACA property: every transaction reads only committed data. If T reads only committed writes, T can never become dirty-read from an aborted transaction. This prevents cascading aborts entirely (no transaction read from T if T aborts, because T only read committed data - it cannot cascade). Strict 2PL (hold all locks until commit) guarantees ACA automatically.
व्याख्या (हिन्दी) एसीए संपत्ति: प्रत्येक लेनदेन केवल प्रतिबद्ध डेटा पढ़ता है। यदि टी केवल प्रतिबद्ध लेखन पढ़ता है, तो टी कभी भी निरस्त लेनदेन से गंदा-पढ़ा नहीं जा सकता है। यह कैस्केडिंग को पूरी तरह से निरस्त होने से रोकता है (यदि टी निरस्त हो जाता है तो टी से कोई लेन-देन नहीं पढ़ा जाता है, क्योंकि टी केवल प्रतिबद्ध डेटा पढ़ता है - यह कैस्केड नहीं कर सकता है)। स्ट्रिक्ट 2PL (कमिट होने तक सभी लॉक को पकड़कर रखें) स्वचालित रूप से ACA की गारंटी देता है।
97
EN + हिं Easy
GB What is the relationship between the isolation levels and the schedule properties (recoverable ACA strict)?
IN अलगाव स्तर और शेड्यूल गुणों (पुनर्प्राप्ति योग्य एसीए सख्त) के बीच क्या संबंध है?
A
Schedule properties apply only to single-transaction systems शेड्यूल गुण केवल एकल-लेन-देन प्रणालियों पर लागू होते हैं
B
Higher isolation levels produce weaker schedule properties उच्च अलगाव स्तर कमजोर शेड्यूल गुण उत्पन्न करते हैं
C
They are completely unrelated concepts वे पूरी तरह से असंबद्ध अवधारणाएँ हैं
D
Isolation levels impose schedules with specific properties: READ UNCOMMITTED may produce non-recoverable schedules. READ COMMITTED produces ACA schedules (reads only committed data). REPEATABLE READ produces ACA schedules and additionally prevents non-repeatable reads. SERIALIZABLE produces strict schedules (only committed data read held until commit) and conflict-serializable execution histories अलगाव स्तर विशिष्ट गुणों के साथ शेड्यूल लागू करते हैं: रीड अनकमिटेड गैर-पुनर्प्राप्ति योग्य शेड्यूल उत्पन्न कर सकता है। रीड कमिटेड एसीए शेड्यूल तैयार करता है (केवल प्रतिबद्ध डेटा पढ़ता है)। दोहराए जाने योग्य रीड एसीए शेड्यूल तैयार करता है और इसके अतिरिक्त गैर-दोहराए जाने योग्य रीड को रोकता है। SERIALIZABLE सख्त शेड्यूल (केवल प्रतिबद्ध डेटा को प्रतिबद्ध होने तक पढ़ा जाता है) और संघर्ष-क्रमबद्ध निष्पादन इतिहास तैयार करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Schedule property hierarchy: Strict (all writes held until commit) > ACA (read only committed) > Recoverable (commit order respects read-from relationship) > All schedules. Isolation level mapping: READ UNCOMMITTED: any schedule. READ COMMITTED: ACA (reads only committed data). REPEATABLE READ: ACA + non-repeatable read prevention. SERIALIZABLE: strict + conflict-serializable.
व्याख्या (हिन्दी) शेड्यूल संपत्ति पदानुक्रम: सख्त (कमिट होने तक सभी लेखन रोके गए) > एसीए (केवल पढ़ने के लिए प्रतिबद्ध) > पुनर्प्राप्त करने योग्य (प्रतिबद्ध आदेश रीड-फ्रॉम संबंध का सम्मान करता है) > सभी शेड्यूल। अलगाव स्तर मानचित्रण: अप्रतिबद्ध पढ़ें: कोई भी कार्यक्रम। प्रतिबद्ध पढ़ें: एसीए (केवल प्रतिबद्ध डेटा पढ़ता है)। दोहराए जाने योग्य पढ़ें: एसीए + गैर-दोहराए जाने योग्य पढ़ने की रोकथाम। क्रमबद्ध: सख्त + संघर्ष-क्रमबद्ध।
98
EN + हिं Easy
GB What is lock contention and what strategies reduce it in high-throughput OLTP systems?
IN लॉक विवाद क्या है और उच्च-थ्रूपुट ओएलटीपी सिस्टम में कौन सी रणनीतियाँ इसे कम करती हैं?
A
Lock contention occurs when multiple transactions compete for the same locks causing waiting and reducing throughput; strategies to reduce it: shorter transactions, access patterns that minimize lock scope, optimistic locking, MVCC (readers never block writers), partitioning hot data across shards, and batch versus row-level updates लॉक विवाद तब होता है जब कई लेनदेन एक ही लॉक के लिए प्रतिस्पर्धा करते हैं जिससे प्रतीक्षा होती है और थ्रूपुट कम हो जाता है; इसे कम करने की रणनीतियाँ: छोटे लेन-देन, एक्सेस पैटर्न जो लॉक स्कोप को कम करते हैं, आशावादी लॉकिंग, एमवीसीसी (पाठक कभी लेखकों को ब्लॉक नहीं करते हैं), हॉट डेटा को शार्क में विभाजित करना, और बैच बनाम पंक्ति-स्तरीय अपडेट
B
The overhead of managing too many database connections simultaneously एक साथ बहुत सारे डेटाबेस कनेक्शन प्रबंधित करने का ओवरहेड
C
Lock contention is a hardware-level issue unrelated to database design लॉक विवाद एक हार्डवेयर-स्तर का मुद्दा है जो डेटाबेस डिज़ाइन से असंबंधित है
D
Lock contention only occurs in distributed databases not single-server systems लॉक विवाद केवल वितरित डेटाबेस में होता है, एकल-सर्वर सिस्टम में नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hot spot examples: account balance row (many transactions increment it), auto-increment counter (each insert locks the counter), status column with low cardinality (UPDATE status=processing WHERE status=pending - all compete for same rows). Solutions: Redis atomic INCR for counters (move hot counter out of DB), UUID primary keys (distribute inserts), sharding by user_id (distribute account updates), SELECT FOR UPDATE SKIP LOCKED.
व्याख्या (हिन्दी) हॉट स्पॉट उदाहरण: खाता शेष पंक्ति (कई लेन-देन इसे बढ़ाते हैं), ऑटो-वृद्धि काउंटर (प्रत्येक प्रविष्टि काउंटर को लॉक करती है), कम कार्डिनैलिटी के साथ स्थिति कॉलम (अद्यतन स्थिति = प्रसंस्करण जहां स्थिति = लंबित - सभी समान पंक्तियों के लिए प्रतिस्पर्धा करते हैं)। समाधान: काउंटरों के लिए रेडिस एटॉमिक आईएनसीआर (डीबी से हॉट काउंटर को बाहर ले जाएं), यूयूआईडी प्राथमिक कुंजी (इन्सर्ट वितरित करें), यूजर_आईडी द्वारा शार्डिंग (खाता अपडेट वितरित करें), अपडेट स्किप लॉक के लिए चयन करें।
99
EN + हिं Easy
GB What is SELECT FOR UPDATE SKIP LOCKED and what use case does it enable?
IN सेलेक्ट फॉर अपडेट स्किप लॉक्ड क्या है और यह किस उपयोग के मामले को सक्षम बनाता है?
A
A SELECT that skips rows with NULL values in locked columns एक चयन जो लॉक किए गए कॉलम में NULL मान वाली पंक्तियों को छोड़ देता है
B
A SELECT that skips the locking mechanism entirely for performance एक चयन जो प्रदर्शन के लिए लॉकिंग तंत्र को पूरी तरह से छोड़ देता है
C
An optimization that skips unnecessary locks on large unfiltered result sets एक अनुकूलन जो बड़े अनफ़िल्टर्ड परिणाम सेटों पर अनावश्यक लॉक को हटा देता है
D
An extension to SELECT FOR UPDATE that skips (does not return or wait for) rows that are already locked by other transactions; enables non-blocking queue-like processing where multiple workers can each claim and process different rows without contention - perfect for job queues, task processing systems, and any pattern where multiple workers process items from a shared pool अपडेट के लिए चयन करने के लिए एक एक्सटेंशन जो उन पंक्तियों को छोड़ देता है (वापस नहीं करता है या प्रतीक्षा नहीं करता है) जो पहले से ही अन्य लेनदेन द्वारा लॉक हैं; गैर-अवरुद्ध कतार-जैसी प्रसंस्करण को सक्षम बनाता है जहां कई कर्मचारी दावा कर सकते हैं और बिना किसी विवाद के अलग-अलग पंक्तियों को संसाधित कर सकते हैं - नौकरी कतारों, कार्य प्रसंस्करण प्रणालियों और किसी भी पैटर्न के लिए बिल्कुल सही जहां कई कार्यकर्ता एक साझा पूल से आइटम संसाधित करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Job queue implementation: Worker: BEGIN; SELECT * FROM jobs WHERE status=pending ORDER BY created_at LIMIT 1 FOR UPDATE SKIP LOCKED; UPDATE jobs SET status=processing WHERE id=?; COMMIT; Process job; BEGIN; UPDATE jobs SET status=done WHERE id=?; COMMIT. Multiple workers run this simultaneously: each claims a different row (SKIP LOCKED skips rows other workers have locked). Supported: PostgreSQL 9.5+, MySQL 8.0+.
व्याख्या (हिन्दी) कार्य कतार कार्यान्वयन: कार्यकर्ता: प्रारंभ; * उन नौकरियों से चुनें जहां स्थिति=अद्यतन के लिए LIMIT 1 पर create_at द्वारा लंबित ऑर्डर स्किप लॉक किया गया; नौकरियां अद्यतन करें सेट स्थिति=प्रसंस्करण कहां आईडी=?; प्रतिबद्ध; प्रक्रिया कार्य; शुरू करना; अद्यतन नौकरियाँ सेट स्थिति=किया गया जहाँ आईडी=?; प्रतिबद्ध। एकाधिक कर्मचारी इसे एक साथ चलाते हैं: प्रत्येक एक अलग पंक्ति का दावा करता है (SKIP LOCKED उन पंक्तियों को छोड़ देता है जिन्हें अन्य श्रमिकों ने लॉक किया है)। समर्थित: PostgreSQL 9.5+, MySQL 8.0+।
100
EN + हिं Easy
GB What is the intention lock hierarchy (IS, IX, SIX locks) and what problem does it solve?
IN इरादा लॉक पदानुक्रम (IS, IX, SIX लॉक) क्या है और यह किस समस्या का समाधान करता है?
A
A hierarchical locking mechanism: Intention Shared (IS) and Intention Exclusive (IX) are set on higher-level objects (table page) to signal intent to lock rows within them - this avoids scanning all row-level locks to check table-level lock compatibility making table-level lock checks O(1) instead of O(rows) एक पदानुक्रमित लॉकिंग तंत्र: इंटेंट शेयर्ड (आईएस) और इंटेंट एक्सक्लूसिव (IX) को उनके भीतर पंक्तियों को लॉक करने के इरादे का संकेत देने के लिए उच्च-स्तरीय ऑब्जेक्ट (तालिका पृष्ठ) पर सेट किया जाता है - यह टेबल-स्तरीय लॉक संगतता की जांच करने के लिए सभी पंक्ति-स्तरीय लॉक को स्कैन करने से बचाता है, जिससे टेबल-स्तरीय लॉक ओ (पंक्तियों) के बजाय ओ (1) की जांच करता है।
B
Locks used to signal transaction priority लेन-देन की प्राथमिकता का संकेत देने के लिए ताले का उपयोग किया जाता है
C
Locks that create intentions for future queries ताले जो भविष्य के प्रश्नों के इरादे बनाते हैं
D
Locks that express intention to acquire more locks ताले जो अधिक ताले प्राप्त करने का इरादा व्यक्त करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without intention locks: to lock a table, must check if any row in table is locked by another transaction (O(n) scan). With intention locks: before locking row X, first set IS/IX on containing table/page. Table-level lock check: just check table IS/IX locks - O(1). Hierarchy: database -> table -> page -> row.
व्याख्या (हिन्दी) इरादे के बिना लॉक: किसी तालिका को लॉक करने के लिए, यह जांचना होगा कि तालिका में कोई पंक्ति किसी अन्य लेनदेन (ओ (एन) स्कैन) द्वारा लॉक की गई है या नहीं। इरादे वाले लॉक के साथ: पंक्ति X को लॉक करने से पहले, पहले तालिका/पेज पर IS/IX सेट करें। टेबल-स्तरीय लॉक जांच: बस टेबल IS/IX लॉक की जांच करें - O(1)। पदानुक्रम: डेटाबेस -> तालिका -> पृष्ठ -> पंक्ति।
101
EN + हिं Easy
GB What is lock escalation and when does it trigger?
IN लॉक एस्केलेशन क्या है और यह कब ट्रिगर होता है?
A
A mechanism to extend lock timeout duration लॉक टाइमआउट अवधि बढ़ाने के लिए एक तंत्र
B
A mechanism to upgrade S-locks to X-locks एस-लॉक को एक्स-लॉक में अपग्रेड करने का एक तंत्र
C
A mechanism to transfer locks between transactions लेनदेन के बीच ताले स्थानांतरित करने के लिए एक तंत्र
D
When a transaction acquires too many fine-grained locks (row/page level) the DBMS automatically escalates to a coarser-grained lock (table level) to reduce lock management overhead - reduces memory used for lock structures at the cost of reduced concurrency जब कोई लेन-देन बहुत अधिक बारीक-बारीक ताले (पंक्ति/पृष्ठ स्तर) प्राप्त करता है, तो लॉक प्रबंधन ओवरहेड को कम करने के लिए डीबीएमएस स्वचालित रूप से एक मोटे-दाने वाले ताले (तालिका स्तर) तक बढ़ जाता है - कम संगामिति की कीमत पर लॉक संरचनाओं के लिए उपयोग की जाने वाली मेमोरी को कम कर देता है।
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Lock escalation: if T holds 5000 row locks on table T1, the lock manager escalates to a single TABLE-level S or X lock. Benefit: dramatically reduces lock memory (5000 locks to 1). Drawback: blocks all other transactions on the entire table. SQL Server escalates at ~5000 locks or when lock memory exceeds threshold.
व्याख्या (हिन्दी) लॉक एस्केलेशन: यदि T टेबल T1 पर 5000 पंक्ति लॉक रखता है, तो लॉक मैनेजर एकल टेबल-स्तर S या X लॉक पर बढ़ता है। लाभ: लॉक मेमोरी को नाटकीय रूप से कम कर देता है (5000 लॉक से 1)। दोष: संपूर्ण तालिका पर अन्य सभी लेनदेन को अवरुद्ध करता है। SQL सर्वर ~5000 लॉक पर या जब लॉक मेमोरी थ्रेशोल्ड से अधिक हो जाती है तो बढ़ जाती है।
102
EN + हिं Medium
GB What is deadlock detection using a wait-for graph and how does the DBMS resolve detected deadlocks?
IN वेट-फॉर ग्राफ़ का उपयोग करके गतिरोध का पता लगाना क्या है और डीबीएमएस पता लगाए गए गतिरोधों को कैसे हल करता है?
A
A wait-for graph has one node per transaction and a directed edge T1 to T2 if T1 is waiting for a lock held by T2; a cycle in this graph indicates a deadlock; DBMS resolves by selecting a victim transaction to abort (typically the youngest cheapest or least-work-done transaction) यदि T1, T2 द्वारा रखे गए लॉक की प्रतीक्षा कर रहा है, तो प्रतीक्षा-ग्राफ़ में प्रति लेनदेन एक नोड और T1 से T2 तक एक निर्देशित किनारा होता है; इस ग्राफ़ में एक चक्र गतिरोध को इंगित करता है; डीबीएमएस निरस्त करने के लिए पीड़ित लेनदेन का चयन करके समाधान करता है (आमतौर पर सबसे कम उम्र का सबसे सस्ता या कम से कम काम करने वाला लेनदेन)
B
A graph showing the order of lock acquisitions लॉक अधिग्रहण का क्रम दर्शाने वाला ग्राफ़
C
Deadlocks are prevented rather than detected गतिरोधों का पता लगाने के बजाय उन्हें रोका जाता है
D
A graph used to optimize lock ordering लॉक ऑर्डरिंग को अनुकूलित करने के लिए उपयोग किया जाने वाला ग्राफ़
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Wait-for graph: periodically built by scanning lock table. Cycle = deadlock. Victim selection criteria: minimize rollback cost (youngest transaction, fewest locks, smallest undo log). Victim is rolled back, releasing its locks, breaking the cycle. Surviving transactions proceed. Detection overhead: O(transactions + locks).
व्याख्या (हिन्दी) प्रतीक्षा-ग्राफ़: समय-समय पर लॉक टेबल को स्कैन करके बनाया जाता है। चक्र = गतिरोध. पीड़ित चयन मानदंड: रोलबैक लागत को कम करें (सबसे कम लेनदेन, सबसे कम लॉक, सबसे छोटा पूर्ववत लॉग)। पीड़ित को पीछे की ओर घुमाया जाता है, उसके ताले खोल दिए जाते हैं, जिससे साइकिल टूट जाती है। जीवित लेनदेन आगे बढ़ते हैं। डिटेक्शन ओवरहेड: O(लेन-देन + लॉक)।
103
EN + हिं Hard
GB What is deadlock prevention (vs detection) and what strategies implement it?
IN गतिरोध रोकथाम (बनाम पता लगाना) क्या है और कौन सी रणनीतियाँ इसे लागू करती हैं?
A
Preventing database crashes caused by deadlocks गतिरोध के कारण होने वाले डेटाबेस क्रैश को रोकना
B
Preventing transactions from acquiring too many locks लेन-देन को बहुत अधिक लॉक प्राप्त करने से रोकना
C
Using timeouts to kill long-waiting transactions लंबे समय से प्रतीक्षारत लेनदेन को समाप्त करने के लिए टाइमआउट का उपयोग करना
D
Ensuring deadlocks cannot occur by design without needing to detect them: (1) Wait-Die: older transaction waits younger dies/restarts; (2) Wound-Wait: older transaction wounds (forces rollback of) younger younger waits; (3) Lock ordering: all transactions acquire locks in predefined order (no circular waits possible) यह सुनिश्चित करना कि गतिरोधों का पता लगाने की आवश्यकता के बिना डिज़ाइन द्वारा उत्पन्न नहीं किया जा सकता है: (1) वेट-डाई: पुराना लेनदेन छोटे लेनदेन के समाप्त होने/पुनः आरंभ होने की प्रतीक्षा करता है; (2) घाव-प्रतीक्षा: पुराने लेन-देन के घाव (बलों को वापस लाने के लिए मजबूर करता है) युवा युवा प्रतीक्षा करता है; (3) लॉक ऑर्डरिंग: सभी लेन-देन पूर्वनिर्धारित क्रम में लॉक प्राप्त करते हैं (कोई सर्कुलर प्रतीक्षा संभव नहीं है)
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Prevention strategies: Wait-Die: if T1(old) waits for T2(young): wait. If T1(young) waits for T2(old): T1 dies (aborts, restarts with same timestamp). Wound-Wait: opposite - older wounds younger. Lock ordering: total order on all lock-able objects, always acquire in that order -> no cycles possible. Timeout: abort if wait exceeds threshold.
व्याख्या (हिन्दी) रोकथाम रणनीतियाँ: रुको-मरो: यदि T1 (बूढ़ा) T2 (युवा) की प्रतीक्षा करता है: रुको। यदि T1 (युवा) T2 (बूढ़े) की प्रतीक्षा करता है: T1 मर जाता है (निरस्त हो जाता है, उसी टाइमस्टैम्प के साथ पुनः आरंभ होता है)। घाव-रुको: विपरीत - पुराने घाव छोटे। लॉक ऑर्डरिंग: सभी लॉक-सक्षम वस्तुओं पर कुल ऑर्डर, हमेशा उसी क्रम में प्राप्त करें -> कोई चक्र संभव नहीं। समयबाह्य: यदि प्रतीक्षा सीमा से अधिक हो जाए तो निरस्त करें।
104
EN + हिं Medium
GB What is predicate locking and why is it theoretically necessary for SERIALIZABLE isolation?
IN विधेय लॉकिंग क्या है और यह क्रमिक अलगाव के लिए सैद्धांतिक रूप से क्यों आवश्यक है?
A
A type of lock used in WHERE clause optimization WHERE क्लॉज ऑप्टिमाइज़ेशन में उपयोग किया जाने वाला एक प्रकार का लॉक
B
Locking based on column predicates कॉलम विधेय के आधार पर लॉकिंग
C
Locking all rows satisfying a predicate (not just currently existing rows) to prevent phantom reads - e.g. locking all rows WHERE salary > 50000 prevents any insertion of a new row with salary=60000 by another transaction; theoretically necessary because row-level locks cannot prevent phantom insertions फैंटम रीड को रोकने के लिए विधेय को संतुष्ट करने वाली सभी पंक्तियों को लॉक करना (न कि केवल वर्तमान में मौजूद पंक्तियाँ) - उदाहरण के लिए सभी पंक्तियों को लॉक करना जहां वेतन > 50000 किसी अन्य लेनदेन द्वारा वेतन = 60000 के साथ एक नई पंक्ति के सम्मिलन को रोकता है; सैद्धांतिक रूप से आवश्यक है क्योंकि पंक्ति-स्तरीय ताले प्रेत सम्मिलन को रोक नहीं सकते हैं
D
Locking tables based on query predicates क्वेरी विधेय के आधार पर तालिकाओं को लॉक करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Predicate locking: lock the logical set defined by a condition, not just existing physical rows. Needed for full serializability. In practice: index range locks (gap locks in MySQL InnoDB) approximate predicate locks. Gap locks: lock the gap between index values, preventing insertion of new rows in the range.
व्याख्या (हिन्दी) विधेय लॉकिंग: किसी शर्त द्वारा परिभाषित तार्किक सेट को लॉक करें, न कि केवल मौजूदा भौतिक पंक्तियों को। पूर्ण क्रमबद्धता के लिए आवश्यक. व्यवहार में: इंडेक्स रेंज लॉक (MySQL InnoDB में गैप लॉक) अनुमानित विधेय लॉक। गैप लॉक: सूचकांक मानों के बीच अंतर को लॉक करें, रेंज में नई पंक्तियों के सम्मिलन को रोकें।
105
EN + हिं Medium
GB What is the gap lock in MySQL InnoDB and how does it implement phantom read prevention?
IN MySQL InnoDB में गैप लॉक क्या है और यह फैंटम रीड प्रिवेंशन को कैसे लागू करता है?
A
A lock on deleted rows हटाई गई पंक्तियों पर लॉक
B
A lock on the gap between index values that prevents other transactions from inserting new rows into that gap - used by InnoDB REPEATABLE READ to prevent phantom reads by locking the index ranges between existing values सूचकांक मानों के बीच अंतर पर एक लॉक जो अन्य लेनदेन को उस अंतर में नई पंक्तियाँ डालने से रोकता है - मौजूदा मानों के बीच सूचकांक श्रेणियों को लॉक करके फैंटम रीड को रोकने के लिए InnoDB रिपीटेबल रीड द्वारा उपयोग किया जाता है
C
A lock on empty rows in a table किसी तालिका में खाली पंक्तियों पर लॉक
D
A lock on non-indexed columns गैर-अनुक्रमित स्तंभों पर लॉक
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Gap lock: if index has values (10, 20, 30), gaps are the intervals between them. SELECT WHERE id BETWEEN 15 AND 25: places gap locks on the ranges between existing values. Another transaction trying to INSERT id=18 must wait. Prevents phantom insertion in the queried range.
व्याख्या (हिन्दी) गैप लॉक: यदि सूचकांक में मान (10, 20, 30) हैं, तो अंतराल उनके बीच का अंतराल है। 15 और 25 के बीच कहां आईडी चुनें: मौजूदा मानों के बीच की सीमाओं पर गैप लॉक लगाता है। INSERT id=18 का प्रयास करने वाले किसी अन्य लेनदेन को प्रतीक्षा करनी होगी। क्वेरी की गई श्रेणी में प्रेत सम्मिलन को रोकता है।
91–105 of 127