Indexen voor toegewezen SQL-pooltabellen in Azure Synapse Analytics
Aanbevelingen en voorbeelden voor het indexeren van tabellen in een toegewezen SQL-pool in Azure Synapse Analytics.
Indextypen
Toegewezen SQL-pool biedt verschillende indexeringsopties, waaronder geclusterde columnstore-indexen, geclusterde indexen en niet-geclusterde indexen, en een niet-indexoptie, ook wel bekend als heap.
Als u een tabel met een index wilt maken, raadpleegt u de documentatie voor CREATE TABLE (toegewezen SQL-pool).
Geclusterde columnstore-indexen
Standaard maakt een toegewezen SQL-pool een geclusterde columnstore-index wanneer er geen indexopties zijn opgegeven in een tabel. Geclusterde columnstore-tabellen bieden zowel het hoogste niveau van gegevenscompressie als de beste algehele queryprestaties. Geclusterde columnstore-tabellen presteren over het algemeen beter dan geclusterde index- of heap-tabellen en zijn meestal de beste keuze voor grote tabellen. Om deze redenen is geclusterde columnstore de beste plek om te beginnen wanneer u niet zeker weet hoe u de tabel indexeert.
Als u een geclusterde columnstore-tabel wilt maken, geeft u CLUSTERED COLUMNSTORE INDEX gewoon op in de WITH-component of laat u de WITH-component uitgeschakeld:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( CLUSTERED COLUMNSTORE INDEX );
Er zijn enkele scenario's waarin gegroepeerde columnstore mogelijk geen goede optie is:
- Columnstore-tabellen bieden geen ondersteuning voor varchar(max), nvarchar(max) en varbinary(max). Overweeg in plaats daarvan een heap- of geclusterde index.
- Columnstore-tabellen zijn mogelijk minder efficiënt voor tijdelijke gegevens. Overweeg heap en misschien zelfs tijdelijke tafels.
- Kleine tabellen met minder dan 60 miljoen rijen. Overweeg heap tafels.
Heap-tabellen
Wanneer u tijdelijk gegevens in een toegewezen SQL-pool plaatst, kunt u merken dat het algehele proces sneller verloopt met behulp van een heap-tabel. Dit komt doordat het laden van heaps sneller is dan het indexeren van tabellen en in sommige gevallen kan de volgende leesbewerking worden uitgevoerd vanuit de cache. Als u alleen gegevens laadt om deze te fasen voordat u meer transformaties uitvoert, is het laden van de tabel naar een heap-tabel veel sneller dan het laden van de gegevens in een geclusterde columnstore-tabel. Bovendien wordt het laden van gegevens naar een tijdelijke tabel sneller geladen dan het laden van een tabel naar permanente opslag. Nadat gegevens zijn geladen, kunt u indexen in de tabel maken voor snellere queryprestaties.
Clusters columnstore-tabellen beginnen optimale compressie te bereiken zodra er meer dan 60 miljoen rijen zijn. Voor kleine opzoektabellen, minder dan 60 miljoen rijen, kunt u overwegen HEAP of geclusterde index te gebruiken voor snellere queryprestaties.
Als u een heap-tabel wilt maken, geeft u heap op in de WITH-component:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( HEAP );
Notitie
Als u vaak bewerkingen UPDATEuitvoert INSERTop DELETE een heap-tabel, is het raadzaam om tabelrebouw in uw onderhoudsschema op te nemen met behulp van ALTER TABLE de opdracht. Bijvoorbeeld: ALTER TABLE [SchemaName].[TableName] REBUILD. Deze praktijk draagt bij aan verminderde fragmentatie, wat resulteert in verbeterde prestaties tijdens leesbewerkingen.
Geclusterde en niet-geclusterde indexen
Geclusterde indexen presteren mogelijk beter dan geclusterde columnstore-tabellen wanneer één rij snel moet worden opgehaald. Voor query's waarbij één of zeer weinig rijen opzoeken is vereist voor extreme snelheid, kunt u een geclusterde index of niet-geclusterde secundaire index overwegen. Het nadeel van het gebruik van een geclusterde index is dat alleen query's die baat hebben bij het gebruik van een zeer selectief filter op de geclusterde indexkolom. Als u het filter op andere kolommen wilt verbeteren, kan een niet-geclusterde index worden toegevoegd aan andere kolommen. Elke index die aan een tabel wordt toegevoegd, voegt echter zowel ruimte als verwerkingstijd toe aan het laden.
Als u een geclusterde indextabel wilt maken, geeft u GEWOON GECLUSTERDE INDEX op in de WITH-component:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( CLUSTERED INDEX (id) );
Gebruik de volgende syntaxis om een niet-geclusterde index toe te voegen aan een tabel:
CREATE INDEX zipCodeIndex ON myTable (zipCode);
Geclusterde columnstore-indexen optimaliseren
Gegroepeerde columnstore-tabellen organiseren gegevens in segmenten. Een hoge segmentkwaliteit is essentieel voor het bereiken van optimale queryprestaties in een columnstore-tabel. Segmentkwaliteit kan worden gemeten aan de hand van het aantal rijen in een gecomprimeerde rijengroep. Segmentkwaliteit is het meest optimaal wanneer er ten minste 100 K rijen per gecomprimeerde rijgroep zijn en de prestaties verbeteren als het aantal rijen per rijgroep benadering 1.048.576 rijen is. Dit zijn de meeste rijen die een rijgroep kan bevatten.
De onderstaande weergave kan worden gemaakt en gebruikt op uw systeem om de gemiddelde rijen per rijgroep te berekenen en suboptimale columnstore-indexen voor clusters te identificeren. In de laatste kolom in deze weergave wordt een SQL-instructie gegenereerd die kan worden gebruikt om uw indexen opnieuw op te bouwen.
CREATE VIEW dbo.vColumnstoreDensity
AS
SELECT
GETDATE() AS [execution_date]
, DB_Name() AS [database_name]
, s.name AS [schema_name]
, t.name AS [table_name]
, COUNT(DISTINCT rg.[partition_number]) AS [table_partition_count]
, SUM(rg.[total_rows]) AS [row_count_total]
, SUM(rg.[total_rows])/COUNT(DISTINCT rg.[distribution_id]) AS [row_count_per_distribution_MAX]
, CEILING ((SUM(rg.[total_rows])*1.0/COUNT(DISTINCT rg.[distribution_id]))/1048576) AS [rowgroup_per_distribution_MAX]
, SUM(CASE WHEN rg.[State] = 0 THEN 1 ELSE 0 END) AS [INVISIBLE_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE 0 END) AS [INVISIBLE_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 1 THEN 1 ELSE 0 END) AS [OPEN_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE 0 END) AS [OPEN_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 2 THEN 1 ELSE 0 END) AS [CLOSED_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE 0 END) AS [CLOSED_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 3 THEN 1 ELSE 0 END) AS [COMPRESSED_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE 0 END) AS [COMPRESSED_rowgroup_rows]
, SUM(CASE WHEN rg.[State] = 3 THEN rg.[deleted_rows] ELSE 0 END) AS [COMPRESSED_rowgroup_rows_DELETED]
, MIN(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_AVG]
, 'ALTER INDEX ALL ON ' + s.name + '.' + t.NAME + ' REBUILD;' AS [Rebuild_Index_SQL]
FROM sys.[pdw_nodes_column_store_row_groups] rg
JOIN sys.[pdw_nodes_tables] nt ON rg.[object_id] = nt.[object_id]
AND rg.[pdw_node_id] = nt.[pdw_node_id]
AND rg.[distribution_id] = nt.[distribution_id]
JOIN sys.[pdw_table_mappings] mp ON nt.[name] = mp.[physical_name]
JOIN sys.[tables] t ON mp.[object_id] = t.[object_id]
JOIN sys.[schemas] s ON t.[schema_id] = s.[schema_id]
GROUP BY
s.[name]
, t.[name];
Nu u de weergave hebt gemaakt, voert u deze query uit om tabellen met rijgroepen met minder dan 100 K-rijen te identificeren. U kunt de drempelwaarde van 100 K verhogen als u op zoek bent naar een optimale segmentkwaliteit.
SELECT *
FROM [dbo].[vColumnstoreDensity]
WHERE COMPRESSED_rowgroup_rows_AVG < 100000
OR INVISIBLE_rowgroup_rows_AVG < 100000;
Zodra u de query hebt uitgevoerd, kunt u beginnen met het bekijken van de gegevens en het analyseren van uw resultaten. In deze tabel wordt uitgelegd wat u moet zoeken in de analyse van de rijgroep.
| Kolom | Deze gegevens gebruiken |
|---|---|
| [table_partition_count] | Als de tabel is gepartitioneerd, kunt u verwachten dat er hogere aantallen Open-rijgroepen worden weergegeven. Aan elke partitie in de distributie kan in theorie een open rijgroep zijn gekoppeld. Factor dit in uw analyse. Een kleine tabel die is gepartitioneerd, kan worden geoptimaliseerd door de partitionering helemaal te verwijderen, omdat dit de compressie zou verbeteren. |
| [row_count_total] | Totaal aantal rijen voor de tabel. U kunt deze waarde bijvoorbeeld gebruiken om het percentage rijen met de gecomprimeerde status te berekenen. |
| [row_count_per_distribution_MAX] | Als alle rijen gelijkmatig worden verdeeld, is deze waarde het doelaantal rijen per distributie. Vergelijk deze waarde met de compressed_rowgroup_count. |
| [COMPRESSED_rowgroup_rows] | Totaal aantal rijen in columnstore-indeling voor de tabel. |
| [COMPRESSED_rowgroup_rows_AVG] | Als het gemiddelde aantal rijen aanzienlijk kleiner is dan het maximum aantal rijen voor een rijgroep, kunt u CTAS of ALTER INDEX REBUILD gebruiken om de gegevens opnieuw te compileren |
| [COMPRESSED_rowgroup_count] | Aantal rijgroepen in columnstore-indeling. Als dit getal zeer hoog is ten opzichte van de tabel, is het een indicator dat de columnstore-dichtheid laag is. |
| [COMPRESSED_rowgroup_rows_DELETED] | Rijen worden logisch verwijderd in columnstore-indeling. Als het getal hoog is ten opzichte van de tabelgrootte, kunt u overwegen de partitie opnieuw te maken of de index opnieuw te bouwen, omdat deze fysiek worden verwijderd. |
| [COMPRESSED_rowgroup_rows_MIN] | Gebruik dit met de kolommen AVG en MAX om inzicht te verkrijgen in het bereik van waarden voor de rijgroepen in uw columnstore. Een laag aantal boven de laaddrempel (102.400 per uitgelijnde partitieverdeling) geeft aan dat optimalisaties beschikbaar zijn in de gegevensbelasting |
| [COMPRESSED_rowgroup_rows_MAX] | Zoals hierboven |
| [OPEN_rowgroup_count] | Open rijgroepen zijn normaal. U zou redelijkerwijs één OPEN-rijgroep per tabeldistributie (60) verwachten. Overmatige getallen suggereren dat gegevens over partities worden geladen. Controleer de partitioneringsstrategie om er zeker van te zijn dat deze goed klinkt |
| [OPEN_rowgroup_rows] | Elke rijgroep kan maximaal 1.048.576 rijen bevatten. Gebruik deze waarde om te zien hoe vol de geopende rijgroepen momenteel zijn |
| [OPEN_rowgroup_rows_MIN] | Open groepen geven aan dat gegevens worden geladen in de tabel of dat de vorige belasting overblijft over resterende rijen in deze rijgroep. Gebruik de kolommen MIN, MAX, AVG om te zien hoeveel gegevens in OPEN-rijgroepen zijn opgenomen. Voor kleine tabellen kan dit 100% van alle gegevens zijn. In dat geval wijzigT U INDEX REBUILD om de gegevens af te dwingen tot columnstore. |
| [OPEN_rowgroup_rows_MAX] | Zoals hierboven |
| [OPEN_rowgroup_rows_AVG] | Zoals hierboven |
| [CLOSED_rowgroup_rows] | Bekijk de gesloten rijgroeprijen als een sanity-controle. |
| [CLOSED_rowgroup_count] | Het aantal gesloten rijgroepen moet laag zijn als er helemaal geen groepen worden gezien. Gesloten rijgroepen kunnen worden geconverteerd naar gecomprimeerde rijgroepen met de ALTER INDEX ... Opdracht OPNIEUW ORDE GEVEN. Dit is echter normaal gesproken niet vereist. Gesloten groepen worden automatisch geconverteerd naar columnstore-rijgroepen door het achtergrondproces 'tuple mover'. |
| [CLOSED_rowgroup_rows_MIN] | Gesloten rijgroepen moeten een zeer hoge vulsnelheid hebben. Als de vulsnelheid voor een gesloten rijgroep laag is, is verdere analyse van de columnstore vereist. |
| [CLOSED_rowgroup_rows_MAX] | Zoals hierboven |
| [CLOSED_rowgroup_rows_AVG] | Zoals hierboven |
| [Rebuild_Index_SQL] | SQL voor het opnieuw samenstellen van columnstore-index voor een tabel |
Impact van indexonderhoud
De kolom Rebuild_Index_SQL in de vColumnstoreDensity weergave bevat een ALTER INDEX REBUILD instructie die kan worden gebruikt om uw indexen opnieuw te bouwen. Zorg er bij het opnieuw opbouwen van uw indexen voor dat u voldoende geheugen toewijst aan de sessie waarmee uw index opnieuw wordt opgebouwd. Als u dit wilt doen, verhoogt u de resourceklasse van een gebruiker met machtigingen om de index in deze tabel opnieuw op te bouwen tot het aanbevolen minimum. Zie Indexen opnieuw opbouwen om de segmentkwaliteit verderop in dit artikel te verbeteren.
Voor een tabel met een geordende geclusterde columnstore-index worden ALTER INDEX REBUILD de gegevens opnieuw gesorteerd met behulp van tempdb. Tempdb bewaken tijdens herbouwbewerkingen. Als u meer tempdb-ruimte nodig hebt, schaalt u de databasegroep omhoog. Terugschalen zodra het opnieuw opbouwen van de index is voltooid.
Voor een tabel met een geordende geclusterde columnstore-index worden ALTER INDEX REORGANIZE de gegevens niet opnieuw gesorteerd. Als u gegevens opnieuw wilt sorteren, gebruikt u ALTER INDEX REBUILD.
Oorzaken van slechte kwaliteit voor columnstore-indexen
Als u tabellen met een slechte segmentkwaliteit hebt geïdentificeerd, wilt u de hoofdoorzaak identificeren. Hieronder ziet u enkele andere veelvoorkomende oorzaken van slechte segmentkwaliteit:
- Geheugendruk toen index werd gebouwd
- Groot aantal DML-bewerkingen
- Kleine of trickle load-bewerkingen
- Te veel partities
Deze factoren kunnen ertoe leiden dat een columnstore-index aanzienlijk kleiner is dan de optimale 1 miljoen rijen per rijgroep. Ze kunnen er ook voor zorgen dat rijen naar de deltarijgroep gaan in plaats van een gecomprimeerde rijgroep.
Geheugendruk toen index werd gebouwd
Het aantal rijen per gecomprimeerde rijgroep is rechtstreeks gerelateerd aan de breedte van de rij en de hoeveelheid geheugen die beschikbaar is om de rijgroep te verwerken. Wanneer rijen naar columnstore-tabellen worden geschreven onder geheugendruk, kan dit ten koste gaan van de kwaliteit van columnstore-segmenten. Daarom is het raadzaam om de sessie die naar uw columnstore-indextabellen schrijft, toegang te geven tot zoveel mogelijk geheugen. Omdat er sprake is van een afweging tussen geheugen en gelijktijdigheid, zijn de richtlijnen voor de juiste geheugentoewijzing afhankelijk van de gegevens in elke rij van uw tabel, de datawarehouse-eenheden die aan uw systeem zijn toegewezen en het aantal gelijktijdigheidssites dat u kunt geven aan de sessie die gegevens naar uw tabel schrijft.
Groot aantal DML-bewerkingen
Een groot aantal DML-bewerkingen waarmee rijen worden bijgewerkt en verwijderd, kan leiden tot inefficiëntie in de columnstore. Dit geldt met name wanneer de meeste rijen in een rijgroep worden gewijzigd.
- Als u een rij uit een gecomprimeerde rijgroep verwijdert, wordt de rij alleen logisch gemarkeerd als verwijderd. De rij blijft in de gecomprimeerde rijgroep totdat de partitie of tabel opnieuw wordt opgebouwd.
- Als u een rij invoegt, wordt de rij toegevoegd aan een interne rijstore-tabel met de naam een deltarijgroep. De ingevoegde rij wordt pas geconverteerd naar columnstore als de deltarijgroep vol is en is gemarkeerd als gesloten. Rijgroepen worden gesloten zodra ze de maximale capaciteit van 1.048.576 rijen bereiken.
- Het bijwerken van een rij in columnstore-indeling wordt verwerkt als een logische verwijdering en vervolgens een invoegbewerking. De ingevoegde rij kan worden opgeslagen in het Delta-archief.
Bijwerken en invoegen in batchbewerkingen die de bulkdrempel van 102.400 rijen per partitie uitgelijnde distributie overschrijden, gaan rechtstreeks naar de columnstore-indeling. Uitgaande van een gelijkmatige verdeling moet u echter meer dan 6,144 miljoen rijen in één bewerking wijzigen om dit te kunnen doen. Als het aantal rijen voor een bepaalde partitie uitgelijnde distributie kleiner is dan 102.400, gaan de rijen naar het Delta-archief en blijven ze daar totdat er voldoende rijen zijn ingevoegd of gewijzigd om de rijgroep te sluiten of de index opnieuw is opgebouwd.
Kleine of trickle load-bewerkingen
Kleine belastingen die in een toegewezen SQL-pool stromen, worden ook wel 'trickle loads' genoemd. Ze vertegenwoordigen doorgaans een bijna constante stroom van gegevens die door het systeem worden opgenomen. Omdat deze stroom echter bijna continu is, is het volume van rijen niet bijzonder groot. Vaker dan niet de gegevens vallen onder de drempelwaarde die nodig is voor een directe belasting naar columnstore-indeling.
In deze situaties is het vaak beter om de gegevens eerst in Azure Blob Storage te plaatsen en deze te laten verzamelen voordat ze worden geladen. Deze techniek wordt vaak microbatch genoemd.
Te veel partities
Een ander wat u moet overwegen, is de impact van partitionering op uw geclusterde columnstore-tabellen. Voordat u partitioneert, verdeelt de toegewezen SQL-pool uw gegevens al in 60 databases. Door het partitioneren worden uw gegevens verder verdeeld. Als u uw gegevens partitioneert, moet u er rekening mee houden dat elke partitie ten minste 1 miljoen rijen nodig heeft om te profiteren van een geclusterde columnstore-index. Als u uw tabel partitioneert in 100 partities, heeft uw tabel ten minste 6 miljard rijen nodig om te profiteren van een geclusterde columnstore-index (60 distributies 100 partities 1 miljoen rijen). Als uw tabel met 100 partities geen 6 miljard rijen heeft, vermindert u het aantal partities of kunt u overwegen een heap-tabel te gebruiken.
Zodra uw tabellen zijn geladen met enkele gegevens, volgt u de onderstaande stappen om tabellen te identificeren en opnieuw te bouwen met suboptimale geclusterde columnstore-indexen.
Indexen herbouwen om de segmentkwaliteit te verbeteren
Stap 1: Een gebruiker identificeren of maken die gebruikmaakt van de juiste resourceklasse
Een snelle manier om de segmentkwaliteit onmiddellijk te verbeteren, is door de index opnieuw te bouwen. De SQL die door de bovenstaande weergave wordt geretourneerd, bevat een INSTRUCTIE ALTER INDEX REBUILD, die kan worden gebruikt om uw indexen opnieuw op te bouwen. Zorg er bij het opnieuw opbouwen van uw indexen voor dat u voldoende geheugen toewijst aan de sessie waarmee uw index opnieuw wordt opgebouwd. Als u dit wilt doen, verhoogt u de resourceklasse van een gebruiker met machtigingen om de index in deze tabel opnieuw op te bouwen tot het aanbevolen minimum.
Hieronder ziet u een voorbeeld van het toewijzen van meer geheugen aan een gebruiker door de resourceklasse te verhogen. Als u met resourceklassen wilt werken, raadpleegt u Resourceklassen voor workloadbeheer.
EXEC sp_addrolemember 'xlargerc', 'LoadUser';
Stap 2: Geclusterde columnstore-indexen herbouwen met een hogere resourceklassegebruiker
Meld u aan als de gebruiker uit stap 1 (LoadUser), die nu een hogere resourceklasse gebruikt en voer de ALTER INDEX-instructies uit. Zorg ervoor dat deze gebruiker alter-machtigingen heeft voor de tabellen waar de index opnieuw wordt opgebouwd. In deze voorbeelden ziet u hoe u de volledige columnstore-index herbouwt of hoe u één partitie opnieuw bouwt. Bij grote tabellen is het praktischer om indexen één partitie tegelijk opnieuw te bouwen.
U kunt de tabel ook kopiëren naar een nieuwe tabel in plaats van de index opnieuw te bouwen met behulp van CTAS. Welke manier is het beste? Voor grote hoeveelheden gegevens is CTAS meestal sneller dan ALTER INDEX. Voor kleinere hoeveelheden gegevens is ALTER INDEX gemakkelijker te gebruiken en hoeft u de tabel niet te wisselen.
-- Rebuild the entire clustered index
ALTER INDEX ALL ON [dbo].[DimProduct] REBUILD;
-- Rebuild a single partition
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5;
-- Rebuild a single partition with archival compression
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5 WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);
-- Rebuild a single partition with columnstore compression
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5 WITH (DATA_COMPRESSION = COLUMNSTORE);
Het herbouwen van een index in een toegewezen SQL-pool is een offlinebewerking. Zie de sectie ALTER INDEX REBUILD in Columnstore Indexes Defragmentatie en ALTER INDEX voor meer informatie over het opnieuw opbouwen van indexen.
Stap 3: Controleren of de segmentkwaliteit van een geclusterde columnstore is verbeterd
Voer de query opnieuw uit die een tabel met een slechte segmentkwaliteit heeft geïdentificeerd en controleer of de segmentkwaliteit is verbeterd. Als de segmentkwaliteit niet is verbeterd, kan het zijn dat de rijen in de tabel extra breed zijn. Overweeg om een hogere resourceklasse of DWU te gebruiken bij het opnieuw opbouwen van uw indexen.
Indexen herbouwen met CTAS en partitiewisseling
In dit voorbeeld wordt de instructie CREATE TABLE AS SELECT (CTAS) en partitiewisseling gebruikt om een tabelpartitie opnieuw te bouwen.
-- Step 1: Select the partition of data and write it out to a new table using CTAS
CREATE TABLE [dbo].[FactInternetSales_20000101_20010101]
WITH ( DISTRIBUTION = HASH([ProductKey])
, CLUSTERED COLUMNSTORE INDEX
, PARTITION ( [OrderDateKey] RANGE RIGHT FOR VALUES
(20000101,20010101
)
)
)
AS
SELECT *
FROM [dbo].[FactInternetSales]
WHERE [OrderDateKey] >= 20000101
AND [OrderDateKey] < 20010101
;
-- Step 2: Switch IN the rebuilt data with TRUNCATE_TARGET option
ALTER TABLE [dbo].[FactInternetSales_20000101_20010101] SWITCH PARTITION 2 TO [dbo].[FactInternetSales] PARTITION 2 WITH (TRUNCATE_TARGET = ON);
Zie Partities gebruiken in een toegewezen SQL-pool voor meer informatie over het opnieuw maken van partities met behulp van CTAS.
Volgende stappen
Zie Tabellen ontwikkelen voor meer informatie over het ontwikkelen van tabellen.