leonix,

Да, тема стара как мир
Как один из вариантов - на кластерных таблицах пересоздать кластерный индекс (WITH DROP_EXISTING) на новой файловой группе, содержащей файлы, расположенные физически на нужных томах - что физически перенесет таблицы в новое расположение.

В некластерных таблицах-кучах - так же можно временно создать кластерный индекс (без PRIMARY KEY) - с той же последовательностью действий, потом индекс удалить. Данные при этом так же физически останутся в нужном месте. Но тут нужно посмотреть - что уникальный некластерный индекс, который создастся в результате кластерного без PRIMARY ключа, - для внутреннего соблуюдения уникальности - стоит по полю, где нет дубликатов, либо создать временно некий суррогатный ключ (к примеру - ID IDENTITY(1,1))

Либо так же есть втупую вариант - вначале заскриптовать на создание текущую таблицу, поменяв вручную файловую группу с PRIMARY на НОВУЮ и так же указать временное имя таблицы, запустить скрипт, что повлечет за собой создание новой таблицы,
а потом залить в нее данные из старой:
INSERT INTO [scheme].[new_table]
SELECT * FROM [scheme].[old_table]

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

Profit!

P.S. - лучше вначале всегда потестить, сразу в PROD не надо такое на всякий :)

PsyMisha,

Это относится к варианту, когда горячие-теплые-холодные данные лежат в отдельных таблицах, безусловно.
Т.е. - мы переносим таблицы целиком.
В случае, если вертикально в 1й физической таблице лежат данные "всей степени теплоты" - то да, только секционирование самое практичное

Yasha123,

Вот блобы у меня лично опыта не было, надо курить мануалы :)
А как вы с этим справлялись?

Оо, ну это вообще звёздные ребята, особенно последний. Он же в Microsoft вообще работал и писал, в частности саму DBCC CHECKDB