Ice_one1,

Вы пошли путем экстенсивным, просто увеличивая доступное пространство и практически не влияя на то как оно будет
заполнено.
Решение же лежит на поверхности - секционирование.
представим самую простейшую ситуацию:
имеем несколько справочников, чей рост практически никак не влияет на размер базы и пару связанных таблиц, например шапка (чего-то) и табличная часть связанные между собой монотонно увеличивающимся айдишником (бигинт).
из физики (я про диски), к примеру, есть 6 лунов
на первом луне размещаем саму базу, естественно там будет и останется файловая группа PRIMARY вместе со всеми справочниками
добавляем еще 5 файловых групп, пишем функцию секционирования для айдишника с вычислением остатка от его деления на 5 и определяем схему секционирования, как каждому значению остатка своя файловая группа.
указываем кластерным ключам наших шапок и табличных частей использовать эту схему секционирования посредством функции секционирования на основании значений айдишников.
все! получаем не совсем равномерное, но более-менее нормальное распределение по 1/5 на каждый диск, причем для выборки конкретной шапки с табличной частью будет задействован только один лун.
перекос возникать будет если у Вас количество записей в табличной части тоже зависит от остатка деления на 5, например каждая 3-я шапка имеет в 100 раз большую табличную часть.. - но это вряд-ли..

решение - не панацея, но работает.
не знаю как показать, ну вот например 4 секции накопления, а в 5-ой складываются оперативные данные. перекос виден в количестве, в размере примерно столько же в % отношении.