Indexy v tabulkách ve vyhrazeném fondu SQL v Azure Synapse Analytics
Doporučení a příklady indexování tabulek ve vyhrazeném fondu SQL ve službě Azure Synapse Analytics
Typy indexů
Vyhrazený fond SQL nabízí několik možností indexování, včetně clusterovaných indexů columnstore, clusterovaných indexů a neclusterovaných indexů a možnosti bez indexu označované také jako haldy.
Pokud chcete vytvořit tabulku s indexem, přečtěte si dokumentaci k CREATE TABLE (vyhrazený fond SQL).
Clusterované indexy columnstore
Ve výchozím nastavení vyhrazený fond SQL vytvoří clusterovaný index columnstore, pokud nejsou v tabulce zadány žádné možnosti indexu. Clusterované tabulky columnstore nabízejí nejvyšší úroveň komprese dat i nejlepší celkový výkon dotazů. Clusterované tabulky columnstore obvykle překonají clusterované tabulky indexu nebo haldy a obvykle jsou nejlepší volbou pro velké tabulky. Z těchto důvodů je clusterovaný columnstore nejlepším místem, kde začít, když si nejste jisti, jak indexovat tabulku.
Pokud chcete vytvořit clusterovanou tabulku columnstore, jednoduše zadejte CLUSTERED COLUMNSTORE INDEX v klauzuli WITH nebo ponechte klauzuli WITH vypnutou:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( CLUSTERED COLUMNSTORE INDEX );
Existuje několik scénářů, kdy clusterované columnstore nemusí být dobrou volbou:
- Tabulky Columnstore nepodporují varchar(max), nvarchar(max) a varbinary(max). Zvažte místo toho haldu nebo clusterovaný index.
- Tabulky columnstore můžou být pro přechodná data méně efektivní. Zvažte haldu a možná i dočasné tabulky.
- Malé tabulky s méně než 60 miliony řádků Zvažte tabulky haldy.
Tabulky haldy
Pokud dočasně cílíte data ve vyhrazeném fondu SQL, můžete zjistit, že použití tabulky haldy zrychlová celkový proces. Důvodem je to, že načítání do haldy je rychlejší než indexování tabulek a v některých případech je možné následné čtení provést z mezipaměti. Pokud načítáte data jen tak, abyste je zfázovali před spuštěním dalších transformací, načítání tabulky do tabulky haldy je mnohem rychlejší než načtení dat do clusterované tabulky columnstore. Načítání dat do dočasné tabulky navíc načítá rychleji než načítání tabulky do trvalého úložiště. Po načtení dat můžete v tabulce vytvořit indexy pro rychlejší výkon dotazů.
Tabulky columnstore clusteru začínají dosahovat optimální komprese, jakmile je více než 60 milionů řádků. U malých vyhledávacích tabulek, méně než 60 milionů řádků, zvažte použití HEAP nebo clusterovaného indexu pro rychlejší výkon dotazů.
Pokud chcete vytvořit tabulku haldy, stačí v klauzuli WITH zadat HEAP:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( HEAP );
Poznámka:
Pokud často provádíte INSERToperace UPDATEs DELETE tabulkou haldy, doporučujeme zahrnout do plánu údržby opětovné sestavení tabulky pomocí ALTER TABLE příkazu. Například ALTER TABLE [SchemaName].[TableName] REBUILD. Tento postup přispívá ke snížení fragmentace, což vede ke zlepšení výkonu při operacích čtení.
Clusterované a neclusterované indexy
Clusterované indexy můžou po rychlém načtení jednoho řádku převést clusterované tabulky columnstore. U dotazů, ve kterých se vyžaduje vyhledávání s jedním nebo velmi malým množstvím řádků s extrémní rychlostí, zvažte clusterovaný index nebo neclusterovaný sekundární index. Nevýhodou použití clusterovaného indexu je, že pouze dotazy, které mají výhodu, jsou ty, které používají vysoce selektivní filtr ve sloupci clusterovaného indexu. Pokud chcete zlepšit filtrování u jiných sloupců, můžete do jiných sloupců přidat neclusterovaný index. Každý index, který je přidán do tabulky, ale přidává čas na načtení prostoru i zpracování.
Pokud chcete vytvořit clusterovanou indexovou tabulku, jednoduše v klauzuli WITH zadejte CLUSTERED INDEX:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( CLUSTERED INDEX (id) );
Pokud chcete do tabulky přidat neskupený index, použijte následující syntaxi:
CREATE INDEX zipCodeIndex ON myTable (zipCode);
Optimalizace clusterovaných indexů columnstore
Clusterované tabulky columnstore uspořádají data do segmentů. Vysoká kvalita segmentů je klíčová pro dosažení optimálního výkonu dotazů na tabulky columnstore. Kvalitu segmentů je možné změřit podle počtu řádků v komprimované skupině řádků. Kvalita segmentu je nejoptimálnější, pokud existuje alespoň 100 K řádků na komprimovanou skupinu řádků a dosáhnete výkonu, protože počet řádků na skupinu řádků se blíží 1 048 576 řádků, což je nejvíce řádků, které může skupina řádků obsahovat.
Následující zobrazení můžete vytvořit a použít ve vašem systému k výpočtu průměrných řádků na skupinu řádků a identifikaci všech neoptimálních indexů columnstore clusteru. Poslední sloupec v tomto zobrazení vygeneruje příkaz SQL, který lze použít k opětovnému sestavení indexů.
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];
Teď, když jste vytvořili zobrazení, spusťte tento dotaz a identifikujte tabulky se skupinami řádků s méně než 100 K řádky. Pokud hledáte optimální kvalitu segmentu, možná budete chtít zvýšit prahovou hodnotu 100 K.
SELECT *
FROM [dbo].[vColumnstoreDensity]
WHERE COMPRESSED_rowgroup_rows_AVG < 100000
OR INVISIBLE_rowgroup_rows_AVG < 100000;
Po spuštění dotazu můžete začít prohlížet data a analyzovat výsledky. Tato tabulka vysvětluje, co hledat v analýze skupiny řádků.
| Column | Jak používat tato data |
|---|---|
| [table_partition_count] | Pokud je tabulka rozdělená na oddíly, můžete očekávat, že se zobrazí vyšší počty skupin řádků Open. Každý oddíl v distribuci by teoreticky mohl mít přidruženou otevřenou skupinu řádků. Zastavte to do analýzy. Malá tabulka, která byla rozdělena, by mohla být optimalizována odebráním dělení úplně, protože by se tím zlepšila komprese. |
| [row_count_total] | Celkový počet řádků pro tabulku. Tuto hodnotu můžete například použít k výpočtu procenta řádků v komprimovaném stavu. |
| [row_count_per_distribution_MAX] | Pokud jsou všechny řádky rovnoměrně rozdělené, bude to cílový počet řádků na rozdělení. Porovnejte tuto hodnotu s compressed_rowgroup_count. |
| [COMPRESSED_rowgroup_rows] | Celkový počet řádků ve formátu columnstore tabulky |
| [COMPRESSED_rowgroup_rows_AVG] | Pokud je průměrný počet řádků výrazně menší než maximální počet řádků pro skupinu řádků, zvažte použití funkce CTAS nebo ALTER INDEX REBUILD k rekomprimování dat. |
| [COMPRESSED_rowgroup_count] | Počet skupin řádků ve formátu columnstore Pokud je toto číslo vzhledem k tabulce velmi vysoké, je to indikátor, že hustota columnstore je nízká. |
| [COMPRESSED_rowgroup_rows_DELETED] | Řádky se logicky odstraní ve formátu columnstore. Pokud je číslo vysoké vzhledem k velikosti tabulky, zvažte opětovné vytvoření oddílu nebo opětovné sestavení indexu, protože je odebere fyzicky. |
| [COMPRESSED_rowgroup_rows_MIN] | Použijte to se sloupci AVG a MAX, abyste porozuměli rozsahu hodnot pro skupiny řádků ve vašem columnstore. Nízké číslo nad prahovou hodnotou zatížení (102 400 na rozdělení zarovnané oddíly) naznačuje, že optimalizace jsou k dispozici v zatížení dat. |
| [COMPRESSED_rowgroup_rows_MAX] | Viz výše |
| [OPEN_rowgroup_count] | Otevřené skupiny řádků jsou normální. Jedna by přiměřeně očekávala jednu skupinu řádků OPEN na distribuci tabulky (60). Nadměrné počty navrhují načítání dat napříč oddíly. Pečlivě zkontrolujte strategii dělení, abyste měli jistotu, že je to zvuk. |
| [OPEN_rowgroup_rows] | Každá skupina řádků může mít maximálně 1 048 576 řádků. Pomocí této hodnoty zjistíte, jak jsou v současné době úplné skupiny otevřených řádků. |
| [OPEN_rowgroup_rows_MIN] | Otevřené skupiny označují, že data se buď načítají do tabulky, nebo že se předchozí načtení přelilo přes zbývající řádky do této skupiny řádků. Pomocí sloupců MIN, MAX a AVG můžete zjistit, kolik dat se nachází ve skupinách řádků OPEN. U malých tabulek může být 100 % všech dat. V takovém případě ALTER INDEX REBUILD vynutit data do columnstore. |
| [OPEN_rowgroup_rows_MAX] | Viz výše |
| [OPEN_rowgroup_rows_AVG] | Viz výše |
| [CLOSED_rowgroup_rows] | Podívejte se na řádky skupiny uzavřených řádků jako kontrolu sanity. |
| [CLOSED_rowgroup_count] | Počet uzavřených skupin řádků by měl být nízký, pokud se vůbec nějaké zobrazí. Uzavřené skupiny řádků lze převést na komprimované skupiny řádků pomocí ALTER INDEX ... Příkaz REORGANIZE. Obvykle se to ale nevyžaduje. Uzavřené skupiny se automaticky převedou na skupiny řádků columnstore procesem přesunu řazené kolekce členů na pozadí. |
| [CLOSED_rowgroup_rows_MIN] | Skupiny uzavřených řádků by měly mít velmi vysokou míru výplně. Pokud je míra výplně pro uzavřenou skupinu řádků nízká, je potřeba provést další analýzu columnstore. |
| [CLOSED_rowgroup_rows_MAX] | Viz výše |
| [CLOSED_rowgroup_rows_AVG] | Viz výše |
| [Rebuild_Index_SQL] | SQL pro opětovné sestavení indexu columnstore pro tabulku |
Dopad údržby indexů
Sloupec Rebuild_Index_SQL v vColumnstoreDensity zobrazení obsahuje ALTER INDEX REBUILD příkaz, který lze použít k opětovnému sestavení indexů. Při opětovném sestavení indexů nezapomeňte přidělit dostatek paměti relaci, která znovu sestaví index. Chcete-li to provést, zvyšte třídu prostředků uživatele, který má oprávnění k opětovnému sestavení indexu v této tabulce na doporučené minimum. Příklad najdete v tématu Opětovné sestavení indexů pro zlepšení kvality segmentů dále v tomto článku.
U tabulky s uspořádaným clusterovaným indexem ALTER INDEX REBUILD columnstore se data znovu seřadí pomocí databáze tempdb. Monitorování databáze tempdb během operací opětovného sestavení Pokud potřebujete více místa databáze tempdb, vertikálně navyšte kapacitu fondu databází. Po dokončení opětovného sestavení indexu vertikálně snížit kapacitu.
U tabulky s seřazeným clusterovaným indexem ALTER INDEX REORGANIZE columnstore se data znovu seřadí. Chcete-li data znovu seřadit, použijte ALTER INDEX REBUILD.
Další informace o uspořádaných clusterovaných indexech columnstore najdete v tématu Ladění výkonu s seřazeným clusterovaným indexem columnstore.
Příčiny nekvalitních indexů columnstore
Pokud jste identifikovali tabulky s nízkou kvalitou segmentů, chcete identifikovat původní příčinu. Níže jsou uvedeny některé další běžné příčiny špatné kvality segmentů:
- Zatížení paměti při vytváření indexu
- Velký objem operací DML
- Malé nebo složité operace zatížení
- Příliš mnoho oddílů
Tyto faktory můžou způsobit, že index columnstore bude mít výrazně méně než optimálních 1 milion řádků na skupinu řádků. Můžou také způsobit, že řádky přejdou do skupiny delta řádků místo komprimované skupiny řádků.
Zatížení paměti při vytváření indexu
Počet řádků na komprimovanou skupinu řádků přímo souvisí s šířkou řádku a množstvím paměti dostupné ke zpracování skupiny řádků. Když se řádky zapisují do tabulek columnstore při zatížení paměti, může tím utrpět kvalita segmentů columnstore. Osvědčeným postupem je proto dát relaci, která zapisuje do tabulek indexu columnstore, přístup k co nejvíce paměti. Vzhledem k tomu, že existuje kompromis mezi pamětí a souběžností, pokyny ke správnému přidělení paměti závisí na datech v každém řádku tabulky, jednotkách datového skladu přidělených vašemu systému a počtu slotů souběžnosti, které můžete dát relaci, která zapisuje data do tabulky.
Velký objem operací DML
Velký objem operací DML, které aktualizují a odstraní řádky, můžou do columnstore zavádět neefektivitu. To platí zejména v případě, že se upraví většina řádků ve skupině řádků.
- Odstranění řádku z komprimované skupiny řádků pouze logicky označí řádek jako odstraněný. Řádek zůstane ve skupině komprimovaných řádků, dokud se oddíl nebo tabulka znovu nesestaví.
- Když vložíte řádek, přidá se řádek do interní tabulky rowstore označované jako rozdílová skupina řádků. Vložený řádek se nepřevedí na columnstore, dokud se skupina řádků delta nezaplní a nebude označena jako uzavřená. Skupiny řádků se zavře, jakmile dosáhnou maximální kapacity 1 048 576 řádků.
- Aktualizace řádku ve formátu columnstore se zpracuje jako logické odstranění a pak vložení. Vložený řádek může být uložen v rozdílovém úložišti.
Operace dávkové aktualizace a vkládání, které překračují hromadnou prahovou hodnotu 102 400 řádků na distribuci zarovnanou do oddílů, se přejdou přímo do formátu columnstore. Za předpokladu rovnoměrného rozdělení byste ale museli upravit více než 6,144 milionů řádků v jedné operaci, aby k tomu došlo. Pokud je počet řádků pro dané rozdělení zarovnané do oddílů menší než 102 400, řádky přejdou do rozdílového úložiště a zůstanou tam, dokud nebudou vloženy nebo změněny dostatečné řádky pro zavření skupiny řádků nebo opětovného vytvoření indexu.
Malé nebo složité operace zatížení
Malá zatížení, která proudí do vyhrazeného fondu SQL, se také někdy označují jako zátěžové triky. Obvykle představují téměř konstantní datový proud, který systém ingestuje. Vzhledem k tomu, že tento datový proud je téměř souvislý, objem řádků není zvláště velký. Častěji než ne data jsou výrazně nižší než prahová hodnota požadovaná pro přímé načtení do formátu columnstore.
V těchto situacích je často lepší nejprve přiložit data do úložiště objektů blob v Azure a nechat je nahromadět před načtením. Tato technika se často označuje jako mikrodávkové dávkování.
Příliš mnoho oddílů
Další věcí, kterou je potřeba vzít v úvahu, je dopad dělení na clusterované tabulky columnstore. Před dělením už vyhrazený fond SQL rozdělí vaše data do 60 databází. Dělením dále rozdělíte data. Pokud rozdělíte data, zvažte, že každý oddíl potřebuje alespoň 1 milion řádků, aby mohl využívat clusterovaný index columnstore. Pokud tabulku rozdělíte na 100 oddílů, potřebuje vaše tabulka alespoň 6 miliard řádků, aby využívala clusterovaný index columnstore (60 distribucí 100 oddílů 1 milion řádků). Pokud tabulka s 100 oddíly nemá 6 miliard řádků, snižte počet oddílů nebo zvažte použití tabulky haldy.
Po načtení tabulek s některými daty pomocí následujících kroků identifikujte a znovu sestavte tabulky s podoptimálními clusterovanými indexy columnstore.
Opětovné sestavení indexů za účelem zlepšení kvality segmentů
Krok 1: Identifikace nebo vytvoření uživatele, který používá správnou třídu prostředků
Jedním z rychlých způsobů, jak okamžitě zlepšit kvalitu segmentu, je opětovné sestavení indexu. PŘÍKAZ ALTER INDEX REBUILD vrácený výše uvedeným zobrazením obsahuje příkaz ALTER INDEX REBUILD, který lze použít k opětovnému sestavení indexů. Při opětovném sestavení indexů nezapomeňte přidělit dostatek paměti relaci, která znovu sestaví index. Chcete-li to provést, zvyšte třídu prostředků uživatele, který má oprávnění k opětovnému sestavení indexu v této tabulce na doporučené minimum.
Níže je příklad, jak uživateli přidělit více paměti zvýšením třídy prostředků. Pokud chcete pracovat s třídami prostředků, přečtěte si téma Třídy prostředků pro správu úloh.
EXEC sp_addrolemember 'xlargerc', 'LoadUser';
Krok 2: Opětovné sestavení clusterovaných indexů columnstore s využitím uživatele vyšší třídy prostředků
Přihlaste se jako uživatel z kroku 1 (LoadUser), který teď používá vyšší třídu prostředků, a spusťte příkazy ALTER INDEX. Ujistěte se, že tento uživatel má oprávnění ALTER k tabulkám, ve kterých se index znovu sestavuje. Tyto příklady ukazují, jak znovu sestavit celý index columnstore nebo jak znovu sestavit jeden oddíl. U velkých tabulek je vhodnější znovu sestavit indexy jednoho oddílu najednou.
Případně místo opětovného sestavení indexu můžete tabulku zkopírovat do nové tabulky pomocí CTAS. Jaký způsob je nejlepší? U velkých objemů dat je CTAS obvykle rychlejší než ALTER INDEX. U menších objemů dat je funkce ALTER INDEX jednodušší a nevyžaduje prohození tabulky.
-- 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);
Opětovné sestavení indexu ve vyhrazeném fondu SQL je offline operace. Další informace o opětovném sestavení indexů naleznete v části ALTER INDEX REBUILD v Columnstore Indexy Defragmentace a ALTER INDEX.
Krok 3: Ověření zvýšení kvality clusterovaného segmentu columnstore
Znovu spusťte dotaz, který identifikoval tabulku s nízkou kvalitou segmentu, a ověřte, že se zlepšila kvalita segmentu. Pokud se kvalita segmentu nezlepšila, může to být tím, že řádky v tabulce jsou extra široké. Při opětovném sestavení indexů zvažte použití vyšší třídy prostředků nebo DWU.
Opětovné sestavení indexů pomocí CTAS a přepínání oddílů
Tento příklad používá příkaz CREATE TABLE AS SELECT (CTAS) a přepínání oddílů k opětovnému sestavení oddílu tabulky.
-- 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);
Další informace o opětovném vytváření oddílů pomocí CTAS naleznete v tématu Použití oddílů ve vyhrazeném fondu SQL.
Další kroky
Další informace o vývoji tabulek naleznete v tématu Vývoj tabulek.