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

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

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

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

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

i.e. I do know approximately the size of 1 row and approx how many rows will be inserted in an average week per table. I know these are estimates from the ground up so you think once a month is a suitable approximation for the file to extend or is it preferable to extend every hour>? or never?

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

Благодарю.

3

6 ответы

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

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

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

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

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

3
добавлено

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

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

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

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

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

2
добавлено

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

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

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

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

0
добавлено

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

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

0
добавлено

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

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

0
добавлено

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

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

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

0
добавлено
SqlCom.ru - Стиль жизни SQL
SqlCom.ru - Стиль жизни SQL
908 участник(ов)

Правила чата - https://t.me/sqlcom/88269 @sqlcom - основной канал (только MS SQL) @sql_ninja - второй канал (SQL вопросы начального уровня и свободное общение) @Gopnegbot - Викторина по SQL Server (наберите в привате /quiz). Предложения в @sql_ninja

SQL_Ninja
SQL_Ninja
340 участник(ов)

Правила чата - https://t.me/sqlcom/88269 @sqlcom - основной канал (только SQL) @sql_ninja - второй канал (SQL вопросы начального уровня и свободное общение) @Gopnegbot - Викторина по SQL Server (наберите в привате /quiz)