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
1831
EN + हिं Medium
GB What is the driving table concept in nested loop join execution and how does the optimizer choose it?
IN नेस्टेड लूप जॉइन निष्पादन में ड्राइविंग टेबल अवधारणा क्या है और ऑप्टिमाइज़र इसे कैसे चुनता है?
A
The driving table is always the first table listed in the FROM clause ड्राइविंग टेबल हमेशा FROM क्लॉज में सूचीबद्ध पहली टेबल होती है
B
In a nested loop join the driving table (outer loop) is the table whose rows are iterated one by one with the inner table looked up for each outer row; the optimizer chooses the smaller or more filtered table as the driving table to minimize iterations; an index on the inner table's join column is critical एक नेस्टेड लूप में ड्राइविंग टेबल से जुड़ें (बाहरी लूप) वह तालिका है जिसकी पंक्तियों को एक-एक करके दोहराया जाता है और प्रत्येक बाहरी पंक्ति के लिए आंतरिक तालिका देखी जाती है; ऑप्टिमाइज़र पुनरावृत्तियों को कम करने के लिए ड्राइविंग टेबल के रूप में छोटी या अधिक फ़िल्टर की गई तालिका को चुनता है; आंतरिक टेबल के जॉइन कॉलम पर एक इंडेक्स महत्वपूर्ण है
C
The table that drives the query plan in all join types always वह तालिका जो सभी प्रकार के जॉइन में हमेशा क्वेरी प्लान चलाती है
D
The driving table is always the larger table for maximum efficiency अधिकतम दक्षता के लिए ड्राइविंग टेबल हमेशा बड़ी टेबल होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Driving table selection: optimizer estimates rows returned by each table after applying WHERE filter, chooses smaller filtered result as outer (driving) table, verifies inner table has suitable index. Example: orders(10M rows) JOIN customers(100K rows) WHERE orders.date=2024 (returns 10K orders): driving=filtered orders(10K), inner=customers with index on id. If no index on customers.id: optimizer may switch to hash join.
व्याख्या (हिन्दी) ड्राइविंग टेबल चयन: ऑप्टिमाइज़र WHERE फ़िल्टर लागू करने के बाद प्रत्येक तालिका द्वारा लौटाई गई पंक्तियों का अनुमान लगाता है, बाहरी (ड्राइविंग) तालिका के रूप में छोटे फ़िल्टर किए गए परिणाम को चुनता है, सत्यापित करता है कि आंतरिक तालिका में उपयुक्त सूचकांक है। उदाहरण: ऑर्डर (10M पंक्तियाँ) ग्राहकों से जुड़ें (100K पंक्तियाँ) जहाँ ऑर्डर.डेट = 2024 (10K ऑर्डर लौटाता है): ड्राइविंग = फ़िल्टर किए गए ऑर्डर (10K), आंतरिक = आईडी पर इंडेक्स वाले ग्राहक। यदि customer.id पर कोई इंडेक्स नहीं है: ऑप्टिमाइज़र हैश जॉइन पर स्विच कर सकता है।
1832
EN + हिं Medium
GB What is predicate pushdown through a join and why is it important for query performance?
IN जॉइन के माध्यम से प्रीडिकेट पुशडाउन क्या है और क्वेरी प्रदर्शन के लिए यह महत्वपूर्ण क्यों है?
A
Pushing predicates from subqueries to outer queries automatically सबक्वेरीज़ से बाहरी क्वेरीज़ की ओर स्वचालित रूप से विधेय को पुश करना
B
Pushing SQL predicates into stored procedures for reuse पुन: उपयोग के लिए संग्रहीत कार्यविधियों में SQL प्रेडिकेट को पुश करना
C
Moving predicates from WHERE to HAVING clause for correctness शुद्धता के लिए विधेय को WHERE से HAVING उपवाक्य की ओर ले जाना
D
Moving filter conditions (WHERE predicates) to be applied as early as possible in the execution plan - ideally directly on the base table scan before the join - so that fewer rows participate in the join operation; this is one of the most impactful query optimizer transformations and can reduce join input size by orders of magnitude निष्पादन योजना में जितनी जल्दी हो सके मूविंग फ़िल्टर शर्तों (जहां विधेय) को लागू किया जाना चाहिए - आदर्श रूप से सीधे जुड़ने से पहले बेस टेबल स्कैन पर - ताकि कम पंक्तियाँ जुड़ने के ऑपरेशन में भाग लें; यह सबसे प्रभावशाली क्वेरी ऑप्टिमाइज़र परिवर्तनों में से एक है और परिमाण के क्रम से जॉइन इनपुट आकार को कम कर सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Without pushdown: scan all orders (10M), scan all customers (1M), join, then filter WHERE orders.date=2024. With pushdown: filter orders first (10M -> 10K rows with date=2024), filter customers WHERE region=US (1M -> 100K), then join (10K * 100K). Pushdown blocked by: non-deterministic functions, LIMIT in subquery, some aggregate views. EXPLAIN shows Filter node placement.
व्याख्या (हिन्दी) पुशडाउन के बिना: सभी ऑर्डर स्कैन करें (10एम), सभी ग्राहकों को स्कैन करें (1एम), शामिल हों, फिर फ़िल्टर करें WHERE ऑर्डर.दिनांक=2024। पुशडाउन के साथ: पहले ऑर्डर फ़िल्टर करें (तारीख = 2024 के साथ 10M -> 10K पंक्तियाँ), ग्राहकों को फ़िल्टर करें जहाँ क्षेत्र = US (1M -> 100K), फिर जुड़ें (10K * 100K)। पुशडाउन द्वारा अवरुद्ध: गैर-नियतात्मक कार्य, सबक्वेरी में LIMIT, कुछ समग्र दृश्य। EXPLAIN फ़िल्टर नोड प्लेसमेंट दिखाता है।
1833
EN + हिं Medium
GB What is a hash join spill and what happens when the build-side hash table does not fit in memory?
IN हैश जॉइन स्पिल क्या है और क्या होता है जब बिल्ड-साइड हैश टेबल मेमोरी में फिट नहीं होती है?
A
A hash join that overflows into another database automatically एक हैश जुड़ाव स्वचालित रूप से दूसरे डेटाबेस में ओवरफ्लो हो जाता है
B
When the build-side relation is too large to fit in the allocated hash join memory, the DBMS performs a grace hash join: partitions both relations to disk using the hash function (ensuring matching rows land in same partition files), then processes each partition pair independently in memory; this increases I/O but prevents out-of-memory errors जब बिल्ड-साइड संबंध आवंटित हैश जॉइन मेमोरी में फिट होने के लिए बहुत बड़ा है, तो डीबीएमएस एक ग्रेस हैश जॉइन करता है: हैश फ़ंक्शन का उपयोग करके डिस्क पर दोनों संबंधों को विभाजित करता है (सुनिश्चित करता है कि मिलान पंक्तियां समान विभाजन फ़ाइलों में आती हैं), फिर प्रत्येक विभाजन जोड़ी को मेमोरी में स्वतंत्र रूप से संसाधित करता है; यह I/O बढ़ाता है लेकिन आउट-ऑफ-मेमोरी त्रुटियों को रोकता है
C
A hash join that automatically converts to a nested loop join when memory is full एक हैश जॉइन जो मेमोरी भर जाने पर स्वचालित रूप से नेस्टेड लूप जॉइन में परिवर्तित हो जाता है
D
A hash join that produces incorrect results when data is too large एक हैश जॉइन जो डेटा बहुत बड़ा होने पर गलत परिणाम उत्पन्न करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hash join memory: work_mem in PostgreSQL (default 4MB per sort/hash). If build table > work_mem: grace hash join kicks in. Cost: 3*(|R|+|S|) I/O pages vs 1*(|R|+|S|) for in-memory. Detection in EXPLAIN ANALYZE: Batches=N (N>1 means spill occurred). Fix: increase work_mem (SET work_mem=256MB), add filter to reduce build table size, or add index to use nested loop join instead.
व्याख्या (हिन्दी) हैश जॉइन मेमोरी: PostgreSQL में Work_mem (डिफ़ॉल्ट 4MB प्रति सॉर्ट/हैश)। यदि बिल्ड टेबल> वर्क_मेम: ग्रेस हैश जॉइन शुरू होता है। लागत: 3*(|R|+|S|) I/O पेज बनाम 1*(|R|+|S|) इन-मेमोरी के लिए। व्याख्या विश्लेषण में पता लगाना: बैच=एन (एन>1 का मतलब है रिसाव हुआ)। ठीक करें: वर्क_मेम बढ़ाएँ (SET वर्क_मेम=256एमबी), बिल्ड टेबल का आकार कम करने के लिए फ़िल्टर जोड़ें, या इसके बजाय नेस्टेड लूप जॉइन का उपयोग करने के लिए इंडेक्स जोड़ें।
1834
EN + हिं Medium
GB What is view dependency tracking and why is it critical for database change management?
IN दृश्य निर्भरता ट्रैकिंग क्या है और डेटाबेस परिवर्तन प्रबंधन के लिए यह महत्वपूर्ण क्यों है?
A
Tracking the performance metrics of view queries over time समय के साथ दृश्य क्वेरी के प्रदर्शन मेट्रिक्स को ट्रैक करना
B
Tracking how many users are accessing a view at any given time यह ट्रैक करना कि किसी भी समय कितने उपयोगकर्ता किसी दृश्य तक पहुंच रहे हैं
C
The process of maintaining records of which views depend on which base tables (and which views depend on other views), enabling DBAs to identify the impact of schema changes before making them, determine the correct order to drop/recreate objects, and automatically invalidate dependent objects when base schemas change कौन से दृश्य किस आधार तालिका पर निर्भर करते हैं (और कौन से दृश्य अन्य दृश्यों पर निर्भर करते हैं) के रिकॉर्ड को बनाए रखने की प्रक्रिया, डीबीए को उन्हें बनाने से पहले स्कीमा परिवर्तनों के प्रभाव की पहचान करने, वस्तुओं को छोड़ने/पुनः बनाने का सही क्रम निर्धारित करने और आधार स्कीमा बदलने पर स्वचालित रूप से निर्भर वस्तुओं को अमान्य करने में सक्षम बनाती है।
D
A method of versioning view definitions for rollback capability रोलबैक क्षमता के लिए दृश्य परिभाषाओं को संस्करणबद्ध करने की एक विधि
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Dependency queries: PostgreSQL: SELECT * FROM information_schema.view_table_usage WHERE view_name=my_view. Oracle: SELECT * FROM dba_dependencies WHERE name=MY_VIEW. SQL Server: sys.sql_expression_dependencies. WITH SCHEMABINDING prevents breaking changes. Tools: Liquibase/Flyway track migration order. Impact analysis: before ALTER TABLE, find all views/functions/procs referencing it.
व्याख्या (हिन्दी) निर्भरता प्रश्न: PostgreSQL: चुनें * जानकारी_schema.view_table_usage से जहां view_name=my_view. ओरेकल: dba_dependency से * चुनें जहां नाम = MY_VIEW है। SQL सर्वर: sys.sql_expression_dependcies. SCHEMABINDING के साथ परिवर्तनों को तोड़ने से रोकता है। उपकरण: लिक्विबेस/फ्लाईवे ट्रैक माइग्रेशन ऑर्डर। प्रभाव विश्लेषण: परिवर्तन तालिका से पहले, इसे संदर्भित करने वाले सभी दृश्य/फ़ंक्शन/प्रोसेस ढूंढें।
1835
EN + हिं Easy
GB What is the performance impact of deeply nested views (view on view on view) in a DBMS?
IN डीबीएमएस में गहराई से नेस्टेड दृश्यों (दृश्य पर दृश्य) का प्रदर्शन प्रभाव क्या है?
A
Deeply nested views have absolutely no performance impact whatsoever गहराई से निहित दृश्यों का प्रदर्शन पर बिल्कुल भी कोई प्रभाव नहीं पड़ता है
B
The DBMS automatically and always flattens all nested views for performance प्रदर्शन के लिए DBMS स्वचालित रूप से और हमेशा सभी नेस्टेड दृश्यों को फ़्लैट करता है
C
Deeply nested views always improve performance through automatic caching गहरे रूप से नेस्टेड दृश्य हमेशा स्वचालित कैशिंग के माध्यम से प्रदर्शन में सुधार करते हैं
D
Deep view nesting adds query parsing and optimization overhead; the query optimizer must recursively expand all view definitions before planning; deep nesting can prevent some optimizer transformations (predicate pushdown, join reordering) if intermediate view definitions use features that block merging such as aggregates, DISTINCT, or LIMIT डीप व्यू नेस्टिंग क्वेरी पार्सिंग और ऑप्टिमाइज़ेशन ओवरहेड जोड़ता है; योजना बनाने से पहले क्वेरी ऑप्टिमाइज़र को सभी दृश्य परिभाषाओं का पुनरावर्ती विस्तार करना चाहिए; यदि मध्यवर्ती दृश्य परिभाषाएँ उन सुविधाओं का उपयोग करती हैं जो समुच्चय, DISTINCT, या LIMIT जैसे विलय को अवरुद्ध करती हैं, तो डीप नेस्टिंग कुछ ऑप्टिमाइज़र परिवर्तनों (प्रिडिकेट पुशडाउन, जॉइन रीऑर्डरिंग) को रोक सकती है।
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View nesting performance: V3 -> V2 -> V1 -> base_table. V2 has GROUP BY: optimizer cannot push V3 predicates into V2 or V1 (GROUP BY blocks merge). Solution: materialize V2 as MV_V2, query V3 on top of MV_V2. PostgreSQL EXPLAIN: shows whether view is merged or materialized as subquery (InitPlan node). Best practice: max 3-4 view levels; use materialized views for aggregation layers.
व्याख्या (हिन्दी) नेस्टिंग प्रदर्शन देखें: V3 -> V2 -> V1 -> बेस_टेबल। V2 में ग्रुप BY है: ऑप्टिमाइज़र V3 विधेय को V2 या V1 (GROUP BY ब्लॉक मर्ज) में नहीं धकेल सकता है। समाधान: V2 को MV_V2 के रूप में साकार करें, MV_V2 के शीर्ष पर V3 को क्वेरी करें। PostgreSQL EXPLAIN: दिखाता है कि दृश्य को मर्ज किया गया है या सबक्वेरी (InitPlan नोड) के रूप में मूर्त रूप दिया गया है। सर्वोत्तम अभ्यास: अधिकतम 3-4 दृश्य स्तर; एकत्रीकरण परतों के लिए भौतिक दृश्यों का उपयोग करें।
1836
EN + हिं Easy
GB What is index selectivity estimation and why do stale statistics cause poor query plans?
IN सूचकांक चयनात्मकता अनुमान क्या है और पुराने आँकड़े खराब क्वेरी योजनाओं का कारण क्यों बनते हैं?
A
Estimating how many indexes a table needs for optimal performance यह अनुमान लगाना कि इष्टतम प्रदर्शन के लिए किसी तालिका को कितने अनुक्रमितों की आवश्यकता है
B
A method for compressing index storage to reduce disk space usage डिस्क स्थान के उपयोग को कम करने के लिए इंडेक्स स्टोरेज को संपीड़ित करने की एक विधि
C
The query optimizer estimates how many rows an index access will return using column statistics (histogram, distinct value count, null fraction); stale statistics cause the optimizer to generate suboptimal plans such as choosing a full table scan when a highly selective index exists or choosing an index scan when most rows match and a full scan would be faster क्वेरी ऑप्टिमाइज़र अनुमान लगाता है कि कॉलम आँकड़ों (हिस्टोग्राम, विशिष्ट मान गणना, शून्य अंश) का उपयोग करके इंडेक्स एक्सेस कितनी पंक्तियाँ लौटाएगा; पुराने आँकड़े ऑप्टिमाइज़र को उप-इष्टतम योजनाएँ उत्पन्न करने का कारण बनते हैं जैसे कि अत्यधिक चयनात्मक सूचकांक मौजूद होने पर पूर्ण तालिका स्कैन चुनना या जब अधिकांश पंक्तियाँ मेल खाती हैं तो सूचकांक स्कैन चुनना और पूर्ण स्कैन तेज़ होगा
D
Counting the number of distinct index values for reporting purposes रिपोर्टिंग उद्देश्यों के लिए विशिष्ट सूचकांक मानों की संख्या की गणना करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Statistics staleness: after bulk INSERT/DELETE/UPDATE of large percentage of table, statistics become stale. Fix: ANALYZE table (PostgreSQL), UPDATE STATISTICS table (SQL Server), ANALYZE TABLE table (MySQL). Auto-stats: autovacuum in PostgreSQL updates stats when >20% of table changes. Bad plan symptoms: EXPLAIN shows Rows=1 but actual=1000000 (huge estimate error).
व्याख्या (हिन्दी) सांख्यिकी बासीपन: तालिका के बड़े प्रतिशत को सम्मिलित करने/हटाने/अद्यतन करने के बाद, आँकड़े बासी हो जाते हैं। ठीक करें: तालिका का विश्लेषण करें (PostgreSQL), अद्यतन सांख्यिकी तालिका (SQL सर्वर), तालिका तालिका का विश्लेषण करें (MySQL)। ऑटो-आँकड़े: PostgreSQL में ऑटोवैक्यूम आँकड़े अपडेट करता है जब तालिका का 20% बदलता है। ख़राब योजना के लक्षण: EXPLAIN पंक्तियाँ=1 दिखाता है लेकिन वास्तविक=1000000 (भारी अनुमान त्रुटि)।
1837
EN + हिं Medium
GB What is the difference between index range scan and full index scan in execution plans?
IN निष्पादन योजनाओं में इंडेक्स रेंज स्कैन और पूर्ण इंडेक्स स्कैन के बीच क्या अंतर है?
A
Full index scan is always faster than range scan in all scenarios पूर्ण सूचकांक स्कैन सभी परिदृश्यों में रेंज स्कैन से हमेशा तेज़ होता है
B
Range scan always reads more data than full index scan रेंज स्कैन हमेशा पूर्ण इंडेक्स स्कैन की तुलना में अधिक डेटा पढ़ता है
C
Index range scan: uses the B-tree to navigate to the start of a range and reads sequentially until the range end; efficient for selective range conditions. Full index scan: reads all leaf pages of the index from start to end; used when ORDER BY matches index, covering index answers query without heap access, or for small tables इंडेक्स रेंज स्कैन: किसी रेंज की शुरुआत में नेविगेट करने के लिए बी-ट्री का उपयोग करता है और रेंज के अंत तक क्रमिक रूप से पढ़ता है; चयनात्मक श्रेणी स्थितियों के लिए कुशल। पूर्ण इंडेक्स स्कैन: इंडेक्स के सभी लीफ पेजों को शुरू से अंत तक पढ़ता है; इसका उपयोग तब किया जाता है जब ORDER BY इंडेक्स से मेल खाता है, इंडेक्स उत्तर क्वेरी को बिना हीप एक्सेस के, या छोटी तालिकाओं के लिए कवर करता है
D
They are identical operations with different names in different databases वे अलग-अलग डेटाबेस में अलग-अलग नामों के साथ समान ऑपरेशन हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) PostgreSQL EXPLAIN: Index Scan (range seek) vs Index Only Scan (covering, full or range) vs Seq Scan (heap). When does optimizer prefer full index scan over full heap scan? When index is much smaller than table AND all needed columns are in the index (index-only scan). When does it prefer full heap scan over full index scan? When index is nearly as large as heap and most rows are selected. Threshold: typically >10-20% of rows -> full scan preferred.
व्याख्या (हिन्दी) PostgreSQL व्याख्या: इंडेक्स स्कैन (रेंज सीक) बनाम इंडेक्स ओनली स्कैन (कवरिंग, फुल या रेंज) बनाम सेक स्कैन (हीप)। ऑप्टिमाइज़र कब पूर्ण हीप स्कैन की तुलना में पूर्ण इंडेक्स स्कैन को प्राथमिकता देता है? जब सूचकांक तालिका से बहुत छोटा होता है और सभी आवश्यक कॉलम सूचकांक में होते हैं (केवल सूचकांक स्कैन)। यह पूर्ण इंडेक्स स्कैन की तुलना में पूर्ण हीप स्कैन को कब प्राथमिकता देता है? जब सूचकांक लगभग ढेर जितना बड़ा हो और अधिकांश पंक्तियाँ चयनित हों। सीमा: आम तौर पर >10-20% पंक्तियाँ -> पूर्ण स्कैन को प्राथमिकता दी जाती है।
1838
EN + हिं Easy
GB What is a compensation transaction in distributed transaction management and when is it used?
IN वितरित लेनदेन प्रबंधन में मुआवजा लेनदेन क्या है और इसका उपयोग कब किया जाता है?
A
A compensation transaction is a semantically inverse operation that undoes the effects of a previously committed transaction when a later step in a distributed saga or workflow fails; unlike physical undo (only possible for uncommitted transactions), compensation is a new positive transaction that reverses the business effect such as issuing a refund to compensate for a completed charge मुआवज़ा लेनदेन एक शब्दार्थ रूप से उलटा ऑपरेशन है जो पहले प्रतिबद्ध लेनदेन के प्रभावों को समाप्त कर देता है जब वितरित गाथा या वर्कफ़्लो में बाद का चरण विफल हो जाता है; भौतिक पूर्ववत (केवल अप्रतिबद्ध लेनदेन के लिए संभव) के विपरीत, मुआवजा एक नया सकारात्मक लेनदेन है जो व्यावसायिक प्रभाव को उलट देता है जैसे कि पूर्ण शुल्क की भरपाई के लिए रिफंड जारी करना
B
A transaction that compensates database administrators for their overtime work एक लेनदेन जो डेटाबेस प्रशासकों को उनके ओवरटाइम काम के लिए मुआवजा देता है
C
A transaction that adjusts database statistics after bulk operations एक लेन-देन जो थोक संचालन के बाद डेटाबेस आँकड़ों को समायोजित करता है
D
A transaction that compensates for slow query performance एक लेन-देन जो धीमे क्वेरी प्रदर्शन की भरपाई करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Compensation examples: SAGA order processing: Step1=charge card (committed), Step2=reserve inventory (failed). Compensation for Step1=issue_refund (new transaction, not rollback). Compensation must be idempotent (safe to retry). Not always possible: some actions cannot be compensated (sent email). Design: for each saga step T_i, define compensating transaction C_i upfront.
व्याख्या (हिन्दी) मुआवज़े के उदाहरण: SAGA ऑर्डर प्रोसेसिंग: चरण1=चार्ज कार्ड (प्रतिबद्ध), चरण2=आरक्षित इन्वेंट्री (असफल)। चरण1 के लिए मुआवज़ा=issue_refund (नया लेनदेन, रोलबैक नहीं)। मुआवज़ा निष्प्रभावी (पुनः प्रयास करने के लिए सुरक्षित) होना चाहिए। हमेशा संभव नहीं: कुछ कार्यों की भरपाई नहीं की जा सकती (ईमेल भेजा गया)। डिज़ाइन: प्रत्येक गाथा चरण T_i के लिए, क्षतिपूर्ति लेनदेन C_i को पहले से परिभाषित करें।
1839
EN + हिं Easy
GB What is the lost update problem and which isolation level prevents it?
IN खोई हुई अद्यतन समस्या क्या है और कौन सा अलगाव स्तर इसे रोकता है?
A
A transaction that accidentally deletes rows instead of updating them एक लेन-देन जो गलती से पंक्तियों को अद्यतन करने के बजाय हटा देता है
B
A problem that only occurs in distributed databases across multiple nodes एक समस्या जो केवल एकाधिक नोड्स में वितरित डेटाबेस में होती है
C
The lost update problem: T1 reads value X=100, T2 reads value X=100, T1 writes X+=50 (X=150), T2 writes X+=30 (X=130 based on its stale read) - T1 update is lost. Prevented by: REPEATABLE READ (read locks prevent T2 from reading until T1 commits), SERIALIZABLE, or optimistic locking (T2 update fails because X changed since T2 read it) खोई हुई अद्यतन समस्या: T1 मान X=100 पढ़ता है, T2 मान X=100 पढ़ता है, T1 X+=50 (X=150) लिखता है, T2 X+=30 लिखता है (X=130 इसके पुराने पाठ के आधार पर) - T1 अद्यतन खो गया है। द्वारा रोका गया: दोहराए जाने योग्य रीड (रीड लॉक T2 को तब तक पढ़ने से रोकता है जब तक कि T1 प्रतिबद्ध न हो जाए), सीरियलाइज़ेबल, या आशावादी लॉकिंग (T2 अपडेट विफल हो जाता है क्योंकि T2 द्वारा इसे पढ़ने के बाद से X बदल गया है)
D
An issue where a transaction loses its network connection before committing एक समस्या जहां कोई लेन-देन करने से पहले अपना नेटवर्क कनेक्शन खो देता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Lost update solutions: (1) SELECT FOR UPDATE: T1 acquires X-lock on read, T2 blocks until T1 commits. T2 then reads X=150, writes X=180 (correct). (2) Optimistic: UPDATE t SET balance=130 WHERE balance=100 AND id=X -> 0 rows affected (X changed to 150) -> retry. (3) Atomic operations: UPDATE t SET balance=balance+30 WHERE id=X (database handles atomically). Option 3 is best for simple increments.
व्याख्या (हिन्दी) खोए हुए अद्यतन समाधान: (1) अद्यतन के लिए चयन करें: टी1 पढ़ने पर एक्स-लॉक प्राप्त करता है, टी1 के प्रतिबद्ध होने तक टी2 ब्लॉक करता है। T2 फिर X=150 पढ़ता है, X=180 लिखता है (सही)। (2) आशावादी: अद्यतन टी सेट संतुलन = 130 जहां संतुलन = 100 और आईडी = एक्स -> 0 पंक्तियाँ प्रभावित (एक्स को 150 में बदल दिया गया) -> पुनः प्रयास करें। (3) परमाणु संचालन: अद्यतन टी सेट संतुलन = संतुलन + 30 जहां आईडी = एक्स (डेटाबेस परमाणु रूप से संभालता है)। साधारण वेतन वृद्धि के लिए विकल्प 3 सर्वोत्तम है।
1840
EN + हिं Easy
GB What is lock contention and what strategies reduce it in high-throughput OLTP systems?
IN लॉक विवाद क्या है और उच्च-थ्रूपुट ओएलटीपी सिस्टम में कौन सी रणनीतियाँ इसे कम करती हैं?
A
Lock contention occurs when multiple transactions compete for the same locks causing waiting and reducing throughput; strategies to reduce it: shorter transactions, access patterns that minimize lock scope, optimistic locking, MVCC (readers never block writers), partitioning hot data across shards, and batch versus row-level updates लॉक विवाद तब होता है जब कई लेनदेन एक ही लॉक के लिए प्रतिस्पर्धा करते हैं जिससे प्रतीक्षा होती है और थ्रूपुट कम हो जाता है; इसे कम करने की रणनीतियाँ: छोटे लेन-देन, एक्सेस पैटर्न जो लॉक स्कोप को कम करते हैं, आशावादी लॉकिंग, एमवीसीसी (पाठक कभी लेखकों को ब्लॉक नहीं करते हैं), हॉट डेटा को शार्क में विभाजित करना, और बैच बनाम पंक्ति-स्तरीय अपडेट
B
The overhead of managing too many database connections simultaneously एक साथ बहुत सारे डेटाबेस कनेक्शन प्रबंधित करने का ओवरहेड
C
Lock contention is a hardware-level issue unrelated to database design लॉक विवाद एक हार्डवेयर-स्तर का मुद्दा है जो डेटाबेस डिज़ाइन से असंबंधित है
D
Lock contention only occurs in distributed databases not single-server systems लॉक विवाद केवल वितरित डेटाबेस में होता है, एकल-सर्वर सिस्टम में नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hot spot examples: account balance row (many transactions increment it), auto-increment counter (each insert locks the counter), status column with low cardinality (UPDATE status=processing WHERE status=pending - all compete for same rows). Solutions: Redis atomic INCR for counters (move hot counter out of DB), UUID primary keys (distribute inserts), sharding by user_id (distribute account updates), SELECT FOR UPDATE SKIP LOCKED.
व्याख्या (हिन्दी) हॉट स्पॉट उदाहरण: खाता शेष पंक्ति (कई लेन-देन इसे बढ़ाते हैं), ऑटो-वृद्धि काउंटर (प्रत्येक प्रविष्टि काउंटर को लॉक करती है), कम कार्डिनैलिटी के साथ स्थिति कॉलम (अद्यतन स्थिति = प्रसंस्करण जहां स्थिति = लंबित - सभी समान पंक्तियों के लिए प्रतिस्पर्धा करते हैं)। समाधान: काउंटरों के लिए रेडिस एटॉमिक आईएनसीआर (डीबी से हॉट काउंटर को बाहर ले जाएं), यूयूआईडी प्राथमिक कुंजी (इन्सर्ट वितरित करें), यूजर_आईडी द्वारा शार्डिंग (खाता अपडेट वितरित करें), अपडेट स्किप लॉक के लिए चयन करें।
1841
EN + हिं Easy
GB What is SELECT FOR UPDATE SKIP LOCKED and what use case does it enable?
IN सेलेक्ट फॉर अपडेट स्किप लॉक्ड क्या है और यह किस उपयोग के मामले को सक्षम बनाता है?
A
A SELECT that skips rows with NULL values in locked columns एक चयन जो लॉक किए गए कॉलम में NULL मान वाली पंक्तियों को छोड़ देता है
B
A SELECT that skips the locking mechanism entirely for performance एक चयन जो प्रदर्शन के लिए लॉकिंग तंत्र को पूरी तरह से छोड़ देता है
C
An optimization that skips unnecessary locks on large unfiltered result sets एक अनुकूलन जो बड़े अनफ़िल्टर्ड परिणाम सेटों पर अनावश्यक लॉक को हटा देता है
D
An extension to SELECT FOR UPDATE that skips (does not return or wait for) rows that are already locked by other transactions; enables non-blocking queue-like processing where multiple workers can each claim and process different rows without contention - perfect for job queues, task processing systems, and any pattern where multiple workers process items from a shared pool अपडेट के लिए चयन करने के लिए एक एक्सटेंशन जो उन पंक्तियों को छोड़ देता है (वापस नहीं करता है या प्रतीक्षा नहीं करता है) जो पहले से ही अन्य लेनदेन द्वारा लॉक हैं; गैर-अवरुद्ध कतार-जैसी प्रसंस्करण को सक्षम बनाता है जहां कई कर्मचारी दावा कर सकते हैं और बिना किसी विवाद के अलग-अलग पंक्तियों को संसाधित कर सकते हैं - नौकरी कतारों, कार्य प्रसंस्करण प्रणालियों और किसी भी पैटर्न के लिए बिल्कुल सही जहां कई कार्यकर्ता एक साझा पूल से आइटम संसाधित करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Job queue implementation: Worker: BEGIN; SELECT * FROM jobs WHERE status=pending ORDER BY created_at LIMIT 1 FOR UPDATE SKIP LOCKED; UPDATE jobs SET status=processing WHERE id=?; COMMIT; Process job; BEGIN; UPDATE jobs SET status=done WHERE id=?; COMMIT. Multiple workers run this simultaneously: each claims a different row (SKIP LOCKED skips rows other workers have locked). Supported: PostgreSQL 9.5+, MySQL 8.0+.
व्याख्या (हिन्दी) कार्य कतार कार्यान्वयन: कार्यकर्ता: प्रारंभ; * उन नौकरियों से चुनें जहां स्थिति=अद्यतन के लिए LIMIT 1 पर create_at द्वारा लंबित ऑर्डर स्किप लॉक किया गया; नौकरियां अद्यतन करें सेट स्थिति=प्रसंस्करण कहां आईडी=?; प्रतिबद्ध; प्रक्रिया कार्य; शुरू करना; अद्यतन नौकरियाँ सेट स्थिति=किया गया जहाँ आईडी=?; प्रतिबद्ध। एकाधिक कर्मचारी इसे एक साथ चलाते हैं: प्रत्येक एक अलग पंक्ति का दावा करता है (SKIP LOCKED उन पंक्तियों को छोड़ देता है जिन्हें अन्य श्रमिकों ने लॉक किया है)। समर्थित: PostgreSQL 9.5+, MySQL 8.0+।
1842
EN + हिं Medium
GB What is deadlock probability as a function of transaction size and why do longer transactions cause more deadlocks?
IN लेन-देन के आकार के आधार पर गतिरोध की संभावना क्या है और लंबे लेन-देन अधिक गतिरोध का कारण क्यों बनते हैं?
A
Transaction length has absolutely no effect on deadlock probability लेन-देन की लंबाई का गतिरोध की संभावना पर बिल्कुल कोई प्रभाव नहीं पड़ता है
B
Deadlock probability increases approximately as O(n^2) where n is the number of locks held per transaction: each transaction holding n locks has n potential conflicts with each other transaction; as transaction size (locks held) grows the probability of circular wait increases because each lock held is a potential blocker and each lock needed is a potential waiter गतिरोध की संभावना लगभग O(n^2) के रूप में बढ़ जाती है, जहां n प्रति लेन-देन रखे गए तालों की संख्या है: n ताले रखने वाले प्रत्येक लेन-देन में एक दूसरे लेन-देन के साथ n संभावित टकराव होते हैं; जैसे-जैसे लेन-देन का आकार (ताले लगाए गए) बढ़ते हैं, सर्कुलर प्रतीक्षा की संभावना बढ़ जाती है क्योंकि रखा गया प्रत्येक ताला एक संभावित अवरोधक होता है और प्रत्येक आवश्यक ताला एक संभावित वेटर होता है
C
Deadlock probability only depends on the number of concurrent database users गतिरोध की संभावना केवल समवर्ती डेटाबेस उपयोगकर्ताओं की संख्या पर निर्भर करती है
D
Longer transactions are less likely to deadlock because they complete faster लंबे लेनदेन में गतिरोध की संभावना कम होती है क्योंकि वे तेजी से पूरे होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Deadlock probability formula (approximate): P(deadlock) ~ (t^2 * r^2) / (2 * D) where t=transactions/sec, r=rows locked per transaction, D=total distinct lockable rows. Mitigation: reduce r (shorter transactions, fewer rows per transaction), reduce t (rate limiting, batching), increase D (shard data across more rows/tables).
व्याख्या (हिन्दी) गतिरोध संभाव्यता सूत्र (अनुमानित): P(गतिरोध) ~ (t^2 * r^2) / (2 * D) जहां t=लेन-देन/सेकंड, r=प्रति लेन-देन लॉक की गई पंक्तियाँ, D=कुल अलग लॉक करने योग्य पंक्तियाँ। शमन: आर कम करें (छोटे लेनदेन, प्रति लेनदेन कम पंक्तियाँ), टी कम करें (दर सीमित करना, बैचिंग), डी बढ़ाएं (अधिक पंक्तियों/तालिकाओं में शार्प डेटा)।
1843
EN + हिं Easy
GB What is native compilation (NATIVE) vs interpreted mode for PL/SQL and what are the performance trade-offs?
IN पीएल/एसक्यूएल के लिए मूल संकलन (नेटिव) बनाम व्याख्यायित मोड क्या है और प्रदर्शन ट्रेड-ऑफ क्या हैं?
A
NATIVE compilation is only available in Oracle Enterprise Edition not Standard नेटिव संकलन केवल Oracle एंटरप्राइज़ संस्करण में उपलब्ध है, मानक में नहीं
B
NATIVE compilation is always significantly better than interpreted mode नेटिव संकलन हमेशा व्याख्या किए गए मोड से काफी बेहतर होता है
C
INTERPRETED mode produces more secure code than NATIVE mode इंटरप्रेटेड मोड नेटिव मोड की तुलना में अधिक सुरक्षित कोड उत्पन्न करता है
D
PL/SQL NATIVE: compiles PL/SQL code to native machine code via an external C compiler; eliminates interpreter overhead; best for CPU-intensive computations and complex algorithms. INTERPRETED: PL/SQL bytecode executed by the PL/SQL VM; faster compilation, simpler deployment; best for I/O-bound code (most DB code waits on SQL, not PL/SQL computation) पीएल/एसक्यूएल नेटिव: बाहरी सी कंपाइलर के माध्यम से पीएल/एसक्यूएल कोड को मूल मशीन कोड में संकलित करता है; दुभाषिया ओवरहेड को समाप्त करता है; सीपीयू-गहन गणनाओं और जटिल एल्गोरिदम के लिए सर्वोत्तम। व्याख्या: पीएल/एसक्यूएल वीएम द्वारा निष्पादित पीएल/एसक्यूएल बाइटकोड; तेज़ संकलन, सरल परिनियोजन; I/O-बाउंड कोड के लिए सर्वोत्तम (अधिकांश DB कोड SQL पर प्रतीक्षा करता है, PL/SQL गणना पर नहीं)
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) NATIVE mode: ALTER SESSION SET PLSQL_CODE_TYPE=NATIVE; CREATE OR REPLACE PROCEDURE... (compiles to native library). 2-10x faster for CPU-bound PL/SQL. I/O-bound (SQL-heavy) code: minimal benefit since SQL execution time dominates. Configure: PLSQL_NATIVE_LIBRARY_DIR must be set. Check: SELECT plsql_code_type FROM user_plsql_object_settings WHERE name=MY_PROC.
व्याख्या (हिन्दी) मूल मोड: परिवर्तन सत्र सेट PLSQL_CODE_TYPE=मूल; प्रक्रिया बनाएं या बदलें... (मूल पुस्तकालय में संकलित)। सीपीयू-बाउंड पीएल/एसक्यूएल के लिए 2-10 गुना तेज। I/O-बाउंड (SQL-भारी) कोड: SQL निष्पादन समय हावी होने के कारण न्यूनतम लाभ। कॉन्फ़िगर करें: PLSQL_NATIVE_LIBRARY_DIR सेट होना चाहिए. जांचें: user_plsql_object_settings से plsql_code_type चुनें जहां नाम = MY_PROC है।
1844
EN + हिं Easy
GB What is PL/SQL profiling and what tools are available in Oracle for identifying PL/SQL bottlenecks?
IN PL/SQL प्रोफाइलिंग क्या है और PL/SQL बाधाओं की पहचान के लिए Oracle में कौन से उपकरण उपलब्ध हैं?
A
PL/SQL has absolutely no native profiling capabilities built in पीएल/एसक्यूएल में कोई मूल प्रोफ़ाइलिंग क्षमताएं अंतर्निहित नहीं हैं
B
Profiling only works for standalone procedures not package subprograms प्रोफ़ाइलिंग केवल स्टैंडअलोन प्रक्रियाओं के लिए काम करती है, पैकेज उपप्रोग्राम के लिए नहीं
C
Profiling is only available through expensive third-party Oracle tools प्रोफ़ाइलिंग केवल महंगे तृतीय-पक्ष Oracle टूल के माध्यम से उपलब्ध है
D
PL/SQL profiling measures execution time and call counts for each line/procedure in PL/SQL code; Oracle provides DBMS_PROFILER (line-level timing), DBMS_HPROF (hierarchical profiler showing call trees and cumulative times), and PL/SQL Developer/SQL Developer GUI tools that visualize profiling data; essential for identifying slow procedures and optimization targets पीएल/एसक्यूएल प्रोफाइलिंग पीएल/एसक्यूएल कोड में प्रत्येक लाइन/प्रक्रिया के लिए निष्पादन समय और कॉल गणना को मापता है; Oracle DBMS_PROFILER (लाइन-लेवल टाइमिंग), DBMS_HPROF (कॉल ट्री और संचयी समय दिखाने वाला पदानुक्रमित प्रोफाइलर), और PL/SQL डेवलपर/SQL डेवलपर GUI उपकरण प्रदान करता है जो प्रोफाइलिंग डेटा को विज़ुअलाइज़ करते हैं; धीमी प्रक्रियाओं और अनुकूलन लक्ष्यों की पहचान के लिए आवश्यक
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) DBMS_HPROF usage: DBMS_HPROF.START_PROFILING('PROFILER_DIR','profile.trc'); your_procedure(); DBMS_HPROF.STOP_PROFILING; run_id := DBMS_HPROF.ANALYZE(location=>'PROFILER_DIR', filename=>'profile.trc'); SELECT * FROM dbmshp_function_info WHERE runid=run_id ORDER BY function_elapsed_time DESC. Shows: which functions took most time, call counts, sub-function breakdown.
व्याख्या (हिन्दी) DBMS_HPROF उपयोग: DBMS_HPROF.START_PROFILING('PROFILER_DIR','profile.trc'); आपकी_प्रक्रिया(); DBMS_HPROF.STOP_PROFILING; run_id := DBMS_HPROF.ANALYZE(location=>'PROFILER_DIR', फ़ाइल नाम=>'profile.trc'); * dbmshp_function_info से चुनें जहां runid=run_id function_elapsed_time DESC द्वारा ऑर्डर करें। दिखाता है: किस फ़ंक्शन में सबसे अधिक समय लगा, कॉल की संख्या, उप-फ़ंक्शन ब्रेकडाउन।
1845
EN + हिं Easy
GB What is the PL/SQL function result cache (RESULT_CACHE) and what automatic invalidation mechanism does it use?
IN PL/SQL फ़ंक्शन परिणाम कैश (RESULT_CACHE) क्या है और यह किस स्वचालित अमान्यकरण तंत्र का उपयोग करता है?
A
The result cache requires manual invalidation by the DBA when data changes जब डेटा बदलता है तो परिणाम कैश को डीबीए द्वारा मैन्युअल अमान्यकरण की आवश्यकता होती है
B
The result cache only works for functions that have no input parameters परिणाम कैश केवल उन फ़ंक्शंस के लिए काम करता है जिनमें कोई इनपुट पैरामीटर नहीं है
C
The result cache stores results only for the current database session परिणाम कैश केवल वर्तमान डेटाबेस सत्र के लिए परिणाम संग्रहीत करता है
D
The PL/SQL RESULT_CACHE stores function results in the SGA (System Global Area) shared across all sessions; Oracle automatically invalidates cached results when any dependent database table or view is modified (DML commit), ensuring cache consistency without any manual intervention required PL/SQL RESULT_CACHE फ़ंक्शन परिणामों को सभी सत्रों में साझा किए गए SGA (सिस्टम ग्लोबल एरिया) में संग्रहीत करता है; जब किसी भी आश्रित डेटाबेस तालिका या दृश्य को संशोधित (डीएमएल प्रतिबद्ध) किया जाता है, तो ओरेकल स्वचालित रूप से कैश्ड परिणामों को अमान्य कर देता है, बिना किसी मैन्युअल हस्तक्षेप के कैश स्थिरता सुनिश्चित करता है।
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RESULT_CACHE mechanism: CREATE FUNCTION get_config(p_key VARCHAR2) RETURN VARCHAR2 RESULT_CACHE; First call: execute function, store result in SGA result cache keyed by (function_name, parameter_values). Subsequent calls: return cached value (no SQL execution). On COMMIT to config table: Oracle invalidates all cached results for this function. Query: SELECT * FROM V$RESULT_CACHE_OBJECTS to monitor cache usage. Most effective for lookup functions on stable reference data.
व्याख्या (हिन्दी) RESULT_CACHE तंत्र: फ़ंक्शन बनाएं get_config(p_key VARCHAR2) रिटर्न VARCHAR2 RESULT_CACHE; पहली कॉल: फ़ंक्शन निष्पादित करें, परिणाम को SGA परिणाम कैश में संग्रहीत करें (फ़ंक्शन_नाम, पैरामीटर_वैल्यू)। बाद की कॉल: कैश्ड मान लौटाएँ (कोई SQL निष्पादन नहीं)। कॉन्फ़िगरेशन तालिका के लिए प्रतिबद्ध होने पर: Oracle इस फ़ंक्शन के लिए सभी कैश्ड परिणामों को अमान्य कर देता है। क्वेरी: कैशे उपयोग की निगरानी के लिए V$RESULT_CACHE_OBJECTS से चयन करें। स्थिर संदर्भ डेटा पर लुकअप फ़ंक्शन के लिए सबसे प्रभावी।
1831–1845 of 2982