Erstellen von verteilten partitionierten Sichten

Erstellen von Elementtabellen

Sie entwerfen die Elementtabellen derart, dass jede Tabelle einen horizontalen Slice der ursprünglichen Tabelle basierend auf einem Schlüsselwertbereich speichert. Diese Bereiche basieren auf den Datenwerten in einer Partitionierungsspalte. Der Wertebereich in jeder Elementtabelle wird durch eine CHECK-Einschränkung in der Partitionierungsspalte erzwungen, und die Bereiche dürfen sich nicht überschneiden. So ist es beispielsweise nicht möglich, eine Tabelle mit einem Bereich von 1 bis 200.000 und eine andere Tabelle mit einem Bereich von 150.000 bis 300.000 zu verwenden, da in diesem Fall nicht erkennbar ist, welche Tabelle die Werte von 150.000 bis 200.000 enthält.

Beispiel: Sie partitionieren eine Customer-Tabelle und erhalten drei Tabellen. Die CHECK-Einschränkung für diese Tabellen sieht folgendermaßen aus:

-- On Server1:
CREATE TABLE Customers_33
  (CustomerID   INTEGER PRIMARY KEY
                CHECK (CustomerID BETWEEN 1 AND 32999),
  ... -- Additional column definitions)

-- On Server2:
CREATE TABLE Customers_66
  (CustomerID   INTEGER PRIMARY KEY
                CHECK (CustomerID BETWEEN 33000 AND 65999),
  ... -- Additional column definitions)

-- On Server3:
CREATE TABLE Customers_99
  (CustomerID   INTEGER PRIMARY KEY
                CHECK (CustomerID BETWEEN 66000 AND 99999),
  ... -- Additional column definitions)

Definieren verteilter partitionierter Sichten

Nach dem Erstellen der Elementtabellen definieren Sie auf jedem Mitgliedsserver eine verteilte partitionierte Sicht, wobei jede Sicht den gleichen Namen hat. Auf diese Weise können Abfragen, die auf den Namen der verteilten partitionierten Sicht verweisen, auf einem oder auf mehreren der Mitgliedsserver ausgeführt werden. Das System arbeitet so, als ob sich auf jedem Mitgliedsserver eine Kopie der ursprünglichen Tabelle befinden würde, aber jeder Server weist nur eine Elementtabelle und eine verteilte partitionierte Sicht auf. Der Speicherort der Daten ist für die Anwendung transparent.

Sie erstellen die verteilten partitionierten Sichten, indem Sie folgende Schritte ausführen:

• Hinzufügen von Verbindungsserverdefinitionen auf jedem Mitgliedsserver, der die erforderlichen Verbindungsinformationen zum Ausführen verteilter Abfragen auf den anderen Mitgliedsservern enthält. Dadurch erhält eine verteilte partitionierte Sicht Zugriff auf die Daten auf den anderen Servern.

• Festlegen der Option lazy schema validation mithilfe von sp_serveroption für jede in verteilten partitionierten Sichten verwendete Verbindungsserverdefinition. Hierdurch wird die Leistung optimiert, indem sichergestellt wird, dass der Abfrageprozessor erst dann Metadaten für verknüpfte Tabellen anfordert, wenn die Daten tatsächlich von der Remoteelementtabelle benötigt werden.

• Erstellen einer verteilten partitionierten Sicht auf jedem Mitgliedsserver. Die Sichten verwenden verteilte SELECT-Anweisungen für den Zugriff auf Daten von den Verbindungsmitgliedsservern, und die verteilten Zeilen werden mit Zeilen aus der lokalen Elementtabelle zusammengeführt.

Um verteilte partitionierte Sichten für das vorherige Beispiel zu erstellen, müssen Sie folgendermaßen vorgehen:

• Hinzufügen der Verbindungsserverdefinition Server2 mit den Verbindungsinformationen für Server2 sowie der Verbindungsserverdefinition Server3 für den Zugriff auf Server3.

• Erstellen Sie die folgende verteilte partitionierte Sicht:

  CREATE VIEW Customers AS
     SELECT * FROM CompanyDatabase.TableOwner.Customers_33
  UNION ALL
     SELECT * FROM Server2.CompanyDatabase.TableOwner.Customers_66
  UNION ALL
     SELECT * FROM Server3.CompanyDatabase.TableOwner.Customers_99
  

• Führen Sie dieselben Schritte auf Server2 und Server3 aus.

Tabellenregeln

Elementtabellen werden in der FROM-Klausel der einzelnen SELECT-Anweisungen in der Sichtdefinition definiert. Jede Elementtabelle muss folgenden Regeln entsprechen:

• In der Sicht darf nur maximal einmal auf eine Elementtabelle verwiesen werden.

• Elementtabellen dürfen keine für berechnete Spalten erstellten Indizes enthalten.

• Elementtabellen müssen über sämtliche PRIMARY KEY-Einschränkungen in derselben Anzahl von Spalten verfügen.

• Elementtabellen müssen dieselbe Einstellung für ANSI-Leerstellen aufweisen. Weitere Informationen zur Einstellung von ANSI-Leerstellen finden Sie unter SET ANSI_PADDING.

Spaltenregeln

Spalten werden in der Auswahlliste der einzelnen SELECT-Anweisungen in der Sichtdefinition definiert. Jede Spalte muss folgenden Regeln entsprechen:

• Alle Spalten in jeder einzelnen Elementtabelle müssen in der Auswahlliste enthalten sein. SELECT * FROM <member table> ist ein Beispiel zulässiger Syntax.

• In der Auswahlliste darf nur maximal einmal auf eine Spalte verwiesen werden.

• Die Spalten müssen sich in der Auswahlliste an derselben Ordnungsposition befinden.

• Die Spalten in der Auswahlliste der einzelnen SELECT-Anweisungen müssen vom gleichen Typ sein. Dies bezieht sich z. B. auf Datentyp, Genauigkeit, Dezimalstellen und Sortierung. Die folgende Sichtdefinition würde beispielsweise einen Fehler erzeugen, weil die erste Spalte in beiden SELECT-Anweisungen nicht vom selben Datentyp ist:

  CREATE VIEW NonUpdatable
  AS
  SELECT IntPrimaryKey, IntPartNmbr
  FROM FirstTable
    UNION ALL
  SELECT NumericPrimaryKey, IntPartNmbr
  FROM SecondTable
  

Regeln für Partitionierungsspalten

Zum Partitionieren kann jeweils nur eine Spalte verwendet werden, die in jeder Elementtabelle vorhanden sein muss. CHECK-Einschränkungen identifizieren die in den einzelnen Elementtabellen verfügbaren Daten. Es gelten folgende zusätzliche Regeln:

• Die Schlüsselbereiche der CHECK-Einschränkungen in jeder Tabelle dürfen sich nicht mit den Bereichen anderer Tabellen überschneiden. Jeder bestimmte Wert in der Partitionierungsspalte darf nur einer einzigen Tabelle zugeordnet sein. In CHECK-Einschränkungen können nur die folgenden Operatoren verwendet werden: BETWEEN, IN, AND, OR, <, <=, >, >=, =.

• Bei der Partitionierungsspalte darf es sich nicht um eine Identitäts-, Standard- oder timestamp-Spalte handeln.

• Die Partitionierungsspalte muss sich in der Auswahlliste jeder SELECT-Anweisung der Sicht an derselben Ordnungsposition befinden. Beispielsweise ist die Partitionierungsspalte stets die erste Spalte in jeder Auswahlliste oder die zweite Spalte in jeder Auswahlliste usw.

• In der Partitionierungsspalte sind keine NULL-Werte zugelassen.

• Die Partitionierungsspalte muss Teil des Primärschlüssels der Tabelle sein.

• Die Partitionierungsspalte darf keine berechnete Spalte sein.

• Für die Partitionierungsspalte darf nur eine Einschränkung gelten. Liegen mehrere Einschränkungen vor, werden sämtliche Einschränkungen von SQL Server ignoriert und nicht berücksichtigt, wenn bestimmt wird, ob es sich bei einer Sicht um eine partitionierte Sicht handelt.

• Für Partitionierungsspalten gelten keine Einschränkungen hinsichtlich der Aktualisierbarkeit.

Eine Partitionierungsspalte, die alle diese Regeln erfüllt, unterstützt sämtliche Optimierungen, die der Abfrageoptimierer ermöglicht. Weitere Informationen finden Sie unter Auflösen verteilter partitionierter Sichten.

Allgemeine Regeln

Hinweis
Folgende Bedingungen gelten nicht für lokal partitionierte Sichten, die auf demselben Server erstellt wurden. Dieses Feature wird für die Rückwärtskompatibilität bereitgestellt.

Nachfolgend sind einige zusätzliche Regeln aufgeführt:

• Eine verteilte partitionierte Sicht kann nicht mithilfe von EXCEPT- und INTERSECT-Operatoren erstellt werden.

• Es wird eine verteilte Transaktion gestartet, um die Unteilbarkeit bei allen durch die Aktualisierung betroffenen Knoten sicherzustellen.

• Die SET-Option XACT_ABORT muss auf ON festgelegt werden.

• smallmoney- und smalldatetime-Spalten in Remotetabellen werden jeweils als money bzw. datetime zugeordnet. Demzufolge sollten die entsprechenden Spalten in den lokalen Tabellen ebenfalls vom Datentyp money bzw. datetime sein.

• Als Verbindungsserver kann kein Loopback-Verbindungsserver eingesetzt werden. Dies ist ein Verbindungsserver, der auf dieselbe SQL Server-Instanz verweist.

Eine Sicht, die auf partitionierte Tabellen verweist, ohne alle diese Regeln einzuhalten, ist möglicherweise weiterhin aktualisierbar, falls in der Sicht ein INSTEAD OF-Trigger vorhanden ist. Der Abfrageoptimierer kann jedoch für eine Sicht mit einem INSTEAD OF-Trigger eventuell nicht immer so effiziente Ausführungspläne wie für eine partitionierte Sicht erstellen, die alle Regeln einhält.

Siehe auch

Verweis

Konzepte