SQL सर्वर 2019 की पहली CTP में नया क्या है

SQL सर्वर 2019 के CTP का पहला संस्करण 24 सितंबर को प्रस्तुत किया गया था, और मुझे यह कहना चाहिए कि यह सभी प्रकार के सुधारों और नई सुविधाओं से भरा है (जिनमें से कई एज़्योर SQL डेटाबेस में पूर्वावलोकन रूप में पाए जा सकते हैं)। मेरे पास इसे पहले जानने का एक असाधारण अवसर था, जिसने मुझे परिवर्तनों की अपनी समझ का विस्तार करने की अनुमति दी, यहां तक ​​कि सतही रूप से। आप SQL सर्वर टीम और अद्यतन किए गए दस्तावेज़ से नवीनतम प्रकाशन भी पढ़ सकते हैं।

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

उत्पादकता

टेबल चर: विलंबित योजना भवन

टेबल चर की बहुत अच्छी प्रतिष्ठा नहीं है, ज्यादातर लागत अनुमान के क्षेत्र में। डिफ़ॉल्ट रूप से, SQL सर्वर मानता है कि एक तालिका चर में केवल एक पंक्ति हो सकती है, जो कभी-कभी योजना की अपर्याप्त पसंद की ओर ले जाती है जब चर में कई गुना अधिक पंक्तियाँ होंगी। विकल्प (RECOMPILE) आमतौर पर एक वर्कअराउंड के रूप में उपयोग किया जाता है, लेकिन इसके लिए कोड परिवर्तन की आवश्यकता होती है और यह संसाधनों के संबंध में, हर बार पुनर्निर्माण करने के लिए बेकार है, जबकि लाइनों की संख्या सबसे अधिक बार एक ही होती है। पुनर्निर्माण का अनुकरण करने के लिए, ट्रेस ध्वज 2453 पेश किया गया था, लेकिन इसे ध्वज के साथ एक लॉन्च की भी आवश्यकता होती है, और केवल तब काम करता है जब लाइनों में एक महत्वपूर्ण परिवर्तन होता है।

संगतता स्तर 150 पर, तालिका चर मौजूद होने पर आस्थगित निर्माण किया जाता है और क्वेरी योजना तब तक नहीं बनाई जाती है जब तक कि तालिका चर एक बार पॉपुलेटेड न हो जाए। लागत का अनुमान तालिका के चर के पहले उपयोग के परिणामों के आधार पर लगाया जाएगा, आगे पुनर्निर्माण के बिना। यह सटीक लागत प्राप्त करने के लिए निरंतर पुनर्निर्माण के बीच एक समझौता है, और निरंतर लागत के साथ पुनर्निर्माण की पूर्ण अनुपस्थिति 1. यदि पंक्तियों की संख्या अपेक्षाकृत स्थिर रहती है, तो यह एक अच्छा संकेतक है (और अगर संख्या 1 से अधिक हो तो भी बेहतर), लेकिन कम लाभदायक हो सकता है अगर पंक्तियों की संख्या में बड़ी भिन्नता है।

मैंने एक हालिया लेख Tabular Variables: Delayed Build in SQL Server में एक गहरा विश्लेषण प्रस्तुत किया, और ब्रेंट ओजेर ने इस लेख के बारे में फास्ट टेबुलर वेरिएबल्स (और नए पैरामीटर विश्लेषण समस्याओं) में भी बात की।

स्ट्रिंग मोड में मेमोरी आवंटन प्रतिक्रिया

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

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

लाइन-बाय-लाइन स्टोरेज के लिए बैच मोड

SQL सर्वर 2012 के साथ शुरू करना, कॉलम इंडेक्स के साथ तालिकाओं को क्वेरी करना बेहतर बैच मोड प्रदर्शन से लाभ हुआ है। प्रदर्शन में सुधार एक क्वेरी प्रोसेसर के कारण होता है जो पंक्ति-वार प्रसंस्करण के बजाय बैच निष्पादित करता है। पैकेजों में स्टोरेज कोर द्वारा लाइनों को भी संसाधित किया जाता है, जो समसामयिक विनिमय विवरणों से बचा जाता है। पॉल व्हाइट ( @SQL_Kiwi ) ने मुझे याद दिलाया कि यदि आप बैच संचालन को संभव बनाने के लिए स्तंभ भंडारण के साथ एक खाली तालिका का उपयोग करते हैं, तो संसाधित पंक्तियों को एक अदृश्य विवरण द्वारा पैकेट में एकत्र किया जाएगा। हालाँकि, यह क्रैक बैच प्रोसेसिंग से प्राप्त किसी भी सुधार को नकार सकता है। इसके बारे में कुछ जानकारी स्टैक एक्सचेंज के जवाब में है ।

संगतता स्तर 150 पर, SQL Server 2019 स्वचालित रूप से कुछ मामलों में मध्य मैदान के रूप में बैच मोड का चयन करेगा, भले ही कोई कॉलम इंडेक्स न हो। आप सोच सकते हैं कि सिर्फ कॉलम इंडेक्स और हैट ही क्यों? या ऊपर उल्लिखित बैसाखी का उपयोग करना जारी रखें? पंक्ति भंडारण के साथ पारंपरिक वस्तुओं के लिए भी इस दृष्टिकोण को बढ़ाया गया था, क्योंकि स्तंभ अनुक्रमणिका, कई कारणों से, हमेशा संभव नहीं होती हैं, जिसमें कार्यात्मक सीमाएं (उदाहरण के लिए, ट्रिगर), अत्यधिक लोड किए गए अपडेट या हटाने के संचालन के दौरान ओवरहेड, और तृतीय-पक्ष निर्माताओं से समर्थन की कमी शामिल है। और उस बैसाखी से कुछ भी अच्छा होने की उम्मीद नहीं की जा सकती।
मैंने 10 मिलियन पंक्तियों और एक पूर्णांक स्तंभ पर एक क्लस्टर इंडेक्स के साथ एक बहुत ही सरल तालिका बनाई और इस क्वेरी को चलाया:

SELECT sa5, sa2, SUM(i1), SUM(i2), COUNT(*) FROM dbo.FactTable WHERE i1 > 100000 GROUP BY sa5, sa2 ORDER BY sa5, sa2; 

योजना स्पष्ट रूप से संकुल अनुक्रमणिका खोज और संगामिति को दिखाती है, लेकिन स्तंभ अनुक्रमणिका के बारे में एक शब्द नहीं (जैसा कि सेंट्रीऑन प्लान दिखाता है):



लेकिन अगर आप थोड़ा गहरा खुदाई करते हैं, तो आप देख सकते हैं कि लगभग सभी ऑपरेटरों को बैच मोड में निष्पादित किया गया था, यहां तक ​​कि छंटाई और स्केलर गणना भी:



आप डेटाबेस कॉन्फ़िगरेशन बदलकर या क्वेरी में DISALLOW_BATCH_MODE प्रॉम्प्ट का उपयोग करके कम संगतता स्तर पर रहकर इस सुविधा को अक्षम कर सकते हैं:

 SELECT … OPTION (USE HINT ('DISALLOW_BATCH_MODE')); 

इस स्थिति में, एक अतिरिक्त एक्सचेंज ऑपरेटर दिखाई देता है, सभी ऑपरेटरों को लाइन-बाय-लाइन मोड में निष्पादित किया जाता है, और क्वेरी निष्पादन का समय लगभग तीन गुना हो जाता है।



एक निश्चित स्तर तक, आप इसे आरेख में देख सकते हैं, लेकिन योजना के विवरण ट्री में आप एक चयन स्थिति के प्रभाव को भी देख सकते हैं जो छंटाई होने तक पंक्तियों को बाहर करने में असमर्थ है:



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

APPROX_COUNT_DISTINCT

यह नया समुच्चय फ़ंक्शन डेटा वेयरहाउसिंग परिदृश्यों के लिए है और COUNT (DISTINCT ()) के बराबर है। हालांकि, वास्तविक मात्रा निर्धारित करने के लिए महंगा छँटाई करने के बजाय, नया फ़ंक्शन अपेक्षाकृत सटीक डेटा प्राप्त करने के लिए आँकड़ों पर निर्भर करता है। आपको यह समझने की आवश्यकता है कि त्रुटि सटीक राशि के 2% के भीतर है, और 97% मामलों में जो उच्च-स्तरीय एनालिटिक्स के लिए आदर्श हैं, ये संकेतक पर प्रदर्शित मान हैं या त्वरित अनुमान के लिए उपयोग किए जाते हैं।

मेरे सिस्टम पर, मैंने पूर्णांक स्तंभों के साथ एक तालिका बनाई जिसमें 100 से 100,000 की सीमा में अद्वितीय मान और 100 से 100,000 की सीमा में अद्वितीय मानों के साथ पंक्ति कॉलम थे। इसमें पहले प्राथमिक क्लस्टर कुंजी को छोड़कर कोई अनुक्रमणिका नहीं थी। पूर्णांक स्तंभ। इन स्तंभों पर COUNT (DISTINCT ()) और APPROX_COUNT_DISTINCT () निष्पादित करने के परिणाम हैं, जहां से आप थोड़ी विसंगतियां (लेकिन हमेशा 2% के भीतर) देख सकते हैं:



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



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



अगर मैं बड़ी तालिकाओं, SQL सर्वर के लिए कम स्मृति, उच्च संगामिति, या ऊपर के कुछ संयोजन के लिए शायद अंतर अधिक महत्वपूर्ण होगा।

एक क्वेरी के भीतर संगतता स्तर का उपयोग करने के लिए टिप्स

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



संक्षेप में: ट्रेस झंडे को याद करने की कोई आवश्यकता नहीं है, या आश्चर्य है कि क्या आपको इस बारे में चिंता करने की ज़रूरत है कि क्या क्वेरी ऑप्टिमाइज़र के लिए TF 4199 पैच वितरित किया गया है, या इसे किसी अन्य सर्विस पैक द्वारा रद्द कर दिया गया है। ध्यान दें कि इन अतिरिक्त युक्तियों को हाल ही में SQL Server 2017 के लिए संचयी अद्यतन # 10 में भी जोड़ा गया है (विवरण के लिए पेड्रो लोपेज़ का ब्लॉग देखें)। आप निम्न कमांड के साथ सभी उपलब्ध संकेत देख सकते हैं:

 SELECT name FROM sys.dm_exec_valid_use_hints; 

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

में समस्या निवारण करना

सरलीकृत डिफ़ॉल्ट प्रोफाइलिंग

इस सुधार को समझने के लिए याद रखने के लिए कुछ बिंदुओं की आवश्यकता होती है। SQL सर्वर 2014 ने DMV sysinos_exec_query_profiles दृश्य पेश किया, जो उपयोगकर्ता को क्वेरी के सभी हिस्सों के बारे में नैदानिक ​​जानकारी एकत्र करने के लिए क्वेरी को निष्पादित करने की अनुमति देता है। एकत्रित जानकारी क्वेरी के पूरा होने के बाद उपलब्ध हो जाती है और आपको यह निर्धारित करने की अनुमति देती है कि कौन से ऑपरेटर वास्तव में मुख्य संसाधनों और क्यों खर्च करते हैं। कोई भी उपयोगकर्ता जो किसी विशेष अनुरोध को पूरा नहीं करता है, वह किसी भी सत्र के लिए यह डेटा प्राप्त कर सकता है जिसमें STATISTICS XML या STATISTICS PROFILE कथन को शामिल किया गया था, या सभी सत्रों के लिए, विस्तारित query_post_execution_showplan ईवेंट का उपयोग करते हुए, हालाँकि यह ईवेंट, विशेष रूप से, समग्र प्रदर्शन को प्रभावित कर सकता है।

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

SQL Server 2016 सर्विस पैक 1 (SP1) के साथ शुरू करके, आप ट्रेस फ़्लैग 7412 या उन्नत query_thread_profile प्रॉपर्टी का उपयोग करके सभी सत्रों के लिए इस डेटा को एकत्रित करने का एक हल्का संस्करण भी सक्षम कर सकते हैं, जो आपको बिना किसी सत्र की जानकारी के बिना किसी भी चीज़ की तुरंत जानकारी प्राप्त करने की अनुमति देता है। इसमें स्पष्ट रूप से शामिल करें (विशेष रूप से, ऐसी चीजें जो प्रदर्शन को प्रतिकूल रूप से प्रभावित करती हैं)। पेड्रो लोपेज के ब्लॉग पर यह अधिक विस्तार से वर्णित है ।

SQL सर्वर 2019 में, यह सुविधा डिफ़ॉल्ट रूप से सक्षम होती है, इसलिए आपको किसी भी सत्र को विस्तारित घटनाओं के साथ चलाने या किसी भी क्वेरी में किसी भी ट्रेस ध्वज और सांख्यिकी कथन का उपयोग करने की आवश्यकता नहीं है। सभी समवर्ती सत्रों के लिए किसी भी समय DMV के डेटा को देखें। लेकिन LIGHTWEIGHT_QUERY_PROFILING का उपयोग करके इस मोड को अक्षम करना संभव है, हालांकि, यह सिंटैक्स CTP 2.0 में काम नहीं करता है और भविष्य के संस्करणों में तय किया जाएगा।

क्लोन किए गए कॉलम इंडेक्स आँकड़े अब क्लोन किए गए डेटाबेस में उपलब्ध हैं

SQL सर्वर के वर्तमान संस्करणों में, जब डेटाबेस का क्लोनिंग किया जाता है, तो क्लस्टर कॉलम इंडेक्स से केवल मूल ऑब्जेक्ट आँकड़े का उपयोग किया जाता है, इसके निर्माण के बाद तालिका में किए गए अपडेट को छोड़कर। यदि आप प्रश्नों और अन्य प्रदर्शन परीक्षण को कॉन्फ़िगर करने के लिए एक क्लोन का उपयोग करते हैं, जो बिजली रेटिंग पर आधारित हैं, तो ये उदाहरण काम नहीं कर सकते हैं। परीक्षित सेवानी ने इस प्रकाशन में सीमाओं का वर्णन किया और एक अस्थायी समाधान प्रदान किया - क्लोन बनाने से पहले, आपको एक स्क्रिप्ट बनाने की जरूरत है जो DBCC SHOW_STATISTICS को निष्पादित करती है ... प्रत्येक वस्तु के लिए STATS_STREAM के साथ। यह महंगा है और निश्चित रूप से, इसके बारे में भूलना आसान है।

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

स्तंभ भंडारण के लिए संपीड़न पूर्वानुमान

वर्तमान संस्करणों में, sys.sp_estimate_data_compression_savings प्रक्रिया में निम्नलिखित जांच है:

 if (@data_compression not in ('NONE', 'ROW', 'PAGE')) 

इसका मतलब है कि यह आपको एक पंक्ति या पृष्ठ के संपीड़न की जांच करने की अनुमति देता है (या वर्तमान संपीड़न को हटाने का परिणाम देखें)। SQL Server 2019 में, यह चेक अब इस तरह दिखता है:

 if (@data_compression not in ('NONE', 'ROW', 'PAGE', 'COLUMNSTORE', 'COLUMNSTORE_ARCHIVE')) 

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

 EXEC sys.sp_estimate_data_compression_savings @schema_name = N'dbo', @object_name = N'FactTable', @index_id = NULL, @partition_number = NULL, @data_compression = N'NONE'; -- repeat for ROW, PAGE, COLUMNSTORE, COLUMNSTORE_ARCHIVE 

परिणाम:



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

पृष्ठ की जानकारी प्राप्त करने के लिए नई सुविधा

एक लंबे समय के लिए, DBCC पृष्ठ और DBCC IND का उपयोग अनुभाग, सूचकांक, या तालिका वाले पृष्ठों के बारे में जानकारी एकत्र करने के लिए किया गया था। लेकिन वे अनिर्दिष्ट और असमर्थित हैं, और यह कई अनुक्रमित या पृष्ठों से जुड़े कार्यों के समाधान को स्वचालित करने के लिए थकाऊ हो सकता है।

बाद में, एक गतिशील प्रशासनिक फ़ंक्शन (DMF) sysinos_db_database_page_allocations दिखाई दिया, जो निर्दिष्ट ऑब्जेक्ट में सभी पृष्ठों का प्रतिनिधित्व करने वाला एक सेट देता है। अभी भी अनिर्दिष्ट और खामियां हैं जो बड़ी तालिकाओं पर एक वास्तविक समस्या बन सकती हैं: यहां तक ​​कि एक पृष्ठ के बारे में जानकारी प्राप्त करने के लिए, इसे पूरी संरचना को पढ़ना चाहिए, जो काफी महंगा हो सकता है।

SQL Server 2019 में, एक और DMF दिखाई दिया है - sysinos_db_page_info। यह मूल रूप से DMF वितरण के ओवरहेड के बिना, सभी पृष्ठ जानकारी लौटाता है। हालांकि, वर्तमान बिल्ड में फ़ंक्शन का उपयोग करने के लिए, आपको उस पृष्ठ की संख्या जानने की आवश्यकता है जिसे आप पहले से देख रहे हैं। शायद यह कदम जानबूझकर उठाया गया था, क्योंकि यह प्रदर्शन सुनिश्चित करने का एकमात्र तरीका है। इसलिए यदि आप किसी इंडेक्स या टेबल के सभी पेजों को पहचानने की कोशिश कर रहे हैं, तो आपको अभी भी डीएमएफ वितरण का उपयोग करने की आवश्यकता है। अगले लेख में मैं इस प्रश्न का अधिक विस्तार से वर्णन करूंगा।

सुरक्षा

एक सुरक्षित वातावरण (एन्क्लेव) का उपयोग कर स्थायी एन्क्रिप्शन

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

एक सुरक्षित वातावरण (एन्क्लेव) मेमोरी का एक संरक्षित क्षेत्र है जहां इस तरह की संगणना और फ़िल्टरिंग को प्रत्यायोजित किया जा सकता है (विंडोज़ वर्चुअलाइजेशन-आधारित सुरक्षा का उपयोग करता है) - डेटा कर्नेल में एन्क्रिप्टेड रहता है, लेकिन सुरक्षित वातावरण में सुरक्षित रूप से डिक्रिप्ट या एन्क्रिप्ट किया जा सकता है। आपको केवल SSMS का उपयोग करके प्राथमिक कुंजी में ENCLAVE_COMPUTATIONS पैरामीटर जोड़ना होगा, उदाहरण के लिए, "सुरक्षित वातावरण में गणना की अनुमति दें" बॉक्स चेक करके:



अब आप पुराने तरीके की तुलना में (जिसमें विज़ार्ड, सेट- SqlColumnEncyption cmdlet या आपके आवेदन की तुलना में, लगभग तुरंत डेटा एन्क्रिप्ट कर सकते हैं, डेटाबेस से पूरे सेट को पूरी तरह से प्राप्त करना होगा, इसे एन्क्रिप्ट करें, और वापस भेजें):

 ALTER TABLE dbo.Patients ALTER COLUMN SSN char(9) -- currently not encrypted! ENCRYPTED WITH ( COLUMN_ENCRYPTION_KEY = ColumnEncryptionKeyName, ENCRYPTION_TYPE = Randomized, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256' ) NOT NULL; 

मुझे लगता है कि कई संगठनों के लिए यह सुधार मुख्य समाचार होगा, लेकिन वर्तमान सीटीपी में इनमें से कुछ उपप्रणालियों में अभी भी सुधार किया जा रहा है, इसलिए उन्हें डिफ़ॉल्ट रूप से बंद कर दिया जाता है, लेकिन यहां आप देख सकते हैं कि उन्हें कैसे चालू किया जाए।

कॉन्फ़िगरेशन प्रबंधक में प्रमाणपत्र प्रबंधन

एसएसएल और टीएलएस प्रमाणपत्रों का प्रबंधन हमेशा एक दर्द रहा है, और कई लोग अपने उद्यम प्रमाणपत्रों को तैनात करने और बनाए रखने के लिए अपनी स्क्रिप्ट बनाने के थकाऊ काम करने के लिए मजबूर हुए हैं। SQL Server 2019 के लिए अपडेट किया गया कॉन्फ़िगरेशन मैनेजर आपको किसी भी उदाहरण के प्रमाण पत्र को जल्दी से देखने और सत्यापित करने में मदद करेगा, जल्द ही समाप्त होने वाले प्रमाण पत्र ढूंढेगा, और उपलब्धता समूह में सभी प्रतिकृति या विफलता क्लस्टर उदाहरण में सभी नोड्स को सिंक्रनाइज़ करना होगा।

मैंने इन सभी कार्यों की कोशिश नहीं की है, लेकिन यदि प्रबंधन SQL सर्वर 2019 कॉन्फ़िगरेशन प्रबंधक से आता है, तो उन्हें SQL सर्वर के पिछले संस्करणों के लिए काम करना चाहिए।

अंतर्निहित डेटा वर्गीकरण और लेखा परीक्षा

SQL सर्वर डेवलपमेंट टीम ने SSMS 17.5 में डेटा को वर्गीकृत करने की क्षमता को जोड़ा है, जो आपको किसी भी कॉलम की पहचान करने की अनुमति देता है जिसमें संवेदनशील जानकारी हो सकती है या विभिन्न मानकों (HIPAA, SOX, PCI, और GDPR, निश्चित रूप से) का खंडन कर सकती है। विज़ार्ड एक एल्गोरिथ्म का उपयोग करता है जो स्तंभ प्रदान करता है जो समस्याओं का कारण माना जाता है, लेकिन आप सूची से इन स्तंभों को हटाकर या तो अपना वाक्य समायोजित कर सकते हैं या अपना स्वयं का जोड़ सकते हैं। वर्गीकरण को संग्रहीत करने के लिए, उन्नत गुणों का उपयोग किया जाता है; अंतर्निहित SSMS रिपोर्ट अपने डेटा को प्रदर्शित करने के लिए समान जानकारी का उपयोग करती है। रिपोर्ट के बाहर, ये गुण इतने स्पष्ट नहीं हैं।

SQL सर्वर 2019 ने इस मेटाडेटा के लिए एक नया बयान पेश किया, जो पहले से ही Azure SQL डेटाबेस में उपलब्ध है, और इसे ADD SENSITIVITY CLASSIFICATION कहा जाता है। यह आपको SSMS में विज़ार्ड के समान करने की अनुमति देता है, लेकिन यह जानकारी अब विस्तारित संपत्ति में संग्रहीत नहीं की जाती है, और इस डेटा तक किसी भी एक्सेस को स्वचालित रूप से ऑडिट में एक नए XML कॉलम डेटा_सेंसेटिविटी_इनफॉर्मेशन के रूप में प्रदर्शित किया जाता है। इसमें सभी प्रकार की जानकारी शामिल है जो ऑडिट के दौरान प्रभावित हुई थी।

एक त्वरित उदाहरण के रूप में, मान लीजिए कि मेरे पास बाहरी ठेकेदारों के लिए एक तालिका है:

 CREATE TABLE dbo.Contractors ( FirstName sysname, LastName sysname, SSN char(9), HourlyRate decimal(6,2) ); 

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

 ADD SENSITIVITY CLASSIFICATION TO dbo.Contractors.FirstName, dbo.Contractors.LastName WITH (LABEL = 'Confidential – GDPR', INFORMATION_TYPE = 'Personal Info'); ADD SENSITIVITY CLASSIFICATION TO dbo.Contractors.SSN WITH (LABEL = 'Highly Confidential', INFORMATION_TYPE = 'National ID'); ADD SENSITIVITY CLASSIFICATION TO dbo.Contractors.HourlyRate WITH (LABEL = 'Highly Confidential', INFORMATION_TYPE = 'Financial'); 

अब, sys.extended_properties को देखने के बजाय, आप उन्हें sys.sunning_classifications में देख सकते हैं:



और अगर हम इस तालिका के लिए ऑडिट सैंपलिंग (या डीएमएल) करते हैं, तो हमें विशेष रूप से कुछ भी बदलने की आवश्यकता नहीं है; वर्गीकरण बनाने के बाद, SELECT * ऑडिट में रिकॉर्ड करेगा एक नए कॉलम डेटा_सेंसिटिविटी फाइल में इस प्रकार की जानकारी का रिकॉर्ड लॉग इन करें:

 <sensitivity_attributes> <sensitivity_attribute label="Confidential - GDPR" information_type="Personal Info" /> <sensitivity_attribute label="Highly Confidential" information_type="National ID" /> <sensitivity_attribute label="Highly Confidential" information_type="Financial" /> </sensitivity_attributes> 

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

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

उपलब्धता

वास्तविक समय अक्षय सूचकांक निर्माण

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

SQL सर्वर 2019 में, आप रीयल-टाइम इंडेक्स बनाने, रोकने और जारी रखने के लिए समान सिंटैक्स का उपयोग कर सकते हैं, और निष्पादन समय को भी सीमित कर सकते हैं (ठहराव का समय निर्धारित करते हुए):

 CREATE INDEX foo ON dbo.bar(blat) WITH (ONLINE = ON, RESUMABLE = ON, MAX_DURATION = 10 MINUTES); 

यदि यह क्वेरी बहुत लंबे समय तक काम करती है, तो विराम देने के लिए, आप अन्य सत्र में ALTER INDEX चला सकते हैं (भले ही सूचकांक अभी तक भौतिक रूप से मौजूद नहीं है):

 ALTER INDEX foo ON dbo.bar PAUSE; 

वर्तमान बिल्ड में, नवीनीकरण के दौरान समानता की डिग्री को कम नहीं किया जा सकता है, जैसा कि पुनर्निर्माण के मामले में है। जब डीओपी को कम करने की कोशिश की जा रही है:

 ALTER INDEX foo ON dbo.bar RESUME WITH (MAXDOP = 2); 

हम निम्नलिखित प्राप्त करते हैं:

 Msg 10666, Level 16, State 1, Line 3 Cannot resume index build as required DOP 4 (DOP operation was started with) is not available. Please ensure sufficient DOP is available or abort existing index operation and try again. The statement has been terminated. 

वास्तव में, यदि आप ऐसा करने की कोशिश करते हैं, और फिर अतिरिक्त मापदंडों के बिना कमांड निष्पादित करते हैं, तो आपको कम से कम वर्तमान बिल्ड पर समान त्रुटि मिलेगी। मुझे लगता है कि नवीनीकरण का प्रयास कहीं दर्ज किया गया था और सिस्टम इसे फिर से उपयोग करना चाहता था। जारी रखने के लिए, आपको सही (या अधिक) DOP मान निर्दिष्ट करना होगा:

 ALTER INDEX foo ON dbo.bar RESUME WITH (MAXDOP = 4); 

इसे स्पष्ट करने के लिए: आप रुके हुए सूचकांक निर्माण को फिर से शुरू करते हुए डीओपी बढ़ा सकते हैं, लेकिन इसे कम नहीं कर सकते।

इन सबका एक अतिरिक्त लाभ यह है कि आप नए डेटाबेस के लिए ELEVATE_ONLINE और ELEVATE_RESUMABLE क्लॉस का उपयोग करके डिफ़ॉल्ट मोड के रूप में वास्तविक समय में अनुक्रमणिका के निर्माण और / या नवीनीकरण को कॉन्फ़िगर कर सकते हैं।

वास्तविक समय निर्माण / क्लस्टर किए गए स्तंभ अनुक्रमणिका का पुनर्निर्माण

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

 CREATE TABLE dbo.splunge ( id int NOT NULL ); GO CREATE UNIQUE CLUSTERED INDEX PK_Splunge ON dbo.splunge(id); GO CREATE CLUSTERED COLUMNSTORE INDEX PK_Splunge ON dbo.splunge WITH (DROP_EXISTING = ON, ONLINE = ON); 

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

 CREATE TABLE dbo.splunge ( id int NOT NULL CONSTRAINT PK_Splunge PRIMARY KEY CLUSTERED (id) ); GO -- or after the fact -- ALTER TABLE dbo.splunge ADD CONSTRAINT PK_Splunge PRIMARY KEY CLUSTERED(id); 

हमें निम्नलिखित त्रुटि मिलती है:

 Msg 1907, Level 16 Cannot recreate index 'PK_Splunge'. The new index definition does not match the constraint being enforced by the existing index. 

आपको पहले इसे एक स्तंभित स्तंभ अनुक्रमणिका में बदलने के लिए बाधा को दूर करना होगा, लेकिन इन दोनों कार्यों को वास्तविक स्थिति में किया जा सकता है:

 ALTER TABLE dbo.splunge DROP CONSTRAINT PK_Splunge WITH (ONLINE = ON); GO CREATE CLUSTERED COLUMNSTORE INDEX PK_Splunge ON dbo.splunge WITH (ONLINE = ON); 

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

एक माध्यमिक सर्वर से एक प्राथमिक के लिए एक प्रतिकृति कनेक्शन को पुनर्निर्देशित करना

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

डिज़ाइन

ग्राफ की अतिरिक्त विशेषताएं

ग्राफ संबंध अब MERGE विधेय का उपयोग करते हुए नोड या सीमा तालिकाओं के लिए MERGE कथन का समर्थन करते हैं; अब एक ऑपरेटर एक मौजूदा बढ़त को अपडेट कर सकता है या एक नया डाल सकता है। नया एज प्रतिबंध आपको यह निर्धारित करने की अनुमति देता है कि किन किन नोड्स को कनेक्ट कर सकते हैं।

UTF-8

SQL Server 2012 में यूनिक्स -16 और अतिरिक्त वर्णों के लिए समर्थन जोड़ा गया, जैसे कि प्रत्यय _SC के साथ एक नाम निर्दिष्ट करके, जैसे कि यूनीकोड ​​कॉलम (nchar / ncharchar) का उपयोग करने के लिए लैटिन 1_General_100_CI_AI_SC। SQL Server 2017 में, आप BCP और BULK INSERT जैसे उपकरणों का उपयोग करके इन स्तंभों से UTF-8 डेटा आयात और निर्यात कर सकते हैं ।

SQL सर्वर 2019 में, अपने मूल रूप में UTF-8 डेटा की जबरन अवधारण का समर्थन करने के लिए नए कोलाज़ विकल्प हैं। इसलिए आप आसानी से char या varchar कालम बना सकते हैं और UTF-8 डेटा को सही ढंग से प्रत्यय _SC_UTF8 के साथ लेटिन 1_General_100_CI_SC_UT_8 जैसे प्रत्यय के साथ प्रयोग कर सकते हैं। यह प्रसंस्करण और भंडारण nvarchar की लागत के बिना, बाहरी अनुप्रयोगों और DBMS के साथ संगतता को बेहतर बनाने में मदद कर सकता है।

ईस्टर अंडा मुझे मिला

जहाँ तक मुझे याद है, SQL सर्वर उपयोगकर्ता इस अस्पष्ट त्रुटि संदेश के बारे में शिकायत करते हैं:

 Msg 8152 String or binary data would be truncated. 

CTP बिल्ड में मैंने प्रयोग किया, एक दिलचस्प त्रुटि संदेश देखा गया जो पहले नहीं था:

 Msg 2628 String or binary data would be truncated in table '%.*ls', column '%.*ls'. Truncated value: '%.*ls' 

मुझे नहीं लगता कि यहां किसी और चीज की जरूरत है; यह एक महान (यद्यपि बहुत देर से) सुधार है, और कई खुश करने का वादा करता है। हालाँकि, यह कार्यक्षमता CTP 2.0 में उपलब्ध नहीं होगी; मैं आपको बस थोड़ा आगे देखने का अवसर देता हूं। ब्रेंट ओजर ने वर्तमान सीटीपी में पाए गए सभी नए संदेशों को सूचीबद्ध किया और उन्हें अपने sys.messages लेख में कुछ उपयोगी टिप्पणियों के साथ सीज किया: अतिरिक्त सुविधाओं की खोज ।

निष्कर्ष

SQL सर्वर 2019 अच्छी अतिरिक्त सुविधाएँ प्रदान करता है जो आपके पसंदीदा रिलेशनल डेटाबेस प्लेटफ़ॉर्म के साथ काम को बेहतर बनाने में मदद करेगा, और ऐसे कई परिवर्तन हैं जिनके बारे में मैंने बात नहीं की है। ऊर्जा-कुशल मेमोरी, मशीन सीखने की सेवाओं के लिए क्लस्टरिंग, लिनक्स, कुबेरनेट्स, ओरेकल / टेराडाटा / मोंगोडीबी पर कनेक्टर्स के लिए लेन-देन और वितरित लेन-देन, तुल्यकालिक एजी प्रतिकृति जावा (पाइथन / आर के समान कार्यान्वयन) का समर्थन करने के लिए बढ़ी है और, बस के रूप में महत्वपूर्ण, एक नई छलांग, बिग डेटा क्लस्टर शीर्षक। इनमें से कुछ सुविधाओं का उपयोग करने के लिए, आपको इस ईएपी फॉर्म का उपयोग करके पंजीकरण करना होगा ।

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

लेकिन यहां तक ​​कि इस पहले सार्वजनिक CTP में लगभग सभी के लिए कुछ महत्वपूर्ण है, और मैं आपसे खुद इसे आजमाने का आग्रह करता हूं!