Entwerfen von Tabellen mithilfe von Synapse SQL in Azure Synapse Analytics

Dieses Dokument enthält wichtige Konzepte für den Entwurf von Tabellen mit einem dedizierten und einem serverlosen SQL-Pool.

Ein serverloser SQL-Pool ist ein Abfragedienst für die Daten in Ihrem Data Lake. Es verfügt weder über einen lokalen Speicher noch über die Datenerfassung. Ein dedizierter SQL-Pool ist eine Sammlung von Analyseressourcen, die bei Verwendung von Synapse SQL bereitgestellt werden. Die Größe eines dedizierten SQL-Pools wird von Data Warehouse-Einheiten (Data Warehouse Units, DWUs) bestimmt.

In der folgenden Tabelle sind die für einen Vergleich eines dedizierten SQL-Pools mit einem serverlosen SQL-Pool relevanten Punkte aufgeführt:

Thema	Dedizierter SQL-Pool	Serverloser SQL-Pool
Bestimmen der Tabellenkategorie	Ja	Nein
Schemanamen	Ja	Ja
Tabellennamen	Ja	Nein
Tabellenpersistenz	Ja	Nein
Normale Tabelle	Ja	Nein
Temporäre Tabelle	Ja	Ja
Externe Tabelle	Ja	Ja
Datentypen	Ja	Ja
Verteilte Tabellen	Ja	Nein
Tabellen mit Hashverteilung	Ja	Nein
Replizierte Tabellen	Ja	Nein
Roundrobintabellen	Ja	Nein
Allgemeine Verteilungsmethoden für Tabellen	Ja	Nein
Partitionen	Ja	Ja
ColumnStore-Indizes	Ja	Nein
Statistik	Ja	Ja
Primärschlüssel und eindeutiger Schlüssel	Ja	Nein
Befehle zum Erstellen von Tabellen	Ja	Nein
Ausrichten von Quelldaten am Data Warehouse	Ja	Nein
Nicht unterstützte Tabellenfunktionen	Ja	Nein
Abfragen für die Tabellengröße	Ja	Nein

Bestimmen der Tabellenkategorie

In einem Sternschema werden Daten in Fakten-und Dimensionstabellen organisiert. Einige Tabellen werden für die Integration oder das Staging von Daten verwendet, bevor sie in eine Fakten- oder Dimensionstabelle verschoben werden. Wenn Sie eine Tabelle entwerfen, entscheiden Sie, ob die Tabellendaten in einer Faktentabelle, eine Dimensionstabelle oder eine Integrationstabelle gehören. Diese Entscheidung bestimmt die Tabellenstruktur und die Verteilung.

• Faktentabellen enthalten quantitative Daten, die häufig in einem transaktionalen System generiert und dann in das Data Warehouse geladen werden. Beispielsweise generiert ein Einzelhandelsunternehmen täglich Verkaufstransaktionen und lädt dann die Daten zur Analyse in eine Faktentabelle in ein Data Warehouse.

• Dimensionstabellen enthalten Attributdaten, die sich ändern können, es in der Regel jedoch nur selten tun. Beispielsweise werden der Name und die Adresse eines Kunden in einer Dimensionstabelle gespeichert und nur aktualisiert, wenn sich das Profil des Kunden ändert. Damit eine Faktentabelle nicht zu groß wird, kann darauf verzichtet werden, den Namen und die Adresse des Kunden in jede Zeile der Faktentabelle aufzunehmen. Stattdessen kann eine Kunden-ID von der Faktentabelle und der Dimensionstabelle gemeinsam genutzt werden. Die beiden Tabellen können mithilfe einer Abfrage verknüpft werden, um das Profil eines Kunden den Transaktionen zuzuordnen.

• Integrationstabellen werden für das Integrieren oder Staging von Daten verwendet. Sie können eine Integrationstabelle als normale Tabelle, externe Tabelle oder temporäre Tabelle erstellen. Sie können z. B. Daten in eine Stagingtabelle laden, Transformationen für die Daten in der Stagingumgebung durchführen und die Daten dann in eine Produktionstabelle einfügen.

Schemanamen

Schemas eignen sich gut zum Gruppieren von Objekten, die auf ähnliche Weise verwendet werden. Mit dem folgenden Code wird ein benutzerdefiniertes Schema mit dem Namen „wwi“ erstellt.

CREATE SCHEMA wwi;

Tabellennamen

Wenn Sie mehrere Datenbanken aus einer lokalen Lösung zu einem dedizierten SQL-Pool migrieren, migrieren Sie am besten alle Fakten-, Dimensions- und Integrationstabellen in ein SQL-Poolschema. Sie können z.B. alle Tabellen im Data Warehouse-Beispiel WideWorldImportersDW in einem Schema namens „wwi“ speichern.

Um die Organisation der Tabellen im dedizierten SQL-Pool anzuzeigen, können Sie „fact“, „dim“ und „int“ als Präfixe für die Tabellennamen verwenden. Die folgende Tabelle zeigt einige der Schema- und Tabellennamen für „WideWorldImportersDW“.

WideWorldImportersDW table	Tabellentyp	Dedizierter SQL-Pool
City	Dimension	wwi.DimCity
Order	Fakt	wwi.FactOrder

Tabellenpersistenz

Tabellen speichern Daten dauerhaft in Azure Storage, vorübergehend in Azure Storage oder in einem Datenspeicher außerhalb des Data Warehouse.

Normale Tabelle

In einer normalen Tabelle werden Daten in Azure Storage als Teil des Data Warehouse gespeichert. Die Tabelle und die Daten werden unabhängig davon beibehalten, ob eine Sitzung geöffnet ist. Im nachfolgenden Beispiel wird eine normale Tabelle mit zwei Spalten erstellt.

CREATE TABLE MyTable (col1 int, col2 int );  

Temporäre Tabelle

Eine temporäre Tabelle ist nur für die Dauer der Sitzung vorhanden. Sie können eine temporäre Tabelle verwenden, um zu verhindern, dass andere Benutzer temporäre Ergebnisse sehen. Die Verwendung von temporären Tabellen verringert auch die Notwendigkeit der Bereinigung. Temporäre Tabellen nutzen lokalen Speicher und können im dedizierten SQL-Pool eine höhere Leistung bieten.

Temporäre Tabellen werden vom serverlosen SQL-Pool unterstützt. Ihre Nutzung ist jedoch begrenzt, da Sie zwar eine temporäre Tabelle auswählen, sie jedoch nicht mit Dateien im Speicher verknüpfen können.

Weitere Informationen finden Sie unter Temporäre Tabellen.

Externe Tabelle

Externe Tabellen verweisen auf Daten in Azure Storage Blob oder Azure Data Lake Store.

Importieren Sie mit der CREATE TABLE AS SELECT-Anweisung Daten aus externen Tabellen in den dedizierten SQL-Pool. Ein Tutorial zum Ladevorgang finden Sie unter Verwenden von PolyBase zum Laden von Daten aus Azure Blob Storage.

Bei Bedarf können Sie beim serverlosen SQL-Pool CETAS verwenden, um das Abfrageergebnis in einer externen Tabelle in Azure Storage zu speichern.

Datentypen

Der dedizierte SQL-Pool unterstützt die am häufigsten verwendeten Datentypen. Eine Liste der unterstützten Datentypen finden Sie in der CREATE TABLE-Anweisung im CREATE TABLE-Verweis im Abschnitt „Datentypen“. Weitere Informationen zur Verwendung von Datentypen finden Sie unter Datentypen.

Verteilte Tabellen

Ein grundlegendes Feature des dedizierten SQL-Pools ist die Art und Weise, wie Tabellen verteilungsübergreifend gespeichert und ausgeführt werden können. Der dedizierte SQL-Pool unterstützt drei Methoden zum Verteilen von Daten:

• Roundrobin (Standard)
• Hash
• Repliziert

Tabellen mit Hashverteilung

Bei einer Hashverteilung werden die Tabellenzeilen auf Basis des Werts in der Verteilungsspalte verteilt. Eine Tabelle mit Hashverteilung ist für eine hohe Leistung bei Abfragen an große Tabellen ausgelegt. Bei der Auswahl der Verteilungsspalte müssen mehrere Faktoren berücksichtigt werden.

Weitere Informationen finden Sie unter Verteilen von Tabellen in SQL Data Warehouse.

Replizierte Tabellen

Eine replizierte Tabelle ist eine vollständige Kopie der Tabelle, die auf jedem Serverknoten zur Verfügung gestellt wird. Abfragen werden für replizierte Tabellen schnell ausgeführt, da bei Verknüpfungen replizierter Tabellen keine Datenverschiebung erforderlich ist. Für die Replikation wird zusätzlicher Speicherplatz benötigt, und sie ist für große Tabellen nicht geeignet.

Weitere Informationen finden Sie unter Entwurfsleitfaden für replizierte Tabellen.

Roundrobintabellen

Bei einer Roundrobintabelle werden die Tabellenzeilen gleichmäßig auf alle Verteilungen aufgeteilt. Die Zeilen werden nach dem Zufallsprinzip verteilt. Das Laden von Daten in eine Roundrobintabelle geht schnell vonstatten. Bei Abfragen kann aber eine größere Anzahl von Datenverschiebungen erforderlich sein als bei anderen Verteilungsmethoden.

Weitere Informationen finden Sie unter Verteilen von Tabellen in SQL Data Warehouse.

Allgemeine Verteilungsmethoden für Tabellen

Die Tabellenkategorie bestimmt oft die optimale Option für die Tabellenverteilung.

Tabellenkategorie	Empfohlene Verteilungsoption
Fakt	Verwenden Sie die Hashverteilung mit gruppiertem Columnstore-Index. Die Leistung wird verbessert, wenn zwei Hashtabellen über die gleiche Verteilungsspalte verknüpft sind.
Dimension	Verwenden Sie bei kleineren Tabellen die Replikation. Wenn Tabellen zu groß sind, um sie auf jedem Serverknoten zu speichern, verwenden Sie die Hashverteilung.
Staging	Verwenden Sie für die Stagingtabelle das Roundrobinprinzip. Das Laden lässt sich mit CTAS beschleunigen. Wenn sich die Daten in der Stagingtabelle befinden, verwenden Sie INSERT...SELECT, um die Daten in Produktionstabellen zu verschieben.

Partitionen

In dedizierten SQL-Pools speichert eine partitionierte Tabelle die Tabellenzeilen nach Datenbereichen und wendet Vorgänge entsprechend an. Beispielsweise könnte eine Tabelle nach Tag, Monat oder Jahr partitioniert werden. Sie können die Abfrageleistung durch eine Partitionsbeseitigung verbessern, wobei ein Abfragescan auf Daten in einer Partition begrenzt wird.

Auch können Sie die Daten durch Partitionswechsel verwalten. Da die Daten in einem dedizierten SQL-Pool bereits verteilt sind, können zu viele Partitionen die Abfrageleistung beeinträchtigen. Weitere Informationen finden Sie unter Partitionieren von Tabellen in SQL Data Warehouse.

Tipp

Beim Wechseln der Partitionen zu Tabellenpartitionen, die nicht leer sind, sollten Sie die Option TRUNCATE_TARGET in Ihrer ALTER TABLE-Anweisung in Erwägung ziehen, wenn die vorhandenen Daten abgeschnitten werden sollen.

Der folgende Code schaltet die transformierten täglichen Daten in eine SalesFact-Partition und überschreibt alle vorhandenen Daten.

ALTER TABLE SalesFact_DailyFinalLoad SWITCH PARTITION 256 TO SalesFact PARTITION 256 WITH (TRUNCATE_TARGET = ON);  

Bei einem serverlosen SQL-Pool können Sie die Dateien/Ordner (Partitionen) einschränken, die von Ihrer Abfrage gelesen werden sollen. Die Partitionierung nach Pfad wird mit den Funktionen „filepath“ und „fileinfo“ unterstützt, die unter Abfragen von Speicherdateien beschrieben sind. Im folgenden Beispiel wird ein Ordner mit Daten für das Jahr 2017 gelesen:

SELECT
    nyc.filepath(1) AS [year],
    payment_type,
    SUM(fare_amount) AS fare_total
FROM  
    OPENROWSET(
        BULK 'https://sqlondemandstorage.blob.core.windows.net/parquet/taxi/year=*/month=*/*.parquet',
        FORMAT='PARQUET'
    ) AS nyc
WHERE
    nyc.filepath(1) = 2017
GROUP BY
    nyc.filepath(1),
    payment_type
ORDER BY
    nyc.filepath(1),
    payment_type

Columnstore-Indizes

Standardmäßig speichert der dedizierte SQL-Pool eine Tabelle als gruppierten Columnstore-Index. Mit dieser Form der Datenspeicherung wird eine hohe Datenkomprimierung und Abfrageleistung für große Tabellen erreicht. Der gruppierte Columnstore-Index ist in der Regel die beste Wahl, aber in einigen Fällen ist ein gruppierter Index oder ein Heap die geeignete Speicherstruktur.

Tipp

Eine Heaptabelle kann besonders für das Laden flüchtiger Daten hilfreich sind, z. B. für eine Stagingtabelle, die in eine endgültige Tabelle transformiert wird.

Eine Liste der Columnstore-Funktionen finden Sie unter Columnstore-Indizes – Neuigkeiten. Informationen zum Verbessern der Leistung von Columnstore-Indizes finden Sie unter Maximieren der Zeilengruppenqualität für Columnstore.

Statistik

Der Abfrageoptimierer verwendet beim Erstellen des Plans für die Ausführung einer Abfrage Statistiken auf Spaltenebene. Um die Abfrageleistung zu verbessern, ist es wichtig, über Statistiken für einzelne Spalten zu verfügen, insbesondere für in Abfrageverknüpfungen verwendete Spalten. Synapse SQL unterstützt die automatische Erstellung von Statistiken.

Die Aktualisierung der Statistiken erfolgt nicht automatisch. Führen Sie die Statistikaktualisierung durch, wenn eine erhebliche Anzahl von Zeilen hinzugefügt oder geändert wurde. Aktualisieren Sie Statistiken z. B. nach einem Ladevorgang. Weitere Informationen finden Sie im Leitfaden zur Statistik.

Primärschlüssel und eindeutiger Schlüssel

PRIMARY KEY wird für den dedizierten SQL-Pool nur unterstützt, wenn sowohl NONCLUSTERED als auch NOT ENFORCED verwendet werden. Der UNIQUE-Constraint wird nur unterstützt, wenn NOT ENFORCED verwendet wird. Weitere Informationen finden Sie im Artikel zu Tabellenconstraints für dedizierte SQL-Pools.

Befehle zum Erstellen von Tabellen

Sie können für den dedizierten SQL-Pool eine Tabelle als neue leere Tabelle erstellen. Alternativ können Sie eine Tabelle erstellen und mit den Ergebnissen einer SELECT-Anweisung füllen. Es folgen die T-SQL-Befehle zum Erstellen einer Tabelle.

T-SQL-Anweisung	BESCHREIBUNG
CREATE TABLE	Erstellt eine leere Tabelle durch die Definition der Tabellenspalten und Optionen.
CREATE EXTERNAL TABLE	Erstellt eine externe Tabelle. Die Definition der Tabelle wird in einem dedizierten SQL-Pool gespeichert. Die Tabellendaten werden in Azure Blob Storage oder Azure Data Lake Storage abgelegt.
CREATE TABLE AS SELECT	Füllt eine neue Tabelle mit den Ergebnissen einer SELECT-Anweisung. Die Spalten und Datentypen der Tabelle basieren auf den Ergebnissen der SELECT-Anweisung. Mit dieser Anweisung können Daten zum Importieren aus einer externen Tabelle ausgewählt werden.
CREATE EXTERNAL TABLE AS SELECT	Erstellt eine neue externe Tabelle durch den Export der Ergebnisse einer SELECT-Anweisung an einen externen Speicherort. Dieser Speicherort ist entweder Azure Blob Storage oder Azure Data Lake Storage.

Ausrichten von Quelldaten am Data Warehouse

Tabellen in dedizierten SQL-Pools werden durch das Laden von Daten aus einer anderen Datenquelle gefüllt. Um einen Ladevorgang erfolgreich ausführen zu können, müssen die Anzahl und die Datentypen der Spalten in den Quelldaten an der Tabellendefinition im Data Warehouse ausgerichtet werden.

Hinweis

Diese Ausrichtung der Daten zu bewältigen, ist möglicherweise der schwierigste Aspekt beim Entwerfen von Tabellen.

Wenn Daten aus mehreren Datenspeichern stammen, können Sie die Daten in das Data Warehouse übertragen und in einer Integrationstabelle speichern. Sobald sich die Daten in der Integrationstabelle befinden, können Sie die Leistungsfähigkeit des dedizierten SQL-Pools nutzen, um Transformationsvorgänge zu implementieren. Sobald die Daten vorbereitet sind, können Sie sie in Produktionstabellen einfügen.

Nicht unterstützte Tabellenfunktionen

Dedizierte SQL-Pools unterstützen viele, aber nicht alle Tabellenfunktionen, die in anderen Datenbanken zu finden sind. Die folgende Liste enthält einige der Tabellenfunktionen, die im dedizierten SQL-Pool nicht unterstützt werden.

• Fremdschlüssel, überprüfen Sie die Tabellenconstraints
• Berechnete Spalten
• Indizierte Sichten
• Sequenz
• Spalten mit geringer Dichte
• Ersatzschlüssel, implementieren mit Identität
• Synonyme
• Trigger
• Eindeutige Indizes
• Benutzerdefinierte Typen

Abfragen für die Tabellengröße

Eine einfache Möglichkeit beim dedizierten SQL-Pool, die Speicherplatz- und Zeilenbelegung einer Tabelle in jeder der 60 Verteilungen zu ermitteln, bietet DBCC PDW_SHOWSPACEUSED.

DBCC PDW_SHOWSPACEUSED('dbo.FactInternetSales');

Denken Sie daran, dass die Verwendung von DBCC-Befehlen mit größeren Einschränkungen verbunden sein kann. Dynamische Verwaltungssichten (DMVs) zeigen mehr Details als DBCC-Befehle. Beginnen Sie mit der Erstellung der folgenden Sicht.

CREATE VIEW dbo.vTableSizes
AS
WITH base
AS
(
SELECT
 GETDATE()                                                             AS  [execution_time]
, DB_NAME()                                                            AS  [database_name]
, s.name                                                               AS  [schema_name]
, t.name                                                               AS  [table_name]
, QUOTENAME(s.name)+'.'+QUOTENAME(t.name)                              AS  [two_part_name]
, nt.[name]                                                            AS  [node_table_name]
, ROW_NUMBER() OVER(PARTITION BY nt.[name] ORDER BY (SELECT NULL))     AS  [node_table_name_seq]
, tp.[distribution_policy_desc]                                        AS  [distribution_policy_name]
, c.[name]                                                             AS  [distribution_column]
, nt.[distribution_id]                                                 AS  [distribution_id]
, i.[type]                                                             AS  [index_type]
, i.[type_desc]                                                        AS  [index_type_desc]
, nt.[pdw_node_id]                                                     AS  [pdw_node_id]
, pn.[type]                                                            AS  [pdw_node_type]
, pn.[name]                                                            AS  [pdw_node_name]
, di.name                                                              AS  [dist_name]
, di.position                                                          AS  [dist_position]
, nps.[partition_number]                                               AS  [partition_nmbr]
, nps.[reserved_page_count]                                            AS  [reserved_space_page_count]
, nps.[reserved_page_count] - nps.[used_page_count]                    AS  [unused_space_page_count]
, nps.[in_row_data_page_count]
    + nps.[row_overflow_used_page_count]
    + nps.[lob_used_page_count]                                        AS  [data_space_page_count]
, nps.[reserved_page_count]
 - (nps.[reserved_page_count] - nps.[used_page_count])
 - ([in_row_data_page_count]
         + [row_overflow_used_page_count]+[lob_used_page_count])       AS  [index_space_page_count]
, nps.[row_count]                                                      AS  [row_count]
from
    sys.schemas s
INNER JOIN sys.tables t
    ON s.[schema_id] = t.[schema_id]
INNER JOIN sys.indexes i
    ON  t.[object_id] = i.[object_id]
    AND i.[index_id] <= 1
INNER JOIN sys.pdw_table_distribution_properties tp
    ON t.[object_id] = tp.[object_id]
INNER JOIN sys.pdw_table_mappings tm
    ON t.[object_id] = tm.[object_id]
INNER JOIN sys.pdw_nodes_tables nt
    ON tm.[physical_name] = nt.[name]
INNER JOIN sys.dm_pdw_nodes pn
    ON  nt.[pdw_node_id] = pn.[pdw_node_id]
INNER JOIN sys.pdw_distributions di
    ON  nt.[distribution_id] = di.[distribution_id]
INNER JOIN sys.dm_pdw_nodes_db_partition_stats nps
    ON nt.[object_id] = nps.[object_id]
    AND nt.[pdw_node_id] = nps.[pdw_node_id]
    AND nt.[distribution_id] = nps.[distribution_id]
LEFT OUTER JOIN (select * from sys.pdw_column_distribution_properties where distribution_ordinal = 1) cdp
    ON t.[object_id] = cdp.[object_id]
LEFT OUTER JOIN sys.columns c
    ON cdp.[object_id] = c.[object_id]
    AND cdp.[column_id] = c.[column_id]
WHERE pn.[type] = 'COMPUTE'
)
, size
AS
(
SELECT
   [execution_time]
,  [database_name]
,  [schema_name]
,  [table_name]
,  [two_part_name]
,  [node_table_name]
,  [node_table_name_seq]
,  [distribution_policy_name]
,  [distribution_column]
,  [distribution_id]
,  [index_type]
,  [index_type_desc]
,  [pdw_node_id]
,  [pdw_node_type]
,  [pdw_node_name]
,  [dist_name]
,  [dist_position]
,  [partition_nmbr]
,  [reserved_space_page_count]
,  [unused_space_page_count]
,  [data_space_page_count]
,  [index_space_page_count]
,  [row_count]
,  ([reserved_space_page_count] * 8.0)                                 AS [reserved_space_KB]
,  ([reserved_space_page_count] * 8.0)/1000                            AS [reserved_space_MB]
,  ([reserved_space_page_count] * 8.0)/1000000                         AS [reserved_space_GB]
,  ([reserved_space_page_count] * 8.0)/1000000000                      AS [reserved_space_TB]
,  ([unused_space_page_count]   * 8.0)                                 AS [unused_space_KB]
,  ([unused_space_page_count]   * 8.0)/1000                            AS [unused_space_MB]
,  ([unused_space_page_count]   * 8.0)/1000000                         AS [unused_space_GB]
,  ([unused_space_page_count]   * 8.0)/1000000000                      AS [unused_space_TB]
,  ([data_space_page_count]     * 8.0)                                 AS [data_space_KB]
,  ([data_space_page_count]     * 8.0)/1000                            AS [data_space_MB]
,  ([data_space_page_count]     * 8.0)/1000000                         AS [data_space_GB]
,  ([data_space_page_count]     * 8.0)/1000000000                      AS [data_space_TB]
,  ([index_space_page_count]  * 8.0)                                   AS [index_space_KB]
,  ([index_space_page_count]  * 8.0)/1000                              AS [index_space_MB]
,  ([index_space_page_count]  * 8.0)/1000000                           AS [index_space_GB]
,  ([index_space_page_count]  * 8.0)/1000000000                        AS [index_space_TB]
FROM base
)
SELECT *
FROM size
;

Tabellenspeicherplatz – Zusammenfassung

Diese Abfrage gibt die Zeilen und den Speicherplatz nach Tabelle zurück. Die Zusammenfassung des Tabellenbereichs ermöglicht es Ihnen zu sehen, welche Tabellen Ihre größten Tabellen sind. Sie können auch sehen, ob es sich um Roundrobin-, replizierte Tabellen oder Tabellen mit Hashverteilung handelt. Für Tabellen mit Hashverteilung wird zudem die Verteilungsspalte angezeigt.

SELECT
     database_name
,    schema_name
,    table_name
,    distribution_policy_name
,      distribution_column
,    index_type_desc
,    COUNT(distinct partition_nmbr) as nbr_partitions
,    SUM(row_count)                 as table_row_count
,    SUM(reserved_space_GB)         as table_reserved_space_GB
,    SUM(data_space_GB)             as table_data_space_GB
,    SUM(index_space_GB)            as table_index_space_GB
,    SUM(unused_space_GB)           as table_unused_space_GB
FROM
    dbo.vTableSizes
GROUP BY
     database_name
,    schema_name
,    table_name
,    distribution_policy_name
,      distribution_column
,    index_type_desc
ORDER BY
    table_reserved_space_GB desc
;

Tabellenspeicherplatz nach Verteilungstyp

SELECT
     distribution_policy_name
,    SUM(row_count)                as table_type_row_count
,    SUM(reserved_space_GB)        as table_type_reserved_space_GB
,    SUM(data_space_GB)            as table_type_data_space_GB
,    SUM(index_space_GB)           as table_type_index_space_GB
,    SUM(unused_space_GB)          as table_type_unused_space_GB
FROM dbo.vTableSizes
GROUP BY distribution_policy_name
;

Tabellenspeicherplatz nach Indextyp

SELECT
     index_type_desc
,    SUM(row_count)                as table_type_row_count
,    SUM(reserved_space_GB)        as table_type_reserved_space_GB
,    SUM(data_space_GB)            as table_type_data_space_GB
,    SUM(index_space_GB)           as table_type_index_space_GB
,    SUM(unused_space_GB)          as table_type_unused_space_GB
FROM dbo.vTableSizes
GROUP BY index_type_desc
;

Verteilungsspeicherplatz – Zusammenfassung

SELECT
    distribution_id
,    SUM(row_count)                as total_node_distribution_row_count
,    SUM(reserved_space_MB)        as total_node_distribution_reserved_space_MB
,    SUM(data_space_MB)            as total_node_distribution_data_space_MB
,    SUM(index_space_MB)           as total_node_distribution_index_space_MB
,    SUM(unused_space_MB)          as total_node_distribution_unused_space_MB
FROM dbo.vTableSizes
GROUP BY     distribution_id
ORDER BY    distribution_id
;

Nächste Schritte

Nach dem Erstellen der Tabellen für das Data Warehouse werden im nächsten Schritt Daten in die Tabelle geladen. Ein Tutorial zum Laden von Daten finden Sie unter Laden von Daten in einen dedizierten SQL-Pool.