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

Я сделал через три файловых группы и функцию секционирования по следующим правилам:
1) от сотворения мира до неделю назад;
2) от неделю назад до завтра;
3) от завтра до конца света.

Проблема в том, что даты забиваются жёстко, и завтра уже этот план будет работать не так, как задумывался.
Я "решил" эту проблему через ежедневную модификацию функции секционирования весьма извращённым на мой взгляд способом:
1. Удаляю из функции секционирования секцию 2), объединяя её с секцией 1).
2. Добавляю к функции секционирования удалённую секцию 2), с границей неделя назад (теперь от текущего дня).
3. Удаляю из функции секционирования секцию 3), объединяя её с секцией 2).
4. Добавляю к функции секционирования удалённую секцию 3), с границей завтра (теперь от текущего дня).

И мне кажется, что всё это будет жутко медленно работать (если вообще будет).
Внимание, вопрос: а как это сделать правильно?

Спасибо за ответы!

Всё дело в том, что с этой базой данных работает некоторая система, а лезть в неё и что-то менять категорически не желательно.
Такая мысль пришла мне уже после публикации поста - по материализованному вычисляемому полю. Но как это будет работать? При обновлении значения поля записи сразу копируются из файла в файл? Если я сделаю поле, вычисляемое на основе поля типа даты (создания записи), как это будет работать? Материализованное вычисляемое поле вроде бы перевычисляется только при обновлении участвующих в вычислении полей, или я ошибаюсь? Тогда, наверное, в вычисляемом поле смысла большого нет и можно использовать обычное.
А разве можно в функции секционирования использовать функции (тем более недетерминированные)?
Про разные таблицы - не вариант. Если только делать две новые таблицы, а существующую удалять и создавать вместо неё обновляемое представление. Тут я предвижу проблемы, поэтому менять таблицу на представление не буду.
Спасибо, учту. Я третий день только в это секционирование погружаюсь, так что пока каша в голове только заваривается.
Месяц слишком много, максимум две недели.
Я это понимаю, поэтому и спросил как правильно.
В дела администрирования сервера я не лезу. Суть задачи дать оперативным операторам DML работать только с оперативными данными (и индексами), а архивным - с оперативными и архивными. Цель - уменьшение времени оперативных запросов, пускай и за счёт увеличения времени архивных. Сейчас данные за два месяца в этой таблице приводят к резкому спаду производительности, вплоть до отказов в ответах на запросы по таймауту.

Всем спасибо за ответы! Хотелось бы больше конкретики: не только "что", но и "как".

В том-то и дело, что они есть.
А с чего она упадёт, если обновлять поле, на которое завязана схема секционирования, по регламенту раз в сутки, например?
Да, такой подход встречал, но у меня дискретность одна неделя, не хотелось бы сотни файлов иметь.
Тут не скользящее окно, по крайней мере в его классическом виде с копией структуры секционируемой таблицы (stage) для переключения секции. А вопрос о секционировании очередной раз встал, и хочется попробовать и посмотреть на результат.

Если к полному скану таблицы, согласен, что не спасёт. Но если всё-таки

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