Таблицы истории в SQL Server

Question

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

Теперь мы заметили, что одна из таблиц, в которых хранятся события для продуктов, быстро растет, она производит около 6,5 миллионов строк в месяц, дает/берет несколько 100 000. Разумеется, база данных занимает много hdd- и он не станет меньше, размером около 12 ГБ, мы на пути к выходу из космоса.

Мне пришла в голову мысль о запуске скрипта каждую ночь, чтобы сохранить небольшое количество строк истории, но это, конечно же, не освобождает hdd-пространство, здесь мне нужно сжать файл базы данных. Прочитайте в сети о сжатии файла данных.

И получить за и против, почему это не следует делать. Может ли обработка таблицы истории быть выполнена каким-то другим способом или я должен запустить сценарий удаления в плане обслуживания, а один раз в неделю/месяц запускать сокращенную работу в плане обслуживания?

На данный момент у меня есть план обслуживания с: - реорганизовать индекс (3 раза в неделю) - Update статики (3 раза в неделю) - Очищает старые не нужны строки в некоторых таблицах. (каждый вечер)

В системе у него более 14 000 единиц, которые выбирают/записывают каждую минуту или 2 минуты, иногда это может быть очень медленно, и некоторые sql-вопросы, похоже, получают тайм-аут команды (30 секунд).

Answer 1

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

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

Answer 2

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

Это хороший обзор для SQL таблицы разделов: http://databases.about.com/od/sqlserver/a/partitioning.htm

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

Надеется, что это помогает

Answer 3

Оставлять размер файла базы данных в установившемся размере данных. Не входите в циклы сокращения роста. Это все. Усадка должна быть разовой очисткой для вас.

Если удаление строк не дает вам места обратно, усадка также не будет. Вам понадобится реорганизация или перестройка.