Rozwiązywanie rozproszonych widoków partycji

SQL Server Kwerendy procesora optymalizację wydajności distributed widoki podzielonym na partycje.Najważniejszy aspekt wydajności distributed widoku podzielonym na partycje jest zminimalizować ilość danych przesyłanych między element członkowski serwerów.

SQL Serverbuduje intelligent, dynamicznych plany, które wydajnie korzystać z kwerendami rozproszonymi dostęp do danych z tabel element członkowski zdalnych:

• Procesor kwerend używa najpierw OLE DB, aby pobrać definicji ograniczenie wyboru tabela każdego element członkowski.Dzięki temu procesor kwerend mapować rozkład klucz wartości w tabelach element członkowski.

• Procesor kwerend porównuje klucz zakresy określone w instrukcja języka SQL gdzie klauzula do mapy, który pokazuje rozkład wierszy w tabelach element członkowski.Procesor kwerend buduje następnie plan wykonania kwerend, który używa kwerend rozproszonych pobrać tylko te wiersze zdalnego, które są wymagane do wykonania instrukcja języka SQL.Plan wykonania jest również zbudowana w taki sposób ich dostępu do tabel element członkowski zdalnych danych lub metadane, poczekać informacja jest wymagana.

Rozważmy na przykład systemu, gdy tabela Klienci jest podzielony na partycje w serwer1 (IDklienta od 1 do 3299999), serwer2 (IDklienta z 3300000 przez 6599999), i serwer3 (IDklienta z 6600000 poprzez 9999999).

Rozważ plan wykonania zbudowane dla tej kwerendy wykonywane na serwer1:

SELECT *
FROM CompanyData.dbo.Customers
WHERE CustomerID BETWEEN 3200000 AND 3400000;

Plan wykonania dla tej kwerendy wyodrębnia wiersze z IDklienta wartości z 3200000 3299999 z lokalnym za pomocą klucza element członkowski tabela i problemy zapytanie rozproszone, aby pobrać wiersze z kluczem wartości z 3300000 przez 3400000 z serwer2.

SQL Server Procesor kwerend można również tworzyć dynamiczne logiki do kwerendy plany wykonanie instrukcji SQL, w których wartości klucz nie wiadomo, kiedy plan muszą być budowane.Na przykład rozważmy tej procedura składowana:

CREATE PROCEDURE GetCustomer @CustomerIDParameter INT
AS
SELECT *
FROM CompanyData.dbo.Customers
WHERE CustomerID = @CustomerIDParameter;

SQL Servernie można przewidzieć, jakie wartości klucz zostanie dostarczone przez @ customeridparameter parametr co czas procedura zostanie wykonana.Ponieważ nie można przewidzieć wartości klucz, procesor kwerend również nie można przewidzieć który element członkowski tabela ma być dostępny.Do obsługi tej przypadek SQL Server tworzy plan wykonania, zawierający logiki warunkowe, określane jako dynamiczne filtry, który element członkowski sterowania tabela jest dostępny, oparty na wartości parametru wejściowego.Przy założeniu, że GetCustomer procedura składowana została wykonana na serwer1, może być reprezentowany logiki wykonanie planu, jak pokazano poniżej:

IF @CustomerIDParameter BETWEEN 1 and 3299999
   Retrieve row from local table CustomerData.dbo.Customer_33
ELSEIF @CustomerIDParameter BETWEEN 3300000 and 6599999
   Retrieve row from linked table Server2.CustomerData.dbo.Customer_66
ELSEIF @CustomerIDParameter BETWEEN 6600000 and 9999999
   Retrieve row from linked table Server3.CustomerData.dbo.Customer_99

SQL ServerCzasami tworzy te typy planów dynamic execution, nawet dla kwerend, które nie są parametryzowane.Optymalizator może parameterize kwerendę, tak aby plan wykonania mogą być ponownie użyte.Jeśli Optymalizator parameterizes kwerenda odwołującym się widokiem podzielonym na partycje, Optymalizator już można przyjąć wymagane wiersze będą pochodzić z określonej tabela bazowa.Za pomocą filtrów dynamicznych w plan wykonania będzie wtedy.Aby uzyskać więcej informacji, zobacz Parametryzacja proste.