[Busla]

Если серьезно - учите матчасть. Могу привести два аргумента, теоретический и практический: 1) В 32х битной системе процессу больше двух гигабайт памяти не выделяется. Потоки делят память внутри процесса. Идеальный случай: - у вас много памяти, по крайней мере достаточно для безпроблемного кеширования всего и вся, или размер данных не велик и полностью влезает в память. - один файл данных обслуживает один процесс кэширования операций чтения/записи. - Файлов много, процессов кеширования тоже. Так вот, дорогой друг, при размере файла данных более 2 гигабайт, даже при наличии свободной памяти, один процесc не сможет обслужить файл данных, дабы тот целиком влез в кэш. А при не равном соотношении количестве процессов - файлов это уже конкуренция за ресурсы. Естественно на это имеет смысл обращать внимание лишь в высоконагруженных системах. »

Матчасть я, как раз, знаю, спасибо:
1) ключ 3gb файла boot.ini позволяет перераспредилить адресное пространство, и пользовательским процессам будет отведено до 3Гб
2) памяти у нас всё же меньше чем объём данных, и для чтения-записи какой-то части файла его ОС целиком в память не грузит
3) ОС работает с дисковой системой не на уровне байтов, а на уровне секторов (512 байт); кластеров (как правило больше секторов); SQL Server на уровне - страниц (8Кб) и групп страниц (extent - 64Кб). Соответственно и чтение-запись осуществляется блоками по 8-64 Кб, а не массивами "сколько в память влезет".
4) У нас речь и о величине прироста файла или об абсолютном размере файла? Прирост я как раз рекомендовал делать меньше 2Гб. А разбивать БД на множество мелких файлов в большинстве случаев неэффективно.