डाउनटाइम के बिना लोड किए गए सिस्टम 24/7 पर एक इंडेक्स कैसे जोड़ें?

दोस्तों, जनवरी के अंत में, हम “MS SQL Server Developer ” नामक एक नया पाठ्यक्रम शुरू करेंगे। इसके लॉन्च की प्रत्याशा में, हमने पाठ्यक्रम शिक्षक क्रिस्टीना कुचरोवा को एक लेखक का लेख तैयार करने के लिए कहा। यह लेख आपके लिए उपयोगी होगा यदि आपके पास 24/7 पहुंच के साथ ठेस पर एक बहुत लोकप्रिय तालिका है और अचानक आपको पता चलता है कि आपको तत्काल एक सूचकांक जोड़ने और प्रक्रिया में कुछ भी तोड़ने की आवश्यकता नहीं है।

तो क्या करें? पारंपरिक क्रिएट इंडेक्स (ONLINE = ON) विधि आपके लिए उपयुक्त नहीं है, क्योंकि, उदाहरण के लिए, यह आपके DBA के सिस्टम क्रैश और दिल के दौरे का कारण बनता है, सभी टॉपर्स आपके सिस्टम के प्रतिक्रिया समय की बारीकी से निगरानी करते हैं और अगर यह बढ़ जाता है, तो वे आपसे और आपके DBA से बात करने के लिए आते हैं। काम के लिए अपने मुआवजे के overestimated आंकड़े के बारे में।

स्क्रिप्ट और वर्णित तकनीकों का उपयोग सिस्टम पर प्रति मिनट 400K अनुरोधों, SQL Server 2012 और 2016 (एंटरप्राइज़) के संस्करणों के साथ किया गया था।

एक इंडेक्स बनाने के लिए दो बहुत अलग दृष्टिकोण हैं, जिनका उपयोग तालिका के आकार के आधार पर किया जाता है।

केस नंबर 1. एक छोटी लेकिन बहुत लोकप्रिय तालिका

50 हजार रिकॉर्ड (छोटी) की तालिका, लेकिन बहुत लोकप्रिय (प्रति मिनट कई हजार हिट)। आपको एक नया सूचकांक और न्यूनतम डाउनटाइम और मेज पर ताले की आवश्यकता है।
आवेदन में, डेटाबेस तक सभी पहुंच केवल प्रक्रियाओं के माध्यम से है।

यदि कोई त्रुटि होती है, तो एप्लिकेशन तालिका को एक्सेस करने का प्रयास करेगा।



इस सूचकांक को सीधे लागू करने में क्या समस्या है, आप पूछें? ONLINE = ON (हाँ, हम भाग्यशाली थे, और यह एक उद्यम था) के साथ वाक्य के साथ।

तथ्य यह है कि इस तरह के सक्रिय उपयोग के साथ, लॉक होने में कुछ समय लगता है (यहां तक ​​कि न्यूनतम = जो विकल्प के साथ ऑनलाइन के साथ आवश्यक है)। प्रतीक्षा की प्रक्रिया में, नए अनुरोध कतारबद्ध हो रहे हैं, कतार जमा हो रही है, सीपीयू बढ़ रहा है, डीबीए पसीना आ रहा है और डेवलपर्स की ओर घबराहट कर रहा है, जबकि एप्लिकेशन मॉनिटरिंग ग्राफ़ पर आपकी प्रतिक्रिया का समय सुचारू रूप से बढ़ना शुरू होता है, लेकिन फिर भी। एंगेजिंग के आपके उपाध्यक्ष को इस बात में दिलचस्पी है कि क्या प्रतिक्रिया समय में इस वृद्धि के कारण, किसी प्रकार की प्रणाली डाउनटाइम हो जाएगी, कि वर्ष के अंत में आवेदन की उपलब्धता का अनुमान 5 नाइन (99,999), लेकिन कम होगा? और फिर कंपनी के पास कम उपलब्धता के मामले में अनुबंध, दायित्व और भारी जुर्माना है, और निश्चित रूप से, हम प्रतिष्ठा के नुकसान के बारे में नहीं भूलेंगे।

इस दुर्भाग्यपूर्ण स्थिति से बचने के लिए हमने क्या किया है?
सिस्टम को अभी भी एक सूचकांक की आवश्यकता है।
उन्होंने इस टेबल पर वर्तमान सत्र को छोड़कर सभी से अधिकार ले लिया।
सूचकांक लागू करें।

हां, समाधान में एक माइनस है: हर कोई जो इन सेकंड में तालिका में बदल गया, उसे एक्सेस अस्वीकृत प्राप्त होगा। यदि आपका एप्लिकेशन सामान्य रूप से ऐसी स्थिति को संभालता है और डेटाबेस को क्वेरी दोहराता है, तो आपको इस विकल्प पर करीब से नज़र डालनी चाहिए। हमारी परियोजना के मामले में, इस पद्धति ने ठीक काम किया। फिर से, आप सुरक्षित रूप से ONLINE = ON को हटा सकते हैं, क्योंकि हम जानते हैं कि केवल सत्र में सूचकांक निर्माण के दौरान तालिका तक पहुंच होगी।

सूचकांक लागू करने के लिए कोड:

REVOKE EXECUTE ON [dbo].[spUserLogin] TO [User1] REVOKE EXECUTE ON [dbo].[spUserLogin] TO [User2] REVOKE EXECUTE ON [dbo].[spUserCreate] TO [User1] REVOKE EXECUTE ON [dbo].[spUserCreate] TO [User2] CREATE NONCLUSTERED INDEX IX_Users_Email_Status ON [dbo].[Users] ([Email],[Status]); GRANT EXECUTE ON [dbo].[spUserCreate] TO [User1] GRANT EXECUTE ON [dbo].[spUserCreate] TO [User2] GRANT EXECUTE ON [dbo].[spUserLogin] TO [User1] GRANT EXECUTE ON [dbo].[spUserLogin] TO [User2] 

लोड के तहत परीक्षण के दौरान प्रतिक्रिया समय और त्रुटियों का प्रतिशत की अनुसूची।



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

केस नंबर 2. बड़ी तालिका

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

2 तरीके हैं:

1. यदि आपके पास एक तालिका को संशोधित करने के लिए एक विशेष प्रक्रिया है, तो आप बस प्रक्रिया कोड को बदलते हैं ताकि नया डेटा केवल नई तालिका में डाला जाए, विलोपन दोनों से होता है, अपडेट भी दोनों पर लागू किया गया था, और चयन UNION ALL के साथ दो तालिकाओं से किया गया था।
2. यदि आपके पास कोड के कई अलग-अलग हिस्से हैं जहां आप तालिका में डेटा बदल सकते हैं, तो दो लोकप्रिय ट्रिक्स हैं: ट्रिगर्स के साथ देखें या कोड के सभी भागों को एक नई तालिका में डेटा डालने, दोनों से हटाने और दोनों तालिकाओं को अपडेट करने के लिए फिर से लिखें। ट्रिगर्स के साथ एक दृश्य एक विकल्प है जब आप दो तालिकाओं के साथ एक दृश्य बनाते हैं और इसे नाम देते हैं, अपनी वर्तमान तालिका का नाम बदलकर TableOld, और तालिका पर देखें। तब आपको स्वचालित रूप से सभी तालिका कॉल दृश्य में मिल जाती हैं, यहां नाम बदलने के साथ एक समस्या भी हो सकती है, क्योंकि स्कीमालॉक की आवश्यकता है, लेकिन नाम बहुत जल्दी से गुजरता है।

एक नई तालिका में पुनर्लेखन के बारे में थोड़ा और विस्तृत संस्करण:

1. आपके पास आदेश तालिका है, उसी योजना के साथ एक नया आदेश तालिका बनाएं, लेकिन वांछित सूचकांक के साथ। इसी समय, यदि आप इंडेंटिटी का उपयोग करते हैं, तो आपको नई तालिका में पहचान का पहला मूल्य निर्धारित करने की आवश्यकता है पुरानी तालिका में अधिकतम मूल्य के बराबर होने के लिए + बदलाव का चरण या अंतर जिसे आप आदेशों में अधिकतम मूल्य से विचलन करने के लिए खर्च कर सकते हैं।
2. एक ऑर्डर दृश्य बनाएं, जिसके अंदर ऑर्डर्स यूनिअन ऑल ऑर्डर से एक चयन
3. दृश्य से डेटा का चयन करने के लिए सभी प्रक्रियाओं / कॉल को बदलें, इसे आदेश में डालें, दोनों तालिकाओं को हटाएं और संशोधित करें।
4. पुरानी तालिका से डेटा को नए में माइग्रेट करें, उदाहरण के लिए, इस तरह:
   
   

    DECLARE @rowcount INT, @batchsize INT = 4999; SET IDENTITY_INSERT dbo.OrdersNew ON; SET @rowcount = @batchsize; WHILE @rowcount = @batchsize BEGIN BEGIN TRY DELETE TOP (@batchsize) FROM dbo.Orders OUTPUT deleted.Id ,deleted.Column1 ,deleted.Column2 ,deleted.Column3 INTO dbo.OrdersNew (Id ,Column1 ,Column2 ,Column3); SET @rowcount = @@ROWCOUNT; END TRY BEGIN CATCH SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_MESSAGE() AS ErrorMessage; THROW; END CATCH; END; SET IDENTITY_INSERT dbo.OrdersNew OFF; 

   
   
5. माइग्रेशन से पहले संस्करण में सभी प्रक्रियाएं लौटाएं - एक तालिका के साथ। यह परिवर्तन के माध्यम से या प्रक्रियाओं के निष्कासन और निर्माण के माध्यम से किया जा सकता है (फिर अधिकारों के बारे में मत भूलना), और आप खाली तालिका और दृश्य को हटाते हुए नई तालिका का नाम बदल सकते हैं।

चरण 2 में, यह संभव था, यदि लोडिंग की अनुमति देता है, मुख्य तालिका का नाम बदलने के लिए -> आदेशों और आदेशों -> आदेशों और आदेशों को देखने के लिए स्वयं सभी आदेशों का आदेश दें, तो आपको उन सभी स्थानों को बदलने की आवश्यकता नहीं है जहां तालिका से चयन होता है।

जब एक टेबल से दूसरे टेबल पर चलते हैं, तो डेटा खंडित हो जाएगा।
यदि तालिका में परिवर्तन किया जा रहा है, तो इसे पढ़ने के लिए सक्रिय रूप से उपयोग किया जाता है, लेकिन इसमें डेटा शायद ही कभी बदलता है, आप फिर से ट्रिगर्स का उपयोग कर सकते हैं - 3 डी तालिका में सभी परिवर्तनों की एक प्रति लिखें - तालिका से डेटा को bcp आउट और bcp के माध्यम से स्थानांतरित करें (या बल्क सम्मिलित करें) , डेटा ट्रांसफर के बाद उस पर अनुक्रमित बनाएं और फिर परिवर्तन लॉग के साथ तालिका से परिवर्तन लागू करें - और एक तालिका को दूसरे पर स्विच करें - वर्तमान एक, इसका नाम बदलकर टेबलऑल्ड, और नया टेबल टेबल से टेबल तक।

इस स्थिति में त्रुटियों की संभावना थोड़ी अधिक है, इसलिए इस मामले में परिवर्तन और विभिन्न स्विचिंग मामलों के आवेदन का परीक्षण करें।

वर्णित विकल्प केवल वही नहीं हैं। वे मेरे द्वारा एक अत्यधिक लोड किए गए SQL सर्वर डेटाबेस पर उपयोग किए गए थे और आवेदन के दौरान समस्याओं का कारण नहीं बने, जिससे हमारी डीबीए टीम प्रसन्न हुई। इस तरह के बाउंसिंग को आमतौर पर एक केमर मोड के साथ आधार की आवश्यकता नहीं होती है, जब आप कम से कम गतिविधि के घंटों में सुरक्षित रूप से परिवर्तन लागू कर सकते हैं। वर्णित दृष्टिकोण का उपयोग करने वाले प्रोजेक्ट के उपयोगकर्ता यूएसए और यूरोप में स्थित हैं और सक्रिय रूप से कार्यदिवसों और सप्ताहांतों पर एप्लिकेशन का उपयोग करते हैं, और जिन तालिकाओं पर परिवर्तन लागू किए गए थे, वे लगातार काम में उपयोग किए जाते हैं। अधिक "शांत" वस्तुओं को आमतौर पर Redgate टूलकिट के माध्यम से उत्पन्न स्वचालित स्क्रिप्ट द्वारा संशोधित किया गया था, क्योंकि डेवलपर द्वारा और DBAs में से एक की समीक्षा की गई थी।

सभी को अच्छा! टिप्पणियों में साझा करें यदि आपने इनमें से किसी भी तरीके का उपयोग किया है या अपनी विधि का वर्णन करें! हम आपको एक खुले पाठ और हमारे नए पाठ्यक्रम "एमएस SQL ​​सर्वर डेवलपर" के एक खुले दिन के लिए भी आमंत्रित करते हैं।