76

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 मर जाता है (निरस्त हो जाता है, उसी टाइमस्टैम्प के साथ पुनः आरंभ होता है)। घाव-रुको: विपरीत - पुराने घाव छोटे। लॉक ऑर्डरिंग: सभी लॉक-सक्षम वस्तुओं पर कुल ऑर्डर, हमेशा उसी क्रम में प्राप्त करें -> कोई चक्र संभव नहीं। समयबाह्य: यदि प्रतीक्षा सीमा से अधिक हो जाए तो निरस्त करें।

77

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 में गैप लॉक) अनुमानित विधेय लॉक। गैप लॉक: सूचकांक मानों के बीच अंतर को लॉक करें, रेंज में नई पंक्तियों के सम्मिलन को रोकें।

78

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 का प्रयास करने वाले किसी अन्य लेनदेन को प्रतीक्षा करनी होगी। क्वेरी की गई श्रेणी में प्रेत सम्मिलन को रोकता है।

79

EN + हिं Medium

GB What is the next-key lock in MySQL InnoDB and how does it combine gap lock and record lock?

IN MySQL InnoDB में नेक्स्ट-की लॉक क्या है और यह गैप लॉक और रिकॉर्ड लॉक को कैसे संयोजित करता है?

A

A lock that advances to the next available record एक लॉक जो अगले उपलब्ध रिकॉर्ड की ओर बढ़ता है

B

A combination of a gap lock + record lock that locks both the index record AND the gap before it; used as the standard locking unit in InnoDB for REPEATABLE READ - e.g. next-key lock on value 20 locks the record 20 AND the gap (10 20) गैप लॉक + रिकॉर्ड लॉक का एक संयोजन जो इंडेक्स रिकॉर्ड और उसके पहले के गैप दोनों को लॉक करता है; बार-बार पढ़ने के लिए InnoDB में मानक लॉकिंग यूनिट के रूप में उपयोग किया जाता है - उदाहरण के लिए। मान 20 पर अगली-कुंजी लॉक रिकॉर्ड 20 और अंतर (10 20) को लॉक कर देता है

C

A lock on the next transaction in the queue कतार में अगले लेन-देन पर ताला

D

A lock on the next row in the table तालिका में अगली पंक्ति पर एक ताला

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Next-key lock = gap lock on (prev_val, current_val) + record lock on current_val. For index (10, 20, 30): next-key locks are (-inf,10], (10,20], (20,30], (30,+inf). A range query locks all next-key locks in the range. Prevents both modification of existing rows AND insertion of new rows in the range.

व्याख्या (हिन्दी) नेक्स्ट-की लॉक = गैप लॉक ऑन (prev_val, current_val) + करंट_वैल पर रिकॉर्ड लॉक। इंडेक्स (10, 20, 30) के लिए: नेक्स्ट-की लॉक (-inf,10], (10,20], (20,30], (30,+inf) हैं। एक रेंज क्वेरी रेंज में सभी नेक्स्ट-की लॉक को लॉक कर देती है। रेंज में मौजूदा पंक्तियों के संशोधन और नई पंक्तियों के सम्मिलन दोनों को रोकता है।

80

EN + हिं Hard

GB What is MVCC versus lock-based concurrency control in terms of reader-writer interactions?

IN पाठक-लेखक इंटरैक्शन के संदर्भ में एमवीसीसी बनाम लॉक-आधारित समवर्ती नियंत्रण क्या है?

A

MVCC uses more locks than lock-based एमवीसीसी लॉक-आधारित की तुलना में अधिक लॉक का उपयोग करता है

B

MVCC: readers never block writers and writers never block readers (readers see old versions writers create new versions); Lock-based: readers block writers (S-lock) and writers block readers and writers (X-lock). MVCC provides higher read concurrency but uses more storage for multiple versions एमवीसीसी: पाठक कभी भी लेखकों को ब्लॉक नहीं करते हैं और लेखक कभी भी पाठकों को ब्लॉक नहीं करते हैं (पाठक पुराने संस्करण देखते हैं, लेखक नए संस्करण बनाते हैं); लॉक-आधारित: पाठक लेखकों को ब्लॉक करते हैं (एस-लॉक) और लेखक पाठकों और लेखकों को ब्लॉक करते हैं (एक्स-लॉक)। एमवीसीसी उच्च पठन संगामिति प्रदान करता है लेकिन कई संस्करणों के लिए अधिक भंडारण का उपयोग करता है

C

Lock-based control provides better read concurrency लॉक-आधारित नियंत्रण बेहतर पठन समवर्तीता प्रदान करता है

D

They produce identical concurrency outcomes वे समान समवर्ती परिणाम उत्पन्न करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) MVCC advantage: no read-write conflicts (readers use snapshots). Better for read-heavy workloads. Cost: version storage overhead (old versions kept for active readers), garbage collection needed (VACUUM in PostgreSQL). Write-write conflicts still cause blocking in both MVCC and lock-based.

व्याख्या (हिन्दी) एमवीसीसी लाभ: कोई पढ़ने-लिखने का टकराव नहीं (पाठक स्नैपशॉट का उपयोग करते हैं)। पढ़ने-लिखने के भारी कार्यभार के लिए बेहतर। लागत: संस्करण भंडारण ओवरहेड (पुराने संस्करण सक्रिय पाठकों के लिए रखे गए), कचरा संग्रहण की आवश्यकता (पोस्टग्रेएसक्यूएल में VACUUM)। लिखने-लिखने का विरोध अभी भी एमवीसीसी और लॉक-आधारित दोनों में अवरोध का कारण बनता है।

81

EN + हिं Hard

GB What is serialization graph testing (SGT) concurrency control?

IN क्रमबद्धता ग्राफ़ परीक्षण (एसजीटी) समवर्ती नियंत्रण क्या है?

A

Testing SQL for serialization errors क्रमांकन त्रुटियों के लिए SQL का परीक्षण

B

Testing if transactions can be serialized after execution यह परीक्षण करना कि निष्पादन के बाद लेन-देन को क्रमबद्ध किया जा सकता है या नहीं

C

A protocol for testing deadlock prevention algorithms गतिरोध निवारण एल्गोरिदम के परीक्षण के लिए एक प्रोटोकॉल

D

A concurrency control method that builds the conflict serialization graph in real-time; commits the transaction only if its addition to the graph does not create a cycle (ensuring the resulting schedule is serializable); aborts if a cycle would be created एक समवर्ती नियंत्रण विधि जो वास्तविक समय में संघर्ष क्रमबद्धता ग्राफ़ बनाती है; लेन-देन केवल तभी करता है जब ग्राफ़ में इसे जोड़ने से कोई चक्र नहीं बनता है (यह सुनिश्चित करना कि परिणामी शेड्यूल क्रमबद्ध है); यदि कोई चक्र बनता है तो निरस्त हो जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) SGT: maintains the conflict graph dynamically. When T1 conflicts with T2 (T1 reads data T2 wrote, or T1 writes data T2 read), add edge T2 to T1. Before committing T, check if adding T creates a cycle. If yes: abort T. If no: commit. Optimal (never unnecessary aborts) but expensive (graph maintenance).

व्याख्या (हिन्दी) एसजीटी: संघर्ष ग्राफ को गतिशील रूप से बनाए रखता है। जब T1 का T2 के साथ टकराव होता है (T1 T2 द्वारा लिखा गया डेटा पढ़ता है, या T1 T2 द्वारा पढ़ा गया डेटा लिखता है), तो T1 में किनारा T2 जोड़ें। T करने से पहले, जाँच लें कि क्या T जोड़ने से एक चक्र बनता है। यदि हाँ: निरस्त करें टी। यदि नहीं: प्रतिबद्ध। इष्टतम (कभी भी अनावश्यक गर्भपात नहीं) लेकिन महंगा (ग्राफ़ रखरखाव)।

82

EN + हिं Hard

GB In distributed concurrency control what is the difference between centralized and distributed lock managers?

IN वितरित समवर्ती नियंत्रण में केंद्रीकृत और वितरित लॉक प्रबंधकों के बीच क्या अंतर है?

A

Centralized lock managers are always better केंद्रीकृत लॉक मैनेजर हमेशा बेहतर होते हैं

B

Distributed lock managers do not support deadlock detection वितरित लॉक प्रबंधक गतिरोध का पता लगाने का समर्थन नहीं करते हैं

C

Centralized lock managers only work for one database केंद्रीकृत लॉक मैनेजर केवल एक डेटाबेस के लिए काम करते हैं

D

Centralized: all lock requests go to one lock manager node (simple consistent but single point of failure and bottleneck). Distributed: lock management responsibility spread across nodes (better scalability and fault tolerance but complex coordination and potential split-brain issues) केंद्रीकृत: सभी लॉक अनुरोध एक लॉक मैनेजर नोड (सरल सुसंगत लेकिन विफलता और बाधा का एकल बिंदु) पर जाते हैं। वितरित: लॉक प्रबंधन जिम्मेदारी नोड्स में फैली हुई है (बेहतर स्केलेबिलिटी और गलती सहनशीलता लेकिन जटिल समन्वय और संभावित विभाजन-मस्तिष्क मुद्दे)

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Centralized lock manager: simple, easy deadlock detection (one graph), but single bottleneck/SPOF. Primary copy: each data item has a designated lock manager node. Distributed: each node manages locks for data stored there. Majority-based: require quorum of nodes to grant lock (fault tolerant but slower).

व्याख्या (हिन्दी) केंद्रीकृत लॉक प्रबंधक: सरल, आसान गतिरोध का पता लगाना (एक ग्राफ), लेकिन एकल टोंटी/एसपीओएफ। प्राथमिक प्रतिलिपि: प्रत्येक डेटा आइटम में एक निर्दिष्ट लॉक मैनेजर नोड होता है। वितरित: प्रत्येक नोड वहां संग्रहीत डेटा के लिए लॉक का प्रबंधन करता है। बहुमत-आधारित: लॉक प्रदान करने के लिए नोड्स के कोरम की आवश्यकता होती है (दोष सहिष्णु लेकिन धीमा)।

83

EN + हिं Hard

GB What is livelock in database concurrency control and how does it differ from deadlock?

IN डेटाबेस समवर्ती नियंत्रण में लाइवलॉक क्या है और यह डेडलॉक से किस प्रकार भिन्न है?

A

Livelock involves more transactions than deadlock लाइवलॉक में डेडलॉक की तुलना में अधिक लेनदेन शामिल हैं

B

Livelock is a synonym for deadlock लाइवलॉक गतिरोध का पर्याय है

C

Livelock is easier to detect than deadlock डेडलॉक की तुलना में लाइवलॉक का पता लगाना आसान है

D

Deadlock: transactions are stuck waiting indefinitely (no progress possible). Livelock: transactions are active (not blocked) but keep aborting and restarting in response to each other without making progress - e.g. two transactions using Wait-Die that repeatedly abort each other गतिरोध: लेन-देन अनिश्चित काल तक प्रतीक्षा में अटका हुआ है (कोई प्रगति संभव नहीं)। लाइवलॉक: लेन-देन सक्रिय हैं (अवरुद्ध नहीं हैं) लेकिन प्रगति किए बिना एक-दूसरे के जवाब में निरस्त और पुनः आरंभ होते रहते हैं - उदाहरण के लिए। वेट-डाई का उपयोग करते हुए दो लेनदेन जो बार-बार एक-दूसरे को निरस्त करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Livelock example: T1(ts=1) and T2(ts=2) both try same resources. T2 aborts (younger). T2 restarts with new timestamp. Now T2 is older, T1 aborts. T1 restarts. Loop continues. Prevention: use original timestamp on restart (not new), ensuring transactions eventually become oldest and succeed.

व्याख्या (हिन्दी) लाइवलॉक उदाहरण: T1(ts=1) और T2(ts=2) दोनों समान संसाधनों का प्रयास करते हैं। T2 निरस्त हो जाता है (छोटी उम्र में)। T2 नए टाइमस्टैम्प के साथ पुनः आरंभ होता है। अब T2 पुराना हो गया है, T1 निरस्त हो जाता है। T1 पुनः आरंभ होता है. लूप जारी है. रोकथाम: पुनरारंभ पर मूल टाइमस्टैम्प का उपयोग करें (नया नहीं), यह सुनिश्चित करते हुए कि लेनदेन अंततः सबसे पुराना और सफल हो जाए।

84

EN + हिं Medium

GB What is Strict Two-Phase Locking (Strict 2PL) and why is it preferred over basic 2PL?

IN स्ट्रिक्ट टू-फ़ेज़ लॉकिंग (स्ट्रिक्ट 2PL) क्या है और इसे बेसिक 2PL की तुलना में क्यों पसंद किया जाता है?

A

Strict 2PL holds ALL locks (both read and write) until the transaction commits or aborts instead of releasing write locks early. This prevents: cascading rollbacks (no dirty reads possible as uncommitted data is always locked) and simplifies recovery (undo only affects the aborting transaction) स्ट्रिक्ट 2PL सभी लॉक (पढ़ने और लिखने दोनों) को तब तक रखता है जब तक कि लेन-देन शुरू नहीं हो जाता या राइट लॉक को जल्दी जारी करने के बजाय बंद नहीं हो जाता। यह रोकता है: कैस्केडिंग रोलबैक (कोई गंदा पढ़ना संभव नहीं है क्योंकि अप्रतिबद्ध डेटा हमेशा लॉक होता है) और पुनर्प्राप्ति को सरल बनाता है (पूर्ववत केवल निरस्त लेनदेन को प्रभावित करता है)

B

Strict 2PL is a weaker form of basic 2PL स्ट्रिक्ट 2PL बेसिक 2PL का कमजोर रूप है

C

Strict 2PL acquires locks in strict alphabetical order सख्त 2PL सख्त वर्णमाला क्रम में ताले प्राप्त करता है

D

Strict 2PL requires exactly two phases of exactly equal length सख्त 2PL के लिए बिल्कुल समान लंबाई के दो चरणों की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Basic 2PL: may release locks before commit (after shrinking phase starts). If T1 releases X-lock on R after writing, T2 can read R. If T1 aborts, T2 must also abort (cascading). Strict 2PL: X-locks held until commit. T2 cannot read T1s uncommitted write. No cascading rollbacks. Most DBMS use Strict 2PL.

व्याख्या (हिन्दी) बेसिक 2पीएल: कमिट से पहले लॉक जारी कर सकता है (सिकुड़ने का चरण शुरू होने के बाद)। यदि T1 लिखने के बाद R पर X-लॉक जारी करता है, तो T2 R को पढ़ सकता है। यदि T1 निरस्त हो जाता है, तो T2 को भी निरस्त (कैस्केडिंग) करना होगा। सख्त 2पीएल: एक्स-लॉक प्रतिबद्ध होने तक आयोजित किया जाता है। T2, T1 के अप्रतिबद्ध लेखन को नहीं पढ़ सकता। कोई व्यापक रोलबैक नहीं. अधिकांश DBMS स्ट्रिक्ट 2PL का उपयोग करते हैं।

85

EN + हिं Easy

GB What is the OCC Read-Validate-Write cycle and what conflict check is done in the validation phase?

IN ओसीसी रीड-वैलिडेट-राइट चक्र क्या है और सत्यापन चरण में कौन सी विरोध जांच की जाती है?

A

Reading validating syntax then writing मान्य सिंटैक्स को पढ़ना, फिर लिखना

B

Three phases: Read (execute locally no locks reads from database writes to private workspace); Validate (check if any committed transaction since start wrote to data this transaction read); Write (apply local workspace to database if validation passed) तीन चरण: पढ़ें (स्थानीय रूप से निष्पादित करें, डेटाबेस से कोई लॉक नहीं पढ़ता है, निजी कार्यक्षेत्र में लिखता है); मान्य करें (जांचें कि क्या प्रारंभ से लेकर अब तक कोई प्रतिबद्ध लेन-देन इस लेन-देन के पढ़े गए डेटा में लिखा गया है); लिखें (यदि सत्यापन पारित हो गया है तो डेटाबेस में स्थानीय कार्यस्थान लागू करें)

C

Reading with S-locks validating with X-locks writing without locks एस-लॉक के साथ पढ़ना, एक्स-लॉक के साथ सत्यापन, बिना लॉक के लिखना

D

Reading committed data validating constraints writing with locks प्रतिबद्ध डेटा को पढ़ना, अवरोधों को मान्य करना, ताले के साथ लिखना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) OCC Validation: for each committed transaction Tj that committed during Ti execution, check: (1) Ti finished its read phase before Tj started (safe), OR (2) The write set of Tj and read set of Ti are disjoint (safe). If neither holds for any Tj: conflict, abort Ti.

व्याख्या (हिन्दी) ओसीसी सत्यापन: टीआई निष्पादन के दौरान किए गए प्रत्येक प्रतिबद्ध लेनदेन टीजे के लिए, जांचें: (1) टीआई ने टीजे शुरू होने से पहले अपना रीड चरण समाप्त कर दिया (सुरक्षित), या (2) टीजे का लेखन सेट और टीआई का रीड सेट असंयुक्त (सुरक्षित) है। यदि इनमें से कोई भी Tj के लिए मान्य नहीं है: संघर्ष, Ti को निरस्त करें।

86

EN + हिं Medium

GB What is conflict serializability and how does the conflict serialization graph test for it?

IN संघर्ष क्रमबद्धता क्या है और संघर्ष क्रमबद्धता ग्राफ़ इसका परीक्षण कैसे करता है?

A

All transactions execute without any conflicts सभी लेन-देन बिना किसी विरोध के निष्पादित होते हैं

B

Transactions conflict only on primary key columns लेन-देन केवल प्राथमिक कुंजी कॉलम पर संघर्ष करता है

C

A schedule is conflict-serializable if it is equivalent to some serial schedule; tested by building the conflict graph: edge Ti to Tj if Ti performs an operation conflicting with a later operation by Tj (both access same data item at least one is a write); schedule is conflict-serializable iff graph is acyclic एक शेड्यूल संघर्ष-क्रमबद्ध होता है यदि यह किसी सीरियल शेड्यूल के बराबर होता है; संघर्ष ग्राफ़ बनाकर परीक्षण किया गया: किनारे Ti से Tj यदि Ti Tj द्वारा बाद के ऑपरेशन के साथ विरोधाभासी ऑपरेशन करता है (दोनों एक ही डेटा आइटम तक पहुंचते हैं, कम से कम एक लिखना है); शेड्यूल संघर्ष-क्रमबद्ध है यदि ग्राफ चक्रीय है

D

All read operations happen before all write operations सभी पढ़ने की कार्रवाई सभी लिखने की कार्रवाई से पहले होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Conflict graph (precedence graph): for schedule S, draw node per transaction. Ti to Tj if: Ti reads X before Tj writes X (RW), Ti writes X before Tj reads X (WR), or Ti writes X before Tj writes X (WW). Acyclic graph = conflict-serializable. Cyclic = NOT conflict-serializable.

व्याख्या (हिन्दी) संघर्ष ग्राफ़ (प्राथमिकता ग्राफ़): शेड्यूल एस के लिए, प्रति लेनदेन नोड बनाएं। Ti से Tj यदि: Tj के X (RW) लिखने से पहले Ti, X पढ़ता है, Tj के X (WR) पढ़ने से पहले Ti, X लिखता है, या Tj के X (WW) लिखने से पहले Ti, X लिखता है। चक्रीय ग्राफ = संघर्ष-क्रमबद्ध। चक्रीय = संघर्ष-क्रमबद्ध नहीं।

87

EN + हिं Medium

GB What is view serializability and how does it differ from conflict serializability?

IN दृश्य क्रमबद्धता क्या है और यह संघर्ष क्रमबद्धता से किस प्रकार भिन्न है?

A

They are identical criteria वे समान मानदंड हैं

B

View serializability is stricter than conflict serializability दृश्य क्रमबद्धता संघर्ष क्रमबद्धता की तुलना में अधिक कठोर है

C

View serializability is a broader criterion: a schedule S is view-serializable if it is view-equivalent to some serial schedule (same transactions read the same values and produce the same final writes). Every conflict-serializable schedule is view-serializable but NOT vice versa दृश्य क्रमबद्धता एक व्यापक मानदंड है: एक शेड्यूल एस दृश्य-क्रमबद्ध है यदि यह कुछ सीरियल शेड्यूल के दृश्य-समतुल्य है (समान लेनदेन समान मान पढ़ते हैं और समान अंतिम लेखन उत्पन्न करते हैं)। प्रत्येक संघर्ष-क्रमबद्ध शेड्यूल दृश्य-क्रमबद्ध है, लेकिन इसके विपरीत नहीं

D

View serializability only applies to read operations दृश्य क्रमबद्धता केवल पढ़ने के संचालन पर लागू होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) View equivalence: S1 and S2 are view-equivalent if: (1) Same initial reads. (2) Same reads: each read returns same value. (3) Same final writes: same final writer per data item. Every CS schedule is VS but some VS schedules have blind writes allowing non-CS-but-VS schedules. VS testing is NP-complete; CS testing is O(n-squared).

व्याख्या (हिन्दी) समतुल्यता देखें: S1 और S2 दृश्य-समतुल्य हैं यदि: (1) प्रारंभिक पाठ समान हों। (2) समान पठन: प्रत्येक पठन समान मान लौटाता है। (3) वही अंतिम लेखक: प्रति डेटा आइटम वही अंतिम लेखक। प्रत्येक सीएस शेड्यूल वीएस है, लेकिन कुछ वीएस शेड्यूल में गैर-सीएस-लेकिन-वीएस शेड्यूल की अनुमति देने के लिए ब्लाइंड राइट्स हैं। वीएस परीक्षण एनपी-पूर्ण है; सीएस परीक्षण ओ(एन-वर्ग) है।

88

EN + हिं Easy

GB What is the no-wait deadlock avoidance policy and when is it appropriate?

IN प्रतीक्षा न करने की गतिरोध टालने की नीति क्या है और यह कब उचित है?

A

A policy where a transaction immediately aborts if any requested lock is not immediately available (rather than waiting) then restarts - eliminates deadlocks by eliminating the hold and wait condition; appropriate for: short transactions high-contention workloads where waiting is rarely productive and systems where fast retry is acceptable एक नीति जहां अनुरोधित लॉक तुरंत उपलब्ध नहीं होने पर लेनदेन तुरंत निरस्त कर दिया जाता है (प्रतीक्षा करने के बजाय) फिर से शुरू होता है - होल्ड और प्रतीक्षा की स्थिति को समाप्त करके गतिरोध को समाप्त करता है; इनके लिए उपयुक्त: छोटे लेनदेन, उच्च-विवाद वाले कार्यभार जहां प्रतीक्षा करना शायद ही कभी उत्पादक होता है और सिस्टम जहां तेजी से पुनः प्रयास स्वीकार्य है

B

Never waiting for any resources in any situation किसी भी स्थिति में किसी संसाधन का इंतजार न करें

C

A policy used only for read operations एक नीति जिसका उपयोग केवल पढ़ने के कार्यों के लिए किया जाता है

D

A policy where transactions never acquire locks ऐसी नीति जहां लेन-देन में कभी भी ताले नहीं लगते

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) No-wait policy: if lock not immediately available -> immediate abort and restart. Pro: zero deadlocks, no wait overhead, simple implementation. Con: high abort rate in contention (wasted work). Appropriate: very short transactions (retry cost low), hard real-time systems. Some optimistic systems use this at commit validation.

व्याख्या (हिन्दी) प्रतीक्षा न करने की नीति: यदि लॉक तुरंत उपलब्ध नहीं है -> तत्काल निरस्त करें और पुनरारंभ करें। प्रो: शून्य गतिरोध, कोई प्रतीक्षा ओवरहेड नहीं, सरल कार्यान्वयन। विपक्ष: विवाद में उच्च गर्भपात दर (बर्बाद कार्य)। उपयुक्त: बहुत कम लेनदेन (पुनः प्रयास की लागत कम), कठिन वास्तविक समय प्रणाली। कुछ आशावादी प्रणालियाँ प्रतिबद्ध सत्यापन में इसका उपयोग करती हैं।

89

EN + हिं Hard

GB What is starvation in concurrency control and how is it prevented?

IN समवर्ती नियंत्रण में भुखमरी क्या है और इसे कैसे रोका जाता है?

A

A condition where all locks are starved of resources ऐसी स्थिति जहां सभी ताले संसाधनों से वंचित हैं

B

A situation where a transaction is indefinitely prevented from acquiring a lock because other transactions continuously acquire the same lock preventing the waiting transaction from ever proceeding; prevented by: FIFO queuing for lock requests priority aging (waiting transactions gain priority over time) ऐसी स्थिति जहां एक लेनदेन को अनिश्चित काल तक लॉक प्राप्त करने से रोका जाता है क्योंकि अन्य लेनदेन लगातार उसी लॉक को प्राप्त करते हैं जो प्रतीक्षा लेनदेन को आगे बढ़ने से रोकता है; इसके द्वारा रोका गया: लॉक अनुरोधों के लिए फीफो की कतार प्राथमिकता उम्र बढ़ने (प्रतीक्षा लेनदेन समय के साथ प्राथमिकता प्राप्त करते हैं)

C

Transactions that consume too much CPU ऐसे लेनदेन जो बहुत अधिक CPU का उपभोग करते हैं

D

A transaction that reads from an empty table एक लेनदेन जो एक खाली तालिका से पढ़ा जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Starvation: T1 waits for X-lock on R. T2, T3, T4... keep acquiring S-locks on R. T1 never gets X-lock. Prevention: (1) FIFO queue: new S-lock requests blocked if X-lock request is waiting. (2) Priority aging: waiting transaction priority increases over time, eventually preempting others. (3) Wound-Wait/Wait-Die with timestamp.

व्याख्या (हिन्दी) भुखमरी: T1 R पर X-लॉक की प्रतीक्षा करता है। T2, T3, T4... R पर S-लॉक प्राप्त करते रहें। T1 को कभी भी X-लॉक नहीं मिलता है। रोकथाम: (1) फीफो कतार: यदि एक्स-लॉक अनुरोध प्रतीक्षा कर रहा है तो नए एस-लॉक अनुरोध अवरुद्ध हो जाते हैं। (2) प्राथमिकता की उम्र बढ़ना: प्रतीक्षा लेनदेन की प्राथमिकता समय के साथ बढ़ती है, अंततः दूसरों को छूट देती है। (3) टाइमस्टैम्प के साथ घाव-प्रतीक्षा/प्रतीक्षा-मरना।

90

EN + हिं Easy

GB What is isolation level degradation and when is it safe to lower the isolation level from SERIALIZABLE?

IN आइसोलेशन स्तर में गिरावट क्या है और सीरियलाइज़ेबल से आइसोलेशन स्तर को कम करना कब सुरक्षित है?

A

Lowering the isolation level causes data corruption अलगाव स्तर को कम करने से डेटा भ्रष्टाचार होता है

B

Isolation level can only be raised not lowered अलगाव स्तर को केवल बढ़ाया जा सकता है, कम नहीं

C

Deliberately using a lower isolation level than SERIALIZABLE to improve performance; safe when: the application can tolerate specific anomalies (e.g. approximate counts where phantom reads are acceptable) or when transactions are read-only (no write skew possible) or when application-level controls compensate प्रदर्शन को बेहतर बनाने के लिए जानबूझकर सीरियलाइज़ेबल से कम अलगाव स्तर का उपयोग करना; सुरक्षित है जब: एप्लिकेशन विशिष्ट विसंगतियों को सहन कर सकता है (उदाहरण के लिए अनुमानित गणना जहां फैंटम रीडिंग स्वीकार्य है) या जब लेनदेन केवल पढ़ने के लिए होते हैं (कोई लिखना संभव नहीं है) या जब एप्लिकेशन-स्तरीय नियंत्रण क्षतिपूर्ति करते हैं

D

Isolation level degradation is never safe अलगाव स्तर में गिरावट कभी भी सुरक्षित नहीं होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Safe isolation degradation: READ ONLY transactions: snapshot isolation provides full consistency for reads (no write skew possible). Reporting queries: stale reads acceptable. Statistical queries: approximate counts fine with READ COMMITTED. Application retries handle non-repeatable reads. Balance: lower isolation = higher concurrency = better performance.

व्याख्या (हिन्दी) सुरक्षित अलगाव गिरावट: केवल पढ़ने के लिए लेनदेन: स्नैपशॉट अलगाव पढ़ने के लिए पूर्ण स्थिरता प्रदान करता है (कोई लिखना संभव नहीं है)। रिपोर्टिंग प्रश्न: पुराना पाठ स्वीकार्य है। सांख्यिकीय प्रश्न: रीड कमिटेड के साथ अनुमानित गणना ठीक है। एप्लिकेशन पुनर्प्रयास गैर-दोहराए जाने योग्य रीड्स को संभालता है। संतुलन: कम अलगाव = उच्च संगामिति = बेहतर प्रदर्शन।

DBMS — MCQ Practice