В настоящее время у меня есть база данных SQL Server размером около 2 ГБ. Я знаю, что в течение следующего года он вырастет максимум до 10 ГБ. Место на жестком диске не является проблемой ни в малейшей степени.
Есть ли недостаток в том, чтобы изменить размер файла данных до 20 ГБ сейчас, а затем выполнить дефрагментацию жесткого диска?
Следует ли мне также изменить размер файла журнала до 1 ГБ? Что-то смехотворно большое, чтобы и там не произошло фрагментации.
С помощью этого вопроса я хотел бы избежать фрагментации файла данных на самом диске, но я не хочу отрицательно влиять на производительность.
Я всегда увеличиваю размер базы данных до разумного размера.
Однако более важным является правильное разбиение на разделы, особенно при использовании блоков RAID. Убедитесь, что ваши разделы также совпадают. И настраиваемое форматирование NTFS с размером узла 64 ГБ.
Если вы можете предсказать свои размеры MDF и LDF, дерзайте.
Помимо выравнивания разделов и форматирования с размером кластера 64 КБ (согласно ответу TomTom), также помните, что для дефрагментации таблицы (обслуживания индекса) требуется свободное пространство в MDF, примерно в 1,2 раза превышающее размер этой таблицы. Таким образом, вам нужно около 7,5 ГБ свободного места на MDF для стола 6 ГБ. Это частая причина неожиданного роста MDF и LDF.
Фрагментация существует на двух уровнях: SQL и ОС. Фрагментация ОС произойдет только в том случае, если размер файла был предварительно изменен на фрагментированном диске. Если вы измените размер файла в соответствии с вашими максимальными потребностями и отключите автоматический рост, диск не будет фрагментирован, если вы вручную не переместите некоторые данные в новый созданный файл данных.
В любом случае вам следует проверить фрагментацию SQL с помощью dbcc showcontig.
Так что да, на ваш вопрос: лучшая практика - давать размер в соответствии с растущими потребностями. Таким образом, SQL не будет терять время на выделение пространства, а также будет хранить байты данных SQL на диске в непрерывном порядке.