Az Azure Synapse Analytics dedikált SQL készletének táblákon elhelyezett indexei

Javaslatok és példák táblák indexelésével az Azure Synapse Analytics dedikált SQL-készletében.

Indextípusok

A dedikált SQL-készlet számos indexelési lehetőséget kínál, beleértve a fürtözött oszlopcentrikus indexeket, a fürtözött és a nem fürtözött indexeket, valamint a halomnak is nevezett nem indexelési lehetőséget.

Ha indexet tartalmazó táblát szeretne létrehozni, tekintse meg a CREATE TABLE (dedikált SQL-készlet) dokumentációját.

Fürtözött oszlop-tároló indexek

A dedikált SQL-készlet alapértelmezés szerint fürtözött oszlopcentrikus indexet hoz létre, ha nincsenek megadva indexbeállítások egy táblában. A fürtözött oszlopcentrikus táblák a legmagasabb szintű adattömörítést és a legjobb teljes lekérdezési teljesítményt kínálják. Az oszlopalapú csoportosított táblák jellemzően felülmúlják a fürtözött index- vagy halomtáblákat, és a nagy méretű táblák esetében általában a legjobb választást jelentik. Ezért a fürtözött oszloptár a legjobb kiindulópont, ha nem biztos abban, hogy miként indexelheti a táblát.

Fürtözött oszlopcentrikus tábla létrehozásához adja meg a CLUSTERED COLUMNSTORE INDEX paramétert a WITH záradékban, vagy hagyja el a WITH záradékot.

CREATE TABLE myTable
  (  
    id int NOT NULL,  
    lastName varchar(20),  
    zipCode varchar(6)  
  )  
WITH ( CLUSTERED COLUMNSTORE INDEX );

Vannak olyan esetek, amikor a fürtözött oszlopcentrikus adattároló nem feltétlenül jó megoldás:

• Az oszlopcentrikus táblák nem támogatják a varchar(max), az nvarchar(max) és a varbinary(max) adattípusokat. Fontolja meg inkább a halom vagy a fürtözött index használatát.
• Az oszlopcentrikus táblák kevésbé hatékonyak lehetnek az átmeneti adatok esetében. Fontolja meg a halom- és ideiglenes táblákat.
• 60 milliónál kevesebb sorból álló kis táblák. Fontolja meg a halomtáblákat.

Heap típusú táblák

Ha ideiglenesen a dedikált SQL-készletben ad le adatokat, azt tapasztalhatja, hogy a halomtábla használatával gyorsabb lesz az általános folyamat. Ennek az az oka, hogy a halomba való betöltés gyorsabb, mint a táblák indexelése, és bizonyos esetekben a későbbi olvasás elvégezhető a gyorsítótárból. Ha csak a további átalakítások előtti előkészítés céljából tölti be az adatokat, a hozzátáblázatba való betöltés sokkal gyorsabb, mint a fürtözött oszlopos táblába való betöltés. Emellett az adatok ideiglenes táblába való betöltése gyorsabban töltődik be, mint egy tábla állandó tárolóba való betöltése. Az adatok betöltése után indexeket hozhat létre a táblában a gyorsabb lekérdezési teljesítmény érdekében.

A klaszter oszlopcentrikus táblák több mint 60 millió sor esetén érik el az optimális tömörítést. A kisebb, 60 millió sornál kisebb keresési táblák esetében érdemes heap vagy fürtözött indexet használni a gyorsabb lekérdezési teljesítmény érdekében.

Halomtábla létrehozásához adja meg a HEAP értéket a WITH záradékban:

CREATE TABLE myTable
  (  
    id int NOT NULL,  
    lastName varchar(20),  
    zipCode varchar(6)  
  )  
WITH ( HEAP );

Feljegyzés

Ha gyakran végez INSERTvagy UPDATEDELETE műveletet végez egy halomtáblán, ajánlott a tábla újraépítését belefoglalni a karbantartási ütemtervbe a parancs használatávalALTER TABLE. Például: ALTER TABLE [SchemaName].[TableName] REBUILD. Ez a gyakorlat hozzájárul a töredezettség csökkentéséhez, ami jobb teljesítményt eredményez az olvasási műveletek során.

Fürtözött és nemclustered indexek

A fürtözött indexek felülmúlhatják a fürtözött oszlopcentrikus táblákat, ha egy sort gyorsan le kell kérni. Olyan lekérdezések esetében, ahol egy vagy nagyon kevés sorkeresésre van szükség a szélsőséges sebesség végrehajtásához, fontolja meg a fürtözött indexet vagy a nemclustered másodlagos indexet. A fürtözött indexek használatának hátránya, hogy a fürtözött indexoszlopon csak azok a lekérdezések használhatók, amelyek nagy mértékben szelektív szűrőt használnak. A többi oszlop szűrésének javítása érdekében nem klaszterezett index adható más oszlopokhoz. A táblához hozzáadott indexek azonban helyet és feldolgozási időt is hozzáadnak a betöltésekhez.

Fürtözött indextábla létrehozásához adja meg a FÜRTÖZÖTT INDEXet a WITH záradékban:

CREATE TABLE myTable
  (  
    id int NOT NULL,  
    lastName varchar(20),  
    zipCode varchar(6)  
  )  
WITH ( CLUSTERED INDEX (id) );

Ha nemclustered indexet szeretne hozzáadni egy táblához, használja a következő szintaxist:

CREATE INDEX zipCodeIndex ON myTable (zipCode);

Klaszterezett oszlopalapú indexek optimalizálása

A csoportosított oszlopcentrikus táblák szegmensekbe rendezik az adatokat. A magas szegmensminőség kritikus fontosságú az oszlopcentrikus táblákban az optimális lekérdezési teljesítmény eléréséhez. A szegmensminőség a tömörített sorcsoportokban található sorok száma alapján mérhető fel. A szegmensminőség akkor a legoptimálisabb, ha tömörített sorcsoportonként legalább 100 K sor található, és a sorcsoportonkénti sorok száma 1 048 576 sorhoz közelít, ami a sorcsoportok által tartalmazható legtöbb sor.

Az alábbi nézet létrehozható és használható a rendszeren az átlagos sorok sorcsoportonkénti kiszámításához, valamint a fürt aluloptimális oszlop-tárolójú indexeinek azonosításához. A nézet utolsó oszlopa létrehoz egy SQL-utasítást, amely az indexek újraépítéséhez használható.

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]
,       MAX(p.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.[dm_pdw_nodes_db_column_store_row_group_physical_stats] 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_permanent_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]
JOIN    sys.[partitions] p                          ON P.object_id      = t.object_id
GROUP BY
        s.[name]
,       t.[name];

Most, hogy létrehozta a nézetet, futtassa ezt a lekérdezést a 100 K-nál kisebb sorcsoportokkal rendelkező táblák azonosításához. Érdemes lehet növelni a 100 K küszöbértéket, ha optimálisabb szegmensminőséget keres.

SELECT    *
FROM    [dbo].[vColumnstoreDensity]
WHERE    COMPRESSED_rowgroup_rows_AVG < 100000
        OR INVISIBLE_rowgroup_rows_AVG < 100000;

A lekérdezés futtatása után megkezdheti az adatok megtekintését és az eredmények elemzését. Ez a táblázat bemutatja, hogy mit kell keresni a sorcsoportelemzésben.

Oszlop	Az adatok használata
[tábla_partíció_szám]	Ha a tábla particionálva van, előfordulhat, hogy magasabb nyitott sorcsoportszám jelenik meg. Az eloszlás minden partíciója elméletileg egy nyitott sorcsoporttal rendelkezhet. Ezt vegye figyelembe az elemzésben. A particionált kis táblák optimalizálhatók a particionálás teljes eltávolításával, mivel ez javítaná a tömörítést.
[row_count_total]	A tábla összes sorainak száma. Ezzel az értékkel például kiszámíthatja a tömörített állapotban lévő sorok százalékos arányát.
[sorok_száma_eloszlás_szerint_MAX]	Ha az összes sor egyenlően oszlik el, ez az érték a sorok eloszlásonkénti célszáma lenne. Hasonlítsa össze ezt az értéket a "compressed_rowgroup_count" értékkel.
[COMPRESSED_rowgroup_rows]	A tábla oszloptár formátumú sorainak teljes száma.
[COMPRESSED_rowgroup_rows_AVG]	Ha a sorok átlagos száma jelentősen kisebb, mint egy sorcsoport sorainak maximális száma, fontolja meg a CTAS vagy az ALTER INDEX REBUILD használatát az adatok újracsomagolásához
[COMPRESSED_rowgroup_count]	Oszlopboltos formátumú sorcsoportok száma. Ha ez a szám nagyon magas a táblázathoz képest, az azt jelzi, hogy az oszlopcentrikus sűrűség alacsony.
[COMPRESSED_rowgroup_rows_DELETED]	A sorok logikailag oszlopos formátumban kerülnek törlésre. Ha a szám a táblázat méretéhez képest magas, fontolja meg a partíció újraépítését vagy az index újraépítését, mivel ez fizikailag eltávolítja őket.
[COMPRESSED_rowgroup_rows_MIN]	Ezzel az AVG- és MAX-oszlopokkal megismerheti az oszloptárban lévő sorcsoportok értékeinek tartományát. A terhelési küszöbérték feletti alacsony szám (partícióhoz igazított eloszlásonként 102 400) azt jelzi, hogy az adatbetöltésben optimalizálás érhető el
[COMPRESSED_rowgroup_rows_MAX]	A fentieknek megfelelően
[OPEN_rowgroup_count]	A nyitott sorcsoportok normálisak. Egy táblaeloszlásonként (60) észszerűen elvárható egy OPEN sorcsoport. A túl sok adat a partíciók közötti adatbetöltésre utal. Ellenőrizze duplán a particionálási stratégiát, hogy biztosan megfelelő legyen
[OPEN_rowgroup_rows]	Minden sorcsoport legfeljebb 1 048 576 sort tartalmazhat. Ezzel az értékkel megtekintheti, hogy a nyitott sorcsoportok jelenleg mennyire teljesek
[OPEN_rowgroup_rows_MIN]	A nyitott csoportok azt jelzik, hogy az adatok fokozatosan kerülnek betöltésre a táblába, vagy az előző terhelésből fennmaradó sorok átbuktak ebbe a sorcsoportba. A MIN, MAX, AVG oszlopokkal megtekintheti, hogy mennyi adat található OPEN sorcsoportokban. Kis táblák esetén az összes adat 100%-a lehet! Ha az adatok oszloptárba kényszerítése szükséges, használja az ALTER INDEX REBUILD parancsot.
[OPEN_rowgroup_rows_MAX]	A fentieknek megfelelően
[OPEN_rowgroup_rows_AVG]	A fentieknek megfelelően
[LEZÁRT_csoportsorok]	Ellenőrizze a zárt sorcsoport sorait.
[CLOSED_rowgroup_count]	A zárt sorcsoportok számának alacsonynak kell lennie, ha egyáltalán láthatók ilyenek. A zárt sorcsoportok tömörített sorcsoportokká alakíthatók az ALTER INDEX használatával... REORGANIZE parancs. Ez azonban általában nem kötelező. A bezárt csoportok automatikusan oszlopcentrikus sorcsoportokká alakulnak a háttérbeli "mozgatás" folyamattal.
[CLOSED_rowgroup_rows_MIN]	A zárt sorcsoportoknak nagyon magas kihasználtsági aránnyal kell rendelkezniük. Ha egy zárt sorcsoport kitöltési sebessége alacsony, akkor további elemzésre van szükség az oszloptárban.
[ZÁRVA_sorcsoport_sorok_MAX]	A fentieknek megfelelően
[CLOSED_rowgroup_rows_AVG]	A fentieknek megfelelően
[Rebuild_Index_SQL]	SQL egy tábla oszlop-tároló indexének újraépítéséhez

Az indexkarbantartás hatása

A nézetben lévő Rebuild_Index_SQL oszlop vColumnstoreDensity egy utasítást ALTER INDEX REBUILD tartalmaz, amely az indexek újraépítéséhez használható. Az indexek újraépítésekor győződjön meg arról, hogy elegendő memóriát foglal le az indexet újraépítő munkamenethez. Ehhez növelje annak a felhasználónak az erőforrásosztályát , aki jogosult az index újraépítésére ezen a táblán a javasolt minimálisra. Példa: Indexek újraépítése a szegmensminőség javítása érdekében a cikk későbbi részében.

Rendezett fürtözött oszlopcentrikus indexet ALTER INDEX REBUILD tartalmazó tábla esetén a rendszer újra rendezi az adatokat a tempdb használatával. A tempdb monitorozása az újraépítési műveletek során. Ha több tempdb-tárhelyre van szüksége, skálázza fel az adatbáziskészletet. Az index újraépítésének befejezése után vertikálisan lefelé skálázható.

Rendezett fürtözött oszlopcentrikus indexet ALTER INDEX REORGANIZE tartalmazó táblák esetében nem rendezi újra az adatokat. Az adatok újrarendezéséhez használja a következőt ALTER INDEX REBUILD: .

A rendezett fürtözött oszlopcentrikus indexekkel kapcsolatos további információkért lásd : Teljesítmény finomhangolás rendezett fürtözött oszlopcentrikus indexekkel.

Az oszlopstore indexek gyenge minőségének okai

Ha rossz szegmensminőségű táblákat azonosított, meg kell határoznia a kiváltó okot. Az alábbiakban a gyenge szegmensminőség néhány egyéb gyakori oka látható:

1. Memóriaterhelés az index létrehozásakor
2. Nagy mennyiségű DML-művelet
3. Kis vagy csepegtető terhelési műveletek
4. Túl sok partíció

Ezek a tényezők azt eredményezhetik, hogy az oszlop-tároló index sorcsoportonként jelentősen kevesebb sorral rendelkezik, mint az optimális 1 millió sor. Azt is okozhatják, hogy a sorok tömörített sorcsoport helyett a delta sorcsoportra kerülnek.

Feljegyzés

Az oszlopcentrikus táblák általában csak akkor küldik le az adatokat egy tömörített oszloptár-szegmensbe, ha táblánként több mint 1 millió sor van. Ha egy fürtözött oszlopcentrikus indexet tartalmazó tábla számos nyitott sorcsoporttal rendelkezik, amelyek teljes száma nem felel meg a tömörítési küszöbértéknek (1 millió sor), ezek a sorcsoportok nyitva maradnak, és soradatokként lesznek tárolva. Következésképpen ez növeli a terjesztési adatbázis méretét, mivel azok nincsenek tömörítve. Ezen kívül ezek a nyitott sorcsoportok nem fogják kihasználni a CCI előnyeit, és több erőforrást igényelnek a karbantartáshoz. Célszerű lehet az ALTER INDEX REORGANIZE használatát használni.

Memóriaterhelés az index létrehozásakor

A tömörített sorcsoportonkénti sorok száma közvetlenül kapcsolódik a sor szélességéhez és a sorcsoport feldolgozásához rendelkezésre álló memória mennyiségéhez. Amikor a sorokat nagy memóriaterhelés mellett írják oszlopos adattáblákba, az oszlopos szegmens minősége romolhat. Ezért a legjobb gyakorlat az, hogy a munkamenetnek, amely az oszlopcentrikus indextáblákra ír, biztosítsa a lehető legtöbb memóriához való hozzáférést. Mivel a memória és az egyidejűség között kompromisszum áll fenn, a megfelelő memóriafoglalásra vonatkozó útmutatás a táblázat egyes soraiban lévő adatoktól, a rendszer számára lefoglalt adattárház-egységektől és a táblához adatokat író munkamenetnek adható egyidejűségi pontok számától függ.

Nagy mennyiségű DML-művelet

A sorok frissítésével és törlésével kapcsolatos nagy mennyiségű DML-művelet nem hatékony lehet az oszloptárban. Ez különösen igaz, ha a sorcsoport legtöbb sorát módosítják.

• Ha töröl egy sort egy tömörített sorcsoportból, az csak logikailag jelöli meg a sort töröltként. A sor a tömörített sorcsoportban marad addig, amíg a partíciót vagy a táblát újra nem építik.
• A sor beszúrása hozzáadja a sort egy deltasorcsoportnak nevezett belső sortártáblához. A beszúrt sorcsoport csak akkor lesz oszlopalapúra átalakítva, ha a deltasorcsoport megtelt és lezártként van megjelölve. A sorcsoportok akkor lesznek bezárva, ha elérik az 1 048 576 sor maximális kapacitását.
• Az oszlopcentrikus formátumú sorok frissítése logikai törlésként, majd beszúrásként történik. A beszúrt sor tárolható a deltatárolóban.

A partícióhoz igazított eloszlásonkénti 102 400 sort meghaladó kötegelt frissítési és beszúrási műveletek közvetlenül az oszloptár formátumára kerülnek. Egyenlő eloszlást feltételezve azonban több mint 6,144 millió sort kell módosítania egyetlen műveletben ahhoz, hogy ez megtörténjen. Ha egy adott partícióhoz igazított eloszlás sorainak száma kisebb, mint 102 400, a sorok a deltatárolóba kerülnek, és ott maradnak, amíg elegendő sort nem szúrnak be vagy módosítanak a sorcsoport bezárásához vagy az index újraépítéséhez.

Kis vagy csordogáló terhelési műveletek

A dedikált SQL-készletbe áramló kis terheléseket más néven trükkös terhelésnek is nevezik. Általában egy közel folyamatos adatfolyamot jelentenek, amelyet a rendszer feldolgoz. Mivel azonban ez a stream közel folyamatos, a sorok mennyisége nem túl nagy. Az adatok gyakran nem érik el jelentősen az oszloptár formátumba való közvetlen betöltéshez szükséges küszöbértéket.

Ezekben az esetekben gyakran jobb, ha először az Azure Blob Storage-ban tárolja az adatokat, és hagyja, hogy a betöltés előtt halmozódjon fel. Ezt a technikát gyakran mikro kötegelésnek is nevezik.

Túl sok partíció

Egy másik fontos szempont a particionálás hatása a klaszterezett oszlopalapú táblákra. A particionálás előtt a dedikált SQL-készlet már 60 adatbázisra osztja az adatokat. A particionálás tovább osztja az adatokat. Ha particionálja az adatokat, vegye figyelembe, hogy mindegyik partíciónak legalább 1 millió sorra van szüksége ahhoz, hogy kihasználhassa a fürtözött oszlopcentrikus index előnyeit. Ha a táblát 100 partícióra particionálja, akkor a táblának legalább 6 milliárd sorra van szüksége ahhoz, hogy kihasználhassa a fürtözött oszlopcentrikus index előnyeit (60 eloszlás 100 partíció 1 millió sor). Ha a 100 partíciós tábla nem rendelkezik 6 milliárd sortal, csökkentse a partíciók számát, vagy inkább használjon halomtáblát.

Miután a táblákat betöltötte néhány adattal, kövesse az alábbi lépéseket a nem optimális fürtözött oszlopalapú indexekkel rendelkező táblák azonosításához és újraépítéséhez.

Indexek újraépítése a szegmensminőség javítása érdekében

1. lépés: A megfelelő erőforrásosztályt használó felhasználó azonosítása vagy létrehozása

A szegmensminőség azonnali javításának egyik gyors módja az index újraépítése. A fenti nézet által visszaadott SQL tartalmaz egy ALTER INDEX REBUILD utasítást, amely az indexek újraépítéséhez használható. Az indexek újraépítésekor győződjön meg arról, hogy elegendő memóriát foglal le az indexet újraépítő munkamenethez. Ehhez növelje annak a felhasználónak az erőforrásosztályát, aki jogosult az index újraépítésére ezen a táblán a javasolt minimálisra.

Az alábbiakban látható egy példa arra, hogyan oszthat ki több memóriát egy felhasználó számára az erőforrásosztály növelésével. Az erőforrásosztályok használatához lásd : Erőforrásosztályok a számítási feladatok kezeléséhez.

EXEC sp_addrolemember 'xlargerc', 'LoadUser';

2. lépés: Fürtözött oszlopcentrikus indexek újraépítése magasabb erőforrásosztály-felhasználóval

Jelentkezzen be felhasználóként az 1. lépésből (LoadUseramely most egy magasabb erőforrásosztályt használ), és hajtsa végre az ALTER INDEX utasításokat. Győződjön meg arról, hogy ez a felhasználó alter engedéllyel rendelkezik azokra a táblákra, ahol az indexet újraépítették. Ezek a példák bemutatják, hogyan lehet újraépíteni a teljes oszlopcentrikus indexet, vagy hogyan lehet újraépíteni egy partíciót. Nagy táblákon célszerűbb egyszerre egyetlen partíció indexeit újraépíteni.

Másik lehetőségként az index újraépítése helyett átmásolhatja a táblát egy új táblába a CTAS használatával. Melyik út a legjobb? Nagy mennyiségű adat esetén a CTAS általában gyorsabb, mint az ALTER INDEX. Kisebb adatmennyiségek esetén az ALTER INDEX használata egyszerűbb, és nem szükséges felcserélni a táblát.

-- 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);

Az index dedikált SQL-készletben való újraépítése offline művelet. Az indexek újraépítéséről további információt a Columnstore Indexek töredezettségmentesítése és az ALTER INDEX című szakaszban talál.

3. lépés: Annak ellenőrzése, hogy javult-e a fürtözött oszlopalapú szegmens minősége

Futtassa újra azt a lekérdezést, amely rossz szegmensminőséggel azonosította a táblát, és ellenőrizze, hogy javult-e a szegmensminőség. Ha a szegmens minősége nem javul, előfordulhat, hogy a táblázat sorai extra szélesek. Érdemes lehet magasabb erőforrásosztályt vagy DWU-t használni az indexek újraépítésekor.

Indexek újraépítése CTAS-vel és partícióváltással

Ez a példa a CREATE TABLE AS SELECT (CTAS) utasítást és a partícióváltást használja egy táblapartíció újraépítéséhez.

-- 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);

További információ a partíciók CTAS-sel történő újbóli létrehozásáról: Partíciók használata dedikált SQL-készletben.

Kapcsolódó tartalom

A táblák fejlesztéséről további információt a Táblák fejlesztése című témakörben talál.