कई डेटाबेस व्यवस्थापक स्वयं को SQL सर्वर रिपोर्टिंग सेवाओं (SSRS), या कम से कम SSRS के लिए आवश्यक बैकएंड डेटाबेस के उदाहरणों का समर्थन करते हुए पाते हैं। वर्षों से SSRS को SQL सर्वर की स्थापना के साथ बंडल किया गया था, जिसने उत्पाद के लिए लाइसेंसिंग और समर्थन के बारे में कुछ भ्रम को जोड़ने में मदद की, इसलिए SSRS 2017 से शुरुआत करते हुए, रिपोर्टिंग सेवाओं के लिए इंस्टॉलेशन पैकेज एक अलग डाउनलोड है।

इस आलेख में ऐसे कई क्षेत्रों को शामिल किया जाएगा जिनके बारे में डेटाबेस व्यवस्थापकों को एक रिपोर्टिंग सेवा स्थापना को ठीक से लाइसेंस देने, पुनर्प्राप्त करने और ट्यून करने के लिए जागरूक होने की आवश्यकता है। ये विषय SQL सर्वर रिपोर्टिंग सेवाओं के साथ-साथ Power BI रिपोर्ट सर्वर दोनों पर लागू होते हैं।

लाइसेंसिंग

SSRS की स्थापना और समर्थन भ्रमित करने वाला हो सकता है। रिपोर्टिंग सेवा को एक समर्पित सर्वर पर, SQL सर्वर के समान इंस्टेंस पर, या स्केल-आउट परिनियोजन (केवल एंटरप्राइज़ संस्करण) में एक स्टैंडअलोन इंस्टेंस के रूप में स्थापित किया जा सकता है। प्रत्येक उदाहरण जहां SSRS को उत्पादन में स्थापित किया जाता है, उसके लिए SQL सर्वर लाइसेंस की आवश्यकता होती है, साथ ही SQL सर्वर के उदाहरण को लाइसेंस देने की आवश्यकता होती है जहाँ ReportServer और ReportServerTempDB डेटाबेस रहते हैं।

जिस तरह से मैं यह बताना चाहता हूं कि रिपोर्टिंग सेवाओं को लाइसेंस कैसे देना है, रिपोर्टिंग सेवा के बारे में एक ऐसे अनुप्रयोग के रूप में सोचना है जो बैक एंड पर SQL सर्वर का उपयोग करता है। SSRS के शुरुआती दिनों में, इंटरनेट सूचना सेवाओं (IIS) को स्थापित और कॉन्फ़िगर करने की भी आवश्यकता थी। SSRS 2008 उस घटक को रिपोर्टिंग सेवा मॉड्यूल में लाया। लाइसेंस के कारण SSRS और MSSQL को एक ही उदाहरण पर स्थापित करना बहुत आम है और यह छोटे कार्यान्वयन के लिए अच्छा काम कर सकता है। बड़े परिनियोजन के लिए, एक समेकित SQL सर्वर पर ReportServer और ReportServerTempDB के साथ एक समर्पित रिपोर्टिंग सेवा सर्वर देखना आम बात है। बहुत बड़े इंस्टॉलेशन के लिए, स्केल-आउट परिनियोजन का उपयोग रिपोर्टिंग सर्वर सेवा के लोड संतुलन को प्रदान करने के लिए किया जाता है। स्केल-आउट परिनियोजन में, फ़ार्म में प्रत्येक इंस्टेंस को लाइसेंस प्राप्त होना चाहिए।

रिकवरी

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

ReportServer और ReportServerTempDB डेटाबेस SQL सर्वर डेटाबेस हैं और अन्य उपयोगकर्ता डेटाबेस की तरह, एक नियमित बैकअप प्रक्रिया का हिस्सा होना चाहिए। रिपोर्टसेवर को पूर्ण पुनर्प्राप्ति मॉडल का उपयोग करना चाहिए जबकि रिपोर्टसेवरटेम्पडीबी साधारण पुनर्प्राप्ति मॉडल का उपयोग कर सकता है। तकनीकी रूप से, ReportServerTempDB को किसी आपदा की स्थिति में एक स्क्रिप्ट द्वारा फिर से बनाया जा सकता है, हालाँकि रिपोर्टिंग सेवाएँ बिना ReportServerTempDB के प्रारंभ नहीं हो सकती हैं। डेटाबेस को फिर से बनाने के लिए स्क्रिप्ट की तलाश करने के बजाय, DBA डेटाबेस को पुनर्स्थापित करने से परिचित हैं। सिस्टम डेटाबेस tempdb के विपरीत, ReportServerTempDB स्टार्टअप पर फिर से नहीं बनाया जाता है। DBA के लिए सबसे अच्छा अभ्यास वास्तव में किसी अन्य उपयोगकर्ता डेटाबेस की तरह केवल ReportServer और ReportServerTempDB का इलाज करना है।

ऐसी कॉन्फ़िगरेशन फ़ाइलें हैं जो एप्लिकेशन सेटिंग्स को संग्रहीत करती हैं जिनका बैकअप भी लिया जाना चाहिए। ये आपके OS-स्तर के बैकअप द्वारा कवर किए जा सकते हैं; हालांकि, डीबीए को यह सुनिश्चित करना चाहिए कि प्रारंभिक कॉन्फ़िगरेशन के बाद और/या किसी कस्टम एक्सटेंशन को लागू करने के बाद इन फ़ाइलों का बैक अप लिया गया है। इन फाइलों में निम्न शामिल हैं:

Rsreportserver.config
Rssvrpolicy.config
Rsmgrpolicy.config
Reportingservciesservice.exe.config
वेब.कॉन्फ़िगरेशन
Machine.config

अपनी रिपोर्ट डिज़ाइनर फ़ाइलों का बैकअप लेने पर विचार जैसे; .rdl, .rds, .dv, .ds, rptproj, और .sln फ़ाइलें दी जानी चाहिए।

ट्यूनिंग विकल्प

ट्यूनिंग SSRS किसी भी अन्य एप्लिकेशन की तरह है। उपयोगकर्ता डेटाबेस के साथ संचार करने वाले एप्लिकेशन सर्वर से रिपोर्ट निष्पादित कर रहे हैं। बड़ा अंतर यह है कि आपके पास अपने डेटाबेस के साथ एक एप्लिकेशन सर्वर (रिपोर्टिंग सेवाएं) है, लेकिन रिपोर्ट में अन्य उपयोगकर्ता डेटाबेस से कनेक्ट होने वाले डेटा स्रोत हैं। डीबीए को रिपोर्टिंग सेवाओं के बुनियादी ढांचे के समग्र स्वास्थ्य के साथ-साथ वास्तविक रिपोर्ट को ट्यून करना चाहिए।

रिपोर्टिंग सेवा इंफ्रास्ट्रक्चर

ReportServer और ReportServerTempDB के लिए डिस्क विलंबता बहुत महत्वपूर्ण है। कार्यभार के आधार पर, उन डेटाबेस को तेज़ डिस्क पर रखने की आवश्यकता हो सकती है। रिपोर्ट परिणामों का संचय ReportServerTempDB डेटाबेस में संग्रहीत किया जाता है और I/O प्रदर्शन यहां एक समस्या बन सकता है।

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

स्नैपशॉट का लाभ उठाएं जहां वे समझ में आते हैं। यदि आपके पास ऐसी रिपोर्टें हैं जो दिन पुराने डेटा का उपयोग कर रही हैं, तो स्नैपशॉट का उपयोग करने पर विचार करें ताकि उस रिपोर्ट के बाद के दृश्य पूरी रिपोर्ट को फिर से जेनरेट करने के बजाय स्नैपशॉट का उपयोग कर सकें।

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

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

सामान्य ट्यूनिंग

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

उदाहरण के लिए, निगरानी और आधारभूत बनाने के अलावा, उद्योग-स्वीकृत सर्वोत्तम प्रथाओं को लागू किया जाना चाहिए। मैंने पिछले लेख, सामान्य SQL सर्वर दुर्घटनाओं में मेमोरी सेटिंग्स, इंडेक्स रखरखाव, सांख्यिकी, MAXDOP, और समानांतरवाद के लिए लागत सीमा को कवर किया है।

रिपोर्ट को तेज़ी से चलाने का असली जादू उस रिपोर्ट के लिए ऑप्टिमाइज़ करना है। एक रिपोर्ट अनिवार्य रूप से सिर्फ एक और प्रश्न है। धीमी रिपोर्ट के लिए ट्यून करने के लिए, इसका आमतौर पर मतलब है कि आपको उस विशिष्ट रिपोर्ट के लिए इंडेक्स बनाने या रिपोर्ट के भीतर कोड को ट्यून करने की आवश्यकता है। यदि ये ऐसी रिपोर्टें हैं जो OLTP डेटाबेस को प्रभावित कर रही हैं, तो रिपोर्ट के लिए अनुक्रमणिका बनाना OLTP सिस्टम को अधिक स्थान का उपयोग करके, अद्यतन, डालने और हटाने के लिए अतिरिक्त I/O उत्पन्न करके और उन अनुक्रमणिकाओं को बनाए रखने के लिए अतिरिक्त ओवरहेड को प्रभावित कर सकता है। आपको जोखिम बनाम इनाम को संतुलित करना होगा। कुछ ग्राहक लेन-देन संबंधी प्रतिकृति का उपयोग करके रिपोर्टिंग डेटाबेस को OLTP से अलग कर सकते हैं और यह OTLP डेटाबेस को प्रभावित किए बिना रिपोर्टिंग डेटाबेस को अनुक्रमित करने की अनुमति देता है।

यद्यपि आप ExecutionLog का उपयोग करके रिपोर्ट उपयोग को ट्रैक कर सकते हैं, आपको उच्च लागत और ट्यूनिंग अवसरों के लिए लंबे समय तक चलने वाले प्रश्नों के लिए उपयोगकर्ता डेटाबेस इंस्टेंस पर शोध करने की आवश्यकता होगी। DMV और क्वेरी स्टोर भी एक बड़ी मदद हैं, लेकिन SQL संतरी जैसा एक निगरानी उपकरण बहुत अधिक शक्तिशाली और लचीला हो सकता है। SQL संतरी में "रिपोर्टिंग सेवा डैशबोर्ड" नहीं है, लेकिन आप SSRS ईवेंट के कैलेंडर दृश्य बना सकते हैं, SSRS गतिविधि पर ध्यान केंद्रित करने के लिए अंतर्निहित मीट्रिक और रिपोर्ट को आसानी से फ़िल्टर कर सकते हैं, और सटीक पहलुओं की निगरानी के लिए मजबूत सलाहकार शर्तें बना सकते हैं। रिपोर्टिंग सेवाएं जिनकी आप परवाह करते हैं (और कोई भी शोर जो आप नहीं करते हैं)। यदि आप SQL सर्वर मशीन पर SSRS नहीं चला रहे हैं, तब भी आप वर्तमान और ऐतिहासिक प्रक्रिया- और सेवा-स्तरीय गतिविधि में समृद्ध प्रदर्शन अंतर्दृष्टि प्राप्त करने के लिए Win Sentry का उपयोग कर सकते हैं।

निष्कर्ष

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