Разделение таблиц для архивирования данных

13

Сценарий:

две базы данных: DB_A и DB_Archive с одной очень большой таблицей с именем tableA.
каждый день записи старше 60 дней удаляются из DB_A и перемещаются в DB_Archive, главным образом, чтобы оставить вещь «отделенной», потому что tableA активно запрашивается в DB_A для записей за последние 2 месяца.

Я хочу избавиться от этого процесса, потому что он медленный и потребляет много ресурсов. Я думаю о реализации разбиения таблиц в DB_A с помощью функции секционирования в столбце даты и хранения всех записей <2 месяца в одном разделе и всех записей> 2 месяцев в другом разделе. Мои вопросы:

будет ли этот сценарий вести себя так, как если бы у меня было 2 разные базы данных? Если я запрашиваю в своей таблице A записи> getdate () - 30, будет ли он читать раздел архивации?
Я должен был разделить индексы, верно?
Как мне справиться с тем фактом, что завтра моя функция разбиения «изменится», я имею в виду, если я создам функцию сегодня (2 июля, ее диапазон будет 2 мая, а завтра будет 3 мая). Могу ли я создать функцию динамического разбиения?

sql-server sql-server-2005 partitioning

— Диего
источник

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

— JNK

Я составил пример того, что вы хотите сделать в прошлом году. Это был особый случай, когда мы хотели хранить x дней данных в быстром (дорогом) массиве и перемещать архивные данные в более дешевое хранилище. Если я смогу очистить пример сценария, я опубликую его, иначе это будет просто краткое изложение процесса.

— Марк Стори-Смит

Привет Марк, да, пожалуйста, сделайте, и если вы можете поделиться своим опытом. это было успешно?

— Диего

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

— Марк Стори-Смит

6

С разделением вам придется делать разделение в день, что ставит предопределение Pre-SQL 2012 в 1000 разделов в новом ракурсе, так как это позволит использовать архив только на 3 года. С SQL Server 2012 вы получаете 15000 разделов, что достаточно для 1 раздела в день.

Каждый день вы добавляете новый раздел. Если вы хотите переместить 61-й раздел прошедшего дня, вы можете сделать это эффективно, но все еще в автономном режиме. См. Эффективное перемещение раздела в другую файловую группу .

Все ваши индексы должны быть выровнены, см. « Особые указания для секционированных индексов» .

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

— Ремус Русану
источник

Новое ограничение доступно в 2008 SP2 и 2008 R2 SP1. blogs.msdn.com/b/hanspo/archive/2010/11/29/…

— Джон Зигель

@Jon: в 2008 SP2, 2008R2 SP1 приходит с большим предупреждением . As explained in this white paper, there are implications on certain features, including performance. . Поддержка SQL 2012 поставляется без предупреждений.

— Ремус Русану

Спасибо что подметил это; Это правда, что есть некоторые предостережения относительно его использования на 2008/2008 R2, но это доступная опция в случае необходимости.

— Джон Зигель

Спасибо за ваш комментарий. Я прочитаю комментарий к материалу позже

— Диего

2

Я не знаю, может ли функция разбиения быть динамической, но я сомневаюсь в этом. Некоторые варианты для вас, не пройдя этот маршрут:

1 - раздел в календаре DATE и каждый день удаляйте самый старый раздел

2 - Создайте представление, которое фильтрует по дате, и укажите все свои существующие запросы (это можно легко сделать, переименовав базовую таблицу в другое, и присвоив представлению имя текущей таблицы). Это может быть оптимизировано также с изменениями индекса.

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

— JNK
источник

Я хотел бы избегать ручных операций "каждый день"

— Диего

2

Вот что должно работать для вас: DB_A - таблица A с различным разделом для каждого из последних 60 дней - stagingTable для перемещения данных из самого старого раздела

DB_Archive tableA - хранит все данные старше 60 дней. (не разделен)

Процесс: 1. до конца дня: изменить функцию раздела - разделить диапазон, чтобы добавить новый раздел для нового дня. (Примечание: вместо создания разделов для «сегодняшней даты + 1 день» вы можете захотеть быть на несколько шагов вперед. Например: «сегодняшняя дата + 5 дней»)

После окончания каждого дня вы сначала переключаете самый старый раздел в DB_A.tableA на DB_A.stagingTable; Объединить самые старые разделы.
Импортируйте данные из DB_A.stagingTable в DB_Archive.tableA. Наконец trunacte DB_A.stagingTable

Вышеуказанное называется «скользящим окном» и представляет собой довольно распространенный сценарий для VLDB. См. Этот технический документ Microsoft по разделению: таблица разделов и стратегии индексирования или попробуйте это специально для сценария с раздвижным окном.

— Дхармендар Кумар 'DK'
источник

0

Вы можете использовать динамический подход архивирования и очистки данных в SQL Server. Пожалуйста, перейдите по ссылке ниже для этого.

http://www.sqlscientist.com/2012/09/auto-maintain-archival-process.html

— Асиф Ганчи
источник

1

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

— Дезсо