अलग पैरामीटर आकार अक्षम क्वेरी योजना कैश में परिणाम

Question

Nhibernate प्रोफाइलर क्वेरी योजना के बारे में त्रुटि संदेशों में से बहुत से पता चलता है:

अलग पैरामीटर आकार अक्षम क्वेरी योजना कैश उपयोग होता

यह भी एक में ले जाता है http://nhprof.com/Learn/Alerts/UncachedQueryPlan में स्पष्टीकरण और सत्र निर्माण करते समय prepare_sql = true पैरामीटर के उपयोग के बारे में आपको चेतावनी देता है। मैं इसे धाराप्रवाह के साथ इस तरह से करता हूं:

.ExposeConfiguration(configuration => configuration 
    .SetProperty("current_session_context_class", "thread_static") 
    .SetProperty("prepare_sql", "true") 
    .SetProperty("generate_statistics", "true") 
    ) 

लेकिन ऐसा लगता है कि यह काम नहीं कर रहा है क्योंकि त्रुटि संदेश अभी भी हैं। क्या यह ओरेकल क्लाइंट कॉन्फ़िगरेशन पर एक सीमा है या क्या मैं इसे गलत कर रहा हूं?

संपादित इस बारे में कुछ और जानकारी प्रदान करने के लिए ...

मेरी भंडार में मैं इस

session.Query<TEntity>.Where(predicate).ToList(); 

करते हैं और इस कॉल

var value = ParameterRepository.First(p => (p.Pipeline.Id == pipelineId && p.Name == name)); 

उदाहरण उन लोगों के लिए है इस कॉल से उत्पन्न दो एसक्यूएल हैं और निबर्ननेट प्रोफाइलर के रूप में दिखाता है "अलग पैरामीटर आकार परिणामस्वरूप अक्षम क्वेरी प्लान कैश उम्र "

select GUID1_12_, 
     PARAMETER2_12_, 
     PARAMETER3_12_, 
     GUID4_12_ 
from (select pipelineex0_.GUID_PIPELINE_EXEC_PARAMETER as GUID1_12_, 
       pipelineex0_.PARAMETER_NAME    as PARAMETER2_12_, 
       pipelineex0_.PARAMETER_VALUE    as PARAMETER3_12_, 
       pipelineex0_.GUID_PIPELINE_TRACKING  as GUID4_12_ 
     from FCT_PIPELINE_EXEC_PARAMETER pipelineex0_ 
     where pipelineex0_.GUID_PIPELINE_TRACKING = 'A5916E73CF1E406DA26F65C24BFBF694' /* :p0 */ 
       and pipelineex0_.PARAMETER_NAME = 'lid' /* :p1 */) 
where rownum <= 1 /* :p2 */ 

और दूसरा

select GUID1_12_, 
     PARAMETER2_12_, 
     PARAMETER3_12_, 
     GUID4_12_ 
from (select pipelineex0_.GUID_PIPELINE_EXEC_PARAMETER as GUID1_12_, 
       pipelineex0_.PARAMETER_NAME    as PARAMETER2_12_, 
       pipelineex0_.PARAMETER_VALUE    as PARAMETER3_12_, 
       pipelineex0_.GUID_PIPELINE_TRACKING  as GUID4_12_ 
     from FCT_PIPELINE_EXEC_PARAMETER pipelineex0_ 
     where pipelineex0_.GUID_PIPELINE_TRACKING = 'A5916E73CF1E406DA26F65C24BFBF694' /* :p0 */ 
       and pipelineex0_.PARAMETER_NAME = 'period' /* :p1 */) 
where rownum <= 1 /* :p2 */ 

IMHO 'ढक्कन' और 'अवधि' है कि विभिन्न क्वेरी योजनाओं पैदा कर रहा है के साथ इस PARAMETER_NAME है। अग्रिम

Answer 1

में

धन्यवाद एक ही योजना हर बार पैरामीटर पैरामीटर मान की परवाह किए बिना एक ही लंबाई के लिए निर्धारित करने की आवश्यकता उत्पन्न करने के लिए।

आप क्वेरी पैरामीटर लंबाई को अपने मैपिंग में निर्दिष्ट फ़ील्ड लम्बाई पर सेट करने के लिए ड्राइवर कार्यान्वयन को कस्टमाइज़ कर सकते हैं।

public class CustomOracleClientDriver : OracleClientDriver 
{ 
    protected override void InitializeParameter(IDbDataParameter dbParam, string name, SqlType sqlType) 
    { 
     base.InitializeParameter(dbParam, name, sqlType); 

     if (sqlType.LengthDefined) 
      dbParam.Size = sqlType.Length; 
    } 
} 

(नोट: OracleDataClientDriver से उत्तराधिकार अगर आप ODP.Net उपयोग कर रहे हैं)

आप उपयोग कर रहे हैं धाराप्रवाह NHibernate आप इस तरह अपने ड्राइवर कार्यान्वयन रजिस्टर:

Fluently.Configure() 
       .Database(
        OracleDataClientConfiguration.Oracle10 
         .ConnectionString(c => c.FromAppSetting("ConnectionString")) 
         .Driver<CustomOracleClientDriver>()) 

Answer 2

मैं के साथ इस परीक्षण किया एक ओवरराइड ओरेकल क्लाइंट ड्रायवर (पुराने माइक्रोसॉफ्ट ओरेकल ड्राइवर का उपयोग, ओडीपी.नेट नहीं), मैटक के जवाब में कोड के समान, और मुझे ओरेकल निष्पादन में कोई अंतर नहीं दिखाई देता, हालांकि स्ट्रिंग पैरामीटर का अब एक सामान्य आकार था।

Here's स्टैकएक्सचेंज डीबीए पर मेरी पोस्ट।

ओरेकल एंटरप्राइज़ मैनेजर ने मेरे एनएचबीर्नेट जेनरेटेड एसक्यूएल के लिए कोई डुप्लिकेट क्वेरी नहीं दिखायी, और दोनों संस्करणों में, प्रत्येक कॉल ने एक पार्स (लंबे परीक्षण के लिए कुछ 1000 तक) का कारण बना दिया, लेकिन बहुत कम हार्ड पार्स, चर और निश्चित के बीच कोई अंतर नहीं पैरामीटर लंबाई।

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

ओरेकल शायद योजना मिलान के लिए केवल SQL स्ट्रिंग की तुलना करता है, जबकि SQL सर्वर पैरामीटर परिभाषाओं की भी जांच करता है। जब गतिशील एसक्यूएल को देख आप भी एक अंतर देख सकते हैं आदेश निष्पादित तत्काल (Oracle) और sp_executesql (SQL सर्वर): sp_executesql भी (एक स्ट्रिंग हो जाता है एक स्ट्रिंग में पैरामीटर परिभाषा के साथ, के लिए मानकों के रूप में नहीं sp_executesql स्वयं को कॉल करें!)। मुझे पता है कि SQL सर्वर पर पैरामीटरयुक्त क्वेरी भेजते समय NH12ernate/ADO.NET sp_executesql का उपयोग करता है, इसलिए इसकी संभावना SQL सर्वर के अंतर्गत एक अलग हैंडलिंग है। साथ ही, NHBernate के माध्यम से SQL सर्वर से कनेक्ट होने पर, सभी स्ट्रिंग पैरामीटर में अद्वितीय आकार होते हैं (NHibernate मैपिंग या डिफ़ॉल्ट अधिकतम लंबाई से), इसलिए संभावित रूप से समस्या ठीक हो गई है। यदि मैं गलत हूं तो मुझे सही करों!

ADO.NET/NHibernate में तैयार/ready_sql का उपयोग करने से कुछ नुकसान होते हैं: कार्यान्वयन के आधार पर, किसी भी SQL को निष्पादित करने से पहले, अनुरोध तैयार करने के लिए डेटाबेस को भेजना होगा, आवेदन को तैयार कथन के लिए एक हैंडल रखना होगा , और इसका उपयोग केवल एक कनेक्शन के लिए किया जा सकता है। मतलब: नए हैंडल अक्सर बनाया जाना चाहिए। जब मैंने ओरेकल और ओडीपी.नेट के साथ परीक्षण किया, तो यह गैर-तैयार संस्करण की तुलना में कुछ हद तक धीमा था, हालांकि स्वयं को संभालकर पूछताछ पैरामीटर एसक्यूएल की तुलना में अधिक (कम) अधिक प्रदर्शनकारी है, जो स्ट्रिंग समानता द्वारा डेटाबेस पर मेल खाती है। संभावना है, अगर आवेदन एक ही डीबी कनेक्शन या एनएचबीर्नेट सत्र में एक ही क्वेरी के कई बार उपयोग करता है तो तैयार होना अच्छा है।