हाल ही में 12.1.0.2 में अपग्रेड करने के बाद, मैं कई प्रदर्शन मुद्दों पर काम कर रहा हूं। ऐसे कई मुद्दे खराब SQL से संबंधित हैं और मैंने जिन कई मुद्दों को हल किया है, वे पुराने 11.2.0.4 रिलीज़ में समस्याएँ थीं। इसका सीधा सा मतलब है कि यह हमेशा एक मुद्दा रहा है। लेकिन लोग अपग्रेड का मौका ले रहे हैं ताकि मैं उन चीजों को ठीक कर सकूं जो काफी समय से टूट चुकी हैं।
प्रदर्शन के मुद्दों को देखते हुए, मुझे दो SQL कथन मिले हैं जो हमारे सिस्टम में सुअर बन रहे हैं। यहाँ दो SQL कथनों का एक स्क्रीनशॉट है जैसा कि Lighty में देखा गया है:
हम देख सकते हैं कि पहला SQL स्टेटमेंट (SQL ID 4b4wp0a8dvkf0) CPU का उपभोग कर रहा है और कंट्रोल फाइल से रीड होने का इंतजार कर रहा है। दूसरा SQL स्टेटमेंट (SQL ID frjd8zfy2jfdq) बहुत सारे CPU का उपयोग कर रहा है और इसमें कई अन्य प्रतीक्षा ईवेंट भी हैं। यहाँ इन कथनों का SQL पाठ है।
एसक्यूएल आईडी:frjd8zfy2jfdq
SELECT
executions
,end_of_fetch_count
,elapsed_time / px_servers elapsed_time
,cpu_time / px_servers cpu_time
,buffer_gets / executions buffer_gets
FROM
(
SELECT
SUM (executions) AS executions
,SUM (
CASE
WHEN px_servers_executions > 0
THEN px_servers_executions
ELSE executions
END
) AS px_servers
,SUM (end_of_fetch_count) AS end_of_fetch_count
,SUM (elapsed_time) AS elapsed_time
,SUM (cpu_time) AS cpu_time
,SUM (buffer_gets) AS buffer_gets
FROM
gv$sql
WHERE
executions > 0
AND sql_id = : 1
AND parsing_schema_name = : 2
एसक्यूएल आईडी:4b4wp0a8dvkf0
SELECT
executions
,end_of_fetch_count
,elapsed_time / px_servers elapsed_time
,cpu_time / px_servers cpu_time
,buffer_gets / executions buffer_gets
FROM
(
SELECT
SUM (executions_delta) AS EXECUTIONS
,SUM (
CASE
WHEN px_servers_execs_delta > 0
THEN px_servers_execs_delta
ELSE executions_delta
END
) AS px_servers
,SUM (end_of_fetch_count_delta) AS end_of_fetch_count
,SUM (elapsed_time_delta) AS ELAPSED_TIME
,SUM (cpu_time_delta) AS CPU_TIME
,SUM (buffer_gets_delta) AS BUFFER_GETS
FROM
DBA_HIST_SQLSTAT s
,V$DATABASE d
,DBA_HIST_SNAPSHOT sn
WHERE
s.dbid = d.dbid
AND bitand (
nvl (
s.flag
,0
)
,1
) = 0
AND sn.end_interval_time > (
SELECT
systimestamp AT TIME ZONE dbtimezone
FROM
dual
) - 7
AND s.sql_id = : 1
AND s.snap_id = sn.snap_id
AND s.instance_number = sn.instance_number
AND s.dbid = sn.dbid
AND parsing_schema_name = : 2
)
)
ये दोनों अब 12c में नई अनुकूली क्वेरी अनुकूलन सुविधाओं का हिस्सा हैं। अधिक विशेष रूप से, ये इस सुविधा के स्वचालित गतिशील सांख्यिकी भाग से संबंधित हैं। SQL आईडी frjd8zfy2jfdq Oracle है जो GV$SQL से SQL कथन प्रदर्शन पर जानकारी प्राप्त कर रहा है। SQL ID 4b4wp0a8dvkf0 Oracle सक्रिय सत्र इतिहास तालिकाओं से SQL कथन प्रदर्शन पर समान जानकारी प्राप्त कर रहा है।
बर्टंड ड्रौवोट ने अपने ब्लॉग पर यहां इस पर चर्चा की:https://bdrouvot.wordpress.com/2014/10/17/watch-out-for-optimizer_adaptive_features-as-it-may-have-a-huge-negative-impact/
इसके अतिरिक्त, मैं ओक टेबल वर्ल्ड 2015 में क्रिश्चियन एंटोग्निनी के एक सत्र में बैठा, जहाँ उन्होंने इन SQL कथनों का उल्लेख किया। OTW से उनकी स्लाइड्स काफी हद तक इन जैसी ही हैं:
http://www.soug.ch/fileadmin/user_upload/SIGs/SIG_150521_Tuning_R/Christian_Antognini_AdaptiveDynamicSampling_trivadis.pdf
ऊपर दिए गए लिंक और नीचे दिए गए एमओएस नोट्स मैं यहां प्रस्तुत जानकारी के आधार पर बहुत कुछ प्रदान करता हूं।
सभी अनुकूली क्वेरी अनुकूलन सुविधाएँ DBA के जीवन को बेहतर बनाने वाली हैं। SQL कथन के क्रियान्वित होने के बाद भी, उन्हें बेहतर निर्णय लेने में ऑप्टिमाइज़र की मदद करनी चाहिए। इस विशिष्ट मामले में, इन प्रश्नों को सीबीओ को बेहतर आँकड़े प्राप्त करने में मदद करने के लिए माना जाता है, भले ही आँकड़े गायब हों। यह SQL प्रदर्शन को बेहतर बनाने में मदद कर सकता है, लेकिन जैसा कि मैंने अपने मामले में पाया, यह समग्र सिस्टम प्रदर्शन में बाधा उत्पन्न कर रहा है।
अनुकूली क्वेरी अनुकूलन के बारे में अधिक जानकारी के लिए, नोट 2031605.1 देखें। यह आपको अन्य नोट्स पर ले जाएगा, लेकिन विशेष रूप से इस चर्चा के लिए, नोट 2002108.1 स्वचालित गतिशील सांख्यिकी।
मामले को बदतर बनाना यह है कि इस व्यवहार को देखने वाली मेरी उत्पादन प्रणाली ओरेकल आरएसी है। जब SQL ID frjd8zfy2jfdq को Oracle RAC सिस्टम पर निष्पादित किया जाता है, तो समानांतर क्वेरी का उपयोग किया जाता है जो enq:PS - कॉन्टेंट और "PX%" प्रतीक्षा ईवेंट द्वारा मेरे स्क्रीन शॉट से स्पष्ट है।
हम डायनामिक सैंपलिंग को इस प्रकार बदल सकते हैं:
सिस्टम सेट में बदलाव करें ऑप्टिमाइज़र_डायनामिक_सैंपलिंग =0 स्कोप =दोनों;
इस पैरामीटर का डिफ़ॉल्ट मान 2 है।
मेरे लिए, ये प्रश्न संसाधनों की खपत कर रहे हैं और समग्र डेटाबेस प्रदर्शन को प्रभावित कर रहे हैं। फिर भी इन सुविधाओं को सुधार . के लिए डिज़ाइन किया गया है प्रदर्शन। हमेशा एक जोखिम होता है कि अगर मैं एक क्षेत्र में प्रदर्शन में मदद करने के लिए सुविधा को बंद कर देता हूं, तो यह दूसरे क्षेत्र में प्रदर्शन को नुकसान पहुंचाएगा। लेकिन मेरे लिए ऑप्टिमाइज़र_डायनामिक_सैंपलिंग<>11 के बाद से, मैं उस सुविधा का पूरी तरह से उपयोग नहीं कर रहा हूं, इसलिए मुझे वह सभी लाभ नहीं मिल रहे हैं जो मैं हो सकता था। साथ ही, हमारा कोड होने वाले डायनेमिक सैंपलिंग पर निर्भर नहीं है। इसलिए इसे बंद करना मेरे लिए सुरक्षित है।
पैरामीटर बदलने के बाद, मैं नीचे दिखाए गए अनुसार तत्काल परिवर्तन देख सकता था।
लाल रेखा उस समय को इंगित करती है जब मैंने परिवर्तन किया था। यह स्पष्ट है कि इस क्वेरी का ASH संस्करण अब क्रियान्वित नहीं हो रहा है। V$SQL संस्करण अभी भी क्रियान्वित हो रहा है लेकिन अब समानांतर क्वेरी प्रतीक्षा ईवेंट नहीं देख रहा है। यह ज्यादातर अभी सीपीयू की खपत कर रहा है। मैं इस प्रगति पर विचार करता हूं, लेकिन पूर्ण संकल्प नहीं।
एक साइड नोट के रूप में, मैं निम्नलिखित के साथ सभी अनुकूली क्वेरी अनुकूलन सुविधाओं को बंद कर सकता था:
alter system set optimizer_adaptive_features=false scope=both;
लेकिन मुझे पता है कि मेरे पास एडेप्टिव जॉइन ऑप्टिमाइज़ेशन का "आनंद ले रहे" प्रश्न हैं और मैं इसे बंद नहीं करना चाहता, बस डायनेमिक सैंपलिंग।
तो अब SQL ID frjd8zfy2jfdq का क्या करें? देखते हैं कि क्या हम शेष मुद्दे को हल कर सकते हैं। मेरे द्वारा ऊपर लिंक किए गए MOS नोट्स में से एक से, मुझे पता है कि हम इस छिपे हुए पैरामीटर को सेट कर सकते हैं:
alter system set "_optimizer_dsdir_usage_control"=0 scope=both;
मेरे 12.1.0.2 सिस्टम में इस छिपे हुए पैरामीटर के लिए डिफ़ॉल्ट मान 126 था। मुझे निम्न के साथ डिफ़ॉल्ट सेटिंग मिली:
select a.ksppinm name, b.ksppstvl value, b.ksppstdf deflt,
from
sys.x$ksppi a,
sys.x$ksppcv b
where a.indx = b.indx
and a.ksppinm like '\_%' escape '\'
and a.ksppinm like '%dsdir%'
order by name;
यह मान महत्वपूर्ण है यदि मैं इसे SPFILE से पैरामीटर निकाले बिना वापस सेट करना चाहता हूं, जिसके लिए डाउनटाइम की आवश्यकता होगी।
अब मैं इस छिपे हुए पैरामीटर को बदलने और इसे शून्य पर सेट करने के साथ आगे बढ़ सकता हूं। यहां बताया गया है कि परिवर्तन के बाद SQL स्टेटमेंट लाइटी में कैसा दिखता है:
उन दो SQL कथनों को क्रियान्वित करने से रोकने में "मिशन पूर्ण" प्रतीत होता है।
Oracle RAC पर 12.1.0.2 चलाने वाले शायद यह सत्यापित करना चाहें कि ये दो SQL कथन स्वयं की प्रदर्शन समस्याएँ उत्पन्न नहीं कर रहे हैं।
ऐसा लगता है कि यह उन मामलों में से एक है जहां एक विशेषता जिसे प्रदर्शन में मदद करने के लिए माना जाता है, वास्तव में इसके विपरीत होता है।
