Обновлено 12.11.2017
добрый день уважаемые читатели блога pyatilistnik.org, у меня на работе по исторически сложившейся ситуации, досталась в наследство одна архаичная служба СКУД Quest 2, кто не в курсе, это очень старая программа по организации системы прохода в компании, по типу СФИНКС. Все это хорошо, но в какой-то момент у меня появилась ошибка «Could not allocate space for object because the ‘PRIMARY’ filegroup is full» не дающая мне ни записывать карточки, ни что либо удалять. Давайте посмотрим как это решается и как это поправить.
Вот как выглядит данная ошибка:
При выполнении операции произошло следующее исключение: Could not allocate space for object ‘Events’ in database ‘Quest’, because the ‘PRIMARY’ filegroup is full
Через какое-то время вообще программа Quesr 2 перестала запускаться.
При выполнении операции произошло следующее исключение» Журнал событий переполнен.
Начав разбираться я обнаружил, что данная утилита, древняя как мамонт, и ее база данных построена на базе MS SQL 2000, да да, ей 17 лет. Размер базы данных оказался 1,8 ГБ.
Исправление ошибки
Если перевести первую ошибку, то видно, что забилась одна из таблиц базы данных, для того, чтобы попасть в базу нам потребуется установить, бесплатный модуль управления SQL Server Management Studio. Как он устанавливается, читаем по ссылке слева. Запускаем его, далее вам необходимо открыть все имеющиеся таблицы, в моем случае это Quest, а в ней уже Events. Щелкните по ней правым кликом и выберите пункт «Открыть таблицу». В результате чего вы увидите общее количество строк в ней.
Как очистить таблицу MS SQL
Давайте теперь вычистим таблицу и восстановим работу нашего СКУД Quest 2. Нам помогут две команды, полностью чистящие таблицу от всех записей.
либо
Если у вас объем таблицы в базе данных SQL большой, то выполнение запроса может занять некоторое время. Отличие truncate от delete, в том, что первый не ведет лог обработки. Надеюсь вам это помогло решить ошибку: Could not allocate space for object because the ‘PRIMARY’ filegroup is full.
24.09.08 — 11:09
УТ 10.3.3. Скуль. При обновлении конфигурации БД выдает ошибку
Каталог не обнаружен ‘v8srvr://server/dbase/configsave/d27921ca-6c64-46db-a20c-e30d84e2c08b.0’
по причине:
Каталог не обнаружен ‘ConfigSaved27921ca-6c64-46db-a20c-e30d84e2c08b.0’
по причине:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Could not allocate space for object ‘dbo.Config’.’PK__Config__07020F21′ in database ‘Dbase’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
HRESULT=80040E14, SQLSrvr: Error state=2, Severity=11, native=1105, line=3
Вроде спасает выгрузказагрузка базы. Но может кто подскажет, как еще решить проблему?
1 — 24.09.08 — 11:10
Чего тебе непонятно здесь — ‘PRIMARY’ filegroup is full ?
2 — 24.09.08 — 11:10
«because the ‘PRIMARY’ filegroup is full.»
На чистом буржуинском языке сказано, что нет места на диске или файл-группе некуда расширяться.
Берём dba, разбегаемся, пинаем его со всех сил, чтобы исправление этой ошибки стало его дембельским аккордом в твоей конторе.
3 — 24.09.08 — 11:13
(2) солдатов насмотрелся?:)
4 — 24.09.08 — 11:17
(3) Нет, админов настроился…
5 — 24.09.08 — 11:53
Извиняюсь, мало опыта работы со скульными базами.
Можно описать процесс «пинания DBA» попонятнее. типа «наведите мышку и щелкните здесь…» 
6 — 24.09.08 — 11:57
(5).
1. Отходим от dba на 10 метров.
2. начинаем разбег в сторону dba
3. при подбеге вытягиваем ногу и целим в musculus gluteus
4. после вскрика «шозанах» говорим ему «настрой сервер быстранах».
5. по инерции пробегаем мимо и направляемся в сторону кабинета начальника со словами «увольняйте dba, он неадекват»
А если серьёзно, для начала проверяй место на диске.
7 — 24.09.08 — 12:19
(6) Ну, Денис, — спасибо за «описание» процесса взаимодействия с SQL :)) Я давно уже догадывался что между мной и SQL-сервером «что-то еще нехватает» — а это «что-то» оказывается админом называется :о)
8 — 24.09.08 — 14:28
Место 146 ГБ.
Можно еще рекомендаций без приколов?
9 — 24.09.08 — 14:33
«or setting autogrowth on for existing files in the filegroup»
Кроме того не озвучена версия ОС и тип файловой системы на диске с файлами базы данных.
10 — 24.09.08 — 14:38
Windows server 2003.
Скуль 2005.
11 — 24.09.08 — 14:41
Версия скуля какая?
Какая файловая система?
12 — 24.09.08 — 14:43
Файловая система NTFS.
Скуль 2005 Express Edition (With Service Pack 2)
(9)Говорю ж в настройках SQL server не силен.
Если не сложно, где ставится этот «autogrowth»?
13 — 24.09.08 — 14:44
(12) Express Edition — еще вопросы есть?
14 — 24.09.08 — 14:44
(12) менеджмент студио — база данных — свойства — файлы.
15 — 24.09.08 — 14:45
(13) Упс. Не заметил…
(12) А экспресса — ограничение на размеры бахзы данных.
16 — 24.09.08 — 14:47
хых
17 — 24.09.08 — 14:48
Вот блин. Проверил. Как раз вырасло на 4 гб.
(14) Нашел. Увеличивать здесь смысла нет? Лучше поставить полную версию?
18 — 24.09.08 — 14:48
(17) читай (15). У полного ограничений как раз нет.
J_Silver
19 — 24.09.08 — 14:51
Спасибо огромное.
- Remove From My Forums
-
Question
-
Today, I was hit by the below error on my SQL Server DB having multiple files in multiple filegroups.
Event ID: 1105. Could not allocate space for object in database because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for
existing files in the filegroup.MSSQL 2014: Could not allocate space for object in database because the Filegroup is full
It occurred when my index maintenance job was running. Specifically during index reorg of one of the index. Upon investigation, I found that all my filegroups had at least one file with auto-growth enabled and all the auto-growth enabled files residing on respective
drives had enough free space available. So there was no question of space issue or file autogrowth(considering I have at least one file in each filegroup with auto-growth enabled).Upon further drill down, found below from one of the MS link https://msdn.microsoft.com/en-us/library/aa337441.aspxWhen an index is located on several files, ALTER INDEX REORGANIZE can return error 1105 when one of the files is full. The reorganization process is blocked when the process tries to move rows to the full file. To work around this limitation perform an ALTER
INDEX REBUILD instead of ALTER INDEX REORGANIZE or increase the file growth limit of any files that are full.So in order to fix my issue I went ahead and rebuild my index which fixed the issue. However, I am looking out for ways to avoid it as it may occur for different index in future and doing manual index rebuild all the time isn’t a good way to fix it? I would
love to hear your suggestions on this.
Answers
-
I appreciate your response. But if you see my question, the problem occurs only during index reorg and NOT rebuild. Rebuild fixes my issue. Why can’t the files in same filegroup isn’t referred as one. i.e. I have
at least one file in each filegroup with auto-growth enabled and that autogrowth enabled file has enough free space available where it resides. So logically file space should be increased at at filegroup level rather than the file level.When you have multiple files in a single filegroup — the recommendation is to size each file the same. This allows SQL Server to appropriately allocate space across each file using its proportional algorithm.
In other words — SQL Server want to spread data across all files in the filegroup evenly…and your configuration is preventing that operation from occurring because one or more files is filled.
Now — specifically to your issue:
When you reorganize an index — the operation attempts to move the data in that file to reorganize it…since the file is full it cannot move those fragments. When you rebuild the index SQL Server creates new storage — and since one or more files are
full it will use the non-full file(s) and allocate the data proportionally across those files.Again — reorganize only moves data within the file and cannot move that data to another file.
Jeff Williams
-
Marked as answer by
Monday, December 26, 2016 5:19 PM
-
Marked as answer by