HINWEIS: Die Übersicht über elastische Abfragen in Azure SQL-Datenbank (Vorschauversion) enthält die aktuellsten relevanten Informationen zu elastischen Datenbankabfragen.

Wir freuen uns, eine Reihe wichtiger Verbesserungen bei elastischen Datenbankabfragen in Azure SQL-Datenbank bekannt geben zu können. Am wichtigsten ist vielleicht, dass elastische Datenbankabfragen jetzt datenbankübergreifende Abfragen in Azure SQL-Datenbank erlauben. Dadurch sind gängige Aufgaben zur datenbankübergreifenden Abfrage wie SELECT-Anweisungen aus einer Remotetabelle in eine lokale Tabelle möglich.

Außerdem werden auch umfassendere Abfragetopologien mit Remotedatenbanken wie in der folgenden Abbildung ermöglicht, in der eine Reihe von Datenbanken Zugriff auf Tabellen in anderen Datenbanken benötigt.

Die neuen Funktionen zur datenbankübergreifenden Abfrage ergänzen bereits bestehende Funktionen für elastische Datenbankabfragen mit horizontaler Partitionierung (Sharding), die in der folgenden Abbildung gezeigt werden.

Im Gegensatz zu lokalen SQL Server-Instanzen werden bei elastischen Datenbankabfragen in Azure SQL-Datenbank nun vertikale und horizontale Partitionierungen unter einem gemeinsamen Konzept über dieselbe Oberfläche zusammengefasst.

Einige Verbesserungen beim neuesten Update der Vorschauversion elastischer Datenbankabfragen:

• Bessere Unterstützung für gängige datenbankübergreifende Abfrageszenarien ohne Sharding
• Elastische Abfragen nun in den Leistungsstufen Standard und Premium verfügbar
• Flexible DDL (Datendefinitionssprache) erlaubt nun Aliase für Schema- und Tabellennamen für die Darstellung von Tabellen in Remotedatenbanken
• Deutlich bessere Leistung bei Abfragen mit T-SQL-Parametern mit Verweisen auf Remotetabellen
• Bessere Leistung bei Abfragen, die eine sehr große Anzahl von Zeilen aus Remotedatenbanken zurückgeben
• Unterstützung für Parameter in der Prozedur sp_execute_fanout

In den folgenden Abschnitten finden Sie weitere Einzelheiten zu diesen Verbesserungen.

Abfragen von Remotedatenbanken

Elastische Datenbankabfragen ermöglichen nun auch den Zugriff auf Tabellen in Remoteinstanzen von Azure SQL-Datenbank. Dies wird über eine einfache Erweiterung in der DDL für externe Datenquellen und externe Tabellen erreicht. Sie können z. B. eine externe Datenquelle definieren, die den Zugriff auf eine Remotedatenbank ermöglicht, in der von allen Datenbanken Ihrer Datenschicht gemeinsam genutzte Verweisdaten gespeichert sind. Außerdem können Sie ganz einfach den Inhalt aus Tabellen in einer Remotedatenbank mit einer INSERT INTO ... SELECT-Anweisung kopieren.

Externe Datenquellen, die auf eine einzelne Remotedatenbank verweisen, werden über die RDBMS-Option in der TYPE-Klausel der folgenden DDL-Anweisung identifiziert:

CREATE EXTERNAL DATA SOURCE RemoteReferenceData
WITH
(
	TYPE=RDBMS,
	LOCATION='myserver.database.windows.net',
	DATABASE_NAME='ReferenceData',
	CREDENTIAL= SqlUser
);

Auf der Basis dieser externen Datenquelle können Sie nun eine externe Tabelle definieren, die Remotezugriff auf eine Tabelle mit Postleitzahlen (ZIP-Codes) in der Datenbank „ReferenceData“ ermöglicht.

CREATE EXTERNAL TABLE [dbo].[zipcode](
	[zc_id] int NOT NULL,
	[zc_cityname] nvarchar(256) NULL,
	[zc_zipcode] nvarchar(20) NOT NULL,
	[zc_country] nvarchar(5) NOT NULL
)
WITH
(
	DATA_SOURCE = RemoteReferenceData
);

Nach dieser einfachen – und einmaligen – Einrichtung können Sie in Ihren Abfragen nun von jeder Azure SQL-Datenbank-Instanz, in der die externe Datenquelle und die externe Tabelle definiert wurden, auf die Remotetabelle mit den Postleitzahlen zugreifen.

Verfügbarkeit in zusätzlichen Leistungsstufen

Elastische Datenbankabfragen sind nun auch auf der Leistungsstufe Standard von Azure SQL-Datenbank verfügbar. Damit lassen sich die Einstiegskosten für Szenarien mit datenbankübergreifenden Abfragen und Partitionierung in Azure SQL-Datenbank erheblich senken. Aufgrund der niedrigeren DTU-Grenzwerte im Tarif Standard kann es bis zu einer Minute dauern, elastische Datenbankabfragen zu initialisieren, wenn Sie das erste Mal eine Remotedatenbank abfragen. Die Wartezeit bei der Initialisierung für elastische Datenbankabfragen ist einer der Aspekte, an denen wir besonders intensiv arbeiten. Dieses Verhalten wird sich in den nächsten Monaten sicherlich verbessern.

Mehr Flexibilität bei der Benennung

Bei verschiedenen wichtigen Szenarien ist es erforderlich, Ihre externe Tabelle anders als die ursprüngliche Tabelle in der Remotedatenbank zu benennen. Dies gilt beispielsweise für Fälle, in denen bereits eine lokale Tabelle mit demselben Namen wie die in der Remotetabelle vorhanden ist. In solchen Szenarien muss es möglich sein, einen Alias anstelle des Namens der Remotetabelle zu verwenden.

Gehen Sie beispielsweise von dem Fall aus, dass die Definition einer externen Tabelle eine dynamische Verwaltungssicht (Dynamic Management View, DMV) über eine horizontal partitionierte Datenschicht (Shard) aggregieren soll. Bisher waren dafür komplizierte Problemumgehungen notwendig, z. B. das Umbenennen der DMV mit einer Sicht der Remotedatenbanken und das Verweisen auf die Sicht aus der externen Tabellendefinition. Dies war notwendig, da DMV-Namen oder Katalognamen, die lokal bereits vorhanden waren, nicht direkt als die Namen externer Tabellen verwendet werden konnten.

Nun können Sie einen beliebigen Namen für die externe Tabelle verwenden und die zugrunde liegende Remotetabelle mit den neuen Klauseln OBJECT_SCHEMA und OBJECT_NAME in der DDL für die externe Tabelle identifizieren. Dies vereinfacht Abfragen über DMVs oder Katalogsichten Ihrer horizontal skalierten Datenschicht, wie die folgenden Beispiele veranschaulichen. Die folgende DDL (Datendefinitionssprache) führt die einmalige Einrichtung der externen Datenquelle und der externen Tabelle durch. Beachten Sie die Verwendung der Klauseln OBJECT_SCHEMA und OBJECT_NAME in der Definition der externen Tabelle:

CREATE EXTERNAL DATA SOURCE MyExtSrc
WITH
(
	TYPE=SHARD_MAP_MANAGER,
	LOCATION='myserver.database.windows.net',
	DATABASE_NAME='ShardMapDatabase',
	CREDENTIAL= SMMUser,
	SHARD_MAP_NAME='ShardMap'
);

 

CREATE EXTERNAL TABLE [dbo].[all_dm_exec_requests](
	[session_id] smallint NOT NULL,
	[request_id] int NOT NULL,
	[start_time] datetime NOT NULL, 
	[status] nvarchar(30) NOT NULL,
	[command] nvarchar(32) NOT NULL,
	[sql_handle] varbinary(64),
	[statement_start_offset] int,
	[statement_end_offset] int,
	[cpu_time] int NOT NULL
)
WITH
(
	DATA_SOURCE = MyExtSrc,
	SCHEMA_NAME = 'sys',
	OBJECT_NAME = 'dm_exec_requests',
	DISTRIBUTION=ROUND_ROBIN
);

Nun können Sie die aufwendigsten Anforderungen über Ihre gesamte Datenschicht mit einer einfachen elastischen Datenbankabfrage wie der folgenden ausführen:

SELECT TOP 10 
	[request_id],
	[start_time]
	[status],
	[command]
FROM all_dm_exec_requests
ORDER BY [cpu_time] DESC

Neue Signatur für sp_execute_fanout

Elastische Datenbankabfragen umfassen die gespeicherte Prozedur sp_execute_fanout, mit der Sie gespeicherte Prozeduren und Funktionen in Remotedatenbanken aufrufen können. Durch die aktuellen Verbesserungen bei Azure SQL-Datenbank wird die Signatur von sp_execute_fanout nun an die vertraute Signatur für sp_executesql angeglichen. Mit der Einführung Anfang nächster Woche können Sie so normale SQL-Parameter in Aufrufen von sp_execute_fanout übergeben.

Leistungsverbesserungen

Bisher konnten mit elastischen Datenbankabfragen keine parametrisierten Vorgänge an Remotedatenbanken gepusht werden. Aus diesem Grund mussten die zum Teil sehr viele Zeilen umfassenden Datensätze unnötigerweise an einen lokalen Speicherort übertragen werden, um diese Vorgänge überprüfen zu können. Durch die aktuellen Verbesserungen können nun parametrisierte Vorgänge an Remotedatenbanken gepusht und remote geprüft werden. Für eine Abfrage über eine externe und eine Tabelle wie im folgenden Fall können Sie damit verhindern, dass Millionen Zeilen übertragen werden müssen, um den Auswahlfilter in der WHERE-Klausel der Remotedatenbank zu überprüfen:

DECLARE @low int
DECLARE @high int
SET @low = 100
SET @high = 200

SELECT c.CustomerId, c.Name, count(OrderId) 
FROM remote_customers c
JOIN local_orders o
ON c.CustomerId = o.CustomerId 
WHERE c.CustomerId > @low and c.CustomerId < @high
GROUP BY c.CustomerId, c.Name

Ein kurzer Blick auf den Abfrageplan der obigen Abfrage bestätigt, dass das Bereichsprädikat der Kunden-ID in der WHERE-Klausel erfolgreich in den Operator der Remoteabfrage übertragen wurde.

Schließlich haben wir auch die Übertragung einer großen Zahl sehr kleiner Zeilen mithilfe einer elastischen Datenbankabfrage effizienter gemacht. Bei unseren Tests zeigte sich eine Leistungssteigerung für Abfragen über externe Tabellen mit einem Faktor über fünf, wenn 100.000 oder mehr Zeilen übertragen wurden.

Wenn Sie mehr über alle hier besprochenen Verbesserungen erfahren möchten, sehen Sie sich die Übersicht über elastische Datenbankabfragen an.