В настоящее время мы сталкиваемся с некоторыми проблемами производительности, так как наша база данных становится слишком большой. Существуют данные, хранящиеся за последние 10 лет, и я не вижу причины, по которой данные старше 2 лет должны храниться в тех же таблицах, что и новые данные.

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

Информация

• Всего в базе данных около 310 000 000 записей.

• База данных нуждается в 250 ГБ на жестком диске.

• Версия сервера - SQL Server 2008 с уровнем совместимости SQL Server 2005 (90), но мы планируем вскоре перейти на SQL Server 2012

Я думал о двух возможностях:

Новая база данных

Создайте базу данных, аналогичную той, что на рабочем сервере, и вставьте все старые данные в новую базу данных.

• Недостаток: поскольку связанные серверы не разрешены в нашей среде, при необходимости будет сложно объединить старые данные.

Схема истории

Создайте новую схему fe [hist] с теми же таблицами, что и в производственной базе данных. Вставьте все старые данные в эти новые таблицы в новую схему.

• Преимущество: простота объединения, если в будущем понадобятся старые данные

• Вы предпочитаете одно из решений другому?
  • Зачем?
• Есть ли лучшие возможности?
• Существуют ли инструменты, с помощью которых эта задача легко выполнима?
• Есть еще мысли?

заранее спасибо

редактировать

Дополнительный вопрос:

Нужно ли только что созданной таблице архивов первичные / внешние ключи?

Или они должны иметь только столбцы, но без ключей / ограничений?

Я думаю, что ответ на многие ваши вопросы заключается в том, что это зависит. Какие проблемы с производительностью у вас возникают? Кажется необычным то, что база данных будет иметь проблемы с производительностью от увеличения до 250 ГБ.

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

Вы предпочитаете одно из решений другому?

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

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

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

Есть ли лучшие возможности?

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

Нужно ли только что созданной таблице архивов первичные / внешние ключи? Или они должны иметь только столбцы, но без ключей / ограничений?

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

Есть еще мысли?

Поскольку вы используете редакцию Enterprise и планируете перейти на SQL 2008+, вы можете рассмотреть сжатие данных для этой таблицы. Сжатие, безусловно, уменьшит дисковое пространство, но в зависимости от дискового и серверного ресурсов вашего сервера оно также может повысить производительность запросов на чтение за счет уменьшения дискового ввода-вывода и улучшения использования памяти (больше данных помещается в кэш одновременно).

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

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

По моему опыту вторая база данных будет предпочтительным выбором по двум причинам.

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

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

Игнорирование лицензии на данный момент, потому что это не то место, где я провожу свое время.

ИМХО, архив базы данных являются простейшими для реализации и поддержки. Они разные, слабо связанные сущности. Движение данных и контроль загрузки / ресурса имеют четкие границы. Можно легко перейти на другой экземпляр или сервер для лучшего управления производительностью, и стоимость не является серьезной проблемой. Обратите внимание, что самое простое! = Самое дешевое или наименьшее усилие. На самом деле у него намного больше задач, но это все простые задачи с двумя важными исключениями:

1. применение ограничений - в SQL Server нет такой вещи, как перекрестные ограничения базы данных, поэтому вам нужно решить, является ли это нарушителем соглашения.
2. кросс-запросы к базе данных используют распределенные запросы, которые все еще зависят от OLEDB, который устарел. Это означает, что вы можете столкнуться с проблемами с новыми типами данных, а также, если у вас возникнут проблемы с производительностью, вряд ли они когда-нибудь будут исправлены

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

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

Некоторые важные соображения:

• Регулярно ли запросы возвращают исторические / холодные данные или редко используются холодные данные?
• Являются ли исторические данные неизменными или они регулярно обновляются / удаляются?
• 310м строк - это «умеренно» (при условии, что все в 1 таблице) в зависимости от размера строки. У вас есть данные о размере строки? Сколько ГБ этой 310-метровой строки?
• Какова скорость роста этой таблицы?
• Вы можете изменить код приложения и его SQL-запросы?

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

Кроме того, если вы думаете об обновлении, подумайте о 2016 году и новой функции Stretch Database: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Я бы предпочел разделить базу данных на отдельную логическую базу данных по следующим причинам:

1. Требования к ресурсам

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

2. Производительность

Разбивая данные на отдельную базу данных, основная производственная база данных уменьшается в размерах, что способствует повышению общей производительности.

3. Более простые резервные копии

Резервное копирование архивных данных может не считаться таким важным, как «текущие / текущие» записи в основной базе данных SQL. Это может означать, что резервное копирование архивных данных может происходить реже. Кроме того, из-за последовательной природы ведения архивных данных может быть возможно резервное копирование разделов архивной базы данных один раз, а затем никогда. Например, после записи архивных данных в базу данных изменений архива за 2014 год эти данные никогда не изменятся.

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