इंक्रीमेंटल स्टैटिस्टिक्स का उपयोग क्वेरी ऑप्टिमाइज़र द्वारा नहीं किया जाता है

वृद्धिशील आँकड़ों पर मेरी पिछली पोस्ट में, SQL सर्वर 2014 में एक नई सुविधा, मैंने प्रदर्शित किया कि वे रखरखाव कार्य अवधि को कम करने में कैसे मदद कर सकते हैं। ऐसा इसलिए है क्योंकि आंकड़ों को विभाजन स्तर पर अद्यतन किया जा सकता है, और परिवर्तन तालिका के लिए मुख्य हिस्टोग्राम में विलय हो जाते हैं। मैंने यह भी नोट किया है कि क्वेरी प्लान जेनरेट करते समय क्वेरी ऑप्टिमाइज़र उन विभाजन-स्तरीय आँकड़ों का उपयोग नहीं करता है, जो कुछ ऐसा हो सकता है जिसकी लोग अपेक्षा कर रहे थे। यह बताने के लिए कोई दस्तावेज मौजूद नहीं है कि क्वेरी ऑप्टिमाइज़र द्वारा वृद्धिशील आंकड़ों का उपयोग किया जाएगा या नहीं किया जाएगा। तो आप कैसे जानते हैं? आपको इसका परीक्षण करना होगा। :-)

सेटअप

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

उपयोग [AdventureWorks2014_Partition];GO /* फाइलग्रुप्स जोड़ें */ALTER DATABASE [AdventureWorks2014_Partition] ADD FILEGROUP [FG2011];ALTER DATABASE [AdventureWorks2014_Partition] ADD FILEGROUP [FG2012];ALTER DATABASE] [AdventureWorks2014_Partition] फ़ाइल समूह जोड़ें [FG2014]; डेटाबेस बदलें [AdventureWorks2014_Partition] फ़ाइल समूह जोड़ें [FG2015]; /* फाइल्स जोड़ें फ़ाइलग्रुप [FG2011]; ALTER DATABASE [AdventureWorks2014_Partition] फ़ाइल जोड़ें (FILENAME =N'C:\Databases\AdventureWorks2014_Partition\2012.ndf', NAME =N'2012', SIZE =512MB, MAXSIZE =2048MB, FILEGROWTH =512MB [FFILEGROWTH =512MB) टू FILEGROUP]; ALTER DATABASE [AdventureWorks2014_Partition] फ़ाइल जोड़ें (FILENAME =N'C:\Databases\AdventureWorks2014_Partition\2013.ndf', NAME =N'2013', SIZE =512MB, MAXSIZE =2048MB, FILEGROWTH =512MB [F करने के लिए FILEGROWTH =512MB) ALTER DATABASE [AdventureWorks2014_Partition] फ़ाइल जोड़ें (FILENAME =N'C:\Databases\AdventureWorks2014_Partition\2014.ndf', NAME =N'2014', SIZE =512MB, MAXSIZE =2048MB, FILEGROWTH =512MB [FFILEGROWTH =512MB]; ALTER DATABASE [AdventureWorks2014_Partition] फ़ाइल जोड़ें (FILENAME =N'C:\Databases\AdventureWorks2014_Partition\2015.ndf', NAME =N'2015', SIZE =512MB, MAXSIZE =2048MB, FILEGROWTH =512MB [F2015GROUP [F2015GROUP] TO FILEGROUP]; पार्टिशन फंक्शन बनाएं [ऑर्डरडेट रेंजपीएफएन] ([डेटटाइम]) वैल्यू के लिए रेंज राइट के रूप में ('20110101', - 2011 '20120101' में सब कुछ, 2012 में '20130101' में सब कुछ, - 2013 में '20140101' में सब कुछ, - 2014 में सब कुछ '20150101' -- 2015 में सब कुछ); जाओ विभाजन योजना बनाएं [ऑर्डरडेटरेंजपीएसकेम]एपार्टिशन [ऑर्डरडेट रेंजपीएफएन] टू([प्राथमिक], [एफजी2011], [एफजी2012], [एफजी2013], [एफजी2014], [एफजी2015]); टेबल बनाएं [डीबीओ]। [आदेश] ( ] न्यूल, [सबटोटल] [पैसा] न्यूल, [स्टेटस] [टिनींट] नॉट न्यूल, [रिविजननंबर] [टिनींट] न्यूल, [मॉडिफाइडडेट] [डेटटाइम] न्यूल, [शिपमैथोडआईडी] [टिनींट] न्यूल, [शिपडेट] [डेटटाइम] नॉट न्यूल, [ऑर्डरडेट] [डेटटाइम] नॉट न्यूल, [टोटलड्यू] [मनी] न्यूल) ऑन [ऑर्डरडेटरेंजपीएसकेम] (ऑर्डरडेट);

जब हम dbo.Orders के लिए संकुल अनुक्रमणिका बनाते हैं, तो हम इसे STATISTICS_INCREMENTAL के बिना बनाएंगे विकल्प सक्षम है, इसलिए हम बिना किसी वृद्धिशील आंकड़ों वाली पारंपरिक विभाजन तालिका के साथ शुरुआत करेंगे:

वैकल्पिक तालिका [डीबीओ]। 

 आगे हम लगभग 4 मिलियन पंक्तियों में लोड करेंगे, जिसमें मेरी मशीन पर एक मिनट से भी कम समय लगता है:
 
नोकाउंट चालू करें; DECLARE @Loops SMALLINT =0; DECLARE @Increment INT =3000; जबकि @लूप्स <1000BEGIN INSERT [डीबीओ]। [ShipMethodID] ,[ShipDate] ,[OrderDate] ,[TotalDue] ) चुनें [PurchaseOrderID] + @Increment , [EmployeeID] , [VendorID] , [TaxAmt] , [Freight] , [SubTotal] , [RevisionNum] , ] , [संशोधित दिनांक] , [ShipMethodID] , DATEADD(DAY, 365, [ShipDate]), DATEADD(DAY, 365, [OrderDate]), [TotalDue] + 365 FROM [क्रय]।[PurchaseOrderHeader]; चौकी; सेट @ लूप्स =@ लूप्स + 1; SET @Increment =@Increment + 5000;END
 

 डेटा लोड होने के बाद, हम FULLSCAN के साथ आँकड़ों को अपडेट करेंगे (ताकि हम परीक्षणों के लिए एक सुसंगत-जैसा-संभव हिस्टोग्राम बना सकें) और फिर सत्यापित करें कि प्रत्येक विभाजन में हमारे पास कौन सा डेटा है:
 
अद्यतन सांख्यिकी [डीबीओ]। [आदेश] फुलस्कैन के साथ; $PARTITION चुनें। [OrderDateRangePFN]([o]। ] , COUNT(*) AS [Rows_In_Partition]FROM [dbo] से। 

 डेटा लोड होने के बाद प्रत्येक विभाजन में डेटा 
 

 अधिकांश डेटा 2015 के विभाजन में है, लेकिन 2012, 2013 और 2014 के लिए भी डेटा है। और अगर हम अनियंत्रित DMV से आउटपुट की जांच करते हैं sys.dm_db_stats_properties_internal , हम देख सकते हैं कि कोई विभाजन स्तर के आँकड़े मौजूद नहीं हैं:
 
चुनें * [sys] से।[dm_db_stats_properties_internal](OBJECT_ID('dbo.Orders'),1) [node_id] से ऑर्डर करें;
 

 sys.dm_db_stats_properties_internal आउटपुट dbo.Orders के लिए केवल एक आँकड़ा दिखा रहा है 
 
परीक्षा
 

 परीक्षण के लिए एक साधारण क्वेरी की आवश्यकता होती है जिसका उपयोग हम यह सत्यापित करने के लिए कर सकते हैं कि विभाजन उन्मूलन होता है, और आंकड़ों के आधार पर अनुमानों की जांच भी कर सकते हैं। क्वेरी कोई डेटा नहीं लौटाती है, लेकिन इससे कोई फ़र्क नहीं पड़ता, हम ऑप्टिमाइज़र सोच में रुचि रखते हैं यह आँकड़ों के आधार पर वापस आ जाएगा:
 
चुनें * [डीबीओ] से।[आदेश] जहां [आदेश दिनांक] ='2014-04-01';
 

 सेलेक्ट स्टेटमेंट के लिए क्वेरी प्लान 
 

 योजना में क्लस्टर्ड इंडेक्स सीक है, और यदि हम गुणों की जांच करते हैं, तो हम देखते हैं कि यह 4000 पंक्तियों का अनुमान लगाता है, और विभाजन 5 तक पहुंचता है, जिसमें 2014 डेटा होता है।
 

 संकुल अनुक्रमणिका से अनुमानित और वास्तविक जानकारी प्राप्त करें 
 

 यदि हम dbo.Orders तालिका के लिए हिस्टोग्राम को देखते हैं, विशेष रूप से अप्रैल 2014 डेटा के क्षेत्र में, हम देखते हैं कि 2014-04-01 के लिए कोई चरण नहीं है, इसलिए ऑप्टिमाइज़र चरण का उपयोग करके उस तिथि के लिए पंक्तियों की संख्या का अनुमान लगाता है। 2014-04-24 के लिए, जहां AVG_RANGE_ROWS 4000 है (2014-02-14 और 2014-04-23 के बीच किसी एक मान के लिए, अनुकूलक अनुमान लगाएगा कि 4000 पंक्तियाँ वापस आ जाएँगी)।
 
DBCC SHOW_STATISTICS('dbo.Orders','OrdersPK');
 

 dbo.Orders हिस्टोग्राम में वितरण 
 

 अनुमान और योजना पूरी तरह से अपेक्षित है। आइए वृद्धिशील आंकड़े सक्षम करें और देखें कि हमें क्या मिलता है।
 
ALTER INDEX [OrdersPK] ऑन [dbo]।[आदेश] के साथ फिर से तैयार करें (STATISTICS_INCREMENTAL =ON);GO UPDATE Statistics [dbo].[Orders] with FULLSCAN;
 

 यदि हम sys.dm_db_stats_properties_internal के विरुद्ध अपनी क्वेरी फिर से चलाते हैं , हम वृद्धिशील आँकड़े देख सकते हैं:
 

 sys.dm_db_stats_properties_internal वृद्धिशील आँकड़ों की जानकारी दिखा रहा है 
 

 अब हम अपनी क्वेरी को फिर से dbo.Orders पर फिर से चलाते हैं, और हम DBCC FREEPROCCACHE चलाएंगे। सबसे पहले यह सुनिश्चित करने के लिए कि योजना का पुन:उपयोग नहीं किया गया है:
 
DBCC FREEPROCCACHE;GO सेलेक्ट * फ्रॉम [डीबीओ]।[ऑर्डर] जहां [ऑर्डरडेट] ='2014-04-01';
 

 हमें वही योजना और वही अनुमान मिलता है:
 

 सेलेक्ट स्टेटमेंट के लिए क्वेरी प्लान 
 

 संकुल अनुक्रमणिका से अनुमानित और वास्तविक जानकारी प्राप्त करें 
 

 यदि हम dbo.Orders के लिए मुख्य हिस्टोग्राम की जांच करते हैं, तो हमें लगभग पहले जैसा ही हिस्टोग्राम दिखाई देता है:
 
DBCC SHOW_STATISTICS('dbo.Orders','OrdersPK');
 

 dbo.Orders के लिए हिस्टोग्राम, वृद्धिशील आंकड़े सक्षम करने के बाद 
 

 अब, 2014 के डेटा के साथ विभाजन के लिए हिस्टोग्राम की जांच करें (हम इसे अनिर्दिष्ट ट्रेस फ्लैग 2309 का उपयोग करके कर सकते हैं, जो विभाजन संख्या को DBCC SHOW_STATISTICS के अतिरिक्त तर्क के रूप में निर्दिष्ट करने की अनुमति देता है। ):
 
DBCC TRACEON(2309);GODBCC SHOW_STATISTICS('dbo.Orders','OrdersPK', 6);
 

 dbo के 2014 विभाजन के लिए हिस्टोग्राम। वृद्धिशील आँकड़ों को सक्षम करने के बाद आदेश 
 

 यहां हम देखते हैं कि, फिर से, 2014-04-01 के लिए कोई चरण नहीं है, लेकिन 0 RANGE_ROWS हैं 2014-02-13 और 2014-04-05 के बीच, AVG_RANGE_ROWS के साथ का 1. यदि ऑप्टिमाइज़र विभाजन स्तर के आँकड़ों के लिए हिस्टोग्राम का उपयोग कर रहा था, तो 2014-04-01 के लिए पंक्तियों की संख्या का अनुमान 1 होगा।
 

 नोट:क्वेरी योजना में प्रयुक्त के रूप में पहचाना गया विभाजन 5 है, लेकिन आप देखेंगे कि DBCC SHOW_STATISTICS कथन संदर्भ विभाजन 6. धारणा सांख्यिकी मेटाडेटा में एक असंगति है (एक सामान्य ऑफ-बाय-वन त्रुटि, संभवतः 0-आधारित बनाम 1-आधारित गणना के कारण), जिसे भविष्य में ठीक किया जा सकता है या नहीं भी। समझें कि इस समय ट्रेस फ़्लैग का दस्तावेज़ीकरण नहीं किया गया है, और यह कि इसे उत्पादन परिवेश में उपयोग करने की अनुशंसा नहीं की जाती है। 
 
सारांश
 

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