Rozpoznawanie usługi widoki podzielonym na partycje
The SQL Server query processor optimizes the performance of distributed partitioned views.Najważniejszy aspekt wydajności rozproszony widok partycjonowany jest zminimalizować ilość danych przesyłanych między serwerami członkowskimi.
SQL Server Tworzy plany inteligentne, dynamiczne, które efektywnego wykorzystania kwerendami rozproszonymi do uzyskiwania dostępu do danych z tabel element członkowski członkowski zdalnych:
Procesor kwerend używa najpierw OLE DB do pobrania definicji ograniczenia wyboru z każdej tabela element członkowski.Dzięki temu procesor kwerend do mapowania rozkład wartości kluczy w tabelach element członkowski.
Procesor kwerend porównuje klucz zakresu określonego w instrukcja języka SQL klauzulę WHERE do mapy, która pokazuje, jak wiersze są rozmieszczone w tabelach element członkowski.Procesor kwerend buduje następnie plan wykonania kwerend, korzystającej z kwerendami rozproszonymi w celu pobrania tylko te wiersze zdalnego, które są wymagane do wykonania instrukcja języka SQL.Plan wykonania jest także wbudowana w taki sposób, opóźnienia ich dostępu do element członkowski członkowski zdalnych tabele, dane lub metadane, dopóki informacja jest wymagana.
Rozważmy na przykład w przypadku gdy tabela Klienci jest podzielony na partycje w systemie Serwer1 (Identyfikator klienta od 1 do 3299999), Serwer2 (Identyfikator klienta z 3300000 za pośrednictwem 6599999), a Server3 (Identyfikator klienta z 6600000 za pośrednictwem 9999999).
Należy wziąć pod uwagę przeznaczony dla tej kwerendy wykonywane na plan wykonania Serwer1:
SELECT *
FROM CompanyData.dbo.Customers
WHERE CustomerID BETWEEN 3200000 AND 3400000;
Plan wykonania dla tej kwerendy wyodrębnia wiersze z Identyfikator klienta klucz wartości z 3200000 za pośrednictwem 3299999 z tabela element członkowski członkowski lokalnej i wydaje rozproszonych kwerendy w celu pobrania wierszy z wartości klucza z 3300000 za pośrednictwem 3400000 z Serwer2.
The SQL Server query processor can also build dynamic logic into query execution plans for SQL statements in which the klucz values are not known when the plan must be built. Na przykład należy wziąć pod uwagę tę procedura przechowywana:
CREATE PROCEDURE GetCustomer @CustomerIDParameter INT
AS
SELECT *
FROM CompanyData.dbo.Customers
WHERE CustomerID = @CustomerIDParameter;
SQL Server Nie można przewidzieć, jakie wartości klucz dostarczanych przez @ CustomerIDParameter parametr przy każdym wykonaniu procedury.Ponieważ nie może być przewidywane wartości klucz, procesor kwerend również nie można przewidzieć których Członkowskie wymagane będzie można uzyskać dostępu do tabela.Do obsługi tej przypadek SQL Server tworzy plan wykonania, który zawiera logikę warunkowe, określonych filtrów dynamicznych, do kontrolowania dostępu do tabel, które element członkowski oparty na wartość parametru wejściowego. Zakładając, że GetCustomer przechowywane procedury zostało wykonane na Serwer1, może być reprezentowany logiki plan wykonania, jak pokazano w następującej:
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 Server Czasami tworzy te typy planów wykonywania dynamicznej, nawet w przypadku kwerendy, które nie są parametryzowane.Optymalizator może parameterize kwerendy, dzięki czemu można ponownie użyć planu wykonania.Jeśli Optymalizator parameterizes kwerendy, odwoływanie się do widoku podzielonym na partycje, Optymalizator może już przyjmować wymagane wiersze będą pochodzić z określonej tabela bazowa.Następnie ma używać filtrów dynamicznych w planu wykonania.Aby uzyskać więcej informacji zobaczParametryzacja proste.