Для чего нужно секционирование?

Tsql теория > Для чего нужно секционирование?
04.04.2013 17:17:05



Статья:

Для чего нужно секционирование?

Прежде, чем говорить о том, как осуществлять секционирование и использовать его возможности, сначала нужно понять, насколько оно необходимо, что такое секционирование и кому стоит его использовать? Когда Вы создаете таблицы, Вы проектируете их таким образом, чтобы хранить информацию о сущностях, например, о покупателях или продажах. Каждая таблица должна иметь атрибуты, которые описывают только эту сущность, и, например, для всех покупателей и продаж исторически сложилось так, что все Ваши покупатели и все Ваши продажи создаются в соответствующих таблицах.
В то время как наличие одной единственной таблицы для каждой сущности является наиболее простым подходом для проектирования и понимания, это может быть не лучшим решением с точки зрения производительности, масштабируемости и управляемости, особенно в тех случаях, когда таблицы становятся достаточно большими. Секционирование может обеспечить преимущества как для больших таблиц (и/или их индексов), так и для таблиц, которые имеют изменяющиеся модели доступа. Более того, секционирование больших таблиц повышает их масштабируемость и управляемость, а также упрощает использование таблиц при добавлении или удалении значительных фрагментов (или диапазонов) данных.
Так что же представляет собой большая таблица? VLDB (Very Large Database) принято называть базы данных, совокупный размер которых измеряется сотнями гигабайт, или даже терабайтами; однако данный термин никак не определяет индивидуальные размеры таблиц. Большая таблица - это такая таблица, показатели производительности или временные затраты на обслуживание которой выходят за допустимые рамки. Кроме того, таблицу можно считать большой, если действия, производимые одним пользователем, оказывают значительное влияние на другого пользователя, или если операции обслуживания базы данных влияют на возможности остальных пользователей. Это приводит к ограничению доступности базы данных. Ведь даже притом, что сервер продолжает оставаться доступным, как можно считать Вашу базу данных доступной, когда рабочие характеристики таблицы продаж значительно ухудшились, либо таблица вовсе недоступна в течение всего периода текущего обслуживания базы данных по 2 часа в день, в неделю, или пусть даже в месяц? В некоторых случаях регулярный простой все же допустим, но чаще всего простоя можно избежать или минимизировать за счет улучшения проектирования.
Таблицу, модель доступа к которой изменяется, можно также считать большой, когда подмножества (или диапазоны) строк этой таблицы имеют разные модели использования. И хотя модели использования не обязательно должны изменяться (и это вовсе не является требованием секционирования), когда модели использования все же меняются, тогда могут быть получены дополнительные преимущества от секционирования. С точки зрения продаж, данные текущего месяца обычно используются для чтения/записи (read-write), в то время как данные предыдущих месяцев (и часто большая часть таблицы) - только для чтения (read-only). Если в больших таблицах использование данных изменяется, либо накладные расходы на обслуживание огромны, то это может ограничить способность таблицы отвечать на различные пользовательские запросы, в свою очередь, ограничивая и доступность и масштабируемость. Кроме того, особенно когда большие массивы данных используются по-разному, операции обслуживания могут отказаться от планового обслуживания статичных данных. Обслуживание данных, которые в этом вовсе не нуждаются - слишком дорогое удовольствие. Излишние затраты могут отразиться на производительности, блокировках, резервном копировании (дисковом пространстве, времени и эксплуатационных характеристиках), а так же отрицательно воздействовать на общую масштабируемость сервера.
Кроме того, в многопроцессорных системах разделение больших таблиц приведет к улучшению производительности за счет параллелизма. Крупномасштабные операции над чрезвычайно большими наборами данных (в миллионы строк) могут извлечь выгоду из параллельной обработки независимых подмножеств данных. В качестве простого примера улучшения производительности при использовании секционирования может выступать агрегирование (группировка) в предыдущих версиях сервера. Например, вместо того, чтобы группировать данные в одной большой таблице, SQL Server может группировать их в нескольких секциях независимо друг от друга, и затем объединить агрегаты. В SQL Server 2005, объединения могут извлекать данные непосредственно из секций; SQL Server 2000, поддерживающий параллельные объединения наборов данных, все же должен был создавать эти наборы данных на лету. В SQL Server 2005, связанные таблицы (к примеру, Order и OrderDetails), которые разделены по одному и тому же ключу секционирования и одной и той же функции секционирования, называются выровненными. Если оптимизатор SQL Server 2005 обнаруживает, что объединяются две секционированные и выровненные таблицы, он может предпочесть объединить сначала данные, располагающиеся в одних и тех же секциях, а затем объединить результаты. Это позволяет SQL Server 2005 более эффективно использовать многопроцессорные системы.
Итак, чем же может помочь секционирование? Там, где таблицы и индексы становятся слишком большими, секционирование может помочь, расщепляя большие массивы данных на меньшие, более управляемые "куски" (т.е. секции). Тип секционирования, описанного в этой статье, называют горизонтальным секционированием. При горизонтальном секционировании большие "куски" строк сохраняются в нескольких отдельных секциях. Архитектура секционированных данных выбирается, настраивается и управляется согласно вашим потребностям. Секционирование в SQL Server 2005 позволяет вам разделять ваши таблицы, основанные на индивидуальных моделях использования данных, задавая ограниченные диапазоны. И наконец, SQL Server 2005 предоставляет большое число настроек (опций) для управления секционированными таблицами и индексами, добавляя дополнительные функции, спроектированные специально для новой концепции.

 

Секционированные Таблицы в SQL Server 2005

В то время как усовершенствования SQL Server 7.0 и SQL Server 2000 значительно улучшили производительность секционированных представлений, они не упрощали их администрирования, разработки или развертывания. Все таблицы, на основе которых строилось секционированное представление, создавались и управлялись по отдельности. Разработка приложений становилась проще за счет того, что разработчику уже не приходилось обращаться непосредственно к базовым таблицам, однако администрирование было затруднено, поскольку приходилось управлять каждой отдельной таблицей, входящей в состав секционированного представления, и его ограничениями целостности. Из-за сложностей управления, разделение таблиц зачастую использовалось только тогда, когда данные нужно было "заархивировать" или загрузить. Операции добавления/удаления из доступной только на чтение таблицы (read-only) были слишком дорогостоящими - они занимали время, место в журнале транзакций, и часто создавали блокировки.
Кроме того, поскольку предшествующие стратегии секционирования требовали, чтобы разработчик создавал индивидуальные таблицы и индексы и затем объединял их посредством представления, оптимизатору запросов требовалось проверить достоверность и определить планы исполнения для каждой секции (поскольку индексы могли измениться). Поэтому время оптимизации запроса в SQL Server 2000 зачастую линейно возрастает с увеличением количества секций, входящих в представление, чего не происходит в SQL Server 2005, где каждая секция по определению имеет одни и те же индексы.
К примеру, разберем случай, когда текущий месяц OLTP-данных (Online Transaction Processing), должен быть перемещен в конце месяца в OLAP-таблицу. Самая последняя таблица (предназначенная для запросов read-only) - это одиночная таблица с одним кластерным и двумя некластерными индексами; массовая загрузка (bulk load) 1GB данных (в уже проиндексированную и действующую таблицу) создает блокировки с текущими пользователями помимо того, что таблица и/или индексы становятся фрагментированным и/или блокированными. Кроме того, процесс загрузки займет существенное время, поскольку таблица и индексы должны обслуживаться по мере поступления каждой строки. Есть способы, позволяющие ускорить bulk load, однако, они могут непосредственно затронуть всех остальных пользователей, таким образом, принося в жертву возможность параллельной работы ради скорости исполнения. Если бы эти данные добавлялись в недавно созданную (пустую) таблицу, то вначале могла бы произойти загрузка данных (в т.ч. параллельная загрузка), а затем построение индексов (возможно, также параллельное). Зачастую вы смогли бы достигать 10-ти кратного (или еще большего) преимущества от использования данного подхода. Фактически, загружая в неиндексированную таблицу (heap - кучу), Вы можете воспользоваться преимуществом многопроцессорной системы, загружая параллельно многочисленные файлы данных или многочисленные "фрагменты" одного и того же файла (заданные начальными и конечными строками). В любом из выпусков SQL Server секционирование позволяет Вам управлять таблицами на более высоком уровне, не обязывая Вас хранить все данные в одном месте - с сильно фрагментированными индексами и отсутствием реального управления любым аспектом поведения на более высоком уровне. Функциональная стратегия секционирования могла быть достигнута в предыдущих выпусках, путем динамического создания и удаления таблиц и модифицирования UNION-представлений. Однако в SQL Server 2005 решение более изящно: Вы можете просто "включить" ("switch in") недавно-наполненную секцию(и), как дополнительную секцию к существующей схеме секционирования, либо "выключить" ("switch out") любую старую секцию(и). Процесс "включения/выключения" секций занимает незначительное время, и может быть даже ускорен за счет применения параллельной загрузки данных (bulk loading) и параллельного создания индексов. Что еще более важно, секция управляется из-за пределов таблицы, таким образом, во время добавления новой секции на действующую таблицу не оказывается никакого воздействия. В результате, добавление секции происходит за считанные секунды.

Еще лучше обстоят дела в случае, если данные необходимо удалить. Если база данных нуждается только в "sliding window" ("скользящее окно") наборе данных, то, когда новые данные будут готовы к переселению (например, в текущий месяц), тогда самые старые данные (например, данные того же месяца за предыдущий год) смогут быть удалены. В этом случае, Вы, вероятно, добьетесь улучшения производительности от использования секционирования на несколько порядков. Поскольку это может показаться неправдоподобным, давайте рассмотрим имеющиеся тут отличия.
Когда все данные находится в одной единственной таблице, удаление 1GB данных (самых старых данных) требует построчной манипуляции данными и связанными с ними индексами. Процесс удаления данных приводит к существенной log-активности и не позволяет усекать журнал транзакций до конца удаления (помните, что удаление - это отдельная auto-commit транзакция; тем не менее, Вы можете управлять размером транзакции, выполняя множественное удаление в одной транзакции там, где только возможно), а также требуется [потенциально очень] больший журнал транзакций. Чтобы удалить такое же количество данных, удаляя определенную секцию из секционированной таблицы, все, что надо сделать - это "выключить" секцию (что является операцией над метаданными), и затем удалить или усечь автономную таблицу.

А кроме того, знаете ли Вы, что использование файловых групп (filegroups) совместно с секциями является идеальным механизмом секционирования? Файловые группы позволяют Вам размещать отдельные таблицы на различных физических дисках. Если отдельная таблица располагается в нескольких файлах, благодаря использованию filegroups, то тогда фактическое расположение данных предсказать невозможно. В системах, которые не допускают параллельной обработки данных, SQL Server, благодаря применению файловых групп, улучшает производительность за счет использования всех дисков более равномерно и поэтому конкретное размещение данных в них не является столь принципиальным.

На Рисунке 2 представлена файловая группа, состоящая из трех файлов. В ней располагаются две таблицы: Orders и OrderDetails. Когда данные таблиц размещаются в файловой группе, SQL Server пропорционально заполняет файлы файловой группы, захватывая в них необходимое дисковое пространство для своих объектов экстентами (кусками по 64 Kb, что равно 8 страницам данных по 8 Kb). В момент создания таблиц Orders и OrderDetails файловая группа будет пуста. Когда приходит новый заказ, в таблице Orders создается соответствующая запись, и по одной записи в таблице OrderDetails для каждого заказанного товара. SQL Server выделяет один экстент для таблицы Orders в File1, и затем еще один экстент для таблицы OrderDetails в File2. По всей вероятности, таблица OrderDetails будет расти быстрее, чем таблица Orders, и поэтому следующие несколько экстентов будут выделены для нее: следующий экстент для таблицы OrderDetails будет располагаться в файле File3. На приведенном ниже рисунке продемонстрировано размещение экстентов данных таблиц Orders и OrderDetails в файловой группе.

Рисунок 2. Пропорциональное заполнение файлов

SQL Server и дальше продолжит балансировать (уравновешивать) размещение всех объектов в пределах этой файловой группы. Наряду с тем, что SQL Server получает выгоду от использования большего количества дисков для данной операции, это не так оптимально с точки зрения управления или перспективы обслуживания (лишние неудобства), или для ситуации, когда модели использования достаточно предсказуемы (и обособлены).

В SQL Server 2005 секционированная таблица может быть спроектирована (используя "функции" и "схемы") таким образом, чтобы строки, имеющие одинаковый ключ секционирования, размещались бы в строго указанном месте. Функция секционирования определяет границы секций и то, в какую секцию должно быть занесено первое значение. В случае LEFT-функции, первое значение будет являться верхней границей в первой секции. В случае RIGHT-функции, первое значение будет являться нижней границей во второй секции. Мы еще рассмотрим подробно особенности функций секционирования дальше в этой статье. Как только функция определена, может быть создана схема секционирования для того, чтобы определить физическое расположение секций в базе данных. Если несколько таблиц используют одну и ту же функцию (но не обязательно одну и ту же схему), строки, имеющие один и тот же ключ секционирования, будут располагаться на диске вместе. Этот принцип называется выравниванием. Выравнивая строки нескольких таблиц по ключу секционирования, SQL Server может (если оптимизатор запросов предпочтет) работать только с необходимыми группами данных (в каждой из таблиц). Для того чтобы выровняться, две секционированные таблицы или два индекса должны иметь некоторое соответствие между их соответствующими секциями. Они должны использовать "эквивалентные" функции секционирования и быть связаны по столбцам секционирования. Две функции секционирования могут использоваться для выравнивания данных, если:

  • обе функции секций используют одинаковое количество аргументов и секций.

  • ключ секционирования, используемый в каждой функции, имеет одинаковый тип (включая длину, точность и масштаб (если допускается), и collation (если допускается)).

  • граничные значения эквивалентны (включая критерии границы LEFT/RIGHT).

Внимание! Даже если две функции секционирования рассчитаны на выравнивание данных, ваши таблицы могут остаться не выровненными из-за не выровненных индексов, если они не секционированы по тем же столбцам, что и таблицы.

Локализация (Collocation) - более строгая форма выравнивания, когда два выровненных объекта объединены с предикатом equi-объединения (inner), где equi-объединение производится по столбцу секционирования. Это становится важным в контексте запроса, подзапроса или другой подобной конструкции, где могут встретиться предикаты equi-объединения. Локализация эффективна, поскольку запросы, объединяющие таблицы по столбцам секционирования, выполняются тогда значительно быстрее. Возьмем, например, таблицы Orders и OrderDetails, описанные выше. Вместо того чтобы заполнять файлы пропорционально, Вы можете создать схему секционирования, которая разнесет БД по трем файловым группам. Вы определяете таблицы Orders и OrderDetails таким образом, чтобы они использовали одну и ту же схему. Связанные данные (по ключу секционирования) будут помещены в один и тот же файла, таким образом, изолируя необходимые для объединения данные. Когда связанные строки из нескольких таблиц секционированы по одному и тому же принципу, SQL Server может объединять секции, не имея необходимости рыться во всей таблице или нескольких секциях (если к таблицам применялись разных функций секционирования) для сопоставления строк. В этом случае, объекты не просто выровнены, они, как говорится, являются выровненным хранилищем, поскольку связанные данные располагаются в одних и тех же файлах.

Следующий рисунок демонстрирует, как два объекта могут использовать одну и ту же схему секционирования, когда все строки данных с одинаковым ключом секционирования окажутся в одной и той же файловой группе. Когда связанные данные выровнены, SQL Server 2005 может эффективно работать с большими наборами данных параллельно. Все данные о продажах за январь (как для Orders, так и для OrderDetails) будут располагаться в первой файловой группе, данные за февраль - во второй файловой группе и т.д.

Рисунок 3. Таблицы выровненных хранилищ

SQL Server поддерживает секционирование, основанное на диапазонах. Таблицы, так же как и индексы могут использовать одну и ту же схему для лучшего выравнивания. Хорошее проектирование способно значительно улучшить производительность системы, но что, если использование данных все время меняется? Что, если потребуется дополнительная секция? Простота администрирования при добавлении и удалении секций, а также управления секциями извне секционированной таблицы была главной целью при разработке SQL Server 2005.
SQL Server 2005 упростил секционирование для администрирования, разработки и развертывания, а также для понимания. Вот некоторые из усовершенствований в производительности и управляемости:

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

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

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

  • Архивирование и/или удаление части секционированной таблицы минимально воздействует на оставшуюся часть таблицы.

  • Поддерживается "переключение" секций в/из секционированной таблицы.

  • Обеспечивается лучшее масштабирование и параллелизм для чрезвычайно больших операций над несколькими связными таблицами.

  • Улучшается производительность всех секций.

  • Уменьшается время оптимизации запроса, поскольку каждая секция не должна быть оптимизирована отдельно.

Определение ключа секционирования

Первый шаг в секционировании таблиц и индексов состоит в определении "ключа". Ключ секционирования - это столбец(ы) таблицы, который удовлетворяет определенным критериям. Функция секционирования определяет тип данных, на котором базируется логическое разделение данных. Физическое размещение данных определено схемой секционирования. Другими словами, схема отображает данные на файловые группы, которые в свою очередь отображают данные на конкретные файлы. Для этого схема всегда использует функцию - если функция определяет пять секции, тогда схема должна использовать пять файловых групп. Однако совсем не обязательно, чтобы все файловые группы были разными; тем не менее, Вы получите больший выигрыш в производительности, если будете использовать систему из нескольких дисков, предпочтительно многопроцессорную. При использовании схемы вы определяете столбец, который будет выступать в качестве аргумента для функции секционирования.

Данные в диапазонных секциях разделены логически. Фактически, секции данных в действительности не могут быть сбалансированы вообще. Однако использование данных навязывает диапазонную секцию, поскольку модель использования этой таблицы определяет специальные границы для анализа (иначе называемые "диапазонами"). Ключ секционирования для диапазонной функции может состоять только из одного столбца, и функция секционирования будет включать всю область данных, даже если эти данные недопустимы для таблицы. Другими словами, границы определены для каждой секции, но первая и последняя секции позволят включать бесконечно малые (первая) и бесконечно большие (последняя) значения. Для секций должны быть заданы ограничения целостности CHECK для реализации Ваших бизнес-правил и обеспечения целостности данных (т.е. ограничения области данных конечным, а не бесконечным диапазоном). Диапазонные секции идеальны, когда обслуживание и администрирование требуют архивирования больших диапазонов данных на регулярной основе, и когда запросы обращаются к большим массивам данных - но только в пределах нескольких диапазонов.

 

Секционирование индекса

Секционировать можно не только данные, но и индексы. Индексы можно секционировать с помощью той же функции, что и базовую таблицу, либо любой другой. Однако с точки зрения производительности лучше всего разделять таблицу и ее индексы, используя одну и ту же функцию. Если таблица и индексы используют одну и ту же функцию секционирования, и секционируются по одним и тем же столбцам (в том же порядке), такая таблица и индексы называются выровненными. Если индекс создается по уже секционированной таблице, SQL Server автоматически выровняет новый индекс согласно схеме секционирования таблицы, если только индекс явно не секционирован по-другому. Если таблица и ее индексы выровнены, тогда SQL Server может перемещать секции внутри секционированных таблиц более эффективно, поскольку все связанные данные и индексы разделены по одному алгоритму.
Если таблица и индексы определены не только по одной и той же функции, но и по одной и той же схеме, тогда они называются выровненным хранилищем. Вообще, если таблицы и индексы располагаются в одном файле или файловой группе, мультипроцессорные системы могут получать дополнительные преимущества за счет параллельной работы с секциями. В мультипроцессорных системах в случае выровненных хранилищ SQL Server может заставить каждый процессор работать с определенным файлом или файловой группой, и при этом быть уверенным, что не будет конфликтов при доступе к данным, поскольку все необходимые для объединения или поиска по индексу данные будут локализованы на одном и том же диске. Это позволяет большему количеству процессов выполняться параллельно без прерываний.
Для получения дополнительной информацией по теме вы можете обратиться к разделу BOL: Special Guidelines for Partitioned Indexes.

 

Особые режимы секционирования - Split, Merge и Switch

В SQL Server 2005 для помощи в управлении секционированными таблицами введено несколько новых понятий. Поскольку секционирование применяется к большим таблицам для обеспечения масштабируемости и поддержания лучшей производительности этих таблиц, весьма вероятно, что количество секций, выбранное в момент создания функции секционирования, со временем изменится. Используя оператор ALTER TABLE с новой опцией "split" (“расщепление”), Вы можете добавить в таблицу новую секцию. Когда секция “расщепляется”, часть данных может быть перенесена в новую секцию, однако это не лучшее решение с точки зрения производительности. Ниже в этой статье будет приведен полный сценарий работы режима “split”.
Напротив, если необходимо удалить секцию используются режимы “switch” (“переключение”) и ”merge” (“слияние”). “Слияние” диапазонных секций выглядит как указание граничной точки, которую необходимо удалить. Если работа ведется только с данными определенного периода и регулярно проводится архивирование базы данных (например, ежемесячно), вы могли бы архивировать одну секцию данных (самый ранний месяц) после добавления новой секции. Например, Вы могли бы пожелать иметь доступ к данным только одного последнего года; тогда в конце каждого месяца вы бы “включали” новый (текущий) месяц, и затем “выключали” бы самый ранний месяц, таким образом, проводя различия между read/write OLTP данными текущего месяца и read-only данными предыдущих месяцев, предназначенными для анализа. Однако, прежде чем Вы объедините граничную точку Вы должны выключить ее (связанные с ней) ассоциированные данные, иначе слияние может стать дорогостоящей операцией. Существует специальная методика, позволяющая добиться при этом наибольшей эффективности. Понятия “switch”, “merge” и “split” только на первый взгляд несколько сложными.
В данном сценарии у вас есть read-only доступ к таблице с данным за последний год. В настоящее время в этой таблице содержатся данные с сентября 2003 по август 2004. Данные за текущий месяц, сентябрь 2004, находится в другой базе данных, оптимизированной для производительности OLTP (операций реального времени). В read-only версии таблицы имеется 13 секции: двенадцать секций, которые содержит данные (сентябрь 2003 - августа 2004), и одна последняя пустая секция (помните, что диапазонные секции включают весь диапазон значений – от бесконечно малого до бесконечно большого). Таблица могла бы содержать определение CHECK constraint, для того чтобы ограничить OrderDate значениями с 1 сентября 2003 по 1 сентября 2004; данное ограничение позволит эффективно держать последнюю секцию пустой.


Рисунок 5: Границы диапазонных секций - перед загрузкой данных/архивацией

Когда начинается октябрь (в базе данных OLTP), необходимо переместить данные сентября в секционированную таблицу, используемую для анализа. Включение/выключение секций в таблицу - очень быстрый процесс, к тому же, вся подготовительная работа может быть выполнена из-за пределов секционированной таблицы. Этот сценарий в подробностях описывается в учебном примере, который будет рассмотрен чуть ниже. Его основная идея заключается в использовании “каскадных таблиц”, которые в конечном счете станут секциями в секционированной таблице (“включение” таблицы, становящейся секцией в секционированной таблице) или будут хранить устаревшие данные таблицы (“выключение” секции, становящейся автономной таблицей).
На Рисунке 6 показано “выключение” секции, становящейся отдельной не секционированной таблицей в той же файловой группе, что и основная таблица. Поскольку эта “несекционированная таблица” уже существует внутри той же файловой группы (и это является очень важным моментом), SQL Server может реализовать это "переключение" как простое изменение метаданных. Выключение секции происходит за считанные секунды, поскольку SQL Server должен всего-навсего изменить метаданные, в отличие от удаления, которое могло бы занять часы и создать блокировки на больших таблицах. Как только эта секция "выключена", у вас все еще будет оставаться 13 секций: первая (самая старая) секция теперь пуста и последняя (самая свежая, также пустая) секция должна быть теперь “расщеплена”.


Рисунок 6: Выключение секции

Для того чтобы удалить первую (старшую) секцию (сентябрь 2003), необходимо воспользоваться новой опцией “слияния” оператора ALTER TABLE - “merge” (см. Рисунок 7). “Сливая” секции, вы фактически удаляете граничную точку между ними, и, следовательно, устраняете одну из секций (в данном случае сокращая количество секций до 12). Слияние секции будет очень быстрой операцией в том случае, если никакие строки данных не должны быть перемещены; в нашем случае, поскольку первая секция пуста, никакие записи не перемещаются (из первой секции во вторую). Если бы первая секция НЕ была пуста, то при слиянии данные пришлось бы перемещать из первой секции во вторую, и это было бы очень дорогостоящей операцией. Впрочем, в весьма распространенном сценарии “sliding window” (“Скользящее Окно”) это никогда не должно произойти, поскольку Вы всегда будете объединять пустую секцию с активной секцией, и соответственно никакие записи перемещаться не будут.


Рисунок 7: Слияние секций

И наконец случай, когда новая таблица должна быть включена в секционированную таблицу. Помните, что для того чтобы осуществить включение секции в секционированную таблицу путем простого изменения метаданных, вся работа по загрузке данных и созданию индексов уже должна быть произведена в новой таблице - вне границ секционированной таблицы. Для включения новой секции в таблицу сначала необходимо “расщепить” последний (самый новый, пустой) диапазон на две секции. Кроме того, вам необходимо перестроить ограничение целостности таблицы под требования нового диапазона. Секционированная таблица будет включать 13 секций. Последняя секция в сценарии “Скользящее Окно” с LEFT-функцией секционирования будет всегда оставаться пустой.


Рисунок 8: Расщепление Секции

И наконец, недавно загруженные данные включаются в 12-ую секцию – в качестве данных за сентябрь 2004.


Рисунок 9: Включение Секции

В результате мы получаем таблицу такого вида:


Рисунок 10: Границы диапазонных секций - после загрузки данных/архивации

Важно знать, что split и merge – это атрибуты оператора ALTER PARTITION FUNCTION, а switch – это атрибут оператора ALTER TABLE. Кроме того, только одна секция может быть добавлена или удалена единовременно. Если в диапазонную секционированную таблицу требуется добавить или удалить сразу несколько секции, то тогда наиболее оптимальным способом балансировки данных (вместо балансировки целой таблицы для каждого расщепления) может послужить создание новой секционированной таблицы – использование новой функции и схемы секционирования и затем перемещение данных в новую секционированную таблицу. Для “перемещения” данных сначала скопируйте их, используя оператор INSERT newtable SELECT … FROM oldtable, а затем удалите исходные таблицы. Будьте осторожны, не потеряйте данные, предотвращая пользовательские (или любые другие) модификации во время этого процесса.
Более полную информацию вы сможете найти в BOL, в разделах ALTER PARTITION FUNCTION and ALTER TABLE.