VERTRIEB: 1-800-867-1380

Verbundrichtlinien und -einschränkungen

Letzte Aktualisierung: April 2014

In diesem Thema werden Richtlinien und Einschränkungen für Verbunde in Microsoft Azure SQL-Datenbank beschrieben. Die Details zu den allgemeinen Richtlinien und Einschränkungen werden in den folgenden Abschnitten behandelt.

ImportantWichtig
Die aktuelle Implementierung von Verbünden wird zusammen mit den Web- und Business-Dienstebenen eingestellt. Erwägen Sie die Bereitstellung benutzerdefinierter Shardinglösungen, um Skalierbarkeit, Flexibilität und Leistung zu maximieren. Weitere Informationen zum benutzerdefinierten Sharding finden Sie unter Horizontales Skalieren von Azure SQL-Datenbanken.

Verbunde können Verbundtabellen und Verweistabellen enthalten. Verbundtabellen werden mit der Klausel FEDERATED ON erstellt und enthalten eine Spalte, die dem Verteilungsschlüssel für den enthaltenden Verbund zugeordnet ist. Verweistabellen sind Tabellen in einem Verbund, die nicht mit der Klausel FEDERATED ON erstellt wurden keine besondere Verbindung zum Verbundverteilungsschlüssel aufweisen. Weitere Informationen zum Erstellen von Tabellen finden Sie unter CREATE TABLE.

Verbundtabellen weisen die folgenden Einschränkungen auf:

  • Die Verbundspalte der Verbundtabelle kann nur Daten enthalten, die innerhalb der Grenzwerte range_low (einschließlich) und range_high (ausschließlich) des Verbundmitglieds liegen.

  • Der Datentyp der Verbundspalte muss exakt mit dem Datentyp übereinstimmen, der in der Verbunddefinition festgelegt ist.

  • All eindeutigen und gruppierten Indizes der Verbundtabelle müssen die Verbundspalte enthalten. Die Reihenfolge, in der die Verbundspalte im Index angezeigt wird, kann von der Ordnungszahl des Schlüssels im Verbund abweichen.

  • Verbundspaltenwerte können nicht auf Werte außerhalb des Verbundmitgliedsbereichs aktualisiert werden.

  • Die Verbundspalte kann keine persistente oder nicht persistente berechnete Spalte sein.

  • Indizierte Sichten werden in Verbundmitgliedern nicht unterstützt.

  • Verbundspalten lassen keine NULL-Werte zu.

  • Alle Fremdschlüsseleinschränkungen für Verbundtabellen müssen die Verbundspalte sowohl in der verweisenden Tabelle als auch in der Tabelle, auf die verwiesen wird, mit derselben Ordnungszahl in den Fremdschlüssel einbeziehen. Für Verweistabellen können keine Fremdschlüsselbeziehungen zu Verbundtabellen definiert werden. Für Verbundtabellen hingegen können ohne Einschränkungen Fremdschlüsselbeziehungen zu Verbundtabellen definiert werden.

  • Mit der FEDERATED ON-Klausel erstellte Tabellen können wie gewohnt gelöscht werden. Sie können auch ALTER TABLE verwenden, um alle Eigenschaften einer Verbundtabelle zu ändern. Verbundattribute wie der Verbundschlüssel sind hiervon ausgenommen. Um eine Verweistabelle in eine Verbundtabelle oder eine Verbundtabelle in eine Verweistabelle zu ändern, müssen Sie neue Tabellen mit den gewünschten Eigenschaften erstellen und die vorhandene Tabelle löschen.

  • Wenn eine Tabelle mit STATISTICS_NORECOMPUTE gekennzeichnet ist, werden Statistiken beim Durchführen von Verbundvorgängen wie SPLIT nicht für ungültig erklärt und nicht neu berechnet. Dies kann nach Neupartitionierungsvorgängen wie SPLIT zu Problemen im Ausführungsplan führen.

  • Verbundmitglieder bieten keine Unterstützung für die IDENTITY-Eigenschaft.

  • Verbundmitglieder bieten keine Unterstützung für die Datentypen timestamp und rowversion.

Alle allgemeinen Tabellenmetadaten für Verbundtabellen stehen über Standardsystemsichten zur Verfügung. Für den Verbund spezifische Eigenschaften stehen über sys.federated_table_columns zur Verfügung.

Verweistabellen werden nicht automatisch an alle Verbundmitglieder verteilt. Verweistabellen können manuell über alle Elemente eines Verbunds repliziert werden. Ein entsprechender automatischer Vorgang ist jedoch nicht vorhanden.

Verweistabellen enthalten oftmals ergänzende Informationen für Abfragen von Verbundtabellen. Dadurch entfällt die Notwendigkeit, mehrere Datenbanken abzufragen. So kann es sinnvoll sein, Kundendaten auf mehrere Elementdatenbanken zu vereinen und zu verteilen, während dies für entsprechende Daten zu Bundesländern und Postleitzahlen nicht unbedingt hilfreich ist. Sie können jedoch eine Kopie der Angaben für das Bundesland und die Postleitzahl im jeweiligen Verbundmitglied speichern, sodass Abfragen nicht für mehrere Datenbanken ausgeführt werden müssen.

Der geography- und der geometry-Typ können nicht als Datentyp der Spalte verwendet werden, mit der eine Verbundtabelle verbunden ist. Sie können jedoch Datentypen der Verbundtabelle sein. Die Verwendung von räumlichen Daten für Verbunde unterliegt keinen weiteren Einschränkungen.

Räumliche Indizes bleiben nach einem SPLIT- oder DROP-Vorgang in den Zielverbundmitgliedern konsistent und intakt.

Der hierarchyid-Typ kann nicht als Datentyp der Spalte verwendet werden, mit der eine Verbundtabelle verbunden ist. Er kann jedoch ein Datentyp der Verbundtabelle sein. Die Verwendung von hierarchyid für Verbunde unterliegt keinen weiteren Einschränkungen.

hierarchyid-Indizes bleiben nach einem SPLIT- oder DROP-Vorgang in den Zielverbundmitgliedern konsistent und intakt.

Verbindungen mit einem Verbund werden über die Anweisung USE FEDERATION hergestellt. Diese Anweisung leitet die Verbindung automatisch an das richtige Mitglied in einem Verbund weiter. Es ist daher nicht erforderlich, den Namen der physischen Datenbank zu kennen, wenn auf die Daten zugegriffen wird. Durch Angeben eines Verbundverteilungsschlüssels und eines Werts wird eine Verbindung mit der entsprechenden Elementdatenbank im Verbund hergestellt.

Authentifizierung und Autorisierung gegenüber einer Datenbank mit einem Verbund werden wie gewohnt durchgeführt. Die Konnektivität wird durch Anmeldungen und Benutzer bestimmt. Die Gruppierung von Prinzipalen wird durch Rollen verwaltet. Die Prinzipale in einer Datenbank mit einem Verbund werden jedoch auf die Verbundstammdatenbank beschränkt und nicht automatisch auf alle Elemente im Verbund angewendet. Weitere Informationen zu Benutzern und Rollen finden Sie unter Verwalten von Datenbankverbunden (Azure SQL-Datenbank).

Für eine Datenbank, die Verbunde enthält, kann kein Datenbankkopiervorgang ausgeführt werden. Wenn in einer Datenbank ein Datenbankkopiervorgang aktiv ist, schlägt das Erstellen eines Verbunds fehl. Für Verbundmitglieder kann ebenfalls keine Datenbankkopie ausgeführt werden.

Verbundvorgänge werden nicht auf das Verbundstammkontingent angewendet. Wenn das Kontingent für die Stammdatenbank überschritten wird, können Sie weiterhin SPLIT- und DROP-Vorgänge ausführen. Wenn das Kontingent für ein Verbundmitglied überschritten wird, können ebenso weiterhin SPLIT- oder DROP-Vorgänge ausgeführt werden, solange das Kontingent der Zieldatenbank nicht durch den Vorgang überschritten wird.

Nach Abschluss von Neupartitionierungsvorgängen wie SPLIT und DROP werden die Verbindungen gelöscht. Das bedeutet, dass Verbindungseigenschaften, z. B. SET-Optionen, Einstellungen der Transaktionsisolationsstufe oder Variablen, ebenfalls zurückgesetzt werden. Durch einen SPLIT-Vorgang wird eine neue physische Datenbank erstellt. Daher können die folgenden Transact-SQL-Eigenschaften nicht über mehrere SPLIT-Vorgänge beibehalten werden.

 

Transact-SQL Einschränkungen der SQL-Datenbank-Unterstützung Unterstützung in Datenbanken mit Verbunden

timestamp-Datentyp und rowversion-Datentyp

Nicht per Commit bestätigte timestamp-Werte und rowversion-Werte der aktuellen Datenbank (DBTS) werden von der SQL-Datenbank möglicherweise nicht failoverübergreifend beibehalten.

Der timestamp-Datentyp und der rowversion-Datentyp werden in Verbundmitgliedern nicht unterstützt.

Funktionen mit timestamp und rowversion, z. B. @@dbts, geben Werte zurück, wenn in einer angegebenen Datenbank kein timestamp-Wert und kein rowversion-Wert vorhanden ist.

SYSUTCDATETIME(),SYSDATETIMEOFFSET(),SYSDATETIME(),getdate(), getutcdate()current_timestamp

SQL-Datenbank meldet möglicherweise timestamp-Werte und rowversion-Werte vom lokalen Computer sowie failoverübergreifende Zeitangaben, die weiter in der Zukunft oder weiter in der Vergangenheit liegen.

Mit den gleichen Einschränkungen über mehrere Neupartitionierungsvorgänge unterstützt.

DATABASE_PRINCIPAL_ID()

Prinzipal-SIDs bleiben für einen angegebenen Prinzipalnamen zwischen Verbundmitgliedern und Verbundstämmen unverändert erhalten. Nach einem Neupartitionierungsvorgang, z. B. DROP, können sich Prinzipal-IDs jedoch ändern.

IDENTITY-Eigenschaft von Spalten

Die IDENTITY-Eigenschaft wird in Verbundmitgliedern nicht unterstützt. Identitätsfunktionen, z. B. IDENT_CURRENT, IDENT_SEED, IDENT_INCR und SCOPE_IDENTITY, geben immer NULL zurück, da in Verbundmitgliedern keine Identitätsspalten vorhanden sein können.

OBJECT_ID und entsprechende Funktionen, die für benutzerdefinierte Objekte ausgeführt werden; object_id(…), object_name(object_id), type_id(…), type_name(type_id)

Nach einem Neupartitionierungsvorgang, z. B. DROP, kann sich die Object_id von benutzerdefinierten Objekten ändern.

Alle Azure SQL-Datenbank-Datenbankeinstellungen werden unterstützt. Jedoch wird durch Änderungen des Werts einer Option für die Verbundstammdatenbank nicht die Option für die Verbundmitglieder geändert.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft