"Основная файловая группа заполнена" в стандарте SQL Server 2008 без видимых причин

Антон,

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

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

SELECT  
ds.name as filegroupname
, df.name AS 'FileName' 
, physical_name AS 'PhysicalName'
, size/128 AS 'TotalSizeinMB'
, size/128.0 - CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0 AS 'AvailableSpaceInMB' 
, CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0 AS 'ActualSpaceUsedInMB'
, (CAST(FILEPROPERTY(df.name, 'SpaceUsed') AS int)/128.0)/(size/128)*100. as '%SpaceUsed'
FROM sys.database_files df LEFT OUTER JOIN sys.data_spaces ds  
    ON df.data_space_id = ds.data_space_id;

EXEC xp_fixeddrives
select  t.name as TableName,  
    i.name as IndexName, 
    p.rows as Rows
from sys.filegroups fg (nolock) join sys.database_files df (nolock)
    on fg.data_space_id = df.data_space_id join sys.indexes i (nolock) 
    on df.data_space_id = i.data_space_id join sys.tables t (nolock)
    on i.object_id = t.object_id join sys.partitions p (nolock)
on t.object_id = p.object_id and i.index_id = p.index_id  
where fg.name = 'PRIMARY' and t.type = 'U'  
order by rows desc
select  t.name as TableName,  
    i.name as IndexName, 
    p.rows as Rows
from sys.filegroups fg (nolock) join sys.database_files df (nolock)
    on fg.data_space_id = df.data_space_id join sys.indexes i (nolock) 
    on df.data_space_id = i.data_space_id join sys.tables t (nolock)
    on i.object_id = t.object_id join sys.partitions p (nolock)
on t.object_id = p.object_id and i.index_id = p.index_id  
where fg.name = 'PRIMARY' and t.type = 'U' and i.index_id = 0 
order by rows desc

Столкнулся с той же проблемой, и поначалу дефрагментация, казалось, работала. Но это было совсем недолго. Оказалось, что сервер, который использовал клиент, работал под управлением Express version и имеет лимит лицензирования около 10gb.

Таким образом, даже если размер был установлен в "неограниченный", это не было.

Я также столкнулся с той же проблемой, где начальный размер dtabase установлен на 4 ГБ, а autogrowth-на 1 Мб. Виртуальный зашифрованный диск TrueCrypt, на котором находилась база данных, казалось, имел достаточно места.

Я изменил пару (вышеперечисленных) вещей:

• я превратил службу Windows для SQL Server Express из автоматической в ручной, таким образом, работает только "обычный" Sql-сервер. (Несмотря на то, что я использую Sql Server 2008 R2, который должен позволить 10 ГБ.)
• я изменил авторост с 1 Мб на 10%
• я изменил размер приращения автороста с 10% до 1000 МБ
• я дефрагментировал диск
• я сократил базу данных:
  • вручную DBCC SHRINKDATABASE('...')
  • автоматически щелкните правой кнопкой мыши на базе данных | "свойства" | "автоматическое сжатие" | "усечение журнала на контрольной точке")

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

• я сделал новый виртуальный диск большего размера с TrueCrypt

Делая это, я столкнулся с TrueCrypt-вопросом, если я собираюсь хранить файлы размером более 4 ГБ (, как показано в этом вопросе суперпользователя).

• я сказал TrueCrypt, что буду хранить файлы размером более 4 ГБ

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

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

Сделай одну вещь, перейти к свойствам базы данных выберите файлы и увеличьте начальный размер базы данных и набор первичной файловой группы, а несколькими. перезапустить SQL Server.

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

Я только что столкнулся с той же проблемой. Причина заключалась в том, что файл виртуальной памяти "pagefile.sys " был расположен на том же диске, что и наши файлы данных для наших баз данных (D: диск). Он удвоился в размере и заполнил диск, но windows не собирала его, то есть казалось, что у нас было 80 ГБ свободного места, когда на самом деле этого не было.

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

Интересно, что в течение 30 минут, которые мы исследовали, windows не рассчитывала размер файла подкачки.sys вообще (80 ГБ). После перезагрузки windows действительно нашла файл подкачки и включила его размер в общую загрузку диска (Теперь 40 Гб - что все еще слишком много).

Пожалуйста, отметьте тип роста файла базы данных, если его ограничение делает его неограниченным

Я обнаружил, что это происходит потому, что: http://support.microsoft.com/kb/913399

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

Если страницы не освобождены, другие объекты в базе данных не могут повторно используйте страницы.

Однако, когда вы включаете уровень изоляции на основе управления версиями строк в a База данных SQL Server 2005, страницы не могут быть выпущены, даже если блокировка на уровне стола удерживается.

Решение Microsoft: http://support.microsoft.com/kb/913399

Чтобы обойти эту проблему, используйте один из следующих методов: Включите подсказку TABLOCK в инструкцию DELETE, если строка уровень изоляции на основе управления версиями не включен. Например, используйте утверждение, которое похоже на следующее:

Удалить из TableName с помощью (TABLOCK)

Примечание представляет имя таблицы. Используйте усечение Инструкция TABLE, если вы хотите удалить все записи в таблице. Например, используйте оператор, подобный следующему:

Усечение таблицы TableName

Создайте кластеризованный индекс для столбца таблицы. Для большего сведения о создании кластеризованного индекса в таблице см. Тема "создание кластеризованного индекса" в SQL

Вы заметите внизу ссылки, что не отмечено, что это относится к SQL Server 2008, но я думаю, что это так

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