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

Ответ 1

ОК, он работает. Оказывается, что тома NTFS, в котором находятся файлы DB, сильно фрагментирована. Остановил SQL Server, дефрагментировал все это, и все это было прекрасно с тех пор.

Ответ 2

Антон

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

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

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

Ответ 3

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

Итак, хотя размер был установлен как "неограниченный", это было не так.

Ответ 4

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

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

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

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

• Я создал новый более крупный виртуальный диск с TrueCrypt

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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

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

DELETE FROM TableName WITH (TABLOCK)

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

TRUNCATE TABLE TableName

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

В нижней части ссылки вы заметите, что НЕ отмечено, что она применяется к SQL Server 2008, но я думаю, что она делает

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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