DBMS — MCQ Practice

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

📚 2982 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2982 questions
1681
EN + हिं Easy
GB What is the XA transaction standard and what is its purpose?
IN XA लेनदेन मानक क्या है और इसका उद्देश्य क्या है?
A
A transaction format for XML data XML डेटा के लिए एक लेनदेन प्रारूप
B
The X/Open XA specification for distributed transaction processing: defines an interface between a transaction manager (TM) and resource managers (RM/databases) enabling global transactions that span multiple databases message queues and other XA-compliant resources using 2PC coordination वितरित लेनदेन प्रसंस्करण के लिए एक्स/ओपन एक्सए विनिर्देश: एक लेनदेन प्रबंधक (टीएम) और संसाधन प्रबंधकों (आरएम/डेटाबेस) के बीच एक इंटरफेस को परिभाषित करता है जो वैश्विक लेनदेन को सक्षम बनाता है जो 2पीसी समन्वय का उपयोग करके कई डेटाबेस संदेश कतारों और अन्य एक्सए-अनुपालक संसाधनों को फैलाता है।
C
A transaction standard for XML databases XML डेटाबेस के लिए एक लेनदेन मानक
D
A special transaction type for cross-application calls क्रॉस-एप्लिकेशन कॉल के लिए एक विशेष लेनदेन प्रकार
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) XA protocol: defines xa_start, xa_end, xa_prepare, xa_commit, xa_rollback functions. TM coordinates multiple RMs (each a separate database or MQ). 2PC over XA: TM calls xa_prepare on all RMs (Phase 1), then xa_commit/xa_rollback (Phase 2). Supported by MySQL, PostgreSQL, Oracle, IBM DB2, JTA in Java EE.
व्याख्या (हिन्दी) XA प्रोटोकॉल: xa_start, xa_end, xa_prepare, xa_commit, xa_rollback फ़ंक्शंस को परिभाषित करता है। टीएम कई आरएम (प्रत्येक एक अलग डेटाबेस या एमक्यू) का समन्वय करता है। XA पर 2PC: TM सभी RM (चरण 1) पर xa_prepare को कॉल करता है, फिर xa_commit/xa_rollback (चरण 2) को कॉल करता है। जावा ईई में MySQL, PostgreSQL, Oracle, IBM DB2, JTA द्वारा समर्थित।
1682
EN + हिं Easy
GB What is the deferred write vs immediate write approach in transaction processing?
IN लेन-देन प्रसंस्करण में विलंबित लेखन बनाम तत्काल लेखन दृष्टिकोण क्या है?
A
Deferred write means transactions are queued विलंबित लेखन का मतलब है कि लेनदेन कतारबद्ध हैं
B
Writing is always immediate for ACID compliance ACID अनुपालन के लिए लेखन हमेशा तत्काल होता है
C
Immediate write bypasses the transaction log तत्काल लिखना लेन-देन लॉग को बायपास कर देता है
D
Immediate write: changes are written to disk as soon as they occur (easier recovery more I/O). Deferred write: changes are kept in memory (buffer pool) and written to disk lazily (batch I/O better performance). WAL is written immediately for durability; data pages use deferred write (buffered writes with WAL ensuring recovery) तत्काल लिखना: परिवर्तन होते ही डिस्क पर लिख दिए जाते हैं (अधिक I/O पुनर्प्राप्ति आसान)। विलंबित लेखन: परिवर्तन मेमोरी (बफर पूल) में रखे जाते हैं और डिस्क पर आलस्य से लिखे जाते हैं (बैच I/O बेहतर प्रदर्शन)। स्थायित्व के लिए तुरंत वाल लिखा जाता है; डेटा पृष्ठ विलंबित लेखन का उपयोग करते हैं (WAL पुनर्प्राप्ति सुनिश्चित करने के साथ बफर्ड लेखन)
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Database I/O strategy: WAL log: force-written to disk on commit (durability). Data pages: buffered in buffer pool, written lazily (dirty page flushing). If crash: WAL lets us redo changes to data pages that were not flushed. This gives both durability (WAL) and performance (deferred data writes).
व्याख्या (हिन्दी) डेटाबेस I/O रणनीति: वाल लॉग: कमिट पर डिस्क पर बलपूर्वक लिखा गया (स्थायित्व)। डेटा पेज: बफ़र पूल में बफ़र किए गए, आलस्य से लिखे गए (गंदे पेज फ्लशिंग)। यदि क्रैश हो जाता है: WAL हमें उन डेटा पेजों में परिवर्तन फिर से करने देता है जिन्हें फ्लश नहीं किया गया था। यह स्थायित्व (वाल) और प्रदर्शन (स्थगित डेटा लेखन) दोनों देता है।
1683
EN + हिं Medium
GB What is the purpose of the isolation level REPEATABLE READ and which anomalies does it prevent and allow?
IN आइसोलेशन लेवल रिपीटेबल रीड का उद्देश्य क्या है और यह किन विसंगतियों को रोकता और अनुमति देता है?
A
REPEATABLE READ is identical to READ COMMITTED रिपीटेबल रीड, रीड कमिटेड के समान है
B
REPEATABLE READ prevents dirty reads and non-repeatable reads (same row read twice returns same value within a transaction by holding read locks or using MVCC snapshots) but in standard SQL REPEATABLE READ allows phantom reads - though MySQL InnoDB also prevents phantoms via gap locks रिपीटेबल रीड गंदे रीड्स और नॉन-रिपीटेबल रीड्स को रोकता है (एक ही पंक्ति को दो बार पढ़ने पर रीड लॉक को पकड़कर या एमवीसीसी स्नैपशॉट का उपयोग करके लेनदेन के भीतर समान मूल्य मिलता है) लेकिन मानक एसक्यूएल में रिपीटेबल रीड फैंटम रीड्स की अनुमति देता है - हालांकि MySQL InnoDB गैप लॉक के माध्यम से फैंटम को भी रोकता है
C
REPEATABLE READ prevents all anomalies दोहराए जाने योग्य रीड सभी विसंगतियों को रोकता है
D
REPEATABLE READ prevents only dirty reads दोहराए जाने योग्य रीड केवल गंदे पढ़ने को रोकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) REPEATABLE READ: dirty reads = prevented. Non-repeatable reads = prevented (read locks held on accessed rows, or MVCC snapshot taken at transaction start). Phantom reads = allowed in SQL standard. However MySQL InnoDB REPEATABLE READ also prevents phantoms via next-key locking (gap locks + record locks). PostgreSQL REPEATABLE READ = snapshot isolation (also prevents phantoms).
व्याख्या (हिन्दी) दोबारा पढ़ने योग्य: गंदा पढ़ना = रोका गया। गैर-दोहराने योग्य रीड्स = रोका गया (एक्सेस की गई पंक्तियों पर रखे गए लॉक को पढ़ें, या लेनदेन शुरू होने पर लिया गया एमवीसीसी स्नैपशॉट)। फैंटम पढ़ता है = SQL मानक में अनुमति दी गई है। हालाँकि MySQL InnoDB REPEATABLE READ अगली-कुंजी लॉकिंग (गैप लॉक + रिकॉर्ड लॉक) के माध्यम से प्रेत को भी रोकता है। PostgreSQL रिपीटेबल रीड = स्नैपशॉट अलगाव (प्रेत को भी रोकता है)।
1684
EN + हिं Easy
GB What is the ACID theorem and who originally proposed these database transaction properties?
IN ACID प्रमेय क्या है और मूल रूप से इन डेटाबेस लेनदेन गुणों का प्रस्ताव किसने दिया?
A
ACID was defined by the SQL-86 standard committee ACID को SQL-86 मानक समिति द्वारा परिभाषित किया गया था
B
ACID (Atomicity Consistency Isolation Durability) was formalized by Jim Gray and Andreas Reuter in 1992 in their book Transaction Processing: Concepts and Techniques though the individual concepts were discussed earlier by Eswaran et al in 1976 (regarding consistency and isolation) and Gray in 1978 (regarding transaction properties) ACID (एटोमिसिटी कंसिस्टेंसी आइसोलेशन ड्यूरेबिलिटी) को जिम ग्रे और एंड्रियास रॉयटर ने 1992 में अपनी पुस्तक ट्रांजेक्शन प्रोसेसिंग: कॉन्सेप्ट्स एंड टेक्निक्स में औपचारिक रूप दिया था, हालांकि व्यक्तिगत अवधारणाओं पर पहले 1976 में ईश्वरन एट अल द्वारा (स्थिरता और अलगाव के संबंध में) और ग्रे द्वारा 1978 में (लेन-देन गुणों के संबंध में) चर्चा की गई थी।
C
ACID was proposed by Dijkstra in the context of operating systems ACID को ऑपरेटिंग सिस्टम के संदर्भ में दिज्क्स्ट्रा द्वारा प्रस्तावित किया गया था
D
ACID was proposed by Codd in his 1970 relational model paper ACID को कोडड ने अपने 1970 के रिलेशनल मॉडल पेपर में प्रस्तावित किया था
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Historical context: Eswaran et al. 1976 (IBM): discussed consistency and isolation in the context of database systems. Jim Gray 1978: formalized transaction concepts including atomicity and durability. Gray and Reuter 1992 Transaction Processing book: coined the ACID acronym and formalized all four properties. Gray received the 1998 Turing Award for this and related work.
व्याख्या (हिन्दी) ऐतिहासिक संदर्भ: ईश्वरन एट अल। 1976 (आईबीएम): डेटाबेस सिस्टम के संदर्भ में स्थिरता और अलगाव पर चर्चा की गई। जिम ग्रे 1978: परमाणुता और स्थायित्व सहित औपचारिक लेनदेन अवधारणाएँ। ग्रे और रॉयटर 1992 ट्रांजेक्शन प्रोसेसिंग पुस्तक: ACID का संक्षिप्त नाम गढ़ा और सभी चार संपत्तियों को औपचारिक रूप दिया। ग्रे को इस और संबंधित कार्य के लिए 1998 का ​​ट्यूरिंग पुरस्कार प्राप्त हुआ।
1685
EN + हिं Medium
GB What is the difference between redo log and undo log in transaction processing?
IN लेन-देन प्रसंस्करण में लॉग फिर से करें और लॉग पूर्ववत करें के बीच क्या अंतर है?
A
Only one of them is needed for ACID compliance ACID अनुपालन के लिए उनमें से केवल एक की आवश्यकता है
B
Redo log: records the AFTER-image (new value) of each change enabling REDO (replay) of committed transactions during crash recovery to bring the database to the committed state. Undo log: records the BEFORE-image (original value) of each change enabling ROLLBACK of uncommitted transactions and MVCC snapshots for concurrent readers दोबारा लॉग करें: डेटाबेस को प्रतिबद्ध स्थिति में लाने के लिए क्रैश रिकवरी के दौरान प्रतिबद्ध लेनदेन के REDO (रीप्ले) को सक्षम करने वाले प्रत्येक परिवर्तन की AFTER-छवि (नया मान) रिकॉर्ड करता है। लॉग को पूर्ववत करें: प्रत्येक परिवर्तन की BEFORE-छवि (मूल मान) को रिकॉर्ड करता है, जो अप्रतिबद्ध लेनदेन के रोलबैक और समवर्ती पाठकों के लिए एमवीसीसी स्नैपशॉट को सक्षम करता है।
C
Redo log is for aborted transactions; undo log is for committed transactions निरस्त लेनदेन के लिए रीडू लॉग है; पूर्ववत लॉग प्रतिबद्ध लेनदेन के लिए है
D
They are different names for the same log वे एक ही लॉग के लिए अलग-अलग नाम हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Redo log (WAL/redo log): COMMIT -> force-write redo records to disk -> redo log. Recovery: replay redo records to apply all committed changes. Undo log (rollback log): before each change, save before-image. ROLLBACK: apply undo log in reverse. MVCC: undo log chain allows readers to see earlier versions. Both are required for full ACID compliance.
व्याख्या (हिन्दी) लॉग फिर से करें (वाल/रीडो लॉग): प्रतिबद्ध -> बलपूर्वक डिस्क पर दोबारा रिकॉर्ड लिखें -> लॉग फिर से करें। पुनर्प्राप्ति: सभी प्रतिबद्ध परिवर्तनों को लागू करने के लिए रिकॉर्ड को दोबारा चलाएं। लॉग को पूर्ववत करें (रोलबैक लॉग): प्रत्येक परिवर्तन से पहले, बिफोर-इमेज को सेव करें। रोलबैक: पूर्ववत लॉग को उल्टा लागू करें। एमवीसीसी: पूर्ववत लॉग श्रृंखला पाठकों को पुराने संस्करण देखने की अनुमति देती है। पूर्ण ACID अनुपालन के लिए दोनों आवश्यक हैं।
1686
EN + हिं Easy
GB What is the concept of nested transactions and how do they relate to SAVEPOINTS?
IN नेस्टेड लेनदेन की अवधारणा क्या है और वे SAVEPOINTS से कैसे संबंधित हैं?
A
Nested transactions always commit when the outer transaction commits नेस्टेड लेनदेन हमेशा तब प्रतिबद्ध होते हैं जब बाहरी लेनदेन प्रतिबद्ध होता है
B
Nested transactions are only available in Oracle नेस्टेड लेनदेन केवल Oracle में उपलब्ध हैं
C
Nested transactions are not supported in any DBMS नेस्टेड लेनदेन किसी भी DBMS में समर्थित नहीं हैं
D
A nested transaction is a transaction started within another transaction; in most DBMS true nested transactions are not supported but SAVEPOINTs provide similar functionality - a ROLLBACK TO SAVEPOINT is analogous to rolling back an inner transaction while keeping the outer transaction alive नेस्टेड लेनदेन किसी अन्य लेनदेन के भीतर शुरू किया गया लेनदेन है; अधिकांश DBMS में सच्चे नेस्टेड लेनदेन समर्थित नहीं हैं, लेकिन SAVEPOINTs समान कार्यक्षमता प्रदान करते हैं - SAVEPOINT पर रोलबैक बाहरी लेनदेन को जीवित रखते हुए आंतरिक लेनदेन को वापस रोल करने के समान है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) True nested transactions (supported by some DBMS like Sybase, SQL Server with XACT_ABORT): inner transaction can commit or rollback independently. Most DBMS simulate nesting with SAVEPOINTs: SAVEPOINT sp1; (inner work); ROLLBACK TO sp1 (inner rollback, outer continues). Full nested transactions with independent commit/rollback require specialized DBMS support.
व्याख्या (हिन्दी) ट्रू नेस्टेड लेनदेन (कुछ DBMS जैसे Sybase, XACT_ABORT के साथ SQL सर्वर द्वारा समर्थित): आंतरिक लेनदेन स्वतंत्र रूप से प्रतिबद्ध या रोलबैक हो सकता है। अधिकांश DBMS SAVEPOINTs के साथ नेस्टिंग का अनुकरण करते हैं: SAVEPOINT sp1; (आंतरिक कार्य); SP1 पर रोलबैक (आंतरिक रोलबैक, बाहरी जारी रहता है)। स्वतंत्र कमिट/रोलबैक के साथ पूर्ण नेस्टेड लेनदेन के लिए विशेष डीबीएमएस समर्थन की आवश्यकता होती है।
1687
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)। पदानुक्रम: डेटाबेस -> तालिका -> पृष्ठ -> पंक्ति।
1688
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 लॉक पर या जब लॉक मेमोरी थ्रेशोल्ड से अधिक हो जाती है तो बढ़ जाती है।
1689
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(लेन-देन + लॉक)।
1690
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 मर जाता है (निरस्त हो जाता है, उसी टाइमस्टैम्प के साथ पुनः आरंभ होता है)। घाव-रुको: विपरीत - पुराने घाव छोटे। लॉक ऑर्डरिंग: सभी लॉक-सक्षम वस्तुओं पर कुल ऑर्डर, हमेशा उसी क्रम में प्राप्त करें -> कोई चक्र संभव नहीं। समयबाह्य: यदि प्रतीक्षा सीमा से अधिक हो जाए तो निरस्त करें।
1691
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 में गैप लॉक) अनुमानित विधेय लॉक। गैप लॉक: सूचकांक मानों के बीच अंतर को लॉक करें, रेंज में नई पंक्तियों के सम्मिलन को रोकें।
1692
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 का प्रयास करने वाले किसी अन्य लेनदेन को प्रतीक्षा करनी होगी। क्वेरी की गई श्रेणी में प्रेत सम्मिलन को रोकता है।
1693
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) हैं। एक रेंज क्वेरी रेंज में सभी नेक्स्ट-की लॉक को लॉक कर देती है। रेंज में मौजूदा पंक्तियों के संशोधन और नई पंक्तियों के सम्मिलन दोनों को रोकता है।
1694
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)। लिखने-लिखने का विरोध अभी भी एमवीसीसी और लॉक-आधारित दोनों में अवरोध का कारण बनता है।
1695
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 जोड़ने से एक चक्र बनता है। यदि हाँ: निरस्त करें टी। यदि नहीं: प्रतिबद्ध। इष्टतम (कभी भी अनावश्यक गर्भपात नहीं) लेकिन महंगा (ग्राफ़ रखरखाव)।
1681–1695 of 2982