[ भाग 1 | भाग 2 | भाग 3 | भाग 4 ]
हैलोवीन समस्या निष्पादन योजनाओं पर कई महत्वपूर्ण प्रभाव डाल सकती है। शृंखला के इस अंतिम भाग में, हम उन तरकीबों को देखते हैं जो ऑप्टिमाइज़र हैलोवीन समस्या से बचने के लिए उपयोग कर सकते हैं जब डेटा जोड़ने, बदलने या हटाने वाली क्वेरी के लिए योजनाएँ संकलित करते हैं।
पृष्ठभूमि
पिछले कुछ वर्षों में, हैलोवीन समस्या से बचने के लिए कई तरीकों की कोशिश की गई है। एक प्रारंभिक तकनीक किसी भी निष्पादन योजना के निर्माण से बचने के लिए थी जिसमें एक ही इंडेक्स की चाबियों से पढ़ना और लिखना शामिल था। यह प्रदर्शन के दृष्टिकोण से बहुत सफल नहीं था, कम से कम नहीं क्योंकि इसका मतलब अक्सर बदलने के लिए पंक्तियों का पता लगाने के लिए एक चयनात्मक गैर-संकुल सूचकांक का उपयोग करने के बजाय आधार तालिका को स्कैन करना था।
एक दूसरा तरीका अपडेट क्वेरी के पढ़ने और लिखने के चरणों को पूरी तरह से अलग करना था, पहले उन सभी पंक्तियों का पता लगाकर जो परिवर्तन के लिए अर्हता प्राप्त करते हैं, उन्हें कहीं संग्रहीत करते हैं, और उसके बाद ही परिवर्तन करना शुरू करते हैं। SQL सर्वर में, यह पूर्ण चरण पृथक्करण अद्यतन ऑपरेटर के इनपुट पक्ष पर अब परिचित उत्सुक टेबल स्पूल रखकर हासिल किया जाता है:
स्पूल अपने इनपुट से सभी पंक्तियों को पढ़ता है और उन्हें एक छिपे हुए tempdb . में संग्रहीत करता है कार्य तालिका। इस कार्य तालिका के पृष्ठ स्मृति में रह सकते हैं, या यदि पंक्तियों का सेट बड़ा है, या सर्वर स्मृति दबाव में है, तो उन्हें भौतिक डिस्क स्थान की आवश्यकता हो सकती है।
पूर्ण चरण पृथक्करण आदर्श से कम हो सकता है क्योंकि हम आम तौर पर अधिक से अधिक योजना को एक पाइपलाइन के रूप में चलाना चाहते हैं, जहां प्रत्येक पंक्ति को अगले पर जाने से पहले पूरी तरह से संसाधित किया जाता है। पाइपलाइनिंग के कई फायदे हैं जिनमें अस्थायी भंडारण की आवश्यकता से बचना और प्रत्येक पंक्ति को केवल एक बार स्पर्श करना शामिल है।
एसक्यूएल सर्वर ऑप्टिमाइज़र
SQL सर्वर अब तक वर्णित दो तकनीकों की तुलना में बहुत आगे जाता है, हालांकि इसमें निश्चित रूप से दोनों विकल्प शामिल हैं। SQL सर्वर क्वेरी ऑप्टिमाइज़र उन क्वेरी का पता लगाता है जिन्हें हैलोवीन सुरक्षा की आवश्यकता होती है, यह निर्धारित करता है कि कितना सुरक्षा की आवश्यकता है, और लागत-आधारित . का उपयोग करता है सुरक्षा प्रदान करने का सबसे सस्ता तरीका खोजने के लिए विश्लेषण।
हैलोवीन समस्या के इस पहलू को समझने का सबसे आसान तरीका कुछ उदाहरणों को देखना है। निम्नलिखित अनुभागों में, कार्य मौजूदा तालिका में संख्याओं की एक श्रृंखला को जोड़ना है - लेकिन केवल वे संख्याएँ जो पहले से मौजूद नहीं हैं:
CREATE TABLE dbo.Test
(
pk integer NOT NULL,
CONSTRAINT PK_Test
PRIMARY KEY CLUSTERED (pk)
); 5 पंक्तियाँ
पहला उदाहरण 1 से 5 तक की संख्याओं की एक श्रृंखला को संसाधित करता है:
INSERT dbo.Test (pk)
SELECT Num.n
FROM dbo.Numbers AS Num
WHERE
Num.n BETWEEN 1 AND 5
AND NOT EXISTS
(
SELECT NULL
FROM dbo.Test AS t
WHERE t.pk = Num.n
); चूंकि यह क्वेरी टेस्ट टेबल पर उसी इंडेक्स की चाबियों से पढ़ती और लिखती है, इसलिए निष्पादन योजना के लिए हैलोवीन प्रोटेक्शन की आवश्यकता होती है। इस मामले में, अनुकूलक ईगर टेबल स्पूल का उपयोग करके पूर्ण चरण पृथक्करण का उपयोग करता है:
50 पंक्तियाँ
परीक्षण तालिका में अब पाँच पंक्तियों के साथ, हम WHERE . को बदलते हुए फिर से वही क्वेरी चलाते हैं 1 से 50 तक की संख्याओं को संसाधित करने के लिए क्लॉज, समावेशी :
यह योजना हैलोवीन समस्या के खिलाफ सही सुरक्षा प्रदान करती है, लेकिन इसमें उत्सुक टेबल स्पूल की सुविधा नहीं है। ऑप्टिमाइज़र पहचानता है कि हैश मैच जॉइन ऑपरेटर इसके बिल्ड इनपुट पर ब्लॉक कर रहा है; सभी पंक्तियों को हैश तालिका में पढ़ा जाता है, इससे पहले कि ऑपरेटर जांच इनपुट से पंक्तियों का उपयोग करके मिलान प्रक्रिया शुरू करता है। परिणामस्वरूप, यह योजना स्पूल की आवश्यकता के बिना स्वाभाविक रूप से चरण पृथक्करण (केवल परीक्षण तालिका के लिए) प्रदान करती है।
अनुकूलक ने लागत-आधारित कारणों से 5-पंक्ति योजना में देखे गए नेस्टेड लूप्स जॉइन पर हैश मैच जॉइन प्लान चुना। 50-पंक्ति हैश मैच योजना की कुल अनुमानित लागत 0.0347345 . है इकाइयां हम नेस्टेड लूप्स योजना को पहले इस्तेमाल किए गए संकेत के साथ यह देखने के लिए बाध्य कर सकते हैं कि ऑप्टिमाइज़र नेस्टेड लूप क्यों नहीं चुना:
इस योजना की अनुमानित लागत 0.0379063 . है स्पूल सहित इकाइयाँ, हैश मैच योजना से थोड़ी अधिक।
500 पंक्तियाँ
परीक्षण तालिका में अब 50 पंक्तियों के साथ, हम संख्याओं की सीमा को 500 . तक बढ़ा देते हैं :
इस बार, ऑप्टिमाइज़र मर्ज जॉइन का चयन करता है, और फिर से कोई ईगर टेबल स्पूल नहीं है। सॉर्ट ऑपरेटर इस योजना में आवश्यक चरण पृथक्करण प्रदान करता है। यह पहली पंक्ति को वापस करने से पहले अपने इनपुट का पूरी तरह से उपभोग करता है (जब तक सभी पंक्तियों को नहीं देखा जाता है, तब तक यह नहीं जान सकता कि कौन सी पंक्ति पहले क्रमबद्ध है)। अनुकूलक ने निर्णय लिया कि 50 . को क्रमबद्ध करना टेस्ट टेबल से पंक्तियाँ उत्सुक-स्पूलिंग से सस्ती होंगी 450 अद्यतन ऑपरेटर के ठीक पहले की पंक्तियाँ।
सॉर्ट प्लस मर्ज जॉइन योजना की अनुमानित लागत 0.0362708 . है इकाइयां हैश मैच और नेस्टेड लूप्स योजना के विकल्प 0.0385677 . पर सामने आते हैं इकाइयां और 0.112433 इकाइयाँ क्रमशः।
सॉर्ट के बारे में कुछ अजीब है
यदि आप इन उदाहरणों को अपने लिए चला रहे हैं, तो आपने उस अंतिम उदाहरण के बारे में कुछ अजीब देखा होगा, खासकर यदि आपने टेस्ट टेबल सीक एंड द सॉर्ट के लिए प्लान एक्सप्लोरर टूल टिप्स को देखा:
सीक एक आदेशित . का उत्पादन करता है pk . की धारा मान, तो तुरंत बाद में उसी कॉलम पर सॉर्ट करने का क्या मतलब है? उस (बहुत ही उचित) प्रश्न का उत्तर देने के लिए, हम केवल SELECT . को देखकर शुरू करते हैं INSERT . का भाग क्वेरी:
SELECT Num.n
FROM dbo.Numbers AS Num
WHERE
Num.n BETWEEN 1 AND 500
AND NOT EXISTS
(
SELECT 1
FROM dbo.Test AS t
WHERE t.pk = Num.n
)
ORDER BY
Num.n;
यह क्वेरी नीचे निष्पादन योजना तैयार करती है (ORDER BY . के साथ या बिना) मैंने आपकी कुछ तकनीकी आपत्तियों को दूर करने के लिए जोड़ा):
सॉर्ट ऑपरेटर की कमी पर ध्यान दें। तो क्यों किया INSERT योजना में एक सॉर्ट शामिल है? बस हैलोवीन समस्या से बचने के लिए। अनुकूलक ने माना कि अनावश्यक प्रकार . का प्रदर्शन करना (इसके अंतर्निर्मित चरण पृथक्करण के साथ) क्वेरी निष्पादित करने और सही परिणामों की गारंटी देने का सबसे सस्ता तरीका था। चतुर।
हैलोवीन सुरक्षा स्तर और गुण
SQL सर्वर ऑप्टिमाइज़र में विशिष्ट विशेषताएं हैं जो इसे क्वेरी प्लान में प्रत्येक बिंदु पर आवश्यक हैलोवीन प्रोटेक्शन (HP) के स्तर और प्रत्येक ऑपरेटर के विस्तृत प्रभाव के बारे में तर्क करने की अनुमति देती हैं। इन अतिरिक्त सुविधाओं को उसी संपत्ति ढांचे में शामिल किया गया है जिसका उपयोग ऑप्टिमाइज़र अपनी खोज गतिविधियों के दौरान सैकड़ों अन्य महत्वपूर्ण सूचनाओं पर नज़र रखने के लिए करता है।
प्रत्येक ऑपरेटर के पास एक आवश्यक . होता है HP संपत्ति और एक वितरित एचपी संपत्ति। आवश्यक संपत्ति सही परिणामों के लिए पेड़ में उस बिंदु पर आवश्यक एचपी के स्तर को इंगित करती है। वितरित संपत्ति वर्तमान ऑपरेटर द्वारा प्रदान की गई एचपी और संचयी . को दर्शाती है इसके सबट्री द्वारा प्रदान किए गए एचपी प्रभाव।
ऑप्टिमाइज़र में यह निर्धारित करने के लिए तर्क होता है कि प्रत्येक भौतिक ऑपरेटर (उदाहरण के लिए, एक कंप्यूट स्केलर) एचपी स्तर को कैसे प्रभावित करता है। प्लान विकल्पों की एक विस्तृत श्रृंखला की खोज करके और उन योजनाओं को अस्वीकार करके जहां डिलीवर किया गया एचपी अपडेट ऑपरेटर पर आवश्यक एचपी से कम है, ऑप्टिमाइज़र के पास सही, कुशल योजनाओं को खोजने का एक लचीला तरीका है जिसके लिए हमेशा एक उत्सुक टेबल स्पूल की आवश्यकता नहीं होती है।
हैलोवीन सुरक्षा के लिए योजना में बदलाव
हमने देखा कि ऑप्टिमाइज़र पिछले मर्ज जॉइन उदाहरण में हैलोवीन प्रोटेक्शन के लिए एक अनावश्यक प्रकार जोड़ता है। हम कैसे सुनिश्चित कर सकते हैं कि यह एक साधारण ईगर टेबल स्पूल की तुलना में अधिक कुशल है? और हम कैसे जान सकते हैं कि अद्यतन योजना की कौन-सी सुविधाएँ केवल हैलोवीन सुरक्षा के लिए हैं?
अनिर्दिष्ट ट्रेस फ्लैग 8692 . का उपयोग करके दोनों प्रश्नों का उत्तर (एक परीक्षण वातावरण में, स्वाभाविक रूप से) दिया जा सकता है , जो अनुकूलक को हैलोवीन सुरक्षा के लिए एक ईगर टेबल स्पूल का उपयोग करने के लिए बाध्य करता है। याद रखें कि अतिरिक्त प्रकार के मर्ज जॉइन योजना की अनुमानित लागत 0.0362708 . थी जादू अनुकूलक इकाइयाँ। ट्रेस फ्लैग 8692 सक्षम के साथ क्वेरी को फिर से संकलित करके हम ईगर टेबल स्पूल विकल्प से इसकी तुलना कर सकते हैं:
INSERT dbo.Test (pk)
SELECT Num.n
FROM dbo.Numbers AS Num
WHERE
Num.n BETWEEN 1 AND 500
AND NOT EXISTS
(
SELECT 1
FROM dbo.Test AS t
WHERE t.pk = Num.n
)
OPTION (QUERYTRACEON 8692);
ईगर स्पूल योजना की अनुमानित लागत 0.0378719 . है इकाइयां (0.0362708 से ऊपर अनावश्यक प्रकार के साथ)। कार्य की तुच्छ प्रकृति और पंक्तियों के छोटे आकार के कारण यहां दिखाए गए लागत अंतर बहुत महत्वपूर्ण नहीं हैं। जटिल पेड़ों और बड़ी पंक्तियों के साथ वास्तविक-विश्व अपडेट क्वेरी अक्सर ऐसी योजनाएं तैयार करती हैं जो SQL सर्वर अनुकूलक की हैलोवीन सुरक्षा के बारे में गहराई से सोचने की क्षमता के कारण अधिक कुशल होती हैं।
अन्य गैर-स्पूल विकल्प
हैलोवीन समस्या के खिलाफ सुरक्षा प्रदान करने की लागत को कम करने के लिए ऑप्टिमाइज़र के लिए एक योजना के भीतर एक ब्लॉकिंग ऑपरेटर को बेहतर स्थिति में रखना एकमात्र रणनीति नहीं है। यह संसाधित किए जा रहे मानों की श्रेणी के बारे में भी तर्क दे सकता है, जैसा कि निम्न उदाहरण दर्शाता है:
CREATE TABLE #Test
(
pk integer IDENTITY PRIMARY KEY,
some_value integer
);
CREATE INDEX i ON #Test (some_value);
-- Pretend the table has lots of data in it
UPDATE STATISTICS #Test
WITH ROWCOUNT = 123456, PAGECOUNT = 1234;
UPDATE #Test
SET some_value = 10
WHERE some_value = 5; निष्पादन योजना हैलोवीन सुरक्षा की कोई आवश्यकता नहीं दिखाती है, इस तथ्य के बावजूद कि हम एक सामान्य सूचकांक की कुंजियों को पढ़ रहे हैं और अपडेट कर रहे हैं:
अनुकूलक यह देख सकता है कि 'some_value' को 5 से 10 में बदलने से इंडेक्स सीक (जो केवल उन पंक्तियों की तलाश में है जहां some_value 5 है) द्वारा अद्यतन पंक्ति को दूसरी बार नहीं देखा जा सकता है। यह तर्क केवल वहीं संभव है जहां क्वेरी में शाब्दिक मानों का उपयोग किया जाता है, या जहां क्वेरी निर्दिष्ट करती है OPTION (RECOMPILE) , ऑप्टिमाइज़र को एकबारगी निष्पादन योजना के लिए मापदंडों के मूल्यों को सूँघने की अनुमति देता है।
क्वेरी में शाब्दिक मानों के साथ भी, ऑप्टिमाइज़र को इस तर्क को लागू करने से रोका जा सकता है यदि डेटाबेस विकल्प FORCED PARAMETERIZATION ON है . उस स्थिति में, क्वेरी में शाब्दिक मानों को पैरामीटर द्वारा बदल दिया जाता है, और ऑप्टिमाइज़र अब यह सुनिश्चित नहीं कर सकता है कि हैलोवीन सुरक्षा की आवश्यकता नहीं है (या विभिन्न पैरामीटर मानों के साथ योजना का पुन:उपयोग किए जाने पर इसकी आवश्यकता नहीं होगी):
यदि आप सोच रहे हैं कि क्या होता है यदि FORCED PARAMETERIZATION सक्षम है और क्वेरी निर्दिष्ट करती है OPTION (RECOMPILE) , उत्तर यह है कि अनुकूलक सूंघे गए मानों के लिए एक योजना संकलित करता है, और इसलिए अनुकूलन लागू कर सकता है। हमेशा की तरह OPTION (RECOMPILE) . के साथ , विशिष्ट-मान क्वेरी योजना पुन:उपयोग के लिए कैश्ड नहीं है।
शीर्ष
यह अंतिम उदाहरण दिखाता है कि कैसे Top ऑपरेटर हेलोवीन सुरक्षा की आवश्यकता को दूर कर सकता है:
UPDATE TOP (1) t SET some_value += 1 FROM #Test AS t WHERE some_value <= 10;
किसी सुरक्षा की आवश्यकता नहीं है क्योंकि हम केवल एक पंक्ति को अपडेट कर रहे हैं। इंडेक्स सीक द्वारा अपडेट किए गए मान का सामना नहीं किया जा सकता है, क्योंकि पहली पंक्ति के अपडेट होते ही प्रोसेसिंग पाइपलाइन बंद हो जाती है। फिर से, यह अनुकूलन केवल तभी लागू किया जा सकता है जब TOP . में एक स्थिर शाब्दिक मान का उपयोग किया जाता है , या यदि '1' मान लौटाने वाला एक चर OPTION (RECOMPILE) का उपयोग करके सूंघ लिया जाता है ।
अगर हम TOP (1) . को बदलते हैं TOP (2) . की क्वेरी में , ऑप्टिमाइज़र इंडेक्स सीक के बजाय क्लस्टर्ड इंडेक्स स्कैन चुनता है:
हम संकुल अनुक्रमणिका की कुंजियों को अद्यतन नहीं कर रहे हैं, इसलिए इस योजना के लिए हैलोवीन सुरक्षा की आवश्यकता नहीं है। TOP (2) . में संकेत के साथ गैर-संकुलित अनुक्रमणिका का उपयोग करने के लिए बाध्य करना क्वेरी सुरक्षा की लागत को स्पष्ट करती है:
अनुकूलक ने अनुमान लगाया कि क्लस्टर्ड इंडेक्स स्कैन इस योजना से सस्ता होगा (इसकी अतिरिक्त हेलोवीन सुरक्षा के साथ)।
बाधाएं और अंत
हैलोवीन प्रोटेक्शन के बारे में कुछ अन्य बिंदु हैं जिन्हें मैं अब से पहले श्रृंखला में एक प्राकृतिक स्थान नहीं मिला है। पहला हैलोवीन संरक्षण का प्रश्न है जब एक पंक्ति-संस्करण अलगाव स्तर उपयोग में है।
पंक्ति संस्करण
SQL सर्वर दो अलगाव स्तर प्रदान करता है, READ COMMITTED SNAPSHOT और SNAPSHOT ISOLATION जो tempdb . में एक संस्करण स्टोर का उपयोग करते हैं एक विवरण प्रदान करने के लिए- या डेटाबेस का लेनदेन-स्तर सुसंगत दृश्य। SQL सर्वर इन आइसोलेशन स्तरों के तहत पूरी तरह से हैलोवीन प्रोटेक्शन से बच सकता है, क्योंकि वर्जन स्टोर किसी भी बदलाव से अप्रभावित डेटा प्रदान कर सकता है जो वर्तमान में निष्पादित स्टेटमेंट में अब तक हो सकता है। यह विचार वर्तमान में SQL सर्वर के रिलीज़ किए गए संस्करण में लागू नहीं किया गया है, हालांकि Microsoft ने यह बताते हुए एक पेटेंट दायर किया है कि यह कैसे काम करेगा, इसलिए शायद भविष्य के संस्करण में इस तकनीक को शामिल किया जाएगा।
ढेर और अग्रेषित रिकॉर्ड
यदि आप ढेर संरचनाओं के आंतरिक भाग से परिचित हैं, तो आप सोच रहे होंगे कि क्या एक विशेष हैलोवीन समस्या तब हो सकती है जब एक हीप तालिका में अग्रेषित रिकॉर्ड उत्पन्न होते हैं। यदि यह आपके लिए नया है, तो एक मौजूदा पंक्ति को इस तरह अद्यतन किया जाता है कि वह मूल डेटा पृष्ठ पर फ़िट न हो जाए, तो एक हीप रिकॉर्ड अग्रेषित किया जाएगा। इंजन एक फ़ॉरवर्डिंग स्टब को पीछे छोड़ देता है, और विस्तारित रिकॉर्ड को दूसरे पेज पर ले जाता है।
एक समस्या हो सकती है यदि एक हीप स्कैन वाली योजना एक रिकॉर्ड को अद्यतन करती है जैसे कि इसे अग्रेषित किया जाता है। जब स्कैन स्थिति अग्रेषित रिकॉर्ड के साथ पृष्ठ पर पहुंचती है तो हीप स्कैन फिर से पंक्ति का सामना कर सकता है। SQL सर्वर में, इस समस्या से बचा जाता है क्योंकि संग्रहण इंजन हमेशा फ़ॉरवर्डिंग पॉइंटर्स का तुरंत पालन करने की गारंटी देता है। यदि स्कैन को एक रिकॉर्ड का सामना करना पड़ता है जिसे अग्रेषित किया गया है, तो वह इसे अनदेखा कर देता है। इस सुरक्षा के साथ, क्वेरी ऑप्टिमाइज़र को इस परिदृश्य के बारे में चिंता करने की ज़रूरत नहीं है।
SCHEMABINDING और T-SQL स्केलर फ़ंक्शंस
ऐसे बहुत कम अवसर होते हैं जब टी-एसक्यूएल स्केलर फ़ंक्शन का उपयोग करना एक अच्छा विचार है, लेकिन यदि आपको एक का उपयोग करना चाहिए तो आपको हैलोवीन सुरक्षा के संबंध में एक महत्वपूर्ण प्रभाव के बारे में पता होना चाहिए। जब तक कोई स्केलर फ़ंक्शन SCHEMABINDING . के साथ घोषित नहीं किया जाता है विकल्प, SQL सर्वर मानता है कि फ़ंक्शन टेबल तक पहुंचता है। उदाहरण के लिए, नीचे दिए गए सरल टी-एसक्यूएल स्केलर फ़ंक्शन पर विचार करें:
CREATE FUNCTION dbo.ReturnInput
(
@value integer
)
RETURNS integer
AS
BEGIN
RETURN @value;
END;
यह फ़ंक्शन किसी भी टेबल तक नहीं पहुंचता है; वास्तव में यह पास किए गए पैरामीटर मान को वापस करने के अलावा कुछ भी नहीं करता है। अब निम्नलिखित को देखें INSERT क्वेरी:
DECLARE @T AS TABLE (ProductID integer PRIMARY KEY); INSERT @T (ProductID) SELECT p.ProductID FROM AdventureWorks2012.Production.Product AS p;
निष्पादन योजना बिल्कुल वैसी ही है जैसी हम अपेक्षा करते हैं, जिसमें हैलोवीन सुरक्षा की आवश्यकता नहीं है:
हालांकि, हमारे कुछ न करें फ़ंक्शन को जोड़ने से नाटकीय प्रभाव पड़ता है:
DECLARE @T AS TABLE (ProductID integer PRIMARY KEY); INSERT @T (ProductID) SELECT dbo.ReturnInput(p.ProductID) FROM AdventureWorks2012.Production.Product AS p;
निष्पादन योजना में अब हैलोवीन संरक्षण के लिए एक उत्सुक टेबल स्पूल शामिल है। SQL सर्वर मानता है कि फ़ंक्शन डेटा तक पहुंचता है, जिसमें उत्पाद तालिका से फिर से पढ़ना शामिल हो सकता है। जैसा कि आपको याद होगा, एक INSERT योजना जिसमें योजना के पठन पक्ष पर लक्ष्य तालिका का संदर्भ है, के लिए पूर्ण हैलोवीन सुरक्षा की आवश्यकता है, और जहाँ तक अनुकूलक को पता है, यहाँ ऐसा ही हो सकता है।
SCHEMABINDING जोड़ना फ़ंक्शन परिभाषा के विकल्प का अर्थ है कि SQL सर्वर यह निर्धारित करने के लिए फ़ंक्शन के मुख्य भाग की जाँच करता है कि यह किन तालिकाओं तक पहुँचता है। इसे ऐसी कोई एक्सेस नहीं मिलती है, और इसलिए इसमें कोई हैलोवीन सुरक्षा शामिल नहीं है:
ALTER FUNCTION dbo.ReturnInput
(
@value integer
)
RETURNS integer
WITH SCHEMABINDING
AS
BEGIN
RETURN @value;
END;
GO
DECLARE @T AS TABLE (ProductID int PRIMARY KEY);
INSERT @T (ProductID)
SELECT p.ProductID
FROM AdventureWorks2012.Production.Product AS p;
टी-एसक्यूएल स्केलर फ़ंक्शन के साथ यह समस्या सभी अद्यतन प्रश्नों को प्रभावित करती है - INSERT , UPDATE , DELETE , और MERGE . यह जानना कि आप कब इस समस्या का सामना कर रहे हैं, और अधिक कठिन बना दिया गया है क्योंकि अनावश्यक हैलोवीन सुरक्षा हमेशा एक अतिरिक्त ईगर टेबल स्पूल के रूप में दिखाई नहीं देगी, और स्केलर फ़ंक्शन कॉल्स, उदाहरण के लिए, दृश्यों या गणना किए गए कॉलम परिभाषाओं में छिपी हो सकती हैं।
[ भाग 1 | भाग 2 | भाग 3 | भाग 4 ]
