Indexes on dedicated SQL pool tables in Azure Synapse Analytics
Javaslatok és példák az Azure Synapse Analytics dedikált SQL-készletében lévő táblák indexelésével.
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 indexeket és a nem indexelt 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 oszlopcentrikus 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. A csoportosított oszlopcentrikus táblák általában felülmúlják a fürtözött index- vagy halomtáblákat, és általában a nagy méretű táblák esetében a legjobb választás. 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 egyszerűen adja meg CLUSTERED COLUMNSTORE INDEX a WITH záradékot, vagy hagyja ki 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) függvényt. 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 talán még az ideiglenes táblákat is.
- 60 milliónál kevesebb sorból álló kis táblák. Fontolja meg a halomtáblákat.
Halomtáblák
Ha ideiglenesen a dedikált SQL-készletben ad le adatokat, előfordulhat, hogy a halomtábla használata felgyorsítja az általános folyamatot. 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 több átalakítás futtatása előtt tölti be az adatokat a szakaszba, a táblázat halomtáblába való betöltése sokkal gyorsabb, mint az adatok fürtözött oszlopcentrikus táblába való betöltése. 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 fürt oszlopcentrikus táblái 60 milliónál több sor után elkezdik elérni 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 egyszerűen 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 );
Megjegyzés:
Ha gyakran végez INSERT, UPDATEvagy DELETE műveleteket egy halomtáblán, a parancs használatával ALTER TABLE ajánlott a tábla újraépítését belefoglalni a karbantartási ütemtervbe. For example, 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 a nemclustered indexek más oszlopokhoz is hozzáadhatók. 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 egyszerűen 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 nem fürtözött indexet szeretne hozzáadni egy táblához, használja az alábbi szintaxist:
CREATE INDEX zipCodeIndex ON myTable (zipCode);
Fürtözött oszlopcentrikus 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 optimális, ha tömörített sorcsoportonként legalább 100 K sor található, és a sorcsoportonkénti sorok száma megközelíti az 1 048 576 sort, 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 és a fürt aluloptimális oszlopcentrikus 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]
, 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];
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. Ha optimálisabb szegmensminőséget keres, érdemes lehet növelni a 100 K-os küszöbértéket.
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.
| Column | Az adatok használata |
|---|---|
| [table_partition_count] | 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 teljes sorszá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. |
| [row_count_per_distribution_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. |
| [COMPRES STANDARD KIADÁSD_ROWGROUP_ROWS] | A tábla oszlopcentrikus formátumú sorainak teljes száma. |
| [COMPRES Standard kiadásD_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 |
| [COMPRES Standard kiadásD_rowgroup_count] | Oszlopcentrikus 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. |
| [COMPRES Standard kiadásD_rowgroup_rows_DELETED] | A sorok logikailag oszlopcentrikus formátumban törlődnek. 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. |
| [COMPRES Standard kiadásD_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 |
| [COMPRES Standard kiadásD_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 betöltődnek a táblába, vagy az előző terhelés a többi sorra kiömlött 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! Ebben az esetben az ALTER INDEX REBUILD az adatok oszloptárba kényszerítéséhez. |
| [OPEN_rowgroup_rows_MAX] | A fentieknek megfelelően |
| [OPEN_rowgroup_rows_AVG] | A fentieknek megfelelően |
| [CLO Standard kiadásD_rowgroup_rows] | Tekintse meg a zárt sorcsoport sorait a józanság ellenőrzéseként. |
| [CLO Standard kiadásD_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. |
| [CLO Standard kiadásD_rowgroup_rows_MIN] | A zárt sorcsoportoknak nagyon magas kitöltési sebességgel 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. |
| [CLO Standard kiadásD_rowgroup_rows_MAX] | A fentieknek megfelelően |
| [CLO Standard kiadásD_rowgroup_rows_AVG] | A fentieknek megfelelően |
| [Rebuild_Index_SQL] | SQL egy tábla oszlopcentrikus indexének újraépítéséhez |
Az indexkarbantartás hatása
A nézetben lévő vColumnstoreDensity oszlop Rebuild_Index_SQL 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 oszlopcentrikus indexek gyenge minőségének okait
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ó:
- Memóriaterhelés az index létrehozásakor
- Nagy mennyiségű DML-művelet
- Kis vagy bonyolult terhelési műveletek
- Túl sok partíció
Ezek a tényezők azt eredményezhetik, hogy az oszlopcentrikus indexek sorcsoportonként jelentősen kevesebb, 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.
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 írja oszlopcentrikus táblákba, az oszlopcentrikus szegmens minősége gyengülhet. Ezért az ajánlott eljárás az, hogy az oszlopcentrikus indextábláknak írt munkamenetet a lehető legtöbb memóriához biztosítsa. 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ázegysé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 sor csak akkor lesz oszlopcentrikussá alakí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 bonyolult 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. Ezek általában a rendszer által betöltött adatok közel állandó adatfolyamát jelentik. Mivel azonban ez a stream közel folyamatos, a sorok mennyisége nem különösebben 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 megfontolandó szempont a particionálás hatása a fürtözött oszlopcentrikus 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 fontolja meg a halomtábla használatát.
Miután a táblákat betöltötte néhány adattal, kövesse az alábbi lépéseket a táblák optimális fürtözött oszlopcentrikus indexekkel való 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ák esetén 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 ALTER INDEX című szakaszában talál.
3. lépés: Annak ellenőrzése, hogy a fürtözött oszlopcentrikus szegmens minősége javult-e
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 javult, 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 Standard kiadás LECT (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.
További lépések
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.