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

Создание таблиц-элементов

Таблицы-элементы конструируются так, чтобы в каждой таблице хранился горизонтальный фрагмент исходной таблицы, основанный на интервале значений ключа. Интервалы основаны на значениях данных в столбце секционирования. Диапазон значений в каждой таблице-элементе определяется проверочным ограничением на столбце секционирования, и интервалы не пересекаются. Например, нельзя, чтобы в одной таблице был интервал от 1 до 200000, а в другой — от 15000 до 300000, иначе будет неясно, какая таблица содержит значения от 15000 до 200000.

Например, таблица Customer секционируется на три таблицы. Для этих таблиц будет задано следующее проверочное ограничение:

-- 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)

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

После создания таблиц-элементов на каждом сервере-элементе определяется распределенное секционированное представление, при этом у всех представлений будет одно и то же имя. Это позволяет запросам, которые ссылаются на имя распределенного секционированного представления, запускать один или несколько серверов-элементов. Система действует так, как если бы на каждом сервере-элементе была копия исходной таблицы, но у каждого сервера есть только одна таблица-элемент и одно распределенное секционированное представление. Расположение данных прозрачно для приложения.

При построении распределенных секционированных представлений выполняются следующие задачи:

• Добавление определений связанных серверов на каждый сервер-элемент, содержащий сведения о соединении, необходимые для запуска распределенных запросов на других серверах-элементах. Это предоставляет распределенному секционированному представлению доступ к данным на других серверах.

• Установка параметра lazy schema validation для всех определений связанных серверов, применяемых в распределенных секционированных представлениях, с помощью процедуры sp_serveroption. Это оптимизирует производительность, поскольку исполнитель запросов не запрашивает метаданные ни для одной из связанных таблиц до тех пор, пока это действительно не понадобится удаленной таблице-элементу.

• Создание распределенного секционированного представления на всех серверах-элементах. Представления обращаются к данным из связанных серверов-элементов с помощью распределенных инструкций SELECT и соединяют распределенные строки со строками из локальной таблицы-элемента.

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

• Добавьте определение связанного сервера под именем Server2 с данными о соединении для Server2, а также определение связанного сервера под именем Server3 для доступа к Server3.

• Создайте следующее распределенное секционированное представление:

  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
  

• Выполните те же действия на Server2 и Server3.

Правила таблиц

Таблицы-элементы определяются в предложении FROM в каждой инструкции SELECT в определении представления. Каждая таблица-элемент должна соответствовать следующим правилам:

• На таблицы-элементы нельзя ссылаться в представлении больше одного раза.

• У таблиц-элементов не может быть индексов, созданных на любых вычисляемых столбцах.

• Все ограничения первичного ключа таблиц-элементов должны быть на одинаковом количестве столбцов.

• У таблиц-элементов должна быть одна и та же настройка дополнения ANSI. Дополнительные сведения о настройке дополнения ANSI см. в разделе SET ANSI_PADDING.

Правила столбцов

Столбцы определяются в списке выборки каждой инструкции SELECT в определении представления. Каждый столбец должен соответствовать следующим правилам.

• Все столбцы в каждой таблице-элементе должны быть включены в список выборки. Допустимый синтаксис: SELECT * FROM <таблица-элемент>.

• На столбцы нельзя ссылаться в списке выборки больше одного раза.

• В списке выборки у столбцов должен быть такой же порядок следования.

• Тип столбцов в списке выборки каждой инструкции SELECT должен совпадать. Это относится к типам данных, точности, масштабу и параметрам сортировки. Например, следующее определение представления будет ошибочным, поскольку первый столбец в обоих выражениях SELECT имеет разный тип данных:

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

Правила столбцов секционирования

Для секционирования может использоваться только один столбец, и он должен присутствовать в каждой таблице-элементе. Проверочные ограничения определяют данные, доступные в каждой таблице-элементе. Применяются следующие дополнительные правила:

• Диапазон ключа проверочных ограничений в таблице не должен пересекаться с диапазонами любой другой таблицы. Любое значение столбца секционирования должно быть сопоставленным только с одной таблицей. Проверочные ограничения могут использовать только следующие операторы: BETWEEN, IN, AND, OR, <, <=, >, >=, =.

• Столбец секционирования не может быть столбцом с автоматическим приращением, столбцом по умолчанию или столбцом типа timestamp.

• Столбец секционирования должен находиться в одинаковом порядковом расположении в списках выборки всех инструкций SELECT в представлении. Например, в каждом списке выборки столбец секционирования всегда является первым, вторым и т.д.

• Столбец секционирования не может содержать значения NULL.

• Столбец секционирования должен быть частью первичного ключа таблицы.

• Столбец секционирования не может быть вычисляемым столбцом.

• У столбца секционирования может быть только одно ограничение. Если задано несколько ограничений, то SQL Server игнорирует их все и не учитывает их при выяснении того, является ли это представление секционированным.

• Ограничения для обновления столбца секционирования отсутствуют.

Столбец секционирования, соответствующий всем этим правилам, будет поддерживать все оптимизации, которые поддерживаются оптимизатором запросов. Дополнительные сведения см. в разделе Разрешение распределенных секционированных представлений.

Общие правила

Примечание
Следующие условия не применяются к локально секционированным представлениям на том же сервере. Эта функция включена для обратной совместимости.

Ниже приведены некоторые дополнительные правила:

• Распределенное секционированное представление нельзя сформировать с помощью операторов EXCEPT или INTERSECT.

• Чтобы обеспечить атомность среди всех узлов, которые затрагивает обновление, будет запущена распределенная транзакция.

• Параметр XACT_ABORT SET должен иметь значение ON.

• Столбцы smallmoney и smalldatetime в удаленных таблицах отображаются как money и datetime соответственно. Следовательно, соответствующие столбцы в локальных таблицах должны также иметь имена money и datetime.

• Любой связанный сервер не может быть замкнут на себя. Это связанный сервер, указывающий на тот же экземпляр SQL Server.

Представление, которое ссылается на секционированные таблицы, но не соответствует всем этим правилам, может поддерживать обновление, если в представлении имеется триггер INSTEAD OF. Однако планы выполнения для представлений с триггером INSTEAD OF, построенные оптимизатором запросов, могут не всегда быть настолько же эффективными, как планы для секционированных представлений, соответствующих всем правилам.

См. также

Справочник

Основные понятия