"डॉट" नोटेशन का उपयोग करते हुए आपके पहले उदाहरण में, क्लाइंट कर्सर इंजन का उपयोग किया जाता है और अधिकांश चीजों का मूल्यांकन स्थानीय रूप से किया जाता है। यदि आप एक बड़ी तालिका से चयन कर रहे हैं और WHERE क्लॉज का उपयोग कर रहे हैं, तो रिकॉर्ड्स को दूरस्थ डीबी से स्थानीय रूप से नीचे खींच लिया जाएगा। एक बार डेटा को लिंक किए गए सर्वर पर खींच लिया गया है, तभी स्थानीय रूप से WHERE क्लॉज लागू होता है। अक्सर यह क्रम एक प्रदर्शन हिट होता है। रिमोट डीबी पर इंडेक्स मूल रूप से बेकार हो जाते हैं।
वैकल्पिक रूप से जब आप OPENQUERY का उपयोग करते हैं, तो SQL सर्वर प्रसंस्करण के लिए लक्ष्य डेटाबेस में sql स्टेटमेंट भेजता है। प्रसंस्करण के दौरान टेबल पर किसी भी इंडेक्स का लाभ उठाया जाता है। साथ ही जहां क्लॉज को SQL सर्वर पर वापस परिणाम भेजने से पहले Oracle पक्ष पर लागू किया जाता है।
मेरे अनुभव में, सरलतम प्रश्नों को छोड़कर, OPENQUERY आपको बेहतर प्रदर्शन देने वाला है।
मैं उपरोक्त कारणों से हर चीज के लिए OpenQuery का उपयोग करने की सलाह दूंगा।
OpenQuery का उपयोग करते समय दर्द बिंदुओं में से एक जो आप पहले ही सामना कर चुके हैं वह सिंगल कोट्स है। यदि दूरस्थ डीबी को भेजी जा रही एसक्यूएल स्ट्रिंग को स्ट्रिंग या दिनांक तिथि के आसपास सिंगल कोट्स की आवश्यकता होती है तो उन्हें बचने की आवश्यकता होती है। अन्यथा वे अनजाने में sql स्ट्रिंग को समाप्त कर देते हैं।
यहां एक टेम्प्लेट है जिसका उपयोग मैं तब भी करता हूं जब मैं सिंगल कोट समस्या का ध्यान रखने के लिए किसी लिंक किए गए सर्वर से ओपनक्वेरी स्टेटमेंट में वेरिएबल के साथ काम कर रहा होता हूं:
DECLARE @UniqueId int
, @sql varchar(500)
, @linkedserver varchar(30)
, @statement varchar(600)
SET @UniqueId = 2
SET @linkedserver = 'LINKSERV'
SET @sql = 'SELECT DummyFunction(''''' + CAST(@UniqueId AS VARCHAR(10))+ ''''') FROM DUAL'
SET @statement = 'SELECT * FROM OPENQUERY(' + @linkedserver + ', '
SET @Statement = @Statement + '''' + @SQL + ''')'
EXEC(@Statement)
