Разрешение распределенных секционированных представлений

Обработчик запросов SQL Server оптимизирует производительность распределенных секционированных представлений. При оптимизации распределенных секционированных представлений важно минимизировать количество данных, передаваемых между серверами.

SQL Server интеллектуальные динамические планы, которые позволяют эффективно использовать распределенные запросы для доступа к данным в таблицах удаленных серверов.

• Обработчик запросов сначала использует OLE DB для получения определений проверочных ограничений для каждой таблицы сервера. Это позволяет ему определить распределение ключевых значений между таблицами серверов.

• Обработчик запросов сравнивает диапазоны ключей, заданные в предложении WHERE инструкции SQL, со схемой, показывающей, как строки распределены между таблицами серверов. Затем обработчик запросов строит план выполнения, который использует распределенные запросы для получения только тех удаленных строк, которые требуются для завершения инструкции SQL. Кроме того, план выполнения строится таким образом, чтобы обращение к удаленным данным или метаданным выполнялось только в тот момент, когда они требуются.

Например, рассмотрим систему, в которой пользовательская таблица разделена на три секции на серверах Server1 (CustomerID от 1 до 3 299 999), Server2 (CustomerID от 3 300 000 до 6 599 999) и Server3 (CustomerID от 6 600 000 до 9 999 999).

Допустим, план выполнения строится для следующего запроса, который выполняется на сервере Server1:

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

План выполнения этого запроса извлекает строки со значениями ключей CustomerID от 3 200 000 до 3 299 999 из локальной таблицы сервера и вызывает распределенный запрос для получения строк со значениями ключей от 3 300 000 до 3 400 000 из Server2.

Обработчик запросов сервера SQL Server умеет встраивать динамическую логику в планы выполнения инструкций SQL, когда значения ключей при построении запроса неизвестны. Рассмотрим следующую хранимую процедуру:

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

SQL Server не может предсказать, какое значение ключа будет присвоено параметру @CustomerIDParameter при выполнении процедуры. Поскольку значение ключа предсказать нельзя, обработчик запросов не может заранее определить, к какой таблице потребуется доступ. В этом случае SQL Server встраивает в план выполнения условную логику, называемую динамическими фильтрами, для управления доступом к удаленным таблицам на основе значения входного параметра. Если предположить, что хранимая процедура GetCustomer была выполнена на сервере Server1, логику плана выполнения можно представить следующим образом:

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 строит динамические планы выполнения даже для непараметризованных запросов. Оптимизатор может параметризовать запрос так, чтобы план выполнения можно было использовать повторно. Если оптимизатор параметризует запрос, ссылающийся на секционированное представление, он не будет знать, находятся ли нужные строки в заданной базовой таблице. В дальнейшем ему придется использовать динамические фильтры в планах выполнения. Дополнительные сведения см. в разделе Простая параметризация.