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

Question

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

Я обдумал это кратко, и это звучит неправильно. Я проверил несколько сайтов по поводу БД, и они не объяснили должным образом эти значения.

Возможно, я бы хотел, чтобы файлы базы данных расширялись раз в месяц, скажем?

Итак, если бы я рассчитал объем данных, которые я ожидаю вставить в день в мегабайтах, и просто умножить на 30, я бы нашел подходящую цифру?

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

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

Спасибо.

Answer 1

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

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

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

РЕДАКТИРОВАТЬ: http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1330922,00.html В этой статье рассказывается об уменьшении базы данных, но в ней подробно описывается, что происходит, когда база данных автоматически увеличивается, и показывается влияние на производительность, которое она может оказать.

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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