Как насчет выполнения курсоров, переиндексации и сжатия?

Question

я, что недавно стало известно, что SQL сервер , если я удалить один столбец или изменить приобретает space at backend поэтому мне нужно индексировать и сжать базу данных, и я сделал это и мой размер datbase сводится к

2,82 до 1,62

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

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

2. Если да, то выше , что определенное время я должен обновить (Shrink) моя база данных?

3. я не имею ни малейшего представления, что должно быть сделано для задачи расстояния диска я с 77000 записей, затрачиваемое 2.82gb DataSpace, который не является приемлемым я имею две таблицы, что один только с одним столом NVARCHAR (макс) так что должно быть минимум пространства в базе данных может кто-нибудь помочь мне в этом Спасибо заранее

Answer 1

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

Две концепции, которые вы должны понимать. Выделенное пространство и свободное пространство. База данных может иметь размер 2 ГБ, но она использует только 1 ГБ, поэтому она выделяет 2 ГБ с 1 ГБ свободного пространства. Когда вы сокращаете базу данных, она удаляет свободное пространство, поэтому свободное пространство должно быть около 0. Не думайте, что размер файла меньше. По мере роста базы данных он должен снова выделить пространство. Когда вы сокращаете файл, а затем он растет, каждый так часто не может выделять пространство смежным образом. Это создаст фрагментацию файлов, которая еще больше замедлит вас.

Файлы с файлами данных (.mdb) не так уж плохи, но при сокращении журнала транзакций журнал может привести к проблемам фрагментации виртуального журнала, что может замедлить работу. Таким образом, в двух словах есть очень мало оснований для сокращения вашей базы данных по расписанию. Пойдите, прочитайте о файлах Виртуального Журнала в SQL Server, есть много статей об этом. This - хорошая статья о файлах журналов с усадкой и о том, почему это плохо. Используйте его как отправную точку.

Во-вторых, индексы становятся фрагментированными с течением времени. Это приведет к плохой работе SELECT запросов в основном, но также повлияет на другие запросы. Таким образом, вам нужно выполнить некоторое обслуживание индекса в базе данных. См. this answer о том, как дефрагментировать ваши индексы.

Update:

Ну раз вы перестраивать индексы не ясно. Индекс восстанавливает блокировку индекса во время восстановления. По сути, они не работают в течение всего времени.В вашем случае это было бы быстрым 77 000 строк ничего для SQL-сервера. Поэтому перестройка индексов будет потреблять ресурсы сервера. IF У вас есть корпоративная версия, которую вы можете сделать онлайн-перестройку индекса, которая НЕ блокирует индексы, но будет потреблять больше места.

Так что вам нужно найти окно обслуживания. Например, если ваша система используется с 8:00 до 17:00, вы можете запланировать переоборудование технического обслуживания через часы. Запланируйте это с помощью агента SQL-сервера. Сценарий в ссылке можно автоматизировать для запуска.

Ваша база данных невелика. Я видел таблицы дескрипторов SQL Server 750 ГБ без нагрузки, если IO разделен на несколько дисков. Самая медленная часть любого сервера базы данных - это не процессор или оперативная память, а пути IO к дискам. Это огромная тема. Вернемся к вашей точке хранения данных в полях NVARCHAR(MAX). Я предполагаю, что это большой текст. Таким образом, после того, как вы сжимаете базу данных, вы видите размер 1,62 ГБ, что означает, что каждая строка в вашей базе данных составляет около 1,62/77 000 больших или примерно 22 КБ. Это кажется разумным. Экспортируйте таблицу в текстовый файл и проверьте размер, который будет удивлен, вероятно, будет больше 1,62 ГБ.

Не стесняйтесь спрашивать больше деталей если требуется.