ओरेकल आईटीएल डेडलॉक की पहचान और संकल्प

Question

मेरे पास ओरेकल डीबी पैकेज है जो नियमित रूप से मुझे लगता है कि आईटीएल (इच्छुक लेनदेन सूची) डेडलॉक है। एक ट्रेस फ़ाइल का प्रासंगिक भाग नीचे है।

Deadlock graph: 
         ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-0000cb52-00000000  22  131   S  23  143   SS 
TM-0000ceec-00000000  23  143 SX    32  138 SX SSX 
TM-0000cb52-00000000  30  138 SX    22  131   S 
session 131: DID 0001-0016-00000D1C session 143: DID 0001-0017-000055D5 
session 143: DID 0001-0017-000055D5 session 138: DID 0001-001E-000067A0 
session 138: DID 0001-001E-000067A0 session 131: DID 0001-0016-00000D1C 
Rows waited on: 
Session 143: no row 
Session 138: no row 
Session 131: no row 

इस तालिका पर कोई बिट-मैप इंडेक्स नहीं है, इसलिए इसका कारण नहीं है। जहां तक ​​मैं कह सकता हूं, "पंक्तियों का इंतजार" की कमी और वेटर में "एस" की कमी कॉलम की प्रतीक्षा करता है, यह इंगित करता है कि यह एक आईटीएल डेडलॉक है। साथ ही, तालिका को अक्सर बार-बार लिखा जाता है (लगभग 8 बार या बार-बार 240 बार एक मिनट), इसलिए आईटीएल डेडलॉक एक मजबूत संभावना की तरह दिखता है।

मैंने तालिका के INITRANS पैरामीटर में वृद्धि की है और यह 100 से सूचकांक है और तालिका में पीसी से 10 से 20 (फिर इंडेक्स को पुनर्निर्मित) में बढ़ा दिया है, लेकिन डेडलॉक्स अभी भी हो रहे हैं। डेडलॉक अक्सर एक अपडेट के दौरान होता है, लेकिन यह सिर्फ एक संयोग हो सकता है, क्योंकि मैंने इसे केवल दो बार देखा है।

मेरे प्रश्न दो गुना हैं:
1) क्या यह वास्तव में एक आईटीएल डेडलॉक है?
2) यदि यह एक आईटीएल डेडलॉक है, तो इससे बचने के लिए और क्या किया जा सकता है?

---

यह पता चला है कि यह आईटीएल डेडलॉक मुद्दा बिल्कुल नहीं था, बल्कि अनगिनत विदेशी कुंजी के साथ एक मुद्दा था। मैंने डीपीब्रैडली के जवाब के लिए धन्यवाद दिया, जिसने मुझे इस तथ्य में चिपकाया कि यह एक आईटीएल मुद्दा नहीं था और मुझे यह पता लगाने के लिए प्रेरित किया कि "कोई पंक्ति नहीं" के साथ डेडलॉक के अन्य कारण क्या हो सकते हैं।

Answer 1

आईटीएल दबाव का सबसे अच्छा संकेत प्रदर्शन विचारों की वजह से है:

select event, total_waits, time_waited, average_wait 
from v$system_event 
where event like 'enq: TX%' 
order by 2 desc; 

से पता चलता TX विवाद प्रतीक्षा करता है, और

select OBJECT_NAME, SUBOBJECT_NAME, TABLESPACE_NAME, 
     OBJECT_TYPE, STATISTIC_NAME, VALUE 
    from v$segment_statistics 
    where statistic_name = 'ITL waits' 
    and value > 0 
    order by value desc; 

टेबल्स और सूचियों को शामिल पता चलता है।

(सभी v$ विचारों की तरह, परिणाम समय था जब उदाहरण शुरू किया गया था में बिंदु से कर रहे हैं।)

यह दिखाता है कि आप वास्तव में आईटीएल इंतजार कर रहा है की क्या ज़रूरत है कि, तो INITRANS और PCTFREE मापदंडों मुख्य घुंडी कर रहे हैं बारी करने के लिए (लेकिन INITRANS = 100 मेरे लिए बहुत अधिक लगता है और ये लागत स्थान)।

यदि आईटीएल कोई समस्या नहीं है, तो आवेदन कोड की जांच की जानी चाहिए।

Answer 2

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

SELECT t.OWNER, t.OBJECT_NAME, t.OBJECT_TYPE, t.STATISTIC_NAME, t.VALUE 
    FROM v$segment_statistics t 
    WHERE t.STATISTIC_NAME = 'ITL waits' AND t.VALUE > 0 
    ORDER BY t.value desc; 

हम आईटीएल के कारण ओरेकल गतिरोध परिदृश्यों के लिए कई समस्वरीकरण किए हैं इस पद्धति का उपयोग इंतजार करता है। नोट: सुनिश्चित करें कि इंडेक्स को पुनर्निर्मित किया गया है, अगर इन्ट्रिटन्स इंडेक्स के लिए संशोधित किया गया है। यह भी सुनिश्चित करें कि आंकड़े बेकार नहीं हैं।

त्वरित जांच के लिए SQL ट्यूनिंग सलाहकार का उपयोग क्वेरी/अनुक्रमणिका और आंकड़ों की पूरी स्थिति देखने के लिए किया जा सकता है।