स्कीमा बदलने के बाद मैं टूटी हुई संग्रहीत प्रक्रियाओं का पता कैसे लगा सकता हूं?


11

मैंने अपने डेटाबेस में एक केंद्रीय तालिका को संशोधित किया है, और sp_depends शाब्दिक रूप से सैकड़ों परिणाम देता है, और मुझे चिंता है कि कुछ संग्रहीत प्रक्रियाएं मेरे परिवर्तन के बाद अब संकलित नहीं हो सकती हैं।

एक एकल संग्रहीत कार्यविधि की जाँच करना आसान है (मैं सिर्फ स्क्रिप्ट को बदल देता हूं और देखता हूं कि ऑपरेशन सफल है), लेकिन 100+ प्रक्रियाओं पर यह करना थोड़ा बोझिल है।

मुझे पता है कि मैं अपने डेटाबेस की सभी वस्तुओं को फिर से जोड़ने के लिए इस तरह से एक स्क्रिप्ट का उपयोग कर सकता हूं, लेकिन वास्तविक संचालन अगली बार होगा जब संग्रहीत प्रक्रिया निष्पादित की जाती है, तुरंत नहीं, ताकि यह मेरे मामले में उचित न लगे।

मैं यह भी सोच रहा था कि मैं सभी संग्रहीत प्रक्रियाओं को पूरी तरह से छोड़ सकता हूं, और अपने स्रोत नियंत्रण प्रणाली के साथ अपने डेटाबेस को फिर से तैयार कर सकता हूं, लेकिन यह विकल्प, हालांकि व्यवहार्य है, बहुत सुरुचिपूर्ण नहीं है। क्या ऐसा करने का कोई बेहतर तरीका है?

मैं SQLServer 2008 R2 का उपयोग कर रहा हूं और मेरे डेटाबेस स्क्रिप्ट को VS 2008 डेटाबेस प्रोजेक्ट में संग्रहीत किया गया है।


स्पष्ट करने के लिए, मैं वकालत नहीं कर रहा हूं कि किसी को केवल परीक्षण कोड के लिए इस दृष्टिकोण पर भरोसा करना चाहिए। ठीक उसी तरह जैसे कि आप सी # कोड के रूप में अन्य निर्भर फ़ाइलों में तुरंत वाक्यविन्यास त्रुटि का पता लगाते हैं (और फिर यूनिट परीक्षण के लिए अन्य रणनीतियों का उपयोग करते हैं, जैसे कि इकाई परीक्षण, जो आमतौर पर परिमाण के कई आदेश हैं), मुझे लगता है कि एसक्यूएल निर्भरता का पता लगाने में समझदारी होगी पूर्ण कार्यात्मक परीक्षण चलाने के बजाय सेकंड में त्रुटियां जो आम तौर पर पूरी होने में कुछ घंटों का समय ले सकती हैं।

जवाबों:


7

आप अपनी इकाई, कार्यात्मक, एकीकरण और प्रदर्शन परीक्षण कैसे चलाते हैं? यदि आपके पास कोई परीक्षण नहीं है तो गंभीर समय है कि आप अपने डेटाबेस स्कीमा को कोड के रूप में समझना शुरू करें और इसे इस तरह से व्यवहार करें, जैसे संस्करण नियंत्रण और परीक्षण। एलेक्स कुज़नेत्सोव के पास इस विषय को समर्पित एक पूरी पुस्तक है: SQL सर्वर के साथ रक्षात्मक डेटाबेस प्रोग्रामिंग


टेस्ट हमेशा 100% कोड को कवर नहीं करते हैं, और जब वे करते हैं तो उन्हें चलाने में कुछ घंटे लगते हैं। सी # में, मैं पता लगा सकता हूं कि क्या मेरा कोड अभी भी सेकंड में संकलित है (इसकी शुद्धता के बावजूद)। इसका मतलब यह नहीं है कि मुझे कोड को धक्का देना चाहिए (कोड की परवाह किए बिना कोड # या PLSQL के उत्पादन में) इसे ठीक से परीक्षण किए बिना, लेकिन यह टूटी हुई निर्भरता का जल्दी से पता लगाने का एक तरीका नहीं है, क्या यह अनुचित है?
Brann

2
दुर्भाग्य से कला का SQL सर्वर राज्य अभी संग्रहीत प्रक्रिया में विज़-ए-निर्भर निर्भरता का पता लगाने के लिए 'गहराई से टूट गया' है, SQL निर्भरता को ध्यान में रखते हुए या SQL Server 2008 में अद्यतित रखने के लिए देखें । यहां तक ​​कि तीसरे पक्ष के उपकरण
रेमुस रुसानु

2
यह यूनिट / कार्यात्मक परीक्षणों को ब्रेकिंग परिवर्तनों का पता लगाने का एकमात्र विश्वसनीय तरीका बनाता है।
रेमस रुसानु

1
एक त्वरित जाँच के लिए विज़ुअल स्टूडियो डेटाबेस प्रोजेक्ट्स किसी भी बदलाव को मान्य करने के लिए एक बहुत अच्छा काम करता है।
रेमस रुसानु

4

यह एक काम के आसपास है, लेकिन आप डेटाबेस के लिए क्रिएट प्रक्रिया स्क्रिप्ट उत्पन्न कर सकते हैं (राइट क्लिक डेटाबेस -> कार्य -> ​​स्क्रिप्ट उत्पन्न), खोजने और बदलने की प्रक्रिया के साथ बेहतर प्रक्रिया और फिर पार्स।

मुझे आशा है कि आपको यहां बेहतर उत्तर मिलेगा - मुझे भी दिलचस्पी है! :)


मैं आपके उत्तर को स्वीकार नहीं कर रहा हूं क्योंकि मैं अभी भी क्लीनर समाधान की उम्मीद करता हूं (उम्मीद है कि यह एक स्क्रिप्ट योग्य है), लेकिन आप निश्चित रूप से मेरे +1 प्राप्त करेंगे! धन्यवाद।
ब्रैन

3
यदि आप एक गैर-मौजूद तालिका का संदर्भ दे रहे हैं तो यह दृष्टिकोण आपको यह बताने नहीं देगा ।
निक चामास

यदि उत्पन्न स्क्रिप्ट लगभग 30k लाइनों से बड़ी है, तो यह दृष्टिकोण भी काम नहीं करेगा। मुझे नफरत है कि मैं यह जानता हूं ..
इयोनसन

3

आप Sql Server Data Tools (SSDT) ​​का उपयोग कर सकते हैं। Microsoft Visual Studio आपको Sql सर्वर प्रोजेक्ट बनाने की अनुमति देता है। एक तो प्रोजेक्ट में डेटाबेस आयात करता है और फिर प्रोजेक्ट का निर्माण करता है। यदि कोई टूटी हुई संग्रहीत कार्यविधि या ऑब्जेक्ट हैं, तो आपको एक संकलन त्रुटि मिलेगी।


मुझे लगता है कि आप आसानी से SSDT परियोजना से स्क्रिप्ट बनाने और एक परीक्षण वातावरण में चलाने के लिए एक नया डेटाबेस उत्पन्न कर सकते हैं, जो एक पूरी तरह से सत्यापन होगा कि स्कीमा परिवर्तन के कारण कोई प्रॉपर / ट्रिगर / आदि टूटा नहीं है।
एरोनल्स

3

आप इस एसओ प्रश्न को देखना चाहते हैं, मैं टी-एसक्यूएल संग्रहीत प्रक्रियाओं को सत्यापित करने के लिए एक विश्वसनीय तरीका ढूंढ रहा हूं। किसी को एक मिला? जो अनिवार्य रूप से एक ही बात पूछ रहा है, जिसमें कई उत्तर हैं।

स्क्रिप्ट को बनाने के लिए Alaa Awad ने पोस्ट किया ... यह संदर्भित और संदर्भित ऑब्जेक्ट्स के स्कीमा और डेटाबेस को दिखाना चाहिए। यदि आप उपनामों के माध्यम से कई अस्थायी तालिकाओं का उपयोग कर रहे हैं (जो कभी-कभी उपयोग करते समय दिखाते हैं sys.sql_expression_dependencies), यूडीटीटी पैरामीटर या अन्य गतिशील विशेषताएं जो आपको फ़ंक्शन का उपयोग करने की आवश्यकता हो सकती हैं sys.dm_sql_referenced_entitiesया sys.dm_sql_referencing_entitiesइसके बजाय / भी।

SELECT
    DB_NAME() + '.' + OBJECT_SCHEMA_NAME(sed.referencing_id) + '.' + OBJECT_NAME(sed.referencing_id) AS [referencingObject],
    isnull(sed.referenced_server_name + '.', '') + isnull(sed.referenced_database_name + '.', DB_NAME() + '.') + isnull(sed.referenced_schema_name + '.', OBJECT_SCHEMA_NAME(sed.referencing_id) + '.') + sed.referenced_entity_name AS [missingReference]
FROM 
    sys.sql_expression_dependencies sed
WHERE 
    sed.is_ambiguous = 0
    AND OBJECT_ID(isnull(sed.referenced_database_name + '.', DB_NAME() + '.') + isnull(sed.referenced_schema_name + '.', OBJECT_SCHEMA_NAME(sed.referencing_id) + '.') + sed.referenced_entity_name) IS NULL
ORDER BY
    [referencingObject], [missingReference]

1
इनको जहां क्लॉज में जोड़ना चाहिए: / * न कि मौजूदा यूजरटाइप / AND sed.referenced_entity_name नॉट इन (SELECT [name] FROM sys.types) / Not a alias * / और sed.referenced_schema_name IS NULL नहीं है
JasonBluefire

1

SQL Server 2008 में जोड़े गए sys.sql_expression_d dependencies का उपयोग करें

CREATE PROCEDURE [dbo].[spMaintenance_Find_Broken_Dependencies]

AS
SELECT
    OBJECT_NAME(referencing_id) AS [referencingObject],
    referenced_entity_name AS [missingReference]
FROM 
    sys.sql_expression_dependencies
WHERE 
    is_ambiguous = 0
    AND OBJECT_ID(referenced_entity_name) IS NULL
ORDER BY 
    OBJECT_NAME(referencing_id), referenced_entity_name

GO

यह उपयोगी हो सकता है, हालांकि यह इतना आसान नहीं है क्योंकि स्कीमा की भी जरूरत है। मुझे ऐसे मुद्दे भी मिल रहे हैं जहाँ sys.sql_expession_d dependencies वास्तविक निर्भर तालिका के बजाय उपयोग किए गए उपनाम प्रदर्शित कर रहे हैं, जो स्पष्ट रूप से object_id () परीक्षण में विफल रहता है। अंत में यह संग्रहीत प्रक्रियाओं के लिए पैरामीटर के रूप में पारित उपयोगकर्ता-परिभाषित तालिकाओं को लाता है - जो वास्तव में उपयोगी नहीं है।
तबलू क्विजिको
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.