Комментарии 7
Стоит отметить пару нюансов касательно статистики, именно объектов статистики.
- Выровненный индекс.
Создание некластерного индекса на той же схеме секционирования — это неполное определение.
Индекс должен содержать в составе ключа атрибут секционирования. В случае некластерного индекса sqlserver неявно добавляет его в included. Уникальный обязательно должен иметь атрибут в составе ключа. - Инкрементальное обновление статистики.
Ещё одно преимущество. Но есть нюанс, вытекающий из п.1. Данное поведение было зафиксировано в версии 2016, после установки sp2.
В случае, если индексы на секционированной таблице не выровнены, то при попытке выполнить инкрементальное обновление статистики вы получите ошибку. Сервер будет пытаться пересоздать инкрементальную статистику на обычную.
Это необходимо учитывать, когда индексы создавались ранее, а потом вы перешли на 2016ю версию, где появилось новое требование по инкрементальное статистике. Индексы придется пересоздавать.
Интересная штука. А можно ли это применить для того, чтобы хранить в секциях данные по годам (для десятков таблиц) и отключать/подключать секции с ненужными годами при необходимости? Скажем, отключить файловую группу с секцией за 2018й год, заархивировать и убрать с глаз долой. Потом, если возникает необходимость посмотреть архивы за 2018й, просто подключить секции и пользоваться данными. Потребность отпала — отключил.
Такое в принципе реализуемо? Насколько это геморно и можно ли автоматизировать процесс? И вообще насколько механизм для этого предназначен?
Такое в принципе реализуемо? Насколько это геморно и можно ли автоматизировать процесс? И вообще насколько механизм для этого предназначен?
SQL Server (на сколько мне известно) не позволяет отключать и подключать ФГ по требованию. Вы можете сжимать архивные ФГ и объявлять их read-only, но отключить не сможете.
Судя по всему, этот момент я пропустил. В самом начале статьи было упомянуто про бэкапы в том плане, что можно не архивировать отдельные файловые группы, верно, но, получается, они будут всегда подключены. А как происходит attach такой базы данных? Все файлы из всех файловых групп нужно выбирать вручную при подключении базы?
Если есть желание перекладывать исторические данные на диск помедленнее, насколько например Merge в файловую группу, которая лежит на этом диске будет медленнее/быстрее, чем перенести файловую группу на другой диск. И можно ли эту операцию выполнить без даунтайма?
Merge напрямую в файловую группу на медленном диске — это самоубийство — операции над секциями накладывают Sch-M блокировки, которые исключают любой доступ к объекту.
Я бы сделал так — создал бы пустую таблицу в той же файловой группе, где сейчас лежат данные, которые надо перенести. Сделал туда SWITCH этой секции. Отключил бы некластерные индексы и перестроил все индексы на ней, начиная с кластерного, в файловой группе на медленных дисках (куда надо перенести). После перестройки — сделал бы SWITCH этой таблицы в таблицу с историческими данными.
В принципе, всё без даунтайма. Если индексы и секции построенные грамотно, всё, кроме перестройки индексов — операции только над метаданными.
Я бы сделал так — создал бы пустую таблицу в той же файловой группе, где сейчас лежат данные, которые надо перенести. Сделал туда SWITCH этой секции. Отключил бы некластерные индексы и перестроил все индексы на ней, начиная с кластерного, в файловой группе на медленных дисках (куда надо перенести). После перестройки — сделал бы SWITCH этой таблицы в таблицу с историческими данными.
В принципе, всё без даунтайма. Если индексы и секции построенные грамотно, всё, кроме перестройки индексов — операции только над метаданными.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Секционирование в SQL Server