संग्रहित प्रक्रियाओं को डीबग करने का सबसे अच्छा तरीका क्या है (और स्प्रॉक्स लिखना जो डीबग करना आसान है)?

Question

डिबगिंग के दर्द को कम करने वाले स्पॉक्स बनाने के लिए अच्छी पद्धतियां क्या हैं? और संग्रहित प्रक्रियाओं को डीबग करने के लिए वहां कौन से टूल्स हैं?

शायद सबसे महत्वपूर्ण बात यह है कि त्रुटियों में क्या त्रुटियां हो रही हैं और कोड में नहीं होने के संकेत हैं? मुझे आशा है कि मैं बोर्ड पर भी बहुत खराब नहीं हूं। उपर्युक्त में से किसी के जवाब के लिए वोट। धन्यवाद।

इसके लायक होने के लिए, मैं .NET पर्यावरण, SQL सर्वर में काम करता हूं।

Answer 1

मैंने सफलतापूर्वक उपयोग किए गए कुछ पैटर्न 'डायग्नोस्टिक' या 'टेस्ट' मोड और लॉगिंग हैं।

परीक्षण या डायग्नोस्टिक मोड उपयोगी होते हैं जब आप गतिशील SQL निष्पादन कर रहे होते हैं। सुनिश्चित करें कि आप देख सकते हैं कि आप निष्पादित करने जा रहे हैं। यदि आपके पास ऐसे क्षेत्र हैं जहां आपको त्रुटियों की जांच करनी है (या चाहिए) पर्याप्त विवरण वाले तालिका में लॉगिंग करने पर विचार करें ताकि आप निदान कर सकें कि क्या हो रहा है।

Answer 2

आप Sql सर्वर डिबगिंग उपयोग कर सकते हैं, लेकिन मैं पाया है कि (आदि स्थानीय सर्वर पर डिबगिंग,) कुछ भी में दर्द लेकिन स्थितियों का सबसे सीधा किया जाना है। मुझे अभी तक प्रिंट स्टेटमेंट से कुछ बेहतर नहीं मिला है, इसलिए मैं इस धागे को ब्याज के साथ निगरानी रखूंगा।

Answer 3

उपकरण के लिए, आप एसपी डीबग करने के लिए विजुअल स्टूडियो का उपयोग कर सकते हैं। यदि संग्रहीत प्रो में लंबे तर्क हैं, तो आप इसे पुन: सक्रिय कर सकते हैं, अलग संग्रहित प्रो बना सकते हैं, और इसे अपने मुख्य संग्रहित प्रो से कॉल कर सकते हैं। यह आपके परीक्षण को कम करने में भी मदद करेगा, और आपको यह जानने में मदद मिलेगी कि प्रश्नों का कौन सा हिस्सा गलत है।

Answer 4

TSQLUnit

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

उदाहरण के लिए, यदि आप एक गाड़ी संग्रहीत proc है तो आप कुछ इकाई परीक्षण लिखने को समझने के लिए कि यह कैसे विफल हो रहा है कर सकते हैं। साथ ही, यदि आप अपने एसक्यूएल कोड में बदलाव करते हैं तो आप मान्य कर सकते हैं कि आपके परिवर्तनों ने कुछ और नहीं तोड़ दिया है या कम से कम आपको बताएं कि कोई समस्या कहां है।

अगर कुछ तो परीक्षण करने के लिए यह एक अच्छा संकेत है कि अपने संग्रहीत proc बहुत ज्यादा कर रही हो सकता है और अगर यह अधिक ध्यान केंद्रित करने और लक्षित procs में टूट जा रहे थे फायदा हो सकता है हो सकता है मुश्किल है। इन procs तो डिबग करने के लिए अपेक्षाकृत आसान हो और लंबे समय में बनाए रखना चाहिए।

Answer 5

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

LEFT JOIN 

मैं इससे पहले कि हम पता लगा कि यह मेरे छोटे, पहुंचे संग्रहीत प्रक्रिया परिवर्तन किया गया 20 मिनट के लिए एक महत्वपूर्ण पेज तोड़ दिया।

और सुनिश्चित करें कि आप अपने प्रक्रियाओं का परीक्षण जब आप कोई परिवर्तन करते हैं। ऐसा करने के लिए, मैं प्रक्रिया की टिप्पणियों में एक सरल परीक्षण क्वेरी डालना पसंद करता हूं।

मैं एक जोड़ें: Obvisouly, मैं डिबग करने के लिए SQL सर्वर 2005 प्रक्रियाओं के लिए (आईडीई या डिबगर के बिना) उन्हें आसान बनाने के लिए :-(

/************************************ 
    MyProcName 

    Test: 
    ----- 
    exec MyProcName @myParam 
*************************************/ 

Answer 6

एक तकनीक मैं संग्रहित प्रक्रियाओं में उपयोग यह आज नहीं कर पायी इनपुट @Debug = 0 नामित पैरामीटर प्रक्रिया के लिए पैरामीटर सूची के अंत में (बंद = 0 डिफ़ॉल्ट रूप से)

मैं तो जोड़ते हैं (@Debug = 1) प्रिंट '...';।

किसी भी उपयोगी आंतरिक मूल्य आदि प्रदर्शित करने के लिए कुंजी जंक्शन पर कोड में बयान

हाँ, यह "पुराने स्कूल" है और डिबगर जिनकी मदद से आप "कोड चलना" महान हैं - लेकिन इस (अपने ही आईडीई के बिना किसी को डिबगिंग सहित) किसी भी एसक्यूएल उपकरण से किसी के लिए भी काम करता है।

रॉन

Answer 7

एक और तकनीक मैं दोनों सरल लॉग उत्पादन और डीबगिंग के लिए उपयोग की प्रक्रिया के शीर्ष पर एक मेज चर बनाने के लिए है:

--************************************************************************** 
    -- Create a log table variable to store messages to be returned to the 
    -- calling application. 
    --************************************************************************** 
    declare @log    as table (msg varchar(MAX)); 

then 

    insert into @log values ('Inserted a new DVO Order into IRMA, order id: [' + convert(varchar(10), @@IDENTITY) + ']'); 
etc. 

then ... 

    select msg from @log; 
end 

प्रक्रिया के अंत में

- इस पर निर्भर करता है कॉलिंग एप्लिकेशन आपके प्रक्रिया कॉल से आउटपुट कितनी अच्छी तरह से लॉग करता है, लेकिन जिस ऐप को मैंने लिखा है वह सब लॉग करता है। :-)

Answer 8

यह वह उत्तर नहीं हो सकता है जिसे आप ढूंढ रहे हैं, लेकिन यदि आप पहले से ही नेट नेटवर्क में हैं, तो LINQtoSQL ने मेरे द्वारा लिखने/उपयोग/डिबग करने की आवश्यकता वाले संग्रहित प्रोसेस की मात्रा को बहुत कम कर दिया है।

डिबगिंग एसक्यूएल की कठिनाई कारणों LINQ में व्यापार तर्क प्रोग्रामिंग में से एक है मेरी नई इच्छित अभ्यास है।

Answer 9

मैंने SQL प्रोसेस को डीबग करने के लिए विभिन्न वातावरण और तकनीकों का उपयोग करने पर बहुत सारे सुझावों को देखा है, लेकिन किसी ने DBFit का उल्लेख नहीं किया है। आप Fit और FitNesse से परिचित नहीं हैं, तो अपने आप को एक एहसान करो और उन्हें ढूंढ निकालेंगे। इन तीन उपकरणों का उपयोग करके आप जल्दी से अपने आप को स्वीकृति परीक्षण है कि आप जानते हुए भी आप दण्ड मुक्ति के साथ refactor कर सकते हैं मन की शांति दे देंगे की एक पूरी सूट बना सकते हैं।

DBFit बस फ़िट फिक्स्चर कि एक डेटाबेस व्यायाम करने के लिए इस्तेमाल किया जा सकता की एक श्रृंखला है। फिटनेस का उपयोग करके आप अपनी संग्रहित प्रो पर कॉल के कई क्रमपरिवर्तन लिख सकते हैं क्योंकि आप परीक्षण करना चाहते हैं।

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

Answer 10

एसक्यूएल सर्वर 2008 प्रबंधन स्टूडियो के एकीकृत डीबगर बनाया कदम के लिहाज से एक चिंच डिबगिंग

Answer 11

यह एक निजी पसंद हो सकता है (तुलना में जूडो पता लगाना कैसे VS2005 + डिबग करने के लिए एसक्यूएल प्राप्त करने के लिए करने के लिए आवश्यक), लेकिन मुझे यह बहुत खोजने के एसक्यूएल प्रश्नों को पढ़ने में मुश्किल है जो सभी एक लंबी लाइन पर थप्पड़ मार रहे हैं।

SELECT 
    [Fields] 
FROM 
    Table 
WHERE 
    x = x 

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

अपने साथी डेवलपर्स पर आसान बनें ... एक पंक्ति पर SQL क्वेरी के 800 वर्णों को क्रैक न करें। यदि डेटाबेस फ़ील्ड नाम या डेटाटाइप बदलता है और कोई आपको ईमेल नहीं करता है तो आप बाद में धन्यवाद देंगे।

Answer 12

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

यानी।

Select * from LogEvent where BatchId = 'blah' 

नमूना कॉल

EXEC LogEvent @Source='MyProc', @Type='Start' 
, @Comment='Processed rows',@Value=50, @BatchId = @batchNum 

मुख्य प्रोक

CREATE PROCEDURE [dbo].[LogEvent] 
    @Source varchar(50), 
    @Type varchar(50), 
    @Comment varchar(400), 
    @Value decimal = null, 
    @BatchId varchar(255) = 'BLANK' 
AS 

IF @BatchId = 'BLANK' 
    SET @BatchId = NEWID() 

    INSERT INTO dbo.Log 
    (Source, EventTime, [Type], Comment, [Value],BatchId) 
    VALUES 
    (@Source, GETDATE(), @Type, @Comment, @Value,@BatchId) 

आगे चल यह CLR का लाभ उठाने और SQL के माध्यम से log4net की तरह कुछ बुला को देखने के लिए अच्छा होगा। चूंकि हमारा एप्लिकेशन कोड Log4Net का उपयोग करता है, इसलिए प्रक्रियाओं के एसक्यूएल पक्ष को उसी आधारभूत संरचना में अंतरित करना फायदेमंद होगा।

Answer 13

मैं दृढ़ता से सुझाव दूंगा कि आप एसक्यूएल प्रबंधन स्टूडियो में निर्मित टूलिंग पर एक नज़र डालें।

मैं इसके बारे में यहाँ एक बहुत विस्तृत ब्लॉग पोस्ट में लिखा है:

http://www.diaryofaninja.com/blog/2010/11/23/debugging-sql-queries-function-amp-stored-procedures-with-sql-management-studio

मूल रूप से यह का सार है कि आप आप अपने संग्रहीत प्रक्रिया निष्पादित करने के लिए एसक्यूएल क्वेरी दर्ज है, और बदले F5 दबा या मारने की विस्मयादिबोधक, आप प्ले बटन दबाते हैं और F10 और F11 का उपयोग करके अपने संग्रहित प्रोसेस में कदम उठाते हैं।

बहुत ही आसान - और कोई भी इसका उपयोग नहीं करता है।