Огромный размер таблицы (vldb, shrink?)

Добрый день.
SQL server 2008 R2 x64.
Есть таблица в БД, благодаря которой, БД занимает на диске место размером (!) 700 Гб.
В таблицу постоянно ИНСЕРТятся данные (очень часто и очень много), и в "реал-тайм" режиме постоянно СЕЛЕКТятся.
Никаких АДЕЙТов и ДИЛИТов.
Сведения о занимаемом месте таблицы:
220 ГБ - Index space
530 Гб - Data space
Row count - десятизначное число.
Таблица никак не обслуживалась долгое время.
Все это крутиться на сервере с рэйдом, в скором времени планируем переносить на дисковую полку (увеличивать), но все же:
Пожалуйста посоветуйте что на данный момент мне можно сделать с такой огромной таблицей?
Данные скидываются со штампом времени, и копятся уже 3 года. Данные нужны за последние 6 месяцев, остальные как то нужно перенести в другое место в качестве архива.
Но даже если я грохну все не актуальные данные, БД потом нужно как то сжать.
Боюсь даже подумать сколько будет выполнятся шринк.
В общем, пожалуйста любые советы, ругательства, линки в мой адрес. Очень прошу помощи.
Как бы вы поступили в такой ситуации (исключая ответ "не довели бы до такого ").

Заранее очень благодарен.

sqlQuestion, наверное, копать надо в сторону секционирования данных по некоему критерию (дате), на я этими вещами не озадачивался, конкретнее не смогу сказать

sqlQuestion
Пожалуйста посоветуйте что на данный момент мне можно сделать с такой огромной таблицей?

Зависит от того, что означают слова "в качестве архива".

Какой будет доступ к перемещённым данным - пара запросов из отдельного интерфейса, или нужно поддерживать полную функцианальность системы при работе с архивом?

В первом варианте можно просто переносить данные в другие базы/таблицы, при необходимости сделать шринк (ну пусть он будет долгий, неважно, да в общем то и объём небольшой, ничего страшного).

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

Благодарю вас за ответы.
alexeyvg, данные не нужны в режиме онлайн, действительно интерфейс будет другой для обращения к ним, наверное попробую сделать в другом месте идентичную БД и сливать туда данные из этой таблицы маленькими порциями до желаемой даты, затем скопированные данные удалю из первоисточника. Ну и шринк.
(Система в целом критична, максимальный период обслуживания при неработоспособности - 2 суток с учетом сна =) )
+ На этом же сервере вертятся другие рабочие системы, боюсь бэкап и шринк подвесят sql server, а без бекапа так же боюсь что либо делать. )
С секционированием не хотел связываться, да и не спец в администрировании скл сервера. Не понимаю преимущества. Только если данные нужны в онлайн режиме, их много и страдает быстродействие... (ну и видимо есть лишнее дисковое пространство).

Полажу еще по просторам, посмотрю и попробую...
Спасибо еще раз.

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

секционировать таблицу и архив,
потом просто переключать секции