💛 🕍 🛌🏼 संबंधित चर के साथ समस्या: दुश्मन से दोस्त के लिए अनुकूलक कैसे चालू करें 👰🏽 ✂️ 👊🏾

लेख के लेखक विक्टर वरलामोव ( varlamovVp18 ), OCP हैं।
मूल लेख 07/07/2017 को प्रकाशित हुआ था ।
अनुवाद के लेखक के लिए विशेष धन्यवाद - क्रूरताग ।

हमारी रिपोर्टिंग प्रणाली आमतौर पर विभिन्न घटनाओं द्वारा ट्रिगर किए गए सैकड़ों लंबे अनुरोधों को निष्पादित करती है। क्वेरी पैरामीटर ग्राहकों की एक सूची और एक समय अंतराल (दैनिक, साप्ताहिक, मासिक) है। तालिकाओं में असमान डेटा के कारण, एक क्वेरी रिपोर्ट मापदंडों के आधार पर या तो एक पंक्ति या मिलियन पंक्तियों का उत्पादन कर सकती है (अलग-अलग क्लाइंट्स की पंक्तियों की संख्या अलग-अलग होती है)। प्रत्येक रिपोर्ट एक मुख्य फ़ंक्शन के साथ पैकेज के रूप में बनाई गई है जो इनपुट मापदंडों को लेती है, अतिरिक्त परिवर्तन करती है, फिर संबंधित चर के साथ एक स्थिर कर्सर खोलता है और अंत में इस खुले कर्सर को वापस करता है। DB पैरामीटर CURSOR_SHARING FORCE पर सेट है।
ऐसी स्थिति में, किसी को खराब प्रदर्शन से निपटना पड़ता है, दोनों को ऑप्टिमाइज़र द्वारा क्वेरी योजना के पुन: उपयोग के मामले में, और जब क्वेरी को शाब्दिक के रूप में मापदंडों के साथ पूरी तरह से पार्स किया जाता है । बाउंड वैरिएबल्स एक सबऑप्टिमल क्वेरी प्लान का कारण बन सकते हैं।

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

“एंड-यूज़र टिप्पणियों के अनुसार, जब सोमवार को भारी बारिश हुई, डेटाबेस प्रदर्शन बहुत भयानक था। सप्ताह के किसी भी दिन या सोमवार को बारिश के बिना कोई समस्या नहीं थी। डीबीए के साथ एक बातचीत से, टॉम काइट ने सीखा कि जब तक डेटाबेस को फिर से शुरू करने के लिए मजबूर नहीं किया गया, तब तक कठिनाइयां बनी रहीं, जिसके बाद प्रदर्शन सामान्य हो गया। वह इस तरह का एक काम था: सोमवार की बारिश - पुनः आरंभ करें। "

यह एक वास्तविक मामला है, और समस्या को पूरी तरह से बिना किसी जादू के हल किया गया था, केवल ओरेकल कैसे काम करता है के उत्कृष्ट ज्ञान के लिए धन्यवाद। मैं लेख के अंत में समाधान दिखाऊंगा।
संबंधित चर कैसे काम करते हैं, इसका एक छोटा सा उदाहरण यहां दिया गया है।
असमान डेटा के साथ एक तालिका बनाएं।

SQL> CREATE TABLE VVP_HARD_PARSE_TEST(C1 NUMBER, C2 NUMBER, C3 VARCHAR2(300)); TABLE created. SQL> INSERT INTO VVP_HARD_PARSE_TEST SELECT ROWNUM C1, CASE WHEN LEVEL < 9 THEN 1 WHEN MOD(ROWNUM, 100)=99 THEN 99 ELSE 1000000 END C2, RPAD('A', 300, 'A') C3 FROM DUAL CONNECT BY LEVEL CREATE INDEX IND_VVP_HARD_PARSE_TEST_C2 ON VVP_HARD_PARSE_TEST(C2); INDEX created. SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => USER, TABNAME => 'VVP_HARD_PARSE_TEST', CASCADE => TRUE, METHOD_OPT=>'FOR ALL INDEXED COLUMNS SIZE 254'); PL/SQL PROCEDURE successfully completed. SQL> SELECT histogram FROM user_tab_columns WHERE table_name = 'VVP_HARD_PARSE_TEST' AND column_name = 'C2'; HISTOGRAM --------- FREQUENCY SQL> SELECT c2, COUNT(*) FROM VVP_HARD_PARSE_TEST GROUP BY c2 ORDER BY 1; C2 COUNT(*) ----------------------- 1 8 99 10000 1000000 989992

दूसरे शब्दों में, हमारे पास एक लाख पंक्तियों के साथ एक VVP_HARD_PARSE_TEST तालिका है, जहां 10,000 मामलों में फ़ील्ड C2 = 99 है, C2 = 1 के साथ 8 रिकॉर्ड हैं, और C2 = 1,000,000 के साथ शेष है। फ़ील्ड C2 के बीच का होलोग्राम इस डेटा वितरण के बारे में Oracle अनुकूलक का संकेत देता है। इस स्थिति को डेटा के असमान वितरण के रूप में जाना जाता है, और एक हिस्टोग्राम आपको अनुरोधित डेटा के आधार पर सही क्वेरी योजना चुनने में मदद कर सकता है।

हम इस तालिका में सरल प्रश्नों का निरीक्षण करते हैं। जाहिर है निवेदन के लिए

SELECT * FROM VVP_HARD_PARSE_TEST WHERE c2 = :p

यदि p = 1 है, तो INDEX RANGE SCAN सबसे अच्छा विकल्प है, केस p = 1000000 के लिए FULL TABLE SCAN का उपयोग करना बेहतर है। Query1 और Query1000000 प्रश्न समान हैं, टिप्पणियों में पाठ के अपवाद के साथ, यह अलग क्वेरी योजना पहचानकर्ताओं को प्राप्त करने के लिए किया जाता है।

 DECLARE p NUMBER; v NUMBER; BEGIN V := 0; p := 1000000; FOR rec IN (SELECT /*+query1000000*/ * FROM VVP_HARD_PARSE_TEST WHERE c2 = p) LOOP V := v + 1; END LOOP; dbms_output.put_line(v); v : =0; p := 1; FOR rec IN (SELECT /*+query1000000*/ * FROM VVP_HARD_PARSE_TEST WHERE c2 = p) LOOP V := v + 1; END LOOP; dbms_output.put_line(v); ----------------- V := 0; p := 1; FOR rec IN (SELECT /*+query1*/ * FROM VVP_HARD_PARSE_TEST WHERE c2 = p) LOOP V := v + 1; END LOOP; dbms_output.put_line(v); v := 0; p := 1000000; FOR rec IN (SELECT /*+query1*/ * FROM VVP_HARD_PARSE_TEST WHERE c2 = p) LOOP V := v + 1; END LOOP; dbms_output.put_line(v); END;

आइए अब क्वेरी योजनाओं को देखें:

 SQL> SELECT sql_id, child_number, executions, plan_hash_value, sql_text FROM v$sql WHERE sql_text LIKE 'SELECT % * FROM VVP_HARD_PARSE_TEST WHERE C2%'; SQL_ID CHILD_NUMBER EXECUTIONS PLAN_HASH_VALUE SQL_TEXT ------------------------------------------------- 7rqnhhp6pahw2 0 2 2782757451 SELECT /*+query1000000*/ * FROM VVP_HARD_PARSE_TEST WHERE C2 = :B1 7xwt28hvw3u9s 0 2 2463783749 SELECT /*+query1*/ * FROM VVP_HARD_PARSE_TEST WHERE C2 = :B1 SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor(sql_id => '7rqnhhp6pahw2', format => 'basic +peeked_binds')); SELECT /*+query1000000*/ * FROM VVP_HARD_PARSE_TEST WHERE C2 = :B1 PLAN hash VALUE: 2782757451 ------------------------------------------------- | Id | Operation | Name | ------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS FULL| VVP_HARD_PARSE_TEST | ------------------------------------------------- Peeked Binds (IDENTIFIED BY position): -------------------------------------- 1 - :B1 (NUMBER): 1000000 SQl> SELECT * FROM TABLE(dbms_xplan.display_cursor(sql_id => '7xwt28hvw3u9s', format => 'basic +peeked_binds')); SELECT /*+query1*/ * FROM VVP_HARD_PARSE_TEST WHERE C2 = :B1 PLAN hash VALUE: 2463783749 ------------------------------------------------------------------ | Id | Operation | Name | ------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS BY INDEX ROWID| VVP_HARD_PARSE_TEST | | 2 | INDEX RANGE SCAN | IND_VVP_HARD_PARSE_TEST_C2 | ------------------------------------------------------------------ Peeked Binds (IDENTIFIED BY position): -------------------------------------- 1 - :B1 (NUMBER): 1

जैसा कि आप देख सकते हैं, पहले निष्पादन के समय केवल एक बार विभिन्न अनुरोधों की योजना बनाई गई है (प्रत्येक अनुरोध के लिए CHILD_NUMBER = 0 के साथ केवल एक चाइल्ड कर्सर मौजूद है)। प्रत्येक अनुरोध को दो बार निष्पादित किया जाता है (EXECUTION = 2)। हार्ड पार्सिंग के दौरान, ओरेकल संबंधित चर के मूल्यों को पुनः प्राप्त करता है और इन मूल्यों के अनुसार एक योजना का चयन करता है। लेकिन वह अगले रन के लिए उसी योजना का उपयोग करता है, भले ही संबंधित चर दूसरे रन में बदल गए हों। गैर-इष्टतम योजनाओं का उपयोग किया जाता है - चर C2 = 1 के साथ Query1000000, INDEX RANGE SCAN के बजाय FULL TABLE SCAN का उपयोग करता है, और इसके विपरीत।

यह स्पष्ट है कि आवेदन को ठीक करना और पैरामीटर को क्वेरी में शाब्दिक रूप से उपयोग करना समस्या को हल करने के लिए सबसे उपयुक्त तरीका है, लेकिन यह अपनी ज्ञात कमियों के साथ गतिशील एसक्यूएल की ओर जाता है। एक अन्य तरीका संबंधित चर के लिए क्वेरी को निष्क्रिय करना है ( ALTER SESSION SET "_OPTIM_PEEK_USER_BINDS" = FALSE ) या हिस्टोग्राम ( लिंक ) को हटाएं।

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

देखते हैं अब हम क्या करेंगे। अपने डेटा का विश्लेषण करने के बाद, हम ग्राहकों को तीन श्रेणियों में विभाजित करने का निर्णय लेते हैं - लार्ज, मीडियम एंड स्मॉल (एलएमएस या 9-5-1) - वर्ष के दौरान लेनदेन या लेनदेन की संख्या के अनुसार। इसके अलावा, रिपोर्ट में लाइनों की संख्या सख्ती से अवधि पर निर्भर करती है: मासिक - बड़े, साप्ताहिक - मध्य, दैनिक - छोटे या 9-5-1। इसके अलावा, समाधान सरल है - हम सुरक्षा नीति को प्रत्येक श्रेणी और प्रत्येक अवधि पर निर्भर करते हैं। इसलिए, प्रत्येक अनुरोध के लिए हमें 9 संभव बाल श्राप मिलते हैं। इसके अलावा, विभिन्न नीतियों के साथ क्वेरी हमें एक ही क्वेरी आइडेंटिफ़ायर तक ले जाएगी, इससे SQL PLAN MANAGEMENT (sql plan baseline) को लागू करना संभव हो जाता है।

 SQL> CREATE TABLE HARD_PARSE_TABLE AS SELECT * FROM dual; TABLE created. SQL> CREATE TABLE CLIENTS_HP_STATISTICS (client_seqno NUMBER, client_id VARCHAR2(255), cnt_year NUMBER); TABLE created. SQL> INSERT INTO CLIENTS_HP_STATISTICS (client_seqno, client_id, cnt_year) VALUES (1, 'SMALL CLIENT', 8); 1 ROW inserted. SQL> INSERT INTO CLIENTS_HP_STATISTICS (client_seqno, client_id, cnt_year) VALUES (99, 'MIDDLE CLIENT', 50001); 1 ROW inserted. SQL> INSERT INTO CLIENTS_HP_STATISTICS (client_seqno, client_id, cnt_year) VALUES (1000000,'LARGE CLIENT', 989992); 1 ROW inserted. SQL> CREATE OR REPLACE PACKAGE FORCE_HARD_PARSE_PKG IS gc_small CONSTANT NUMBER := 1; gc_middle CONSTANT NUMBER := 5; gc_large CONSTANT NUMBER := 9; gc_client_middle CONSTANT NUMBER := 50000; gc_client_large CONSTANT NUMBER := 500000; gc_daterange_middle CONSTANT NUMBER := 10; gc_daterange_large CONSTANT NUMBER := 50; FUNCTION FORCE_HARD_PARSE(in_schema VARCHAR2, in_object VARCHAR2) RETURN VARCHAR2; PROCEDURE SET_PREDICATE (n NUMBER); PROCEDURE SET_PREDICATES (p_daterange NUMBER DEFAULT NULL, p_clientrange NUMBER DEFAULT NULL); PROCEDURE CALC_PREDICATE; PROCEDURE CALC_PREDICATES(p_date_interval NUMBER DEFAULT 1, p_client_seqno NUMBER DEFAULT NULL, p_client_id VARCHAR2 DEFAULT NULL, p_client_seqno_list VARCHAR2 DEFAULT NULL ); END FORCE_HARD_PARSE_PKG; PACKAGE created. SQL> CREATE OR REPLACE PACKAGE BODY FORCE_HARD_PARSE_PKG IS g_predicate NUMBER; -- g_daterange || 0 || g_clientrange g_daterange NUMBER; -- 1 - small, 5 - middle, 9 - large g_clientrange NUMBER; -- 1 - small, 5 - middle, 9 - large -- FUNCTION FORCE_HARD_PARSE(in_schema VARCHAR2, in_object VARCHAR2) RETURN VARCHAR2 IS BEGIN IF NVL(g_predicate, 0) = 0 THEN RETURN NULL; ELSE RETURN TO_CHAR(g_predicate, 'TM') || ' = ' || TO_CHAR(g_predicate, 'TM'); END IF; END FORCE_HARD_PARSE; -- PROCEDURE SET_PREDICATE (n NUMBER) IS BEGIN g_predicate := n; END; PROCEDURE SET_PREDICATES (p_daterange NUMBER DEFAULT NULL, p_clientrange NUMBER DEFAULT NULL) IS BEGIN IF p_daterange IS NOT NULL THEN g_daterange := p_daterange; CALC_PREDICATE; END IF; IF p_clientrange IS NOT NULL THEN g_clientrange := p_clientrange; CALC_PREDICATE; END IF; END SET_PREDICATES; PROCEDURE CALC_PREDICATE IS BEGIN g_predicate := NVL(g_daterange, 0) * 100 + NVL(g_clientrange, 0); END CALC_PREDICATE; PROCEDURE CALC_PREDICATES (p_date_interval NUMBER DEFAULT 1, p_client_seqno NUMBER DEFAULT NULL, p_client_id VARCHAR2 DEFAULT NULL, p_client_seqno_list VARCHAR2 DEFAULT NULL) IS v_cnt NUMBER; BEGIN IF p_date_interval IS NOT NULL THEN g_daterange := CASE WHEN p_date_interval < gc_daterange_middle THEN gc_small WHEN p_date_interval < gc_daterange_large THEN gc_middle ELSE gc_large END; CALC_PREDICATE; END IF; IF COALESCE(p_client_seqno, p_client_id, p_client_seqno_list) IS NOT NULL THEN SELECT NVL(SUM(cnt_year), 0) AS cnt INTO v_cnt FROM CLIENTS_HP_STATISTICS t WHERE 1=1 AND (p_client_seqno IS NULL OR p_client_seqno = t.client_seqno) AND (p_client_id IS NULL OR p_client_id = t.client_id) AND (p_client_seqno_list IS NULL OR t.client_seqno IN (SELECT SUBSTR(s, CASE WHEN LEVEL > 1 THEN INSTR(s, ',', 1, LEVEL - 1 ) + 1 ELSE 1 END, INSTR(s, ',', 1, LEVEL) – CASE WHEN LEVEL > 1 THEN INSTR(s, ',', 1, LEVEL – 1) + 1 ELSE 1 END) FROM (SELECT p_client_seqno_list||',' AS s FROM DUAL) CONNECT BY INSTR(s, ',', 1, LEVEL) > 0)); g_clientrange := CASE WHEN v_cnt > gc_client_large THEN gc_large WHEN v_cnt > gc_client_middle THEN gc_middle ELSE gc_small END; CALC_PREDICATE; END IF; END CALC_PREDICATES; END FORCE_HARD_PARSE_PKG; PACKAGE BODY created. SQL> EXEC DBMS_RLS.ADD_POLICY (USER, 'HARD_PARSE_TABLE', 'HARD_PARSE_POLICY', USER, 'FORCE_HARD_PARSE_PKG.FORCE_HARD_PARSE', 'select'); PL/SQL PROCEDURE successfully completed.

अब, यदि हम रिपोर्ट में ऐसी तकनीक को एम्बेड करना चाहते हैं, तो हमें HARD_PARSE_TABLE को क्वेरी में जोड़ना होगा (यह इसे थोड़ा बर्बाद नहीं करेगा) और मुख्य क्वेरी निष्पादित होने से पहले CALC_PREDICATES पर कॉल करें।

आइए देखें कि यह तकनीक पिछले उदाहरण को कैसे बदल सकती है:

 DECLARE p NUMBER; v NUMBER; BEGIN V := 0; p := 1000000; FORCE_HARD_PARSE_PKG.SET_PREDICATE(1000000); FOR rec IN (SELECT /*+query_hp1000000*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE c2 = p) LOOP V := v + 1; END LOOP; dbms_output.put_line(v); v := 0; p := 1; FORCE_HARD_PARSE_PKG.SET_PREDICATE(1); FOR rec IN (SELECT /*+query_hp1000000*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE c2 = p) LOOP V := v + 1; END LOOP; dbms_output.put_line(v); ----------------- V := 0; p := 1; FORCE_HARD_PARSE_PKG.SET_PREDICATE(1); FOR rec IN (SELECT /*+query_hp1*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE c2 = p) LOOP V := v + 1; END LOOP; dbms_output.put_line(v); v := 0; p := 1000000; FORCE_HARD_PARSE_PKG.SET_PREDICATE(1000000); FOR rec IN (SELECT /*+query_hp1*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE c2 = p) LOOP V := v + 1; END LOOP; dbms_output.put_line(v); END;

आइए क्रियान्वयन योजनाओं को देखें:

 SQL> SELECT sql_id, child_number, executions, plan_hash_value, sql_text, s.* FROM v$sql s WHERE sql_text LIKE 'SELECT % * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE c2%' ORDER BY 1,2; SQL_ID CHILD_NUMBER EXECUTIONS PLAN_HASH_VALUE SQL_TEXT -------------------------------------------------------------------------------- 7wva3uqbgh4qf 0 1 1136240498 SELECT /*+query_hp1000000*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE C2 = :B1 7wva3uqbgh4qf 1 1 3246475190 SELECT /*+query_hp1000000*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE C2 = :B1 8cju3tfjvwm1p 0 1 3246475190 SELECT /*+query_hp1*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE C2 = :B1 8cju3tfjvwm1p 1 1 1136240498 SELECT /*+query_hp1*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE C2 = :B1 -- SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor(sql_id => '7wva3uqbgh4qf', cursor_child_no => 0, format => 'basic +peeked_binds')); SELECT /*+query_hp1000000*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE C2 = :B1 PLAN hash VALUE: 1136240498 ---------------------------------------------------- | Id | Operation | Name | ---------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | MERGE JOIN CARTESIAN| | | 2 | TABLE ACCESS FULL | HARD_PARSE_TABLE | | 3 | BUFFER SORT | | | 4 | TABLE ACCESS FULL | VVP_HARD_PARSE_TEST | ---------------------------------------------------- Peeked Binds (IDENTIFIED BY position): -------------------------------------- 1 - :B1 (NUMBER): 1000000 -- SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor(sql_id => '7wva3uqbgh4qf', cursor_child_no => 1, format => 'basic +peeked_binds')); SELECT /*+query_hp1000000*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE C2 = :B1 PLAN hash VALUE: 3246475190 -------------------------------------------------------------------- | Id | Operation | Name | -------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | MERGE JOIN CARTESIAN | | | 2 | TABLE ACCESS FULL | HARD_PARSE_TABLE | | 3 | BUFFER SORT | | | 4 | TABLE ACCESS BY INDEX ROWID| VVP_HARD_PARSE_TEST | | 5 | INDEX RANGE SCAN | IND_VVP_HARD_PARSE_TEST_C2 | -------------------------------------------------------------------- Peeked Binds (IDENTIFIED BY position): -------------------------------------- 1 - :B1 (NUMBER): 1 -- SQl> SELECT * FROM TABLE(dbms_xplan.display_cursor(sql_id => '8cju3tfjvwm1p', cursor_child_no => 0, format => 'basic +peeked_binds')); SELECT /*+query_hp1*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE C2 = :B1 PLAN hash VALUE: 3246475190 -------------------------------------------------------------------- | Id | Operation | Name | -------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | MERGE JOIN CARTESIAN | | | 2 | TABLE ACCESS FULL | HARD_PARSE_TABLE | | 3 | BUFFER SORT | | | 4 | TABLE ACCESS BY INDEX ROWID| VVP_HARD_PARSE_TEST | | 5 | INDEX RANGE SCAN | IND_VVP_HARD_PARSE_TEST_C2 | -------------------------------------------------------------------- Peeked Binds (IDENTIFIED BY position): -------------------------------------- 1 - :B1 (NUMBER): 1 -- SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor(sql_id => '8cju3tfjvwm1p', cursor_child_no => 1, format => 'basic +peeked_binds')); SELECT /*+query_hp1*/ * FROM VVP_HARD_PARSE_TEST, HARD_PARSE_TABLE WHERE C2 = :B1 PLAN hash VALUE: 1136240498 ---------------------------------------------------- | Id | Operation | Name | ---------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | MERGE JOIN CARTESIAN| | | 2 | TABLE ACCESS FULL | HARD_PARSE_TABLE | | 3 | BUFFER SORT | | | 4 | TABLE ACCESS FULL | VVP_HARD_PARSE_TEST | ---------------------------------------------------- Peeked Binds (IDENTIFIED BY position): -------------------------------------- 1 - :B1 (NUMBER): 1000000

बहुत अच्छा लग रहा है! प्रत्येक क्वेरी को दो बार निष्पादित किया जाता है, अलग-अलग बाल कर्सर और विभिन्न योजनाओं के साथ। पैरामीटर C2 = 1,000,000 के लिए, हम दोनों प्रश्नों में पूर्ण टेबल स्कैन देखते हैं, और पैरामीटर C1 = 1 के लिए हम हमेशा INDEX RANGE SCAN देखते हैं।

अंत में मैं बारिश के मामले का समाधान देता हूं।

“यह पता चला है कि रविवार को हर सप्ताहांत एक ठंडा बैकअप था , ताकि सोमवार सुबह पहले निष्पादन पर सभी क्वेरी योजनाओं को फिर से बनाया गया। कर्मचारियों में से एक ने आमतौर पर दूसरों की तुलना में अपना काम शुरू किया था, और सप्ताह के दौरान अन्य उपयोगकर्ताओं के लिए उनकी अनुरोध योजना को अच्छी तरह से निष्पादित किया गया था। हालांकि, अगर बारिश हो रही थी, तो इस उपयोगकर्ता को अपने सुबह के मार्ग के साथ समस्याओं के कारण कार्य दिवस की शुरुआत तक देर हो गई थी। तब रिपोर्टों की बैच गणना पहली बार शुरू हुई थी, लेकिन संबंधित चर के अनुचित मूल्यों के कारण शेष मामलों के लिए क्वेरी योजना पूरी तरह से खराब थी। "

और कुछ उपयोगी सिस्टम दृश्य:
• dba_tab_histograms, all_tab_histograms, user_tab_histograms
• v$vpd_policy
• v$sql_bind_capture
• dba_hist_sqlbind

संबंधित चर के साथ समस्या: दुश्मन से दोस्त के लिए अनुकूलक कैसे चालू करें

More articles: