Hi ,
I have a SQL Server 2000 database on my C drive.
Over the weekend my C drive got full due to my transaction log files ballooning up.
At that point none of my users were able to log into their the VB application and enter data.
I freed up some disk space, and then the users were able to log in fine, except for a certain column variable(aggregate) values were negative.
I deattached the DBs and Ldf files and made copies of them on to a test envirnoment. Within the test environment, I ran SQL Query Analyzer with SQL statments that did give me the aggregate values as negative. This matched my VB application values aswell.
I ran
DBCC CHECKDB — no errors
DBCC DBREINDEX — no errors
Our programming vendor tells us the DBs are corrupt.
From Error file
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2007-01-30 19:43:56.95 spid52 C:Program FilesMicrosoft SQL ServerMSSQLDatatempdb.mdf: Operating system error 112(There is not enough space on the disk.) encountered.
2007-01-30 19:43:56.98 spid52 Error: 1105, Severity: 17, State: 2
2007-01-30 19:43:56.98 spid52 Could not allocate space for object ‘(SYSTEM table id: -900439724)’ in database ‘TEMPDB’ because the ‘DEFAULT’ filegroup is full..
2007-02-23 09:56:21.21 spid56 C:Program FilesMicrosoft SQL ServerMSSQLDataActgSQL.mdf: Operating system error 112(There is not enough space on the disk.) encountered.
2007-02-23 09:56:21.24 spid56 Error: 1105, Severity: 17, State: 2
2007-02-23 09:56:21.24 spid56 Could not allocate space for object ‘POSInventory’ in database ‘ActgSQL’ because the ‘PRIMARY’ filegroup is full..
2007-02-23 11:11:09.74 spid56 Error: 1105, Severity: 17, State: 2
2007-02-23 11:11:09.74 spid56 Could not allocate space for object ‘POSInventory’ in database ‘ActgSQL’ because the ‘PRIMARY’ filegroup is full..
2007-02-23 15:50:19.27 spid59 Process ID 53 killed by hostname ORCHID, host process ID 3360.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I thought I had backups but I don t. So now I m in a big bind. Help!!
Any suggestions ?
Hi ,
I have a SQL Server 2000 database on my C drive.
Over the weekend my C drive got full due to my transaction log files ballooning up.
At that point none of my users were able to log into their the VB application and enter data.
I freed up some disk space, and then the users were able to log in fine, except for a certain column variable(aggregate) values were negative.
I deattached the DBs and Ldf files and made copies of them on to a test envirnoment. Within the test environment, I ran SQL Query Analyzer with SQL statments that did give me the aggregate values as negative. This matched my VB application values aswell.
I ran
DBCC CHECKDB — no errors
DBCC DBREINDEX — no errors
Our programming vendor tells us the DBs are corrupt.
From Error file
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2007-01-30 19:43:56.95 spid52 C:Program FilesMicrosoft SQL ServerMSSQLDatatempdb.mdf: Operating system error 112(There is not enough space on the disk.) encountered.
2007-01-30 19:43:56.98 spid52 Error: 1105, Severity: 17, State: 2
2007-01-30 19:43:56.98 spid52 Could not allocate space for object ‘(SYSTEM table id: -900439724)’ in database ‘TEMPDB’ because the ‘DEFAULT’ filegroup is full..
2007-02-23 09:56:21.21 spid56 C:Program FilesMicrosoft SQL ServerMSSQLDataActgSQL.mdf: Operating system error 112(There is not enough space on the disk.) encountered.
2007-02-23 09:56:21.24 spid56 Error: 1105, Severity: 17, State: 2
2007-02-23 09:56:21.24 spid56 Could not allocate space for object ‘POSInventory’ in database ‘ActgSQL’ because the ‘PRIMARY’ filegroup is full..
2007-02-23 11:11:09.74 spid56 Error: 1105, Severity: 17, State: 2
2007-02-23 11:11:09.74 spid56 Could not allocate space for object ‘POSInventory’ in database ‘ActgSQL’ because the ‘PRIMARY’ filegroup is full..
2007-02-23 15:50:19.27 spid59 Process ID 53 killed by hostname ORCHID, host process ID 3360.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I thought I had backups but I don t. So now I m in a big bind. Help!!
Any suggestions ?
How to Tackle SQL Server Error 1105 – Severity 17 State 2?
SQL Server database can encounter many errors and issues with it. Any type of issue with the server is followed by errors and every error belongs to a certain internal issue with the server or database. This blog discusses about SQL Server error 1105, which is associated with the disk space allocation. The “SQL Server Error 1105” is prompted when your transaction needs more space than it is available in transaction log file. The major issue with this error is when this error occurs, all the current transactions processing are stopped. SQL Server halts all the transaction unless the log is cleared or more space is added to this file for storing more transactions.
Details of SQL Error 1105
Error 1105 Severity Level 17 Message Text Could not allocate space for object '%.*ls' in database '%.*ls' because the '%.*ls' filegroup is full.
This error is related to the transaction log file when the specified filegroup run out of space and there is no space to add the transaction. In order to avoid this error, DBAs take care to balance the transaction log file’s size with respect to the size of database. This size ratio is regulated while creating log file that should be 1/4th-1/2th of the size of database. Generally, DSSs and data warehouse applications have transaction log files, which are much smaller. Administrators also implement database options like “truncate log on checkpoint” or log-dumping tasks in order to control data in log files.
Symptoms of SQL Server Error 1105
When the temporary database (tempdb) or transaction log file is full, you are restricted to perform any query or any other operation in SQL Server. Error 1105 is displayed as below;
How to Resolve This Situation?
In order to gain the space, users can free-up the disk space on the system drive, which comprise of the files in full filegroup, letting files to grow in the group. Users can gain space using data file with its specific database.
Steps to Free Disk Space
- Disk space can be freed on the local drive or on another drive. For this, move the data files of filegroup, which have insufficient amount of free disk space to different disk drive.
- Detach the target database using sp_detach_db.
- Then attach the database using sp_attach_db, pointing to the moved files.
By Means of a Data File
Another workaround, which can be done in such situation, is by adding data file to specified database using ADD File clause of ALTER DATABASE statement. Alternatively, the data file can be enlarged using the MODIFY FILE clause by specifying the SIZE and MAXSIZE syntax.
Conclusion
The SQL Server error 1105 can be avoided by managing the size and duration of transactions made with respect to Log file. In case if transaction taking too much memory space, they can be managed by dumping the logs or clearing them in order to continue the flow of transactions. In order to avoid such errors in future, administrators must take care in advance so that the transaction log file memory is managed.
Hi ,
I have a SQL Server 2000 database on my C drive.
Over the weekend my C drive got full due to my transaction log files ballooning up.
At that point none of my users were able to log into their the VB application and enter data.
I freed up some disk space, and then the users were able to log in fine, except for a certain column variable(aggregate) values were negative.
I deattached the DBs and Ldf files and made copies of them on to a test envirnoment. Within the test environment, I ran SQL Query Analyzer with SQL statments that did give me the aggregate values as negative. This matched my VB application values aswell.
I ran
DBCC CHECKDB — no errors
DBCC DBREINDEX — no errors
Our programming vendor tells us the DBs are corrupt.
From Error file
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2007-01-30 19:43:56.95 spid52 C:Program FilesMicrosoft SQL ServerMSSQLDatatempdb.mdf: Operating system error 112(There is not enough space on the disk.) encountered.
2007-01-30 19:43:56.98 spid52 Error: 1105, Severity: 17, State: 2
2007-01-30 19:43:56.98 spid52 Could not allocate space for object ‘(SYSTEM table id: -900439724)’ in database ‘TEMPDB’ because the ‘DEFAULT’ filegroup is full..
2007-02-23 09:56:21.21 spid56 C:Program FilesMicrosoft SQL ServerMSSQLDataActgSQL.mdf: Operating system error 112(There is not enough space on the disk.) encountered.
2007-02-23 09:56:21.24 spid56 Error: 1105, Severity: 17, State: 2
2007-02-23 09:56:21.24 spid56 Could not allocate space for object ‘POSInventory’ in database ‘ActgSQL’ because the ‘PRIMARY’ filegroup is full..
2007-02-23 11:11:09.74 spid56 Error: 1105, Severity: 17, State: 2
2007-02-23 11:11:09.74 spid56 Could not allocate space for object ‘POSInventory’ in database ‘ActgSQL’ because the ‘PRIMARY’ filegroup is full..
2007-02-23 15:50:19.27 spid59 Process ID 53 killed by hostname ORCHID, host process ID 3360.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I thought I had backups but I don t. So now I m in a big bind. Help!!
Any suggestions ?
Содержание
- Степени серьезности ошибок компонента Database Engine
- Уровни серьезности
- Серьезность пользовательских сообщений об ошибках
- Серьезность ошибки и конструкция TRY…CATCH
- определение серьезности ошибки
- Основные сведения об ошибках компонента Database Engine
- Is there an overview of all SQL Server 2012 error codes?
- 5 Answers 5
Степени серьезности ошибок компонента Database Engine
Применимо к: SQL Server (все поддерживаемые версии)
При возникновении ошибки ядром СУБД SQL Server серьезность ошибки указывает тип проблемы, возникшей в SQL Server.
Уровни серьезности
В следующей таблице перечислены уровни серьезности ошибок, вызванных ядром СУБД SQL Server.
| Степень серьезности | Описание |
|---|---|
| 0-9 | Информационные сообщения, возвращающие сведения о состоянии или оповещающие о несерьезных ошибках. Ядро СУБД не вызывает системные ошибки с серьезностью от 0 до 9. |
| 10 | Информационные сообщения, возвращающие сведения о состоянии или оповещающие о несерьезных ошибках. По соображениям совместимости ядро СУБД преобразует уровень серьезности 10 в серьезность 0 перед возвратом сведений об ошибке вызывающем приложению. |
| 11-16 | Ошибки, которые могут исправляться пользователем. |
| 11 | Данный объект или сущность не существует. |
| 12 | Специальный уровень серьезности для запросов, не использующих блокировку из-за специальных указаний запросов. В некоторых случаях операции чтения, выполняемые этими инструкциями, могут давать в результате несогласованные данные, так как блокировки не приспособлены для обеспечения согласованности. |
| 13 | Указывает ошибки взаимоблокировки транзакций. |
| 14 | Указывает ошибки, связанные с безопасностью, например запрет на разрешение. |
| 15 | Указывает синтаксические ошибки в команде Transact-SQL. |
| 16 | Обозначает общие ошибки, которые могут исправляться пользователем. |
| 17-19 | Обозначаются программные ошибки, которые не могут исправляться пользователем. Сообщите администратору системы о данной проблеме. |
| 17 | Указывает, что инструкция привела SQL Server к нехватке ресурсов (например, памяти, блокировок или дискового пространства для базы данных) или превышению некоторого ограничения, установленного системным администратором. |
| 18 | Указывает на проблему в программном обеспечении ядра СУБД, но инструкция завершает выполнение и поддерживается подключение к экземпляру ядра СУБД. Необходимо сообщить системному администратору о каждом случае возникновения ошибки со степенью серьезности 18. |
| 19 | Указывает, что превышено ненастранимое ограничение ядра СУБД и завершен текущий пакетный процесс. Сообщения об ошибке со степенью серьезности 19 и выше останавливают выполнение текущего пакета. Ошибки со степенью серьезности 19 происходят редко и должны устраняться системным администратором или основной службой технической поддержки. При возникновении ошибок со степенью серьезности 19 обратитесь к системному администратору. Сообщения об ошибках со степенью серьезности от 19 до 25 записываются в журнал ошибок. |
| 20–24 | Укажите системные проблемы и являются неустранимыми ошибками, что означает, что задача ядра СУБД, выполняющая инструкцию или пакет, больше не выполняется. Задача записывает сведения о том, что произошло, и затем прекращает работу. В большинстве случаев подключение приложения к экземпляру ядра СУБД также может завершиться. В этом случае приложение, возможно, не сможет вновь выполнить подключение (в зависимости от проблемы).
Сообщения об ошибках этого диапазона могут влиять на все процессы, обращающиеся к данным в одной и той же базе данных, и могут указывать на то, что база данных или объект повреждены. Сообщения об ошибках со степенью серьезности от 19 до 24 записываются в журнал ошибок. |
| 20 | Обозначает, что при выполнении инструкции возникла проблема. Так как проблема повлияла только на текущую задачу, маловероятно, что повреждена база данных. |
| 21 | Обозначает, что возникла проблема, влияющая на все задачи в текущей базе данных, но маловероятно, что повреждена база данных. |
| 22 | Обозначает, что таблица или индекс, указанные в сообщении, повреждены из-за программной проблемы или проблемы оборудования.
Ошибки степени серьезности 22 происходят редко. При возникновении такой ошибки запустите инструкцию DBCC CHECKDB, чтобы определить, не повреждены ли другие объекты в базе данных. Проблема может быть ограничена только буферным кэшем и не затрагивать сам диск. В этом случае перезапуск экземпляра ядра СУБД исправляет проблему. Чтобы продолжить работу, необходимо повторно подключиться к экземпляру ядра СУБД; в противном случае используйте DBCC для устранения проблемы. В некоторых случаях может потребоваться восстановление базы данных. Если перезапуск экземпляра ядра СУБД не устранит проблему, проблема находится на диске. Иногда удаление объекта, указанного в сообщении об ошибке, может решить проблему. Например, если сообщение сообщает, что экземпляр ядра СУБД обнаружил строку длиной 0 в некластеризованном индексе, удалите индекс и перестройте его. |
| 23 | Обозначает, что из-за проблем в оборудовании или программном обеспечении целостность всей базы данных находится под вопросом.
Ошибки степени серьезности 23 происходят редко. При возникновении такой ошибки запустите инструкцию DBCC CHECKDB, чтобы определить экстент повреждения. Проблема может быть ограничена только кэшем, и не затрагивать сам диск. В этом случае перезапуск экземпляра ядра СУБД исправляет проблему. Чтобы продолжить работу, необходимо повторно подключиться к экземпляру ядра СУБД; в противном случае используйте DBCC для устранения проблемы. В некоторых случаях может потребоваться восстановление базы данных. |
| 24 | Обозначает неисправность носителя. Возможно, системный администратор должен восстановить базу данных. Кроме того, может потребоваться обращение к поставщику оборудования. |
Серьезность пользовательских сообщений об ошибках
Процедураsp_addmessage может использоваться для добавления пользовательских сообщений об ошибках с уровнем серьезности от 1 до 25 в представление каталога sys.messages . Эти пользовательские сообщения об ошибках могут использоваться инструкцией RAISERROR. Дополнительные сведения см. в разделе sp_addmessage (Transact-SQL).
Инструкция RAISERROR может применяться для формирования пользовательских сообщений об ошибках с уровнем серьезности от 1 до 25. Инструкция RAISERROR может либо ссылаться на определенное пользователем сообщение, находящееся в представлении каталога sys.messages , либо динамически создавать сообщение. Если при формировании ошибки используется пользовательское сообщение об ошибках, хранимое в представлении sys.messages, то уровень серьезности, указанный в инструкции RAISERROR, переопределяет уровень серьезности, указанный в представлении sys.messages. Дополнительные сведения см. в разделе справки RAISERROR (Transact-SQL).
Серьезность ошибки и конструкция TRY…CATCH
Конструкция TRY…CATCH перехватывает все ошибки исполнения с уровнем серьезности выше 10, которые не прерывают подключение к базе данных.
Ошибки с уровнем серьезности от 0 до 10 являются информационными сообщениями и не приводят к выходу процесса выполнения из блока CATCH конструкции TRY…CATCH.
Ошибки, приводящие к прерыванию подключения к базе данных и обычно имеющие уровень серьезности от 20 до 25, не обрабатываются блоком CATCH, так как при разрыве соединения выполнение прерывается.
Дополнительные сведения см. в разделе TRY. CATCH (Transact-SQL).
определение серьезности ошибки
Чтобы определить серьезность ошибки, инициирующей выполнение блока CATCH конструкции TRY…CATCH, можно использовать системную функцию ERROR_SEVERITY. Если вызов происходит не из блока CATCH, функция ERROR_SEVERITY возвращает значение NULL. Дополнительные сведения см. в разделе ERROR_SEVERITY (Transact-SQL).
Источник
Основные сведения об ошибках компонента Database Engine
Применимо к: SQL Server (все поддерживаемые версии) Azure SQL database Управляемый экземпляр SQL Azure Azure Synapse Analytics Analytics Platform System (PDW)
Ошибки, возникшие в компоненте Microsoft Компонент SQL Server Database Engine, имеют атрибуты, описанные в следующей таблице.
| attribute | Описание |
|---|---|
| Номер ошибки | Каждое сообщение имеет уникальный номер ошибки. |
| Строка сообщения об ошибке | Сообщение об ошибке содержит диагностические сведения о причине ошибки. Многие сообщения об ошибках имеют подстановочные переменные, в которые заносятся сведения, например имя объекта, вызвавшего ошибку. |
| Severity | Степень серьезности ошибки указывает, насколько она значительна. Ошибки с низкой степенью серьезности, например 1 или 2, являются информационными сообщениями или предупреждениями низкого уровня. Ошибки с высокой степенью серьезности указывают на проблемы, которые должны быть решены как можно быстрее. Дополнительные сведения о степенях серьезности см. в разделе Степени серьезности ошибок компонента Database Engine. |
| Состояние | Некоторые сообщения об ошибках могут возникнуть в нескольких точках кода компонента Компонент Database Engine. Например, ошибка 1105 может возникнуть при различных условиях. Каждое условие, которое вызывает ошибку, присваивает уникальный код состояния.
При просмотре баз данных со сведениями об известных неполадках, таких как база знаний Microsoft , можно использовать номер состояния, чтобы определить, является ли записанная неполадка возникшей ошибкой. Например, если статья базы знаний описывает ошибку 1105 с состоянием 2, а получена ошибка 1105 с состоянием 3, ошибка, вероятно, возникла не по той причине, которая описана в статье. Инженер поддержки Microsoft также может использовать код состояния, содержащийся в сообщении об ошибке, чтобы найти место в исходном коде, где эта ошибка возникла. Эти данные могут предоставить дополнительные сведения для диагностики проблемы. |
| Имя процедуры | Имя хранимой процедуры или триггера, в которых произошла ошибка. |
| Номер строки | Указывает на инструкцию в пакете, хранимой процедуре, триггере или функции, которая сформировала ошибку. |
Все системные и пользовательские сообщения об ошибках в экземпляре компонента Компонент Database Engine содержатся в представлении каталога sys.messages . Инструкцию RAISERROR можно использовать для возвращения пользовательских ошибок приложению.
Все API-интерфейсы базы данных, например пространство имен Microsoft .NET Framework SQLClient, ActiveX Data Objects (ADO), OLE DB и Open Database Connectivity (ODBC), сообщают основные атрибуты ошибки. Эти сведения включают номер ошибки и строку сообщения. Однако не все API-интерфейсы сообщают остальные атрибуты ошибки.
Сведения об ошибке, возникающей в области блока TRY try try. Конструкцию CATCH можно получить в коде Transact-SQL с помощью таких функций, как ERROR_LINE, ERROR_MESSAGE, ERROR_NUMBER, ERROR_PROCEDURE, ERROR_SEVERITY и ERROR_STATE в области связанного блока CATCH. Дополнительные сведения см. в разделе TRY. CATCH (Transact-SQL).
Источник
Is there an overview of all SQL Server 2012 error codes?
SQLGetDiagRec returns a native error code. Is there anywhere an overview of the error codes of SQL Server 2012? I couldn’t find anything on MSDN.
5 Answers 5
I’m unable to find a list of the individual codes in the internet. However I did find a list of the severity levels here on MSDN. They are as follows:
Severity level / Description
- 0-9: Informational messages that return status information or report errors that are not severe. The Database Engine does not raise system errors with severities of 0 through 9.
- 10: Informational messages that return status information or report errors that are not severe. For compatibility reasons, the Database Engine converts severity 10 to severity 0 before returning the error information to the calling application.
- 11-16: Indicate errors that can be corrected by the user.
- 11: Indicates that the given object or entity does not exist.
- 12: A special severity for queries that do not use locking because of special query hints. In some cases, read operations performed by these statements could result in inconsistent data, since locks are not taken to guarantee consistency.
- 13: Indicates transaction deadlock errors.
- 14: Indicates security-related errors, such as permission denied.
- 15: Indicates syntax errors in the Transact-SQL command.
- 16: Indicates general errors that can be corrected by the user.
- 17-19: Indicate software errors that cannot be corrected by the user. Inform your system administrator of the problem.
- 17: Indicates that the statement caused SQL Server to run out of resources (such as memory, locks, or disk space for the database) or to exceed some limit set by the system administrator.
- 18: Indicates a problem in the Database Engine software, but the statement completes execution, and the connection to the instance of the Database Engine is maintained. The system administrator should be informed every time a message with a severity level of 18 occurs.
- 19: Indicates that a nonconfigurable Database Engine limit has been exceeded and the current batch process has been terminated. Error messages with a severity level of 19 or higher stop the execution of the current batch. Severity level 19 errors are rare and must be corrected by the system administrator or your primary support provider. Contact your system administrator when a message with a severity level 19 is raised. Error messages with a severity level from 19 through 25 are written to the error log.
- 20-24: Indicate system problems and are fatal errors, which means that the Database Engine task that is executing a statement or batch is no longer running. The task records information about what occurred and then terminates. In most cases, the application connection to the instance of the Database Engine may also terminate. If this happens, depending on the problem, the application might not be able to reconnect. Error messages in this range can affect all of the processes accessing data in the same database and may indicate that a database or object is damaged. Error messages with a severity level from 19 through 24 are written to the error log.
- 20: Indicates that a statement has encountered a problem. Because the problem has affected only the current task, it is unlikely that the database itself has been damaged.
- 21: Indicates that a problem has been encountered that affects all tasks in the current database, but it is unlikely that the database itself has been damaged.
- 22: Indicates that the table or index specified in the message has been damaged by a software or hardware problem. Severity level 22 errors occur rarely. If one occurs, run DBCC CHECKDB to determine whether other objects in the database are also damaged. The problem might be in the buffer cache only and not on the disk itself. If so, restarting the instance of the Database Engine corrects the problem. To continue working, you must reconnect to the instance of the Database Engine; otherwise, use DBCC to repair the problem. In some cases, you may have to restore the database. If restarting the instance of the Database Engine does not correct the problem, then the problem is on the disk. Sometimes destroying the object specified in the error message can solve the problem. For example, if the message reports that the instance of the Database Engine has found a row with a length of 0 in a nonclustered index, delete the index and rebuild it.
- 23: Indicates that the integrity of the entire database is in question because of a hardware or software problem. Severity level 23 errors occur rarely. If one occurs, run DBCC CHECKDB to determine the extent of the damage. The problem might be in the cache only and not on the disk itself. If so, restarting the instance of the Database Engine corrects the problem. To continue working, you must reconnect to the instance of the Database Engine; otherwise, use DBCC to repair the problem. In some cases, you may have to restore the database.
- 24: Indicates a media failure. The system administrator may have to restore the database. You may also have to call your hardware vendor.
Источник
Today, I got error 1105 on one of the database server. We were processing some bulk transactions on a database but failed because of space issue. Full description of error 1105 is given below.
Error 1105, Severity 17, State 2
Could not allocate space for object ‘Object_Name’ in database ‘DB_Name’ 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.
Error 1105 – Root Cause
As error suggests, this issue was generated because database was not able to allocate space anymore. Whenever you get such space issue, all transactions will be stopped until you make some room in the database. All transactions will be stopped because of non availability of space because none of the transaction will get any space to proceed their transactions. There are many reasons you can get space issues. Some of them are:
- Data or Log drive is full.
- Database file/s has restricted file growth
- Database File Autogrowth is not enabled.
- Some tables are growing faster than our prediction.
- Some long running transaction is eating all space.
We generally get error 1105 when any database including tempdb or any transaction log file get full and runs out of space. File growth restriction is also a possible reason you can get error 1105. Make sure to check all database files associated with your database to make sure there is no file growth restriction is set that is causing to generate this error. Sometimes when you restrict the file growth and the file size reached its limit, you may get this error message when trying insert / updates on database. I have explained multiple solutions to overcome this issue. Have a look at below section to get the solution of such space issues.
Solution
To fix this error we need to make space in the database so that all running transactions can execute and log their operations. We have multiple solutions to fix such issue based on the nature of the issues. Some of the solutions are given below:
- First you should check if any unwanted file is not there in data or log drive. Sometimes we placed backup files in data or log drive and forgot to delete it. Make sure to remove or move such unwanted files to make space for your database.
- If any of the database files have restricted file growth then you should immediately turn on autogrow feature of the data or log file. You can read below article to understand what should be the perfect value for autogrowth of a data or log file.
How to Enable Autogrowth and What should be the Best value for File Autogrowth?
- If size of your database file is limited to some value then make sure to extend the size of that file or I would suggest going with unrestricted growth. Read above attached article to get more about this.
- If your data or log drive is running out of space then you should add more files to the file group on different drive where you have enough space. You can use below command to add any data or log file to your desired drive. Make sure to change the drive path as per your correct path.
ALTER DATABASE Techyaz ADD FILE ( NAME = techyaz_Data3, FILENAME = 'F:MSSQLDATAtechyaz_DataFile3.ndf')
- We can also free disk space by dropping index or tables that are no longer needed. You can also consider data purging for unwanted tables or indexes.
- You can also consider moving some of the database files to different drive to make some space for your database.
I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.
Read More:
- Fix Error 1101: Could not allocate a new page for database
- Why should we Avoid Database Shrink Operation?
- Why should we always Disable Autoshrink property?
- Author
- Recent Posts
I am working as a Technical Architect in one of the top IT consulting firm. I have expertise on all versions of SQL Server since SQL Server 2000. I have lead multiple SQL Server projects like consolidation, upgrades, migrations, HA & DR. I love to share my knowledge. You can contact me on my social accounts for any consulting work.
Summary
Article Name
Fix Error 1105: Could not allocate space for object ‘Object_Name’ in database ‘DB_Name’ because the ‘Primary’ filegroup is full.
Description
Today, I got error 1105 on one of the database server. We were processing some bulk transactions on a database but failed because of space issue. Full description of error 1105 is given below. Error 1105, Severity 17, State 2
Could not allocate space for object ‘Object_Name’ in database ‘DB_Name’ 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.
|
