title | description | author | ms.author | ms.date | ms.service | ms.subservice | ms.topic | helpviewer_keywords |
---|---|---|---|---|---|---|---|---|
MSSQLSERVER_9004 |
MSSQLSERVER_9004 |
MashaMSFT |
mathoma |
04/04/2017 |
sql |
supportability |
reference |
9004 (Database Engine error) |
MSSQLSERVER_9004
[!INCLUDE SQL Server]
Details
Attribute | Value |
---|---|
Product Name | SQL Server |
Event ID | 9004 |
Event Source | MSSQLSERVER |
Component | SQLEngine |
Symbolic Name | LOG_CORRUPT |
Message Text | An error occurred while processing the log for database ‘%.*ls’. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log. |
Explanation
An error was encountered while processing the log during rollback, recovery, or replication. This could indicate an error detected by the operating system or an internal consistency error detected by [!INCLUDEssNoVersion].
The [!INCLUDEssDEnoversion] performs logical checks on the consistency of the transaction log contents as it reads and processes it. Not all aspects of the log header, log blocks, and log records are checked. The State number provides more information on the type of failure:
- State 1 The log file header of the Virtual Log File (VLF) was damaged. If a damaged log file header is found as part of starting up the database on service startup, you may only see Error 9004 in the ERRORLOG. The Log File Header is the first portion of each VLF inside of a transaction log. The log file header is a not the same as the single file header, or the first 8 KB, of the log file. If the file header of the log file is damaged, you may get Msg 5172, similar to a database-file header-page corruption.
- State 2 and 3 A log block was invalid when performing recovery during a RESTORE operation.
- State 4 through 12 These are all various checks on log blocks when processing log records. These including parity, sector, and other logical checks on the consistency of the transaction log
In most cases, this error is only seen in the ERRORLOG or Windows Application Event Log with EventID = 9004 because the operation processing the log is not based on a direct user command (such as recovery running when the SQL Server Engine starts). In these situations, error 9004 is often seen together with Error 3414. However, some queries such as ALTER DATABASE could require a processing of the log and therefore will see these errors. Since the error is at Severity=21, the user session is disconnected.
Cause
Error 9004 is a general error indicating the contents of the transaction log are damaged. The reason for the log to become inconsistent are similar to any database corruption problem detected by the SQL Server Engine. To find the cause for the log damage, you should follow similar techniques used for database corruption including an analysis of possible hardware, filesystem, and I/O problems. Note that DBCC CHECKDB does not check the transaction log as part of its operations and cannot detect log corruption errors. Error 9004 is raised by SQL Server Engine itself.
User Action
One of the following actions will correct this error:
-
Restore from a backup: Restore from a known good backup to recover from this problem. It is possible that, if the log portion of a database or log backup contains damaged contents, you encounter an Error 9004 on RESTORE. In this situation, the transaction log in the backup is damaged.
-
Rebuild the log: If you cannot restore from a backup, you may be able to bring the database online by rebuilding the transaction log. You should carefully understand the ramifications of rebuilding the transaction log. This includes possible loss of transactional consistency in your database. For more information on how to rebuild the transaction log, please see Resolving Errors in Database Emergency Mode.
-
Examine Logs for system issues: Also, check the System Event log and Errorlogs to identify issues within the system that may have caused the problem.
Table of Contents
- Introduction
- Root Cause of the Error
- What to do
- Restore from Backup
- Rebuild the Transaction Log
Introduction
Transaction logs in SQL database are the vital component consisting of all the changes a user makes in database. Moreover, user can undo the changes that he made in a file of the database using the information contained in the
transaction logs; this operation is also a transaction. It can be understood by the following:
You have made some changes in the data file of a database, say DB1, it means that a transaction is taking place. The log begins keeping record by the time you start making changes till you perform commit of that transaction. Note that a database consists
of minimum one data file and physical transaction log.
Now imagine that there is damage to transaction log, it will directly impact the database. If an operation is performed in SQL that requires processing or reading the transaction log, an error may occur similar to the following:
Error: 9004
An error occurred while processing the log for database. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log.
Root Cause of the Error
The error occurs in case of damage to contents of transaction log. The severity of the error is same as that of a database corruption. Therefore, for in-depth analysis of cause, the similar techniques should be applied that are required for database corruption.
What to do
Try out the following to work around this problem:
Restore from Backup
It is recommended to bring the backup into use. It might be the case that the backup of transaction log or its portion has created corruption in the contents of transaction log. In this case, Error 9004 may occur while restoring. It indicates that there
is damage to transaction log placed in the backup.
Rebuild the Transaction Log
If it is not possible to restore from the backup, you can rebuild the transaction log. However, you need to be aware of all positives and negatives of doing it so that you can avoid possible transactional consistency loss in the database. Furthermore, it
includes
DBCC CHECKDB command to execute.
However, you might not be able to carry out the task successfully or even if you do, it might not give the expected results. If so, you can use commercial SQL recovery application. Such applications are the programs built by software experts. More of it,
such software will perform recovery, which has been failed by DBCC CHECKDB command, it will also recover the database from suspect mode. You can also recover the database in case of severe damages.
- Remove From My Forums
-
Question
-
Hi,
i need to attach my db, but i receive this error:
an error occurred while processing the log for database ‘xyj’.
Could not open database ‘xyj’ . Create database is aborted. (Microsoft Sql Server,
error 9004).
Can you help me?
Answers
-
You have two options:
- You can create an empty database with the same name and physical file layout, shut down the server, swap in the files you want to attach in place of the empty DB files, and start the server. The database should come up in suspect mode. You can then ALTER DATABASE <foo> SET EMERGENCY to put it in emergency mode, and then run DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS. This will pull as much data as possible out of the log to make the database consistent, but may have to delete some data in order to make the database consistent. This is the option which is most likely to get the maximum data back.
- You can attempt to use the CREATE DATABASE FOR ATTACH_REBUILD_LOG to see if that will bring it back. If the database was cleanly shut down, you MIGHT be able to succeed. There is also the chance that the database will be inconsistent or corrupt if there are transactions which could not be rolled back. You should in any event run DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS to make your database consistent. In this event, SQL Server will make no attempt to mine information from the log. It will ignore the contents of the log. If there were transactions in process no rollback will be possible, so the ALLOW_DATA_LOSS will be required.
Summary:
When trying to attach a database in SQL Server, you may receive the error 9004. This error usually occurs due to corruption in database. In this article, we will show how to resolve this error. We will also mention a SQL repair tool that can help resolve the error by repairing the corrupt database.
In SQL Server, the database contains the data file with information of the tables, views, stored procedure, etc. and the transaction log files. The transaction log files store all the transactions and modifications. For example, if you update, insert, or delete data in the tables or views, these changes are stored in the transaction logs.
The SQL Server error 9004 is related to a problem with the transaction logs. The error indicates that the transaction log is corrupt. It can be a problem with the log file header or the Virtual Log File (VLF), which can be damaged. The corruption may occur due to unexpected server or service shutdown, hardware failure, virus or malware attacks, etc.
Let’s discuss how to resolve the SQL Server error 9004.
Solutions to Fix the SQL Server Error 9004
Here are some solutions you can try to resolve this error and recover the database.
Restore the Database using Backup
If you have a backup of your database, the best option is restore your database from the last backup.
For this, open SQL Server Management Studio (SSMS) and go to the Object Explorer pane. Right-click the database to backup and select Tasks > Back Up.
- In the Backup Database window, select the Full Backup type, the destination path, and then press OK.
- If you need to restore the data, in the Object Explorer, right-click the database and select the Restore Database option.
- In the Restore Database window, select the database to restore and select the backup sets to restore, and press OK.
Note: It is strongly recommended to press the Verify Backup Media button before restoring.
Use DBCC CHECKDB Command to Repair the Database
You use the DBCC CHECKDB command to repair the corrupt database.
Here’s the syntax:
USE master;
ALTER DATABASE Adventurewords2019 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB (Adventurewords2019, REPAIR_FAST) WITH NO_INFOMSGS;
GO
ALTER DATABASE Adventurewords2019 SET MULTI_USER;
GO
You need to first set the database in single-user mode. This mode will log out other users of the database. Then, run the CHECKDB command to repair the database.
After repairing the database, you can set the database to multi-user mode to allow other users to access the restored database again.
If the REPAIR_FAST command fails, in the DBCC CHECKDB command, you can try the following options:
- REPAIR_REBUILD: It will try to rebuild the database.
- REPAIR_ALLOW_DATA_LOSS: It repairs the database but you may lose some data.
Use CREATE DATABASE Command with FOR ATTACH_REBUILD_LOG
There is an option in SQL Server to create the database and rebuild the transaction log file. The syntax to rebuild the database is:
USE [master]
GO
CREATE DATABASE [AdventureWorks2019] ON
( FILENAME = N’c:dataadventureworks2019.mdf’ )
FOR ATTACH_REBUILD_LOG
GO
First, you need to go to the master database. Then, create the database and rebuild the corrupt log.
Use a Third-Party SQL Repair Software
You can use a third-party SQL repair software, such as Stellar Repair for MS SQL. This software can repair corrupt databases without any data loss.
The software is simple to use. You need to first find the data file.
Note: Make sure that your database is offline before using the software.
To find your data file, open Stellar Repair for MS SQL and press the Find button.
- To find your data file, you can open the Stellar Repair for MS SQL and press the Find button.
- Select the database file and press the Repair button to start the repair process.
Once the repair process is finished, you can export the repaired data to a SQL Server database or various other formats, such as Excel, CSV, HTML, etc.
Conclusion
The SQL Server 9004 error usually occurs due to corruption in transaction logs or database. In this article, we learned how to fix this error. You can restore the database from the backup or use the DBCC CHECKDB commands to repair and recover the database. However, for quick and easy recovery of the database, use a specialized SQL repair tool, such as Stellar Repair for MS SQL.
About The Author
Bharat Bhushan
Bharat Bhushan is an experienced technical Marketer working at Stellar Data Recovery — expertise in data care. He is skilled in Microsoft Exchange Database, MSSQL Database troubleshooting & data warehousing. He is a Management Post Graduate having a strong grip in Technology & certified in SAP-SD, Oracle 10g & Informatica Powercenter 9.1.
ERROR : 9004 An error occurred while processing the log for database.
If possible, restore from backup.
If a backup is not available, it might be necessary to rebuild the log.
If you receive above error it means you are in great trouble. This error occurs when database is attempted to attach and it does not get attached. I have solved this error using following methods. Hope this will help anybody who is facing the same error.
Microsoft suggest there are two solution to this problem.
1) Restore from a backup.
- Create Empty Database with same name and physical files (.ldf and .mdf).
- Shut down SQL Server.
- Replace the files which you want to attach with this new empty database files.
- Start SQL Server.
- Database will be in suspect mode which means so far everything going as it should be.
- Next is to put database in emergency mode. ALTER DATABASE <DatabaseName> SET EMERGENCY will change the database status to emergency.
- A database which is in emergency mode can be repaired with allowing some data loss. DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS will do the task.
- In this process some of the data may be lost but database will in working condition with most of the data retrieved from log.
2) Rebuild the log.
- Create database using CREATE DATABASE FOR ATTACH_REBUILD_LOG.
- This may fix the problem right away if database which is attempted to be attach is shut down properly. If database is corrupt it will be not restored correctly.
- Next DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS should be ran to bring back the database operational. This may loose some data but it may bring back database in working condition.
- In this option as log is rebuilt SQL Server does not use log file to retrieve any data. In this process none of the log operation like transaction rollback will work.
I prefer to use the first method if it works. First method has worked sevral time without any issue. Syntax of the CREATE database can be found on Book Online for further guidance.
Reference : Pinal Dave (https://blog.sqlauthority.com)