Автоматический рост SQL Server 2005 по размеру

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

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

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

Обновлено: http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1330922,00.html Статья посвящена сжатию вашей базы данных, но в ней подробно описывается, что происходит, когда база данных увеличивается автоматически, и показано влияние на производительность, которое это может оказать.

Вы определенно не хотите, чтобы ваша база данных росла так часто, как при 1 МБ за один раз!

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

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

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

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

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

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

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

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

Я только что проверил в SQL Server Management Studio 2008, и рост по умолчанию при создании новой базы данных составляет 1 МБ ... вероятно, откуда взялась ваша настройка 1 МБ (держу пари, что в 2005 году было то же самое).

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

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

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

На мой взгляд, я бы НЕ настраивал базу данных на рост в процентах, скорее позволил бы базе данных расти в течение недели до 100 МБ, а затем изменил бы настройку роста на рост на одну неделю, скажем, 5 ГБ. У нас есть системы, для которых мы это сделали.

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

Причина, по которой я хотел бы увести человека от процентного роста, заключается в том, что когда в системе 1000 МБ, она вырастет на 100 МБ. Тогда, в следующий раз, размер системы будет 1100 МБ, а мои 110 МБ увеличатся. Тогда размер будет 1210, а база данных вырастет до 121 МБ. Тогда размер будет 1331, а рост будет 133 Мб. При таком неравномерном росте будет очень сложно подсчитать, сколько места на диске у вас осталось, и когда вам нужно изменить максимальный размер.

Только мои 2 цента.

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