2,135,044,521 पंक्ति तालिका पर अनुक्रमणिका ऑप्टिमाइज़ करें

Question

मुझे एक बड़ी तालिका के साथ I / O समस्या है।

सामान्य आँकड़े

तालिका में निम्नलिखित मुख्य विशेषताएं हैं:

• वातावरण: एज़्योर SQL डेटाबेस (टियर पी 4 प्रीमियम (500 डीटीयू) है)
• पंक्तियाँ: 2,135,044,521
• 1,275 ने विभाजन का उपयोग किया
• गुच्छेदार और विभाजित सूचकांक

नमूना

यह तालिका कार्यान्वयन है:

CREATE TABLE [data].[DemoUnitData](
    [UnitID] [bigint] NOT NULL,
    [Timestamp] [datetime] NOT NULL,
    [Value1] [decimal](18, 2) NULL,
    [Value2] [decimal](18, 2) NULL,
    [Value3] [decimal](18, 2) NULL,
    CONSTRAINT [PK_DemoUnitData] PRIMARY KEY CLUSTERED 
    (
        [UnitID] ASC,
        [Timestamp] ASC
    )
)
GO

ALTER TABLE [data].[DemoUnitData] WITH NOCHECK ADD CONSTRAINT [FK_DemoUnitData_Unit] FOREIGN KEY([UnitID])
REFERENCES [model].[Unit] ([ID])
GO

ALTER TABLE [data].[DemoUnitData] CHECK CONSTRAINT [FK_DemoUnitData_Unit]
GO

विभाजन इस से संबंधित है:

CREATE PARTITION SCHEME [DailyPartitionSchema] AS PARTITION [DailyPartitionFunction] ALL TO ([PRIMARY])

CREATE PARTITION FUNCTION [DailyPartitionFunction] (datetime) AS RANGE RIGHT
FOR VALUES (N'2017-07-25T00:00:00.000', N'2017-07-26T00:00:00.000', N'2017-07-27T00:00:00.000', ... )

सेवा की गुणवत्ता

मुझे लगता है कि अनुक्रमित और आँकड़े हर रात वृद्धिशील पुनर्निर्माण / पुनर्गठन / अद्यतन द्वारा बनाए रखा जाता है।

ये सबसे अधिक उपयोग किए जाने वाले सूचकांक विभाजन के वर्तमान सूचकांक आँकड़े हैं:

ये सबसे अधिक उपयोग किए जाने वाले विभाजन के वर्तमान आँकड़े गुण हैं:

मुसीबत

मैं टेबल के खिलाफ उच्च आवृत्ति पर एक साधारण क्वेरी चलाता हूं।

SELECT [UnitID]
    ,[Timestamp]
    ,[Value1]
    ,[Value2]
    ,[Value3]
FROM [data].[DemoUnitData]
WHERE [UnitID] = 8877 AND [Timestamp] >= '2018-03-01' AND [Timestamp] < '2018-03-13'
OPTION (MAXDOP 1)

निष्पादन योजना इस प्रकार है: https://www.brentozar.com/pastetheplan/?id=rJvI_4TTG

मेरी समस्या यह है कि इन प्रश्नों से आई / ओ संचालन की अत्यधिक मात्रा उत्पन्न होती है जिसके परिणामस्वरूप PAGEIOLATCH_SHप्रतीक्षा की अड़चन होती है ।

सवाल

मैंने पढ़ा है कि PAGEIOLATCH_SHइंतजार अक्सर अच्छी तरह से अनुकूलित नहीं अनुक्रमित से संबंधित होते हैं। क्या आपके पास मेरे / I संचालन को कम करने के लिए कोई सिफारिशें हैं? शायद एक बेहतर सूचकांक जोड़कर?

---

उत्तर 1 - @ S4V1N से टिप्पणी से संबंधित है

पोस्ट की गई क्वेरी योजना SSMS में निष्पादित एक क्वेरी से थी। आपकी टिप्पणी के बाद मैं सर्वर इतिहास पर कुछ शोध करता हूं। सेवा से एक्सक्लूसिव क्वेरी थोड़ी भिन्न (EntityFramework संबंधित) दिखती है।

(@p__linq__0 bigint,@p__linq__1 datetime2(7),@p__linq__2 datetime2(7)) 

SELECT 1 AS [C1], [Extent1] 
   .[Timestamp] AS [Timestamp], [Extent1] 
   .[Value1] AS [Value1], [Extent1] 
   .[Value2] AS [Value2], [Extent1] 
   .[Value3] AS [Value3]  
FROM [data].[DemoUnitData] AS [Extent1]  
WHERE ([Extent1].[UnitID] = @p__linq__0)  
AND ([Extent1].[Timestamp] >= @p__linq__1)  
AND ([Extent1].[Timestamp] < @p__linq__2) OPTION (MAXDOP 1) 

इसके अलावा, योजना अलग दिखती है:

https://www.brentozar.com/pastetheplan/?id=H1fhALpKG

या

https://www.brentozar.com/pastetheplan/?id=S1DFQvpKz

और जैसा कि आप यहाँ देख सकते हैं, हमारे DB प्रदर्शन शायद ही इस क्वेरी से प्रभावित हैं।

उत्तर 2 - @ जोए ओबिश से उत्तर से संबंधित

समाधान के परीक्षण के लिए मैंने एंटिटी फ्रेमवर्क को एक सरल SqlCommand से बदल दिया। परिणाम एक अद्भुत प्रदर्शन को बढ़ावा देने वाला था!

क्वेरी प्लान अब SSMS की तरह ही है और लॉजिकल 8 ~ निष्पादन के लिए ड्रॉप पढ़ता है और लिखता है।

कुल मिलाकर I / O लोड ड्रॉप लगभग 0 है!

यह यह भी बताता है कि मासिक से दैनिक में विभाजन की सीमा को बदलने के बाद मुझे एक बड़ा प्रदर्शन ड्रॉप क्यों मिलता है। विभाजन उन्मूलन के लापता होने से स्कैन करने के लिए अधिक विभाजन हुए।

Comments

निष्पादन योजना को देखते हुए, ऐसा लगता नहीं है कि समस्याग्रस्त बिल्कुल भी नहीं है। इसने केवल आवश्यक विभाजन को कम मात्रा में रीड्स के साथ स्कैन किया है और इसके बजाय पेजियोलेच_श इंतजार (sos_sched ..) की सूचना नहीं दी है। जो समझने योग्य है क्योंकि आपके पास वैसे भी कोई शारीरिक रीड नहीं था। क्या वे संचयी प्रतीक्षा कर रहे हैं, या कुछ निश्चित समय से अधिक हो गए हैं? शायद समस्या कुछ और प्रश्न है।

— एस

मैंने आपसे ऊपर एक विस्तृत उत्तर @ S4V1N पोस्ट किया

— स्टीफन

Answer 1

PAGEIOLATCH_SHयदि आप ORM द्वारा उत्पन्न डेटा प्रकारों को बदलने में सक्षम हैं, तो आप इस क्वेरी के लिए प्रतीक्षा को कम करने में सक्षम हो सकते हैं । Timestampअपनी तालिका में स्तंभ के एक डेटा प्रकार है DATETIMEलेकिन मानकों @p__linq__1और @p__linq__2का डेटा प्रकार है DATETIME2(7)। यही कारण है कि ORM प्रश्नों के लिए क्वेरी योजना पहले क्वेरी योजना की तुलना में बहुत अधिक जटिल है, जिसे आपने हार्डकोड खोज फ़िल्टर में पोस्ट किया था। आप एक्सएमएल में इसका संकेत भी प्राप्त कर सकते हैं:

<ScalarOperator ScalarString="GetRangeWithMismatchedTypes([@p__linq__1],NULL,(22))">

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

मैंने यह सुनिश्चित करने के लिए एक साधारण प्रजनन किया। विभाजन फ़ंक्शन के भीतर 11 विभाजन परिभाषित हैं। इस प्रश्न के लिए:

DECLARE @p__linq__0 bigint = 2000;
DECLARE @p__linq__1 datetime2(7) = '20180103';
DECLARE @p__linq__2 datetime2(7) = '20180104';

SELECT 1 AS [C1]
, [Extent1].[Timestamp] AS [Timestamp]
, [Extent1].[Value1] AS [Value1]
FROM [DemoUnitData] AS [Extent1]  
WHERE ([Extent1].[UnitID] = @p__linq__0)  
AND ([Extent1].[Timestamp] >= @p__linq__1)  
AND ([Extent1].[Timestamp] < @p__linq__2)
OPTION (MAXDOP 1) ;

यहाँ IO कैसा दिखता है:

तालिका 'डेमो यूनीटडाटा'। स्कैन गिनती 11, तार्किक 40 पढ़ता है

जब मैं डेटा प्रकार ठीक करता हूं:

DECLARE @p__linq__0 bigint = 2000;
DECLARE @p__linq__1 datetime = '20180103';
DECLARE @p__linq__2 datetime = '20180104';

SELECT 1 AS [C1]
, [Extent1].[Timestamp] AS [Timestamp]
, [Extent1].[Value1] AS [Value1]
FROM [DemoUnitData] AS [Extent1]  
WHERE ([Extent1].[UnitID] = @p__linq__0)  
AND ([Extent1].[Timestamp] >= @p__linq__1)  
AND ([Extent1].[Timestamp] < @p__linq__2)
OPTION (MAXDOP 1) ;

विभाजन उन्मूलन के परिणामस्वरूप IO कम हो गया है:

तालिका 'डेमो यूनीटडाटा'। स्कैन गिनती 2, तार्किक 8 पढ़ता है