Но недавно я наткнулся на какую-то базу данных на сервере, где в каждой базе данных было несколько mdf-файлов.
Это из-за неправильного соглашения об именах. Microsoft говорит, что каждая база данных имеет один первичный файл данных, но это не значит, что она может иметь только один «файл данных mdf», база данных может иметь много файлов данных с .mdfрасширением, но только один будет основным файлом данных. Лучше дать mdfрасширение первичному файлу данных и ndfвторичному файлу данных, чтобы обеспечить надлежащее разграничение, но это не жесткое и быстрое правило, вы также можете дать расширение .abc первичному файлу данных, чтобы вы увидели, что это нормально. На самом деле вы можете дать любое расширение, которое вам нравится.
Есть ли смысл иметь несколько файлов .mdf для базы данных?
Если ты имеешь ввиду:
Есть ли смысл иметь несколько первичных файлов для базы данных?
Ответ - нет, база данных может иметь только один первичный файл данных.
Но если вы имеете в виду:
Есть ли смысл использовать несколько файлов данных (.mdf, .ndf или по-разному) для базы данных?
Это зависит, вы можете и не можете иметь преимущество с несколькими файлами данных. Если они распределены по разным физическим дискам (я говорю о шпинделях), вы увидите некоторое преимущество с интенсивным написанием приложений. Если они все находятся в одних и тех же логических разделах, у них не будет никаких преимуществ, потому что в основе их лежит использование общего ресурса. Использование файлов и файловых групп повышает производительность базы данных, поскольку позволяет создавать базу данных на нескольких дисках, нескольких дисковых контроллерах или в системах RAID (избыточный массив независимых дисков). Например, если на вашем компьютере четыре диска, вы можете создать базу данных, состоящую из трех файлов данных и одного файла журнала, с одним файлом на каждом диске. При доступе к данным четыре головки чтения / записи могут одновременно получать доступ к данным.
Согласно этой статье MSDN BOL
Файловые группы используют стратегию пропорционального заполнения для всех файлов в каждой файловой группе. Когда данные записываются в файловую группу, ядро СУБД SQL Server записывает объем, пропорциональный свободному пространству в файле, в каждый файл в файловой группе вместо записи всех данных в первый файл до полного заполнения. Затем он пишет в следующий файл. Например, если файл f1 имеет 100 МБ свободного места, а файл f2 имеет 200 МБ свободного места, один экстент выделяется из файла f1, два экстента из файла f2 и т. Д. Таким образом, оба файла заполняются примерно в одно и то же время, и достигается простое чередование.
Другое известное мне преимущество - это база данных объемом 1 ТБ, если у вас есть для нее один файл данных, и вы хотите восстановить эту базу данных на каком-либо другом сервере, и вряд ли у вас будет 1 ТБ свободного места. Теперь, если одна и та же база данных распределена по разным файлам, каждый из которых имеет размер 250 G, процесс восстановления становится проще. На самом деле это может быть не ваш сценарий, но он немного помогает найти сервер с четырьмя дисками емкостью 250 ГБ, чем один диск емкостью 1 ТБ.
Я бы сказал, что вместо многих файлов данных лучше иметь разные файловые группы, но опять же не так много сред. Базы данных, состоящие из нескольких файловых групп, можно восстанавливать поэтапно с помощью процесса, известного как частичное восстановление. Пошаговое восстановление работает со всеми моделями восстановления, но более гибко для моделей с полной и массовой регистрацией, чем для простого режима. Файлы или файловые группы в базе данных могут быть зарезервированы и восстановлены индивидуально. Это позволяет восстанавливать только поврежденные файлы без необходимости восстановления остальной базы данных. Файлы в резервной копии файловой группы могут быть восстановлены по отдельности или в группе