Online indexbewerkingen op partitieniveau verkennen in SQL Server 2014 CTP1

SQL Server 2014 CTP1 introduceert uitbreidingen voor online bewerkingsopties die goed nieuws zullen zijn voor bedrijven die zeer grote databases hosten die weinig tot geen downtime vereisen.

Om de context in te stellen, stelt u zich voor dat u SQL Server 2012 Enterprise Edition gebruikt voor de functies voor online indexbeheer en indexpartitionering en u probeert de volgende index opnieuw op te bouwen op een gepartitioneerde tabel:

ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber]
ON [dbo].[FactInternetSales]
REBUILD PARTITION = ALL
WITH (ONLINE= ON);

Door dit in SQL Server 2012 te testen, zijn we in staat om alle partities zonder fouten online opnieuw op te bouwen. Maar wat als we een specifieke partitie willen specificeren in plaats van alle partities?

ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber]
ON [dbo].[FactInternetSales]
REBUILD PARTITION = 1
WITH (ONLINE= ON);

Als u dit probeert in SQL Server 2012 of eerder, ziet u het volgende foutbericht:

Maar vanaf SQL Server 2014 (vanaf CTP1) worden online indexbewerkingen met één partitie nu ondersteund. En dit is zeker een groot probleem voor scenario's voor het onderhoud van zeer grote tafels waar u de voorkeur geeft aan, of zelfs uw algehele onderhoud in de loop van de tijd in kleinere stukken moet breken. U kunt ook onderhoud op partitieniveau uitvoeren voor alleen die partities die dit echt nodig hebben, bijvoorbeeld die partities die een bepaald fragmentatieniveau overschrijden.

Om deze SQL Server 2014 CTP1-functionaliteit te testen, gebruikte ik de AdventureWorksDW2012 met een versie van FactInternetSales die 61.847.552 rijen bevat en gepartitioneerd door de ShipDate-kolom.

Alle partities online opnieuw opbouwen voor de tabel met PARTITION = ALL in mijn testomgeving duurde het 3 minuten en 23 seconden. Wat betreft de totale duur, mijn tests waren voor indexen die niet zo gefragmenteerd waren, dus de duur van 3 minuten en 23 seconden vertegenwoordigt een gemiddelde duur over een paar tests. Houd er ook rekening mee dat ik op dat moment geen concurrerende workloads had, dus het online opnieuw opbouwen gebeurt zonder te hoeven concurreren met andere belangrijke workloads tegen de betreffende index.

De vorm van het query-uitvoeringsplan voor het opnieuw opbouwen van de online index met behulp van PARTITION = ALL was als volgt:

Uitvoeringsplan voor online heropbouw van alle partities

Merk op dat de bewerkingen parallel zijn ingeschakeld, behalve voor de Constant Scan-operator. In het uitvoeringsplan voor query's ziet u 39 rijen in de buitenste referentie Constant Scan die worden doorgegeven aan de operator Distribute Streams en vervolgens de geneste lus aansturen.

De betekenis van de 39 rijen? De volgende query valideert het maximale aantal partities van sys.dm_db_partition_stats . Voor mijn testomgeving was het resultaat 39 voor het maximale partitienummer, wat overeenkomt met wat ik zag voor de werkelijke rijen van Constant Scan:

SELECT MAX([partition_number]) AS [max_partition_number]
FROM [sys].[dm_db_partition_stats]
WHERE [object_id] = OBJECT_ID('FactInternetSales');

Nu zult u ook de Online Index Insert-operator opmerken in het vorige plan. Het verwijderen van de ONLINE = ON optie uit mijn ALTER INDEX REBUILD (waardoor het een offline bewerking wordt), en het behouden van de PARTITION = ALL optie, de enige verandering was het hebben van een "Index Insert"-operator in plaats van een "Online Index Insert" in het query-uitvoeringsplan - en ook een vermindering van de duur, waar mijn test een uitvoeringsduur van 1 minuut en 9 seconden liet zien in vergelijking met de online 3 minuten en 23 seconden.

Ik testte toen een online herbouw van één partitie met 5.678.080 rijen erin (onthoud dat het totale aantal rijen in de tabel 61.847.552 rijen is). Voor deze test duurde de totale duur precies 1 minuut en had het de volgende vorm van het uitvoeringsplan voor de query:

Uitvoeringsplan voor online heropbouw van een enkele partitie

De eerste observatie is dat dit een serieel plan is. Merk ook op dat ik zei dat ik één partitie uit de oorspronkelijke 39 had gekozen, hoewel die specifieke partitie in totaal ~ 9% van de rijen in de tabel vertegenwoordigde. Merk ook op dat de Constant Scan 1 rij toont in plaats van 39, zoals ik zou verwachten.

Hoe zit het met de duur van een enkele partitie, offline opnieuw opbouwen? In mijn testomgeving duurde dit 11 seconden vergeleken met de online rebuild 1 minuut. De vorm van het uitvoeringsplan voor de query voor het offline opnieuw opbouwen van een enkele partitie was als volgt:

Uitvoeringsplan voor offline opnieuw opbouwen van een enkele partitie

Merk op dat er geen Constant Scan of bijbehorend Nested Loops-proces is en merk ook op dat dit plan nu parallelle operators bevat ten opzichte van het vorige seriële plan, ook al doen ze allebei een Clustered Index Scan voor 5.678.080 rijen. Ook het zoeken op trefwoord van "partitie" in de XML-plantekst voor de offline parallelle indexbewerking met enkele partitie resulteerde niet in overeenkomsten - vergeleken met het seriële plan, online enkele partitie-indexbewerking die Partitioned ="true" had voor de Geclusterde Index Scan en Online Index Fysieke operators invoegen.

Terug naar de hoofdverkenning…

Kan ik een paar, maar niet alle partities in één uitvoering kiezen? Jammer genoeg niet.

De ALTER INDEX en ALTER TABLE commando's hebben de PARTITION = ALL argument en dan PARTITION = <partition number> argument, maar niet de mogelijkheid om meerdere partities weer te geven voor een enkele herbouwbewerking. Ik klaag hier echter niet al te hard over, want ik ben blij dat ik de mogelijkheid heb om een ​​enkele partitie online opnieuw op te bouwen en het is niet erg ingewikkeld om de bewerking één keer uit te voeren voor elke herbouw, maar de cumulatieve impact op de duur was iets Ik wilde verder verkennen.

Hoe lang zou het duren om alle 39 partities afzonderlijk en online opnieuw op te bouwen versus de PARTITION = ALL duur van 3 minuten en 23 seconden?

We weten dat een voordeel van online rebuilds de mogelijkheid is om nog steeds toegang te krijgen tot de bijbehorende tabel of index tijdens de indexbewerking. Maar in ruil voor die online operatie, verliezen we het prestatievoordeel van de rebuild in vergelijking met een offline rebuild. En wat ik vervolgens wilde weten, was hoe een online-reconstructie van een partitie één voor één zou presteren versus de PARTITION = ALL alternatief.

Door 39 afzonderlijke herbouwbewerkingen uit te voeren (één herbouw voor elke unieke partitie), was de totale uitvoeringsduur 9 minuten en 54 seconden vergeleken met de PARTITION = ALL wat 3 minuten en 23 seconden duurde, dus het is duidelijk dat de stapsgewijze aanpak cumulatief niet zo snel is als een online herbouw van alle partities in één instructie. Hoewel ik in staat was om één partitie tegelijk te doen, is het overkoepelende voordeel de mogelijkheid om onze onderhoudsactiviteiten in de loop van de tijd op te splitsen en toegang te houden tot de objecten terwijl ze opnieuw worden opgebouwd, maar als u op zoek bent naar een kortere verbouwing venster, offline opties zijn nog steeds de snelste, gevolgd door online voor PARTITION = ALL en dan op de laatste plaats, één partitie tegelijk doen.

De volgende tabel geeft een samenvatting van de duurvergelijkingen - en nogmaals, deze tests waren gebaseerd op SQL Server 2014 CTP1 en een zeer specifieke tabelgrootte en VM-gastconfiguratie, dus besteed meer aandacht aan de relatieve duur van alle tests in plaats van de duur zelf:

Nu zijn er ook andere aspecten over dit onderwerp te onderzoeken. Alleen omdat een operatie online is, betekent niet dat er geen enkele momenten (of langer) zijn waarop sloten nog steeds op het doelobject worden vastgehouden. Indexbewerkingen hebben nog steeds vergrendelingsgedrag voor online bewerkingen - en SQL Server 2014 heeft hier ook opties voor geboden die ik in een apart bericht zal onderzoeken.