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
2251
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.
व्याख्या (हिन्दी) 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). यदि इनमें से कोई भी Tj के लिए मान्य नहीं है: संघर्ष, Ti को निरस्त करें।
2252
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 लिखता है। चक्रीय ग्राफ = संघर्ष-क्रमबद्ध। चक्रीय = संघर्ष-क्रमबद्ध नहीं।
2253
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) वही अंतिम लेखक: प्रति डेटा आइटम वही अंतिम लेखक। प्रत्येक सीएस शेड्यूल वीएस है, लेकिन कुछ वीएस शेड्यूल में गैर-सीएस-लेकिन-वीएस शेड्यूल की अनुमति देने के लिए ब्लाइंड राइट्स हैं। वीएस परीक्षण एनपी-पूर्ण है; सीएस परीक्षण ओ(एन-वर्ग) है।
2254
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.
व्याख्या (हिन्दी) प्रतीक्षा न करने की नीति: यदि लॉक तुरंत उपलब्ध नहीं है -> तत्काल निरस्त करें और पुनरारंभ करें। प्रो: शून्य गतिरोध, कोई प्रतीक्षा ओवरहेड नहीं, सरल कार्यान्वयन। विपक्ष: विवाद में उच्च गर्भपात दर (बर्बाद कार्य)। उपयुक्त: बहुत कम लेनदेन (पुनः प्रयास की लागत कम), कठिन वास्तविक समय प्रणाली। कुछ आशावादी प्रणालियाँ प्रतिबद्ध सत्यापन में इसका उपयोग करती हैं।
2255
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) टाइमस्टैम्प के साथ घाव-प्रतीक्षा/प्रतीक्षा-मरना।
2256
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.
व्याख्या (हिन्दी) सुरक्षित अलगाव गिरावट: केवल पढ़ने के लिए लेनदेन: स्नैपशॉट अलगाव पढ़ने के लिए पूर्ण स्थिरता प्रदान करता है (कोई लिखना संभव नहीं है)। रिपोर्टिंग प्रश्न: पुराना पाठ स्वीकार्य है। सांख्यिकीय प्रश्न: रीड कमिटेड के साथ अनुमानित गणना ठीक है। एप्लिकेशन पुनर्प्रयास गैर-दोहराए जाने योग्य रीड्स को संभालता है। संतुलन: कम अलगाव = उच्च संगामिति = बेहतर प्रदर्शन।
2257
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 पंक्तियाँ देखता है। पंक्ति-स्तरीय ताले केवल मौजूदा पंक्तियों को लॉक करते हैं। विधेय से मेल खाने वाले सम्मिलनों को रोकने के लिए विधेय/गैप लॉक का उपयोग करना चाहिए।
2258
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 की तुलना में बेहतर पठनीय समवर्तीता।
2259
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 है तो निरस्त करें)। टाइमस्टैम्प ऑर्डरिंग संघर्ष समाधान के साथ एमवीसीसी लचीलेपन को जोड़ता है।
2260
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 द्वारा संशोधित), तो किसी को निरस्त करना होगा। खतरनाक डबल आरडब्ल्यू-एंटी-डिपेंडेंसी चक्रों का पता लगाता है। राइट लॉक के बिना क्रमबद्धता प्रदान करता है: मजबूत गारंटी के साथ उच्च संगामिति।
2261
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 (कोई गंदा पाठ नहीं) स्वचालित रूप से शेड्यूल को पुनर्प्राप्त करने योग्य बनाता है।
2262
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 की गारंटी देता है।
2263
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.
व्याख्या (हिन्दी) शेड्यूल संपत्ति पदानुक्रम: सख्त (कमिट होने तक सभी लेखन रोके गए) > एसीए (केवल पढ़ने के लिए प्रतिबद्ध) > पुनर्प्राप्त करने योग्य (प्रतिबद्ध आदेश रीड-फ्रॉम संबंध का सम्मान करता है) > सभी शेड्यूल। अलगाव स्तर मानचित्रण: अप्रतिबद्ध पढ़ें: कोई भी कार्यक्रम। प्रतिबद्ध पढ़ें: एसीए (केवल प्रतिबद्ध डेटा पढ़ता है)। दोहराए जाने योग्य पढ़ें: एसीए + गैर-दोहराए जाने योग्य पढ़ने की रोकथाम। क्रमबद्ध: सख्त + संघर्ष-क्रमबद्ध।
2264
EN + हिं Medium
GB What conditions are necessary for a deadlock to occur (Coffman conditions)?
IN गतिरोध उत्पन्न होने के लिए कौन सी स्थितियाँ आवश्यक हैं (कॉफमैन स्थितियाँ)?
A
Only one condition is necessary: circular waiting केवल एक शर्त आवश्यक है: सर्कुलर प्रतीक्षा
B
Only two conditions needed: mutual exclusion and circular waiting केवल दो शर्तों की आवश्यकता है: पारस्परिक बहिष्कार और परिपत्र प्रतीक्षा
C
Four necessary conditions: (1) Mutual exclusion: resources held exclusively. (2) Hold and wait: transaction holds resources while waiting for more. (3) No preemption: resources cannot be forcibly taken. (4) Circular wait: cycle in the wait-for graph. ALL four must hold simultaneously चार आवश्यक शर्तें: (1) पारस्परिक बहिष्कार: विशेष रूप से रखे गए संसाधन। (2) रुकें और प्रतीक्षा करें: लेन-देन अधिक की प्रतीक्षा करते हुए संसाधनों को रखता है। (3) कोई छूट नहीं: संसाधनों को जबरन नहीं लिया जा सकता। (4) वृत्ताकार प्रतीक्षा: प्रतीक्षा-ग्राफ़ में चक्र। चारों को एक साथ पकड़ना होगा
D
Deadlocks require at least 10 concurrent transactions डेडलॉक के लिए कम से कम 10 समवर्ती लेनदेन की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Coffman conditions applied to DB: (1) Mutual exclusion: X-lock held by only one transaction. (2) Hold and wait: T1 holds lock on A while waiting for lock on B. (3) No preemption: locks not forcibly taken (unless victim selection). (4) Circular wait: T1 waits for T2, T2 waits for T1. Break any one condition and no deadlock occurs.
व्याख्या (हिन्दी) कॉफ़मैन शर्तें डीबी पर लागू होती हैं: (1) पारस्परिक बहिष्करण: एक्स-लॉक केवल एक लेनदेन द्वारा आयोजित किया जाता है। (2) पकड़ें और प्रतीक्षा करें: टी1 ए पर लॉक रखता है जबकि बी पर लॉक की प्रतीक्षा करता है। (3) कोई छूट नहीं: लॉक को जबरन नहीं लिया जाता है (जब तक कि पीड़ित का चयन न हो)। (4) सर्कुलर प्रतीक्षा: T1, T2 की प्रतीक्षा करता है, T2, T1 की प्रतीक्षा करता है। किसी भी एक शर्त को तोड़ें और कोई गतिरोध उत्पन्न न हो।
2265
EN + हिं Hard
GB What is the wait-die scheme for deadlock prevention?
IN गतिरोध निवारण के लिए वेट-डाई योजना क्या है?
A
Older transactions die; younger ones wait पुराने लेन-देन समाप्त हो जाते हैं; छोटे लोग इंतजार करते हैं
B
If requesting transaction Ti is OLDER than holding transaction Tj: Ti waits. If Ti is YOUNGER than Tj: Ti dies (aborts and restarts with original timestamp). Older transactions always wait; younger ones abort - ensures no circular wait since age ordering is consistent यदि लेन-देन का अनुरोध करना Ti लेन-देन को रोकने से पुराना है तो Tj: Ti प्रतीक्षा करता है। यदि Ti, Tj से छोटा है: Ti मर जाता है (निरस्त हो जाता है और मूल टाइमस्टैम्प के साथ पुनः आरंभ होता है)। पुराने लेनदेन हमेशा प्रतीक्षा करते हैं; छोटे बच्चों का गर्भपात - यह सुनिश्चित करता है कि उम्र का क्रम सुसंगत होने के कारण कोई चक्रीय प्रतीक्षा न हो
C
Younger transactions wait; older ones die छोटे लेन-देन प्रतीक्षा करें; बड़े लोग मर जाते हैं
D
Both transactions die and restart simultaneously दोनों लेनदेन एक साथ बंद हो जाते हैं और पुनः आरंभ होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Wait-Die: non-preemptive. Older (lower timestamp) T requesting lock held by younger T: waits. Younger T requesting lock held by older T: younger T dies (aborts). Key: restarted transaction keeps ORIGINAL timestamp so it eventually becomes the oldest and will succeed.
व्याख्या (हिन्दी) वेट-डाई: नॉन-प्रीमेप्टिव। वृद्ध (निचला टाइमस्टैम्प) टी युवा टी द्वारा लॉक का अनुरोध कर रहा है: प्रतीक्षा करता है। छोटे टी ने बड़े टी द्वारा पकड़े गए ताले का अनुरोध किया: छोटे टी की मृत्यु (गर्भपात) हो गई। कुंजी: पुनः आरंभ किया गया लेनदेन मूल टाइमस्टैम्प रखता है इसलिए यह अंततः सबसे पुराना बन जाता है और सफल होगा।
2251–2265 of 2982