и не одна таблица, по которой идет такое секционирование

Если таблица уже секционированная, то надобавлять пустых секций впереди ничего не стоит. Это операция над метаданными, раз нет реальных данных, удовлетворяющих критериям секционирования. Почитайте про Sliding window. Можно каждый месяц создавать секцию на следующий месяц и бед не знать.

вот такой вариант  есть таблица  tbla в которой 20 год не разделен. перемещаем 20 год через свич в tblb переименовываем tbla в tblc. поднимаем view tbla c instead of триггерами ну и далее из tblb мержим в tblc.  Но это теория. потом вьюху убираем и tblc переименовываем обратно в tbla

я так понимаю речь в том что там секциибыли по месяцам если нет то да просто добавить 21 год 22 год и тд

чет мне кажется у них места под логи не хватит, а мерджить придётся какой-то хитрожопой логикой, иначе эскалация всё положит

там же индекс есть по индексу

Эскалация на 5000 так и так произойдет. мердж же в транзакции, для него те же правила.

вопрос только в том, уникальный индекс, если нет то там да сложно будет, если уникальный то просто пачками перекидывать, если есть боязнь что лог вырастет, или я неправильно понял?

да, верно, просто я думал мы про классический оператор Merge говорим. Если можно работать пачками, то конечно по чуть чуть сгрызть можно, без сомнения.

так и есть секции по месяцам, получается что можно в схему партиционирования добавить еще партиции месячные на будущее, и это не повлечет за собой каких действий с данными
а вот что касается функции, я так и не понял как их добавлять как понял из примера командой
пример:
Alter Partition Function OrderPartitionFunction() SPLIT RANGE ('20180201');
Go

данный пример просто добавит еще один период в конец функции, при этом ничего с данными происходить не будет, т.к. их просто нет за данный период ?

да, так и есть

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

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

спасибо большое, буду экспериментировать
просто у меня сомнение было, т.к. конструктор в smss не дает делать alter над функцией, только DROP+CREATe

хорошие новости перед Новым годом )))

Добавлю еще, что длиться это будет почему значительно дольше, чем просто копирование данных.  там какая-то внутренняя магия ресурсозатратная идёт

Ой, да, забыл сказать!!! Очень важно! не делайте ничего с секционированием через SSMS! мастер задаёт неверный порядок операций с индексами, получается что данные будут перекладываться несколько раз.

:)

Доброго вечера

подруге нужна помощь по SQL завтра на экзамене - кто согласен помочь за денежку?