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
1726
EN + हिं Medium
GB What is a deadlock graph visualization and how does it help in diagnosing production deadlock issues?
IN डेडलॉक ग्राफ़ विज़ुअलाइज़ेशन क्या है और यह उत्पादन गतिरोध समस्याओं के निदान में कैसे मदद करता है?
A
A graph showing query execution times क्वेरी निष्पादन समय दर्शाने वाला ग्राफ़
B
A graph showing database query costs डेटाबेस क्वेरी लागत दर्शाने वाला ग्राफ़
C
A graph of database connection patterns डेटाबेस कनेक्शन पैटर्न का एक ग्राफ़
D
A visual representation of transactions as nodes and lock wait relationships as directed edges; cycles indicate deadlocks; helps identify: which transactions are involved which specific rows/tables are the contention points what SQL statements caused conflicts and patterns suggesting application-level fixes नोड्स के रूप में लेनदेन का एक दृश्य प्रतिनिधित्व और निर्देशित किनारों के रूप में लॉक प्रतीक्षा संबंध; चक्र गतिरोध का संकेत देते हैं; पहचानने में मदद करता है: कौन से लेन-देन शामिल हैं, कौन सी विशिष्ट पंक्तियाँ/तालियाँ विवाद बिंदु हैं, कौन से SQL कथनों के कारण टकराव हुआ और एप्लिकेशन-स्तरीय सुधारों का सुझाव देने वाले पैटर्न
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Deadlock graph analysis: SHOW ENGINE INNODB STATUS output shows transactions and their lock waits. Tools like pt-deadlock-logger, Percona Monitoring parse deadlock info. Pattern analysis: if same two tables always appear, fix transaction ordering. If same rows: add index to reduce scan scope (fewer row locks held simultaneously).
व्याख्या (हिन्दी) डेडलॉक ग्राफ विश्लेषण: शो इंजन इननोब स्टेटस आउटपुट लेनदेन और उनके लॉक प्रतीक्षा को दिखाता है। पीटी-डेडलॉक-लॉगर, पेरकोना मॉनिटरिंग पार्स डेडलॉक जानकारी जैसे उपकरण। पैटर्न विश्लेषण: यदि समान दो तालिकाएँ हमेशा दिखाई देती हैं, तो लेनदेन क्रम ठीक करें। यदि पंक्तियाँ समान हों: स्कैन का दायरा कम करने के लिए अनुक्रमणिका जोड़ें (एक साथ कम पंक्ति लॉक रखें)।
1727
EN + हिं Medium
GB In MySQL InnoDB when a deadlock is detected what information does InnoDB provide?
IN MySQL InnoDB में जब गतिरोध का पता चलता है तो InnoDB क्या जानकारी प्रदान करता है?
A
InnoDB does not detect deadlocks automatically InnoDB स्वचालित रूप से गतिरोध का पता नहीं लगाता है
B
InnoDB prevents all deadlocks using lock ordering InnoDB लॉक ऑर्डरिंग का उपयोग करके सभी गतिरोधों को रोकता है
C
MySQL requires manual deadlock detection by the application MySQL को एप्लिकेशन द्वारा मैन्युअल गतिरोध का पता लगाने की आवश्यकता होती है
D
InnoDB has automatic deadlock detection using a wait-for graph; when detected the transaction with less undo log is chosen as victim and rolled back; deadlock information is accessible via SHOW ENGINE INNODB STATUS or the performance_schema.data_lock_waits table InnoDB में प्रतीक्षा-ग्राफ़ का उपयोग करके स्वचालित गतिरोध का पता लगाना है; जब कम पूर्ववत लॉग वाले लेन-देन का पता चलता है तो उसे पीड़ित के रूप में चुना जाता है और वापस ले लिया जाता है; गतिरोध की जानकारी SHOW ENGINE INNODB STATUS या Performance_schema.data_lock_waits तालिका के माध्यम से पहुंच योग्य है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) InnoDB deadlock detection: background thread monitors wait-for graph. Victim: transaction with smallest undo log size rolled back. SHOW ENGINE INNODB STATUS: shows LATEST DETECTED DEADLOCK section with transaction details, lock information, and the SQL statements involved. innodb_deadlock_detect=OFF disables detection.
व्याख्या (हिन्दी) InnoDB गतिरोध का पता लगाना: पृष्ठभूमि थ्रेड प्रतीक्षा-ग्राफ़ की निगरानी करता है। पीड़ित: सबसे छोटे पूर्ववत लॉग आकार वाला लेन-देन वापस ले लिया गया। इंजन इननोड स्थिति दिखाएं: लेन-देन विवरण, लॉक जानकारी और शामिल एसक्यूएल स्टेटमेंट के साथ नवीनतम पता लगाया गया डेडलॉक अनुभाग दिखाता है। innodb_deadlock_detect=OFF पता लगाना अक्षम कर देता है।
1728
EN + हिं Easy
GB What is mutual exclusion as a Coffman condition and can it be eliminated in database systems to prevent deadlocks?
IN कॉफ़मैन स्थिति के रूप में पारस्परिक बहिष्करण क्या है और क्या गतिरोध को रोकने के लिए डेटाबेस सिस्टम में इसे समाप्त किया जा सकता है?
A
Mutual exclusion can always be eliminated पारस्परिक बहिष्कार को हमेशा समाप्त किया जा सकता है
B
Mutual exclusion means resources (data items) can only be held by one transaction at a time in write mode; for READ locks mutual exclusion can be eliminated (multiple readers allowed) via shared locks reducing deadlock probability; but write locks inherently require mutual exclusion for correctness पारस्परिक बहिष्करण का मतलब है कि संसाधनों (डेटा आइटम) को एक समय में केवल एक लेनदेन द्वारा लेखन मोड में रखा जा सकता है; रीड लॉक के लिए आपसी बहिष्करण को साझा लॉक के माध्यम से समाप्त किया जा सकता है (एकाधिक पाठकों को अनुमति दी गई है) जिससे गतिरोध की संभावना कम हो जाती है; लेकिन राइट लॉक को शुद्धता के लिए स्वाभाविक रूप से पारस्परिक बहिष्कार की आवश्यकता होती है
C
Mutual exclusion elimination removes all deadlocks पारस्परिक बहिष्कार उन्मूलन से सभी गतिरोध दूर हो जाते हैं
D
Databases do not use the mutual exclusion concept डेटाबेस पारस्परिक बहिष्करण अवधारणा का उपयोग नहीं करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Eliminating mutual exclusion for reads: shared/read locks allow multiple concurrent readers. This reduces deadlocks significantly. Write mutual exclusion: cannot be eliminated while maintaining data integrity (two concurrent writes to same data = incorrect result). MVCC eliminates read-write mutual exclusion by using versioning.
व्याख्या (हिन्दी) पढ़ने के लिए पारस्परिक बहिष्करण को समाप्त करना: साझा/पढ़ने वाले लॉक एकाधिक समवर्ती पाठकों की अनुमति देते हैं। इससे गतिरोध काफी हद तक कम हो जाता है। पारस्परिक बहिष्करण लिखें: डेटा अखंडता को बनाए रखते हुए समाप्त नहीं किया जा सकता है (एक ही डेटा पर दो समवर्ती लेखन = गलत परिणाम)। एमवीसीसी वर्जनिंग का उपयोग करके पढ़ने-लिखने के पारस्परिक बहिष्करण को समाप्त करता है।
1729
EN + हिं Medium
GB What is the application-level deadlock and how does it differ from database-level deadlock?
IN एप्लिकेशन-स्तरीय गतिरोध क्या है और यह डेटाबेस-स्तरीय गतिरोध से कैसे भिन्न है?
A
They are identical types of deadlocks वे समान प्रकार के गतिरोध हैं
B
Application-level deadlocks are faster to resolve एप्लिकेशन-स्तरीय गतिरोधों का समाधान तेजी से होता है
C
Application deadlocks cannot occur with a DBMS DBMS के साथ एप्लिकेशन गतिरोध उत्पन्न नहीं हो सकता
D
Application-level deadlock: occurs in application code (e.g. Thread A holds Java lock L1 waiting for Java lock L2; Thread B holds L2 waiting for L1) without involving database locks - the database itself is not deadlocked but the application threads are stuck. Different from DB deadlock where DBMS transactions hold DB locks circularly एप्लिकेशन-स्तरीय गतिरोध: एप्लिकेशन कोड में होता है (उदाहरण के लिए थ्रेड ए जावा लॉक एल1 को जावा लॉक एल2 के इंतजार में रखता है; थ्रेड बी एल2 को एल1 के इंतजार में रखता है) डेटाबेस लॉक को शामिल किए बिना - डेटाबेस स्वयं डेडलॉक नहीं है लेकिन एप्लिकेशन थ्रेड अटके हुए हैं। डीबी गतिरोध से भिन्न जहां डीबीएमएस लेनदेन डीबी लॉक को गोलाकार रूप से रखता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Application deadlock: circular waiting in application code (mutexes, semaphores, Java synchronized blocks). DBMS cannot detect this. Solution: application must implement its own deadlock detection or prevention (consistent lock ordering in application code, timeouts in application logic). Different from DBMS-level deadlocks that the DB detects/resolves.
व्याख्या (हिन्दी) एप्लिकेशन गतिरोध: एप्लिकेशन कोड में सर्कुलर प्रतीक्षा (म्यूटेक्स, सेमाफोर, जावा सिंक्रोनाइज्ड ब्लॉक)। DBMS इसका पता नहीं लगा सकता. समाधान: एप्लिकेशन को अपने स्वयं के गतिरोध का पता लगाने या रोकथाम (एप्लिकेशन कोड में लगातार लॉक ऑर्डर, एप्लिकेशन लॉजिक में टाइमआउट) को लागू करना होगा। DBMS-स्तर के गतिरोधों से भिन्न जिनका DB पता लगाता/समाधान करता है।
1730
EN + हिं Easy
GB What is the Bankers algorithm for deadlock avoidance and what information does it require?
IN गतिरोध से बचने के लिए बैंकर्स एल्गोरिदम क्या है और इसके लिए किस जानकारी की आवश्यकता है?
A
A resource allocation algorithm that determines whether granting a resource request leaves the system in a safe state; requires: for each transaction - maximum resource needs declared in advance current allocation and remaining need; safe state = exists a sequence in which all transactions can complete using available resources एक संसाधन आवंटन एल्गोरिदम जो यह निर्धारित करता है कि संसाधन अनुरोध देने से सिस्टम सुरक्षित स्थिति में रहता है या नहीं; आवश्यक है: प्रत्येक लेनदेन के लिए - अधिकतम संसाधन आवश्यकताओं की घोषणा अग्रिम वर्तमान आवंटन और शेष आवश्यकता; सुरक्षित स्थिति = एक अनुक्रम मौजूद है जिसमें सभी लेनदेन उपलब्ध संसाधनों का उपयोग करके पूरा किया जा सकता है
B
An algorithm for distributing resources evenly among transactions लेन-देन के बीच संसाधनों को समान रूप से वितरित करने के लिए एक एल्गोरिदम
C
A financial transaction scheduling algorithm एक वित्तीय लेनदेन शेड्यूलिंग एल्गोरिदम
D
A banking application algorithm for managing transactions लेनदेन के प्रबंधन के लिए एक बैंकिंग एप्लिकेशन एल्गोरिदम
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Bankers algorithm: Safe state check before each allocation. Data needed: Available (resources currently free), Max (maximum needs per transaction), Allocation (current allocation), Need (Max - Allocation). Safety check: find a transaction whose Need <= Available, simulate completion (release allocation), repeat. If all transactions can complete: safe state, grant. Else: deny and wait.
व्याख्या (हिन्दी) बैंकर्स एल्गोरिदम: प्रत्येक आवंटन से पहले सुरक्षित स्थिति की जांच। आवश्यक डेटा: उपलब्ध (संसाधन वर्तमान में निःशुल्क), अधिकतम (प्रति लेनदेन अधिकतम आवश्यकताएं), आवंटन (वर्तमान आवंटन), आवश्यकता (अधिकतम - आवंटन)। सुरक्षा जांच: ऐसा लेन-देन ढूंढें जिसकी आवश्यकता है
1731
EN + हिं Easy
GB What is the hold-and-wait Coffman condition and what strategies eliminate it in database systems?
IN होल्ड-एंड-वेट कॉफ़मैन स्थिति क्या है और कौन सी रणनीतियाँ डेटाबेस सिस्टम में इसे समाप्त करती हैं?
A
Hold-and-wait: a transaction holds one or more resources (locks) while waiting to acquire additional resources it needs. Elimination strategies: (1) Require all-or-nothing lock acquisition (acquire ALL needed locks at once before starting) (2) Release all current locks before requesting new ones (3) Use timeout-based retry after releasing होल्ड-एंड-वेट: एक लेनदेन आवश्यक अतिरिक्त संसाधनों को प्राप्त करने की प्रतीक्षा करते समय एक या अधिक संसाधनों (लॉक) को रखता है। उन्मूलन रणनीतियाँ: (1) सभी या कुछ भी नहीं लॉक अधिग्रहण की आवश्यकता है (शुरू करने से पहले सभी आवश्यक लॉक एक साथ प्राप्त करें) (2) नए लॉक का अनुरोध करने से पहले सभी मौजूदा लॉक जारी करें (3) जारी करने के बाद टाइमआउट-आधारित पुनः प्रयास का उपयोग करें
B
A performance optimization for lock management लॉक प्रबंधन के लिए एक प्रदर्शन अनुकूलन
C
Holding locks for too long during transactions लेन-देन के दौरान बहुत देर तक ताले लटकाए रखना
D
A condition where all resources are held by one transaction ऐसी स्थिति जहां सभी संसाधन एक लेनदेन द्वारा रखे जाते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hold-and-wait elimination: (1) All-or-nothing: declare all needed locks upfront, acquire atomically (difficult - often do not know all needs in advance). (2) Release before requesting (conservative): release all current locks when requesting new ones (causes restart overhead). Both are impractical for most real workloads. This is why most systems detect deadlocks rather than prevent hold-and-wait.
व्याख्या (हिन्दी) होल्ड-एंड-वेट उन्मूलन: (1) सभी या कुछ भी नहीं: सभी आवश्यक तालों को अग्रिम रूप से घोषित करें, परमाणु रूप से प्राप्त करें (कठिन - अक्सर सभी जरूरतों को पहले से नहीं जानते हैं)। (2) अनुरोध करने से पहले रिलीज़ करें (रूढ़िवादी): नए लॉक का अनुरोध करते समय सभी मौजूदा लॉक को रिलीज़ करें (ओवरहेड पुनरारंभ होने का कारण बनता है)। अधिकांश वास्तविक कार्यभार के लिए दोनों अव्यावहारिक हैं। यही कारण है कि अधिकांश सिस्टम होल्ड-एंड-वेट को रोकने के बजाय गतिरोध का पता लगाते हैं।
1732
EN + हिं Easy
GB What is the no-preemption Coffman condition and how can preemption be introduced to break deadlocks?
IN नो-प्रीएम्प्शन कॉफ़मैन स्थिति क्या है और गतिरोध को तोड़ने के लिए प्रीएम्प्शन को कैसे लागू किया जा सकता है?
A
Preemption means stopping a transaction without completing it प्रीएम्प्शन का अर्थ है किसी लेन-देन को पूरा किए बिना रोकना
B
Preemption only works for shared locks प्रीएम्प्शन केवल साझा तालों के लिए काम करता है
C
Preemption requires explicit transaction consent प्रीएम्प्शन के लिए स्पष्ट लेनदेन सहमति की आवश्यकता होती है
D
No preemption means that resources (locks) cannot be forcibly taken from a transaction holding them. Preemption can be introduced by: aborting (preempting) a deadlocked transaction (victim selection) which is how deadlock resolution works - the DBMS forcibly rolls back a chosen victim transaction releasing its locks for other waiting transactions नो प्रीएम्प्शन का मतलब यह है कि संसाधनों (ताले) को उनके पास मौजूद लेनदेन से जबरन नहीं लिया जा सकता है। प्रीएम्प्शन को इसके द्वारा प्रस्तुत किया जा सकता है: एक गतिरोध वाले लेनदेन को निरस्त करना (पीड़ित चयन) जो कि गतिरोध समाधान कैसे काम करता है - डीबीएमएस जबरन चुने गए पीड़ित लेनदेन को वापस लाता है और अन्य प्रतीक्षा लेनदेन के लिए अपने ताले जारी करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) No-preemption elimination (deadlock resolution): when deadlock detected, the DBMS selects a victim transaction and aborts it (preempts its resources). This forcibly takes the victim transactionssource (locks) and releases them. The Wound-Wait prevention scheme also introduces preemption: older transactions can wound (abort) younger transactions holding needed resources.
व्याख्या (हिन्दी) नो-प्रीएम्पशन उन्मूलन (गतिरोध समाधान): जब गतिरोध का पता चलता है, तो डीबीएमएस एक पीड़ित लेनदेन का चयन करता है और इसे निरस्त कर देता है (अपने संसाधनों को रोक देता है)। यह पीड़ित के लेनदेनस्रोत को जबरन ले लेता है (ताले लगा देता है) और उन्हें छोड़ देता है। घाव-प्रतीक्षा रोकथाम योजना प्रीएम्प्शन का भी परिचय देती है: पुराने लेनदेन आवश्यक संसाधनों को रखने वाले युवा लेनदेन को समाप्त (निरस्त) कर सकते हैं।
1733
EN + हिं Medium
GB What is the difference between deadlock detection frequency and deadlock detection latency?
IN डेडलॉक डिटेक्शन फ़्रीक्वेंसी और डेडलॉक डिटेक्शन विलंबता के बीच क्या अंतर है?
A
Detection frequency: how often the deadlock detector runs (e.g. every 100ms or every N lock requests); Detection latency: how long a deadlock persists before being detected and resolved (= time to next detection run + detection + abort time). Trade-off: higher frequency = lower latency but higher CPU overhead from running detection; lower frequency = lower overhead but deadlocked transactions blocked longer पता लगाने की आवृत्ति: डेडलॉक डिटेक्टर कितनी बार चलता है (उदाहरण के लिए प्रत्येक 100 एमएस या प्रत्येक एन लॉक अनुरोध); डिटेक्शन विलंबता: पता लगाने और हल करने से पहले कितने समय तक गतिरोध बना रहता है (= अगली डिटेक्शन रन का समय + डिटेक्शन + निरस्त समय)। ट्रेड-ऑफ: उच्च आवृत्ति = कम विलंबता लेकिन रनिंग डिटेक्शन से उच्च सीपीयू ओवरहेड; कम आवृत्ति = कम ओवरहेड लेकिन गतिरोध वाले लेनदेन लंबे समय तक अवरुद्ध रहते हैं
B
Frequency refers to number of deadlocks; latency refers to resolution time आवृत्ति से तात्पर्य गतिरोधों की संख्या से है; विलंबता का तात्पर्य समाधान समय से है
C
Detection frequency only applies to distributed deadlocks पता लगाने की आवृत्ति केवल वितरित गतिरोधों पर लागू होती है
D
They are the same concept वे एक ही अवधारणा हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Detection frequency vs latency trade-off: If detection runs every 5 seconds: deadlocks may persist up to 5 seconds (blocking other transactions for that duration). If detection runs every 10ms: very low latency but CPU overhead from constant graph scanning. MySQL InnoDB: detects deadlocks immediately after each lock wait (very low latency, efficient because it only checks affected transactions not the whole graph).
व्याख्या (हिन्दी) डिटेक्शन फ़्रीक्वेंसी बनाम विलंबता ट्रेड-ऑफ़: यदि डिटेक्शन हर 5 सेकंड में चलता है: गतिरोध 5 सेकंड तक बना रह सकता है (उस अवधि के लिए अन्य लेनदेन को अवरुद्ध करना)। यदि डिटेक्शन हर 10ms पर चलता है: बहुत कम विलंबता लेकिन निरंतर ग्राफ़ स्कैनिंग से CPU ओवरहेड। MySQL InnoDB: प्रत्येक लॉक प्रतीक्षा के तुरंत बाद गतिरोध का पता लगाता है (बहुत कम विलंबता, कुशल क्योंकि यह केवल प्रभावित लेनदेन की जांच करता है, पूरे ग्राफ की नहीं)।
1734
EN + हिं Easy
GB What is cycle prevention vs cycle detection in the context of deadlock management strategies?
IN गतिरोध प्रबंधन रणनीतियों के संदर्भ में चक्र रोकथाम बनाम चक्र पहचान क्या है?
A
Prevention always outperforms detection रोकथाम हमेशा पता लगाने से बेहतर प्रदर्शन करती है
B
They are different terms for the same approach वे एक ही दृष्टिकोण के लिए अलग-अलग शब्द हैं
C
Detection is always preferred over prevention रोकथाम की तुलना में जांच को हमेशा प्राथमिकता दी जाती है
D
Cycle prevention: design the system so that cycles in the wait-for graph cannot form (e.g., lock ordering, Wait-Die, Wound-Wait, no-wait) - proactive approach that adds overhead to every transaction. Cycle detection: allow cycles to form then detect and break them periodically (e.g., wait-for graph cycle detection) - reactive approach lower per-transaction overhead but deadlocks persist briefly चक्र रोकथाम: सिस्टम को डिज़ाइन करें ताकि वेट-फॉर ग्राफ़ में चक्र न बन सकें (जैसे, लॉक ऑर्डरिंग, वेट-डाई, वाउंड-वेट, नो-वेट) - सक्रिय दृष्टिकोण जो हर लेनदेन में ओवरहेड जोड़ता है। चक्र का पता लगाना: चक्रों को बनने की अनुमति दें, फिर समय-समय पर उनका पता लगाएं और उन्हें तोड़ें (उदाहरण के लिए, ग्राफ़ चक्र का पता लगाने के लिए प्रतीक्षा करें) - प्रतिक्रियाशील दृष्टिकोण कम प्रति-लेन-देन ओवरहेड लेकिन गतिरोध थोड़े समय के लिए बना रहता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Prevention vs Detection trade-offs: Prevention overhead: every lock acquisition must check ordering rules or timestamp comparison - overhead even when no deadlock. Detection overhead: periodic graph scan or per-wait-graph update - overhead only when waits exist, but deadlocks briefly persist. Most OLTP DBMS use detection (InnoDB) because prevention (like lock ordering) is too restrictive for application developers to maintain.
व्याख्या (हिन्दी) रोकथाम बनाम जांच व्यापार-बंद: रोकथाम ओवरहेड: प्रत्येक लॉक अधिग्रहण को ऑर्डरिंग नियमों या टाइमस्टैम्प तुलना की जांच करनी चाहिए - कोई गतिरोध न होने पर भी ओवरहेड। डिटेक्शन ओवरहेड: आवधिक ग्राफ स्कैन या प्रति-प्रतीक्षा-ग्राफ अद्यतन - ओवरहेड केवल तभी जब प्रतीक्षा मौजूद होती है, लेकिन गतिरोध थोड़े समय के लिए बना रहता है। अधिकांश ओएलटीपी डीबीएमएस डिटेक्शन (इनोडीबी) का उपयोग करते हैं क्योंकि रोकथाम (जैसे लॉक ऑर्डरिंग) एप्लिकेशन डेवलपर्स के लिए बनाए रखने के लिए बहुत प्रतिबंधात्मक है।
1735
EN + हिं Easy
GB What is the innodb_deadlock_detect system variable in MySQL and what is the alternative when it is disabled?
IN MySQL में innodb_deadlock_detect सिस्टम वेरिएबल क्या है और इसके अक्षम होने पर विकल्प क्या है?
A
innodb_deadlock_detect=ON (default): InnoDB actively detects deadlocks using a wait-for graph and immediately resolves them by aborting a victim. innodb_deadlock_detect=OFF: deadlock detection is disabled; the lock wait timeout (innodb_lock_wait_timeout) becomes the only mechanism to break deadlocks - transactions wait until timeout then abort. Disabling detection reduces overhead in very high-concurrency scenarios but increases worst-case deadlock resolution time. innodb_deadlock_detect=ON (डिफ़ॉल्ट): InnoDB सक्रिय रूप से प्रतीक्षा-ग्राफ़ का उपयोग करके गतिरोधों का पता लगाता है और पीड़ित को गर्भपात करके तुरंत उनका समाधान करता है। innodb_deadlock_detect=OFF: गतिरोध का पता लगाना अक्षम है; लॉक वेट टाइमआउट (innodb_lock_wait_timeout) गतिरोध को तोड़ने का एकमात्र तंत्र बन जाता है - लेनदेन टाइमआउट तक प्रतीक्षा करते हैं और फिर निरस्त हो जाते हैं। पहचान को अक्षम करने से बहुत उच्च-समवर्ती परिदृश्यों में ओवरहेड कम हो जाता है लेकिन सबसे खराब स्थिति में गतिरोध समाधान समय बढ़ जाता है।
B
It controls the deadlock timeout value यह डेडलॉक टाइमआउट मान को नियंत्रित करता है
C
It controls whether deadlocks are logged to the error log यह नियंत्रित करता है कि त्रुटि लॉग में गतिरोध लॉग हैं या नहीं
D
It determines which transaction becomes the deadlock victim यह निर्धारित करता है कि कौन सा लेनदेन गतिरोध का शिकार बनेगा
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) innodb_deadlock_detect: ON = active detection (default, recommended for most workloads). OFF = use timeout-only for resolution. Use case for OFF: extremely high concurrency systems where the deadlock detection mutex itself becomes a bottleneck (the detection latch protects the wait-for graph - under extremely high concurrent locking, this latch becomes a serialization point). Alternative: use innodb_lock_wait_timeout with a short value (e.g., 5 seconds).
व्याख्या (हिन्दी) innodb_deadlock_detect: ON = सक्रिय पहचान (डिफ़ॉल्ट, अधिकांश कार्यभार के लिए अनुशंसित)। बंद = समाधान के लिए केवल टाइमआउट का उपयोग करें। ऑफ के लिए केस का उपयोग करें: अत्यधिक उच्च समवर्ती प्रणाली जहां डेडलॉक डिटेक्शन म्यूटेक्स स्वयं एक बाधा बन जाता है (डिटेक्शन लैच प्रतीक्षा-ग्राफ की सुरक्षा करता है - अत्यधिक उच्च समवर्ती लॉकिंग के तहत, यह लैच एक क्रमबद्धता बिंदु बन जाता है)। वैकल्पिक: कम मान (जैसे, 5 सेकंड) के साथ innodb_lock_wait_timeout का उपयोग करें।
1736
EN + हिं Easy
GB What are the implications of deadlocks in distributed microservices systems that use distributed transactions (SAGA pattern)?
IN वितरित लेनदेन (एसएजीए पैटर्न) का उपयोग करने वाले वितरित माइक्रोसर्विसेज सिस्टम में गतिरोध के निहितार्थ क्या हैं?
A
Deadlocks in microservices require manual DBA intervention माइक्रोसर्विसेज में गतिरोध के लिए मैन्युअल डीबीए हस्तक्षेप की आवश्यकता होती है
B
In SAGA-based distributed transactions traditional database deadlocks at the local level can still occur within each services database; additionally SAGA introduces higher-level semantic deadlocks where multiple sagas wait for each other to complete compensating actions or where resource locks across services create circular dependencies - resolved by designing sagas to acquire resources in consistent order and implementing timeouts for saga steps एसएजीए-आधारित वितरित लेनदेन में स्थानीय स्तर पर पारंपरिक डेटाबेस गतिरोध अभी भी प्रत्येक सेवा डेटाबेस के भीतर हो सकता है; इसके अतिरिक्त SAGA उच्च-स्तरीय सिमेंटिक गतिरोधों का परिचय देता है, जहां कई गाथाएं क्षतिपूर्ति कार्यों को पूरा करने के लिए एक-दूसरे की प्रतीक्षा करती हैं या जहां सेवाओं में संसाधन लॉक परिपत्र निर्भरताएं बनाते हैं - सुसंगत क्रम में संसाधनों को प्राप्त करने के लिए गाथाओं को डिजाइन करके और गाथा चरणों के लिए टाइमआउट लागू करके हल किया जाता है।
C
SAGA eliminates all deadlock possibilities SAGA सभी गतिरोध संभावनाओं को समाप्त कर देता है
D
SAGA prevents deadlocks by eliminating all locking SAGA सभी लॉकिंग को समाप्त करके गतिरोध को रोकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Distributed microservice deadlocks: (1) Local deadlocks: each service may have deadlocks within its own database (handled by individual DBMS deadlock detection). (2) Saga-level deadlocks: uncommon but possible when sagas hold semantic locks (reservation of resources) in circular dependencies. Prevention: define saga ordering rules, implement step timeouts, use choreography with event-based coordination to reduce blocking.
व्याख्या (हिन्दी) वितरित माइक्रोसर्विस गतिरोध: (1) स्थानीय गतिरोध: प्रत्येक सेवा के अपने डेटाबेस में गतिरोध हो सकते हैं (व्यक्तिगत डीबीएमएस गतिरोध का पता लगाने द्वारा नियंत्रित)। (2) सागा-स्तरीय गतिरोध: असामान्य लेकिन संभव है जब सागा परिपत्र निर्भरता में सिमेंटिक लॉक (संसाधनों का आरक्षण) रखता है। रोकथाम: सागा ऑर्डरिंग नियमों को परिभाषित करें, चरण टाइमआउट लागू करें, अवरोधन को कम करने के लिए इवेंट-आधारित समन्वय के साथ कोरियोग्राफी का उपयोग करें।
1737
EN + हिं Easy
GB What is role-based access control (RBAC) in database security?
IN डेटाबेस सुरक्षा में भूमिका-आधारित अभिगम नियंत्रण (आरबीएसी) क्या है?
A
RBAC: privileges are assigned to roles (logical groups) and roles are assigned to users; changing a roles privileges automatically affects all users with that role. Direct grants: privileges assigned directly to individual users making management complex and error-prone at scale आरबीएसी: विशेषाधिकार भूमिकाओं (तार्किक समूहों) को सौंपे जाते हैं और भूमिकाएं उपयोगकर्ताओं को सौंपी जाती हैं; किसी भूमिका के विशेषाधिकार बदलने से उस भूमिका वाले सभी उपयोगकर्ता स्वचालित रूप से प्रभावित होते हैं। प्रत्यक्ष अनुदान: प्रबंधन को जटिल और बड़े पैमाने पर त्रुटि-प्रवण बनाने वाले व्यक्तिगत उपयोगकर्ताओं को सीधे दिए गए विशेषाधिकार
B
Roles can only be assigned to database administrators भूमिकाएँ केवल डेटाबेस प्रशासकों को सौंपी जा सकती हैं
C
RBAC is weaker than direct privilege grants आरबीएसी प्रत्यक्ष विशेषाधिकार अनुदान से कमजोर है
D
RBAC is identical to direct privilege grants आरबीएसी प्रत्यक्ष विशेषाधिकार अनुदान के समान है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RBAC example: CREATE ROLE analyst_role; GRANT SELECT ON sales TO analyst_role; GRANT analyst_role TO alice, bob, charlie. Adding new analyst: GRANT analyst_role TO dave (one command). Changing analyst privileges: ALTER ROLE analyst_role (affects all automatically). Direct grants: 4 individual GRANT commands, error-prone.
व्याख्या (हिन्दी) आरबीएसी उदाहरण: भूमिका विश्लेषक_भूमिका बनाएं; विश्लेषक_भूमिका को बिक्री पर अनुदान चयन; ऐलिस, बॉब, चार्ली को विश्लेषक की भूमिका प्रदान करें। नया विश्लेषक जोड़ा जा रहा है: डेव को विश्लेषक की भूमिका प्रदान करें (एक आदेश)। विश्लेषक विशेषाधिकार बदलना: भूमिका विश्लेषक_भूमिका बदलें (सभी को स्वचालित रूप से प्रभावित करता है)। प्रत्यक्ष अनुदान: 4 व्यक्तिगत अनुदान आदेश, त्रुटि-प्रवण।
1738
EN + हिं Medium
GB What is row-level security (RLS) and how does it differ from view-based row filtering?
IN पंक्ति-स्तरीय सुरक्षा (आरएलएस) क्या है और यह दृश्य-आधारित पंक्ति फ़िल्टरिंग से कैसे भिन्न है?
A
RLS is only available in NoSQL databases RLS केवल NoSQL डेटाबेस में उपलब्ध है
B
RLS requires application code to implement आरएलएस को लागू करने के लिए एप्लिकेशन कोड की आवश्यकता होती है
C
RLS is a database feature where security policies are automatically applied to queries at the database level based on the executing user/role transparently filtering rows without requiring application code or view modifications; views require explicit usage and can be bypassed if user has direct table access आरएलएस एक डेटाबेस सुविधा है जहां सुरक्षा नीतियां स्वचालित रूप से एप्लिकेशन कोड या दृश्य संशोधनों की आवश्यकता के बिना निष्पादित उपयोगकर्ता/भूमिका के आधार पर पंक्तियों को पारदर्शी रूप से फ़िल्टर करने वाले डेटाबेस स्तर पर प्रश्नों पर लागू होती हैं; दृश्यों के लिए स्पष्ट उपयोग की आवश्यकता होती है और यदि उपयोगकर्ता के पास सीधी तालिका पहुंच है तो इसे बायपास किया जा सकता है
D
RLS and view-based filtering are identical आरएलएस और दृश्य-आधारित फ़िल्टरिंग समान हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RLS (PostgreSQL): CREATE POLICY emp_policy ON employee FOR SELECT USING (dept = current_user_dept()); ALTER TABLE employee ENABLE ROW LEVEL SECURITY. Any SELECT on employee automatically filters by department even if user queries the base table directly. Cannot be bypassed by the restricted user.
व्याख्या (हिन्दी) आरएलएस (पोस्टग्रेएसक्यूएल): चुनिंदा उपयोग के लिए कर्मचारी पर नीति emp_policy बनाएं (विभाग = current_user_dept()); परिवर्तन तालिका कर्मचारी पंक्ति स्तरीय सुरक्षा सक्षम करें। कर्मचारी पर कोई भी चयन स्वचालित रूप से विभाग द्वारा फ़िल्टर किया जाता है, भले ही उपयोगकर्ता सीधे आधार तालिका पर सवाल उठाता हो। प्रतिबंधित उपयोगकर्ता द्वारा बायपास नहीं किया जा सकता.
1739
EN + हिं Easy
GB What is transparent data encryption (TDE) and what threat does it protect against?
IN पारदर्शी डेटा एन्क्रिप्शन (टीडीई) क्या है और यह किस खतरे से बचाता है?
A
Database-level encryption where data files log files and backups are encrypted on disk automatically by the DBMS without application changes; protects against: theft of physical storage media unauthorized access to database file copies but does NOT protect against authorized database users or SQL injection डेटाबेस-स्तरीय एन्क्रिप्शन जहां डेटा फ़ाइलें लॉग फ़ाइलें और बैकअप एप्लिकेशन परिवर्तन के बिना डीबीएमएस द्वारा स्वचालित रूप से डिस्क पर एन्क्रिप्ट की जाती हैं; इनसे सुरक्षा करता है: भौतिक भंडारण मीडिया की चोरी, डेटाबेस फ़ाइल प्रतियों तक अनधिकृत पहुंच, लेकिन अधिकृत डेटाबेस उपयोगकर्ताओं या SQL इंजेक्शन से सुरक्षा नहीं करता है
B
Encryption applied transparently to all SQL results एन्क्रिप्शन सभी SQL परिणामों पर पारदर्शी रूप से लागू किया गया
C
Encryption that is visible to database users एन्क्रिप्शन जो डेटाबेस उपयोगकर्ताओं को दिखाई देता है
D
Encryption of the database schema definition डेटाबेस स्कीमा परिभाषा का एन्क्रिप्शन
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) TDE protection: physical media theft (stolen hard drive has encrypted data = unreadable without DBMS key). Backup file theft (encrypted backup file is unreadable without key). Does NOT protect: legitimate DB user with SELECT privilege, DBA accounts, in-memory data during query execution, or SQL injection attacks.
व्याख्या (हिन्दी) टीडीई सुरक्षा: भौतिक मीडिया चोरी (चोरी की गई हार्ड ड्राइव में एन्क्रिप्टेड डेटा = डीबीएमएस कुंजी के बिना अपठनीय है)। बैकअप फ़ाइल चोरी (एन्क्रिप्टेड बैकअप फ़ाइल कुंजी के बिना अपठनीय है)। सुरक्षा नहीं करता: SELECT विशेषाधिकार के साथ वैध DB उपयोगकर्ता, DBA खाते, क्वेरी निष्पादन के दौरान इन-मेमोरी डेटा, या SQL इंजेक्शन हमले।
1740
EN + हिं Easy
GB What is data masking (static vs dynamic) in database security?
IN डेटाबेस सुरक्षा में डेटा मास्किंग (स्थैतिक बनाम गतिशील) क्या है?
A
Static data masking: permanently replaces sensitive data with realistic but fictitious values in non-production copies. Dynamic data masking: applies masking rules at query time for specific users returning masked values while original data remains stored unchanged स्टेटिक डेटा मास्किंग: गैर-उत्पादन प्रतियों में संवेदनशील डेटा को यथार्थवादी लेकिन काल्पनिक मूल्यों से स्थायी रूप से बदल देता है। डायनामिक डेटा मास्किंग: विशिष्ट उपयोगकर्ताओं के लिए क्वेरी समय पर मास्किंग नियम लागू करता है, जो मास्क्ड मान लौटाते हैं, जबकि मूल डेटा अपरिवर्तित रहता है
B
Compressing data for storage efficiency भंडारण दक्षता के लिए डेटा को संपीड़ित करना
C
Encrypting data before storage भंडारण से पहले डेटा एन्क्रिप्ट करना
D
Hiding column names from users उपयोगकर्ताओं से कॉलम नाम छुपाया जा रहा है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Static masking: copy prod data, apply irreversible masks (SSN 123-45-6789 becomes 999-99-9999), give to dev team. Data cannot be unmasked. Dynamic masking (SQL Server, Oracle): DBA sees real SSN, app user sees masked value. Applied at query time. Useful for: partial data visibility, customer service seeing only last 4 digits.
व्याख्या (हिन्दी) स्टेटिक मास्किंग: उत्पाद डेटा कॉपी करें, अपरिवर्तनीय मास्क लागू करें (एसएसएन 123-45-6789 999-99-9999 बन जाता है), डेव टीम को दें। डेटा को उजागर नहीं किया जा सकता. डायनेमिक मास्किंग (एसक्यूएल सर्वर, ओरेकल): डीबीए वास्तविक एसएसएन देखता है, ऐप उपयोगकर्ता मास्क्ड वैल्यू देखता है। क्वेरी के समय लागू किया गया. इसके लिए उपयोगी: आंशिक डेटा दृश्यता, ग्राहक सेवा केवल अंतिम 4 अंक देखती है।
1726–1740 of 2982