समानांतर सांख्यिकी पुनर्निर्माण के लिए बेहतर समर्थन

SQL सर्वर में बग्स के बारे में जानने का एक शानदार तरीका यह है कि जब वे बाहर आते हैं तो संचयी अपडेट और सर्विस पैक के लिए रिलीज़ नोट्स को पढ़ें। हालाँकि, कभी-कभी यह SQL सर्वर के एन्हांसमेंट के बारे में जानने का भी एक शानदार तरीका है।

SQL Server 2014 सर्विस पैक 1 के लिए संचयी अद्यतन 6 एक नया ट्रेस फ्लैग, 7471 पेश किया, जो SQL सर्वर में अद्यतन सांख्यिकी कार्यों के लॉकिंग व्यवहार को बदलता है (देखें KB #3156157)। इस पोस्ट में हम लॉकिंग व्यवहार में अंतर देखेंगे और जहां यह ट्रेस फ्लैग उपयोगी हो सकता है।

इस पोस्ट के लिए एक उपयुक्त डेमो वातावरण स्थापित करने के लिए, मैंने AdventureWorks2014 डेटाबेस का उपयोग किया और मेरे ब्लॉग पर उपलब्ध स्क्रिप्ट के आधार पर एक विस्तृत संस्करण SalesOrderDetail तालिका बनाई। SalesOrderDetailEnlarged तालिका को आकार में 2GB तक बढ़ा दिया गया था ताकि FULLSCAN संचालन के साथ अद्यतन आँकड़े एक साथ तालिका पर विभिन्न आँकड़ों के विरुद्ध निष्पादित किए जा सकें। मैंने तब दोनों सत्रों में होने वाले तालों की जांच करने के लिए sp_whoisactive का उपयोग किया था।

TF 7471 के बिना व्यवहार

SQL सर्वर के डिफ़ॉल्ट व्यवहार के लिए तालिका के लिए OBJECT.UPDSTATS संसाधन पर एक विशेष लॉक (X) की आवश्यकता होती है जब भी किसी तालिका के विरुद्ध अद्यतन सांख्यिकी आदेश निष्पादित किया जाता है। आप इसे SP_whoisactive आउटपुट में FULLSCAN के साथ UPDATE Statistics with FULLSCAN के दो समवर्ती निष्पादन के लिए देख सकते हैं। इसके परिणामस्वरूप पहला निष्पादन पूरा होने तक अद्यतन सांख्यिकी का दूसरा निष्पादन अवरुद्ध हो जाता है।

अद्यतन आंकड़े [बिक्री]। 
<ऑब्जेक्ट का नाम="SalesOrderDetailEnlarged" schema_name="Sales">      <लॉक>        <लॉक Resource_type="METADATA.INDEXSTATS" index_name="PK_SalesOrderDetailEnlarged_SalesOrderID_SalesOrderDetailID" request_mode="status-GRANT" request_mode="Sch-GRANT" request_mode="Sch-GRANT" अनुरोध />        <लॉक Resource_type="METADATA.STATS" request_mode="Sch-S" request_status="GRANT" request_count="1" />                <लॉक Resource_type="OBJECT.UPDSTATS" request_mode="X" request_status="GRANT" request_count="1" />          
 
अद्यतन आंकड़े [बिक्री]। [SalesOrderDetailEnlarged] ([IX_SalesOrderDetailEnlarged_ProductID]) FULLSCAN के साथ;
 
<ऑब्जेक्ट का नाम="SalesOrderDetailEnlarged" schema_name="Sales">      <लॉक>        <लॉक Resource_type="METADATA.INDEXSTATS" index_name="PK_SalesOrderDetailEnlarged_SalesOrderID_SalesOrderDetailID" request_mode="1="status-GRANT" request_mode="Sch-GRANT" request_mode="Sch-GRANT" अनुरोध />        <लॉक Resource_type="OBJECT" request_mode="Sch-S" request_status="GRANT" request_count="1" />        <लॉक Resource_type="OBJECT.UPDSTATS" request_mode="X" request_status="WAIT" request_count=" 1" />          
 

 OBJECT.UPDSTATS पर होने वाले लॉक रिसोर्स की ग्रैन्युलैरिटी एक ही टेबल के खिलाफ कई आंकड़ों के समवर्ती अपडेट को रोकता है। हाल के वर्षों में हार्डवेयर संवर्द्धन ने वास्तव में संभावित बाधाओं को बदल दिया है जो SQL सर्वर कार्यान्वयन के लिए सामान्य हैं, और जैसे ही DBCC CHECKDB में परिवर्तन किए गए हैं, इसे तेजी से चलाने के लिए, अद्यतन सांख्यिकी के लॉकिंग व्यवहार को बदलकर आँकड़ों के समवर्ती अद्यतन की अनुमति देने के लिए। समान तालिका VLDB के लिए रखरखाव विंडो को महत्वपूर्ण रूप से कम कर सकती है, विशेष रूप से जहां पर्याप्त CPU और I/O सबसिस्टम क्षमता है जो अंतिम-उपयोगकर्ता के अनुभवों को प्रभावित किए बिना समवर्ती अपडेट होने की अनुमति देती है।
 
TF 7471 के साथ व्यवहार 
 

 ट्रेस फ्लैग 7471 के साथ लॉकिंग व्यवहार में परिवर्तन को OBJECT.UPDSTATS संसाधन पर एक विशेष लॉक (X) की आवश्यकता से लेकर METADATA पर एक अपडेट लॉक (U) की आवश्यकता होती है। अद्यतन किए जा रहे विशिष्ट आंकड़ों के लिए STATS संसाधन, जो समवर्ती निष्पादन की अनुमति देता है एक ही टेबल पर अद्यतन सांख्यिकी का। ट्रेस फ्लैग सक्षम के साथ फुलकैन कमांड के साथ एक ही अद्यतन आंकड़ों के लिए sp_whoisactive का आउटपुट नीचे दिखाया गया है:
 
अद्यतन आंकड़े [बिक्री]। 
<ऑब्जेक्ट का नाम="SalesOrderDetailEnlarged" schema_name="Sales">      <लॉक>        <लॉक Resource_type="METADATA.INDEXSTATS" index_name="PK_SalesOrderDetailEnlarged_SalesOrderID_SalesOrderDetailID" request_mode="status-GRANT" request_mode="Sch-GRANT" request_mode="Sch-GRANT" अनुरोध />        <लॉक Resource_type="METADATA.STATS" request_mode="U" request_status="GRANT" request_count="1" />        <लॉक Resource_type="OBJECT" request_mode="Sch-S" request_status="GRANT" request_count=" 2" />          
 
अद्यतन आंकड़े [बिक्री]। [SalesOrderDetailEnlarged] ([IX_SalesOrderDetailEnlarged_ProductID]) FULLSCAN के साथ;
 
<ऑब्जेक्ट्स>    <ऑब्जेक्ट का नाम="SalesOrderDetailEnlarged" schema_name="Sales">      <लॉक>        <लॉक Resource_type="METADATA.INDEXSTATS" index_name="IX_SalesOrderDetailEnlarged_ProductID" request_mode="Sch-S" request_status=status "2" />        <लॉक Resource_type="METADATA.INDEXSTATS" index_name="PK_SalesOrderDetailEnlarged_SalesOrderID_SalesOrderDetailID" request_mode="Sch-S" request_status="GRANT" request_count="2" /="S        <लॉक संसाधन. U" request_status="GRANT" request_count="1" />                  
 

 VLDB के लिए, जो कि बहुत अधिक सामान्य स्थान बनते जा रहे हैं, यह एक सर्वर पर सांख्यिकी अद्यतन करने में लगने वाले समय में एक बड़ा अंतर ला सकता है। 
 

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

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

 सर्विस ब्रोकर कॉन्फ़िगरेशन का उपयोग करके समानांतर में केवल अद्यतन आंकड़ों के प्रदर्शन का परीक्षण करने के लिए, मैंने डीडीएल कमांड को निष्पादित करने के लिए निम्न स्क्रिप्ट का उपयोग करके एडवेंचरवर्क्स2014 डेटाबेस में प्रत्येक कॉलम पर एक कॉलम स्टेटिस्टिक बनाकर शुरू किया।
 
उपयोग [AdventureWorks2014]जाओ चुनें *, 'आंकड़े छोड़ें' + QUOTENAME(c.TABLE_SCHEMA) + '।' + QUOTENAME(c.TABLE_NAME) + '.' + QUOTENAME(c.TABLE_NAME + '_' + c.COLUMN_NAME) + ';GOCREATE आँकड़ों' +QUOTENAME(c.TABLE_NAME + '_' + c.COLUMN_NAME) + 'ON' + QUOTENAME(c.TABLE_SCHEMA) + '। ' + QUOTENAME(c.TABLE_NAME) + '(' +QUOTENAME(c.COLUMN_NAME) + ');' + INFORMATION_SCHEMA से 'जाओ'। CINNER के रूप में COLUMNS INFORMATION_SCHEMA में शामिल हों। c.TABLE_CATALOG =t.TABLE_CATALOG और c.TABLE_SCHEMA =t.TABLE_SCHEMA और c.TABLE_NAME ='T.TABLE_NAME =t.TABLE_NAME =t.TABLE_NAME =t.TABLE_NAME .DATA_TYPE <> N'xml';
 

 यह ऐसा कुछ नहीं है जिसे आप आम तौर पर करना चाहते हैं, लेकिन यह मुझे समवर्ती रूप से आंकड़ों को अद्यतन करने पर ट्रेस ध्वज के प्रभाव के समानांतर परीक्षण के लिए बहुत सारे आंकड़े देता है। जिस क्रम में मैं सेवा ब्रोकर को कार्यों को कतारबद्ध करता हूं, उसे यादृच्छिक करने के बजाय, मैं इसके बजाय केवल कार्यों को कतारबद्ध करता हूं क्योंकि वे तालिका के आईडी के आधार पर कमांडलॉग तालिका में मौजूद होते हैं, बस आईडी को एक-एक करके तब तक बढ़ाते हैं जब तक कि सभी कमांड कतारबद्ध नहीं हो जाते। प्रसंस्करण के लिए।
 
उपयोग [मास्टर]; - कमांड लॉग को साफ़ करें TRUNCATE टेबल [मास्टर]। [dbo]। [CommandLog]; DECLARE @MaxID INT; चुनें @MaxID =MAX(ID) Master.dbo.CommandLog से; चुनें @MaxID =ISNULL(@MaxID, 1) ---- कमांड में नए कार्यों को लोड करें LogEXEC Master.dbo.IndexOptimize @Databases =N'AdventureWorks2014', @FragmentationLow =NULL, @FragmentationMedium =NULL, @FragmentationHigh =NULL, @UpdateStatistics ='ALL', @StatisticsSample =100, @LogToTable ='Y', @Execute ='N'; DECLARE @NewMaxID INTSELECT @NewMaxID =MAX(ID) Master.dbo.CommandLog से; एमएसडीबी का उपयोग करें; DECLARE @CurrentID INT =@MaxIDWHILE (@CurrentID <=@NewMaxID)BEGIN -- बातचीत शुरू करें और अनुरोध संदेश भेजें DECLARE @conversation_handle UNIQUEIDENTIFIER; DECLARE @message_body एक्सएमएल; लेनदेन शुरू करें; सेवा से @conversation_handle शुरू करें [OlaHallengrenMaintenanceTaskService] सेवा के लिए N'OlaHallengrenMaintenanceTaskService' अनुबंध पर [OlaHallengrenMaintenanceTaskContract] एन्क्रिप्शन के साथ =OFF; चुनें @message_body =N''+CAST(@CurrentID AS NVARCHAR)+N''; बातचीत पर भेजें @conversation_handle संदेश प्रकार [OlaHallengrenMaintenanceTaskMessage] (@message_body); प्रतिबद्ध लेनदेन; SET @CurrentID =@CurrentID + 1; मौजूद रहते हुए समाप्त करें (OlaHallengrenMaintenanceTaskQueue के साथ (NOLOCK) से 1 चुनें) '00:00:01.000' के अंत की प्रतीक्षा करें। ), MAX(EndTime)) Master.dbo.CommandLog से;GO 10
 

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

 
 

 परीक्षण के परिणाम बताते हैं कि ट्रेस ध्वज के बिना डिफ़ॉल्ट व्यवहार के तहत होने वाली अवरोधन के साथ भी, आंकड़ों के नमूना अद्यतन 6% तेजी से चलते हैं और पूर्ण स्कैन अपडेट सेवा ब्रोकर को कतारबद्ध कार्यों को संसाधित करने वाले पांच थ्रेड के साथ 16% तेजी से चलते हैं। ट्रेस फ्लैग 7471 सक्षम होने के साथ, आंकड़ों के समान नमूना अपडेट 38% तेजी से चलते हैं और पूर्ण स्कैन अपडेट 45% तेजी से चलते हैं, जिसमें पांच थ्रेड सर्विस ब्रोकर के लिए कतारबद्ध कार्यों को संसाधित करते हैं।
 
TF 7471 के साथ संभावित चुनौतियाँ
 

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

 मैं मूल रूप से 4GB RAM के साथ 4vCPU VM का उपयोग करके समानांतर रखरखाव का परीक्षण कर रहा था जिसे मैंने विशेष रूप से इस उद्देश्य के लिए सेटअप किया था। जैसे ही मैंने सर्विस ब्रोकर में सक्रियण प्रक्रिया के लिए MAX_QUEUE_READERS की संख्या बढ़ाना शुरू किया, मुझे ट्रेस फ्लैग सक्षम होने पर RESOURCE_SEMAPHORE प्रतीक्षा के साथ समस्याओं का सामना करना पड़ा, स्मृति अनुदान आवश्यकताओं के कारण मेरे एडवेंचरवर्क्स2014 डेटाबेस में बढ़े हुए तालिकाओं पर आंकड़ों के समानांतर अपडेट की अनुमति देता है। प्रत्येक अद्यतन सांख्यिकी आदेश के लिए जो चल रहे थे। वीएम कॉन्फ़िगरेशन को 16 जीबी रैम में बदलकर इसे कम कर दिया गया था, लेकिन इंडेक्स रखरखाव को शामिल करने के लिए बड़ी टेबल पर समानांतर कार्यों को करते समय यह निगरानी और देखने के लिए कुछ है, क्योंकि मेमोरी अनुदान भुखमरी अंतिम उपयोगकर्ता अनुरोधों को भी प्रभावित करेगी जो निष्पादित करने की कोशिश कर रहे हैं और एक बड़े स्मृति अनुदान की भी आवश्यकता है। 
 

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

 आनंद लें!