We have following version of SQL Server:
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)
Database mentioned is in simple recovery mode.
We have one process which is deleting data from database. It executes the following set of statements:
set deadlock_priority low
set rowcount 1000
delete from TestTableA with(PAGLOCK) where time>= DATEADD(ss, 1357686000, '19700101') and time< DATEADD(ss, 1357772400, '19700101')
set rowcount 0
checkpoint
I have been following transaction log during this deletion with dbcc sqlperf(logspace) and it grows as the deletion process.
In one moment, transaction log get full(I am not sure why, but this is not point of this issue), and database go down in recovery mode with following set of errors:
2015-04-02 08:33:06.01 spid89 Error: 9002, Severity: 17, State: 1.
2015-04-02 08:33:06.01 spid89 The transaction log for database 'TestDB' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
2015-04-02 08:33:07.03 spid89 Error: 9002, Severity: 17, State: 1.
2015-04-02 08:33:07.03 spid89 The transaction log for database 'TestDB' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
2015-04-02 08:33:07.03 spid89 Error: 3314, Severity: 21, State: 4.
2015-04-02 08:33:07.03 spid89 During undoing of a logged operation in database 'TestDB', an error occurred at log record ID (410:23344:114). Typically, the specific failure is logged previously as an error in the Windows Event Log service.
Restore the database or file from a backup, or repair the database.
2015-04-02 08:33:07.03 spid89 Database TestDB was shutdown due to error 9002 in routine 'XdesRMReadWrite::RollbackToLsn'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.
2015-04-02 08:33:07.03 spid89 Error: 9001, Severity: 21, State: 5.
2015-04-02 08:33:07.03 spid89 The log for database 'TestDB' is not available. Check the event log for related error messages. Resolve any errors and restart the database.
2015-04-02 08:33:07.03 spid89 Error: 3314, Severity: 21, State: 4.
2015-04-02 08:33:07.03 spid89 During undoing of a logged operation in database 'TestDB', an error occurred at log record ID (410:23944:196). Typically, the specific failure is logged previously as an error in the Windows Event Log service.
Restore the database or file from a backup, or repair the database.
2015-04-02 08:33:07.03 spid89 Error: 9001, Severity: 21, State: 1.
2015-04-02 08:33:07.03 spid89 The log for database 'TestDB' is not available. Check the event log for related error messages. Resolve any errors and restart the database.
2015-04-02 08:33:07.03 spid89 Error: 3314, Severity: 21, State: 5.
2015-04-02 08:33:07.03 spid89 During undoing of a logged operation in database 'TestDB', an error occurred at log record ID (410:22984:1). Typically, the specific failure is logged previously as an error in the Windows Event Log service.
Restore the database or file from a backup, or repair the database.
2015-04-02 08:33:10.38 spid35s Starting up database 'TestDB'.
2015-04-02 08:33:13.08 spid35s Recovery of database 'TestDB' (7) is 0% complete (approximately 158 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.
And then follows the sequence of database recovery.
The same behavior is for all databases on that server.
I have doing DBCC CHECKDB without any errors, run sqliosim to check hardware(disks) validity, also without errors.
My expectation would be that transaction log full error does not cause database to go into recovery mode.