Backup Logs [*] throws errors with databases in SIMPLE mode

KatanaCS · February 1, 2008 9:09PM

Hi,

We recently implemented SQLBackup v5.2.0.2825 to a series of servers containing hundreds of small databases, and almost everything is working fine. We're using Full backups every night, and Log backups every 15 minutes. For both, we use the "Backup Databases|Logs [*]" command.

Over the past 2 days, one database (our dba admin database) has been throwing sporadic errors:
SQL Backup log file 5.2.0.2825
2/1/2008 4:45:00 PM: Backing up dbadmin (transaction log) to:
2/1/2008 4:45:00 PM: d:\MSSQL\Backup\dbadmin\LOG_dbadmin_20080201164500.sqb

2/1/2008 4:45:00 PM: BACKUP LOG [dbadmin] TO DISK = '<AUTO>' WITH NAME = '<AUTO>', DESCRIPTION = '<AUTO>', INIT, ERASEFILES = 2, MAILTO_ONERROR = '<<emailaddressreplaced>>', COPYTO = '\\<<servernamereplaced>>\SQLBackup$\<SERVER>\<DATABASE>\', LOGTO = 'D:\MSSQL\Backup\\_LogFiles', FILEOPTIONS = 1, COMPRESSION = 1

2/1/2008 4:45:31 PM: VDI error 1010: Failed to get configuration from server. Check that the SQL Server instance is running, and that you have the SQL Server Systems Administrator server role. Error code: (-2139684861: The api was waiting and the timeout interval had elapsed.)
2/1/2008 4:45:31 PM: SQL error 3013: BACKUP LOG is terminating abnormally.
2/1/2008 4:45:31 PM: SQL error 4208: The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE.

The database has been in SIMPLE mode all along, and while the backup logs job runs every 15 minutes, this error is not being thrown every time. The job has run 72 times today (every 15 minutes from 12am-6pm), and only 12 times so far has this error been thrown. All of the instances of the job write a log file, and in the other logs, this database isn't even shown as being attempted to have the backup run. There seems to be no pattern to the failures; hours will go by with none, and sometimes there are 2 per hour.

Any help with this would be greatly appreciated.

Thanks!

Chris Auckland · February 3, 2008 11:11PM

Thanks for your post.

Due to the nature of the simply recovery model, it is not possible to take a transaction log backup while the database is in simple recovery mode.
For reference:
SQL 2000: http://msdn2.microsoft.com/en-us/librar ... 551(SQL.80).aspx
SQL 2005: http://msdn2.microsoft.com/en-us/librar ... 0.aspx?s=1

This is why the backup failed. However, it is quite curious that the backup works most of the time time, but fails with this error on occasion.

I would suspect that you may have a maintenance plan or other job that changes the recovery model of certain databases to SIMPLE for whatever reason. After this occurs the t-log backup jobs for those databases will fail.

Check the jobs that you have running on that server, they should hopefully explain why this is happening. Please note that you will need to run a full backup to switch to full recovery mode after you have made the change through EM or SSMS.

Let me know what you find.

petey · February 4, 2008 3:45AM

When run BACKUP LOGS [*] ..., SQL Backup runs a command at the beginning of the backup process to pick up all databases that are running in FULL or BULK-LOGGED recovery models. It then backs up the transaction logs of these databases.

It would appear that the database in question had its recovery model set to something other than simple when SQL Backup ran the 'discovery' command, and the recovery model was switched back to simple before SQL Backup attempted to back up the transaction log of that database.

Would it be possible to run a trace on the ALTER DATABASE command, to see if this was indeed happenning? Thanks.

KatanaCS · February 4, 2008 2:32PM

Thanks for the response guys.

Chris, to your point about the database being in simple recovery and no logs can be taken, I'm aware of that. However, I'm using the "BACKUP LOGS [*]" command, which per the SQLBackup help file states:
"A single wildcard character can be used. For example:

BACKUP LOGS [*]

This backs up transaction logs for all databases that are currently online, operational, and using the FULL or BULK-LOGGED recovery models."

I take it to mean this skips databases in SIMPLE recovery, which Petey confirms.

Petey - Thanks, I triple-checked everything, and it's not the case. If anything were changing that database option, it would show in the log:

2008-02-04 10:50:02.49 spid51 Setting database option RECOVERY to SIMPLE for database dbadmin.

and there are no records of this. Here's a snippet:
2008-02-03 21:00:01.46 Backup Log was backed up. Database: LogShip_Test, creation date(time): 2007/11/20(20:04:46), first LSN: 1705:1194:1, last LSN: 1705:1194:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_7864D60A-6A9E-41CB-9159-F81B74601317'}). This is an informational message only. No user action is required.
2008-02-03 21:00:11.51 Backup Log was backed up. Database: XXXXAdmin, creation date(time): 2006/12/05(03:05:36), first LSN: 57633:2565:1, last LSN: 57633:2611:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_188CA3CC-B50B-4B77-A543-6528734D451C'}). This is an informational message only. No user action is required.
2008-02-03 21:00:24.07 Backup Log was backed up. Database: XXXXAdminMaster, creation date(time): 2006/12/04(23:02:59), first LSN: 145073:397:1, last LSN: 145073:415:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_5455CC69-8F00-4958-A232-7AF5586D189F'}). This is an informational message only. No user action is required.
2008-02-03 21:00:33.89 Backup Log was backed up. Database: XXXXCore, creation date(time): 2006/08/29(00:22:15), first LSN: 297811:434:1, last LSN: 297811:1267:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_29292649-463A-42A4-879C-46CB5A44E02A'}). This is an informational message only. No user action is required.
2008-02-03 21:00:49.36 Backup Log was backed up. Database: XXXXCoreMaster, creation date(time): 2006/08/30(23:19:17), first LSN: 321108:1110:1, last LSN: 321108:1274:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_D3C78A0A-1E41-4E4B-9733-2CB9190DBC4E'}). This is an informational message only. No user action is required.
2008-02-03 21:01:02.45 Backup Log was backed up. Database: XXXXJournal, creation date(time): 2006/09/15(14:59:02), first LSN: 3180:9115:1, last LSN: 3180:9115:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_88BF68B0-7B19-452D-9060-A50196CA9304'}). This is an informational message only. No user action is required.
2008-02-03 21:01:15.29 Backup Log was backed up. Database: XXXXManagement, creation date(time): 2006/08/29(00:04:09), first LSN: 86939:13279:1, last LSN: 86940:4760:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_03322C9B-71AA-4F68-8B8C-EA0F283DC094'}). This is an informational message only. No user action is required.
2008-02-03 21:15:00.94 Backup Log was backed up. Database: LogShip_Test, creation date(time): 2007/11/20(20:04:46), first LSN: 1705:1194:1, last LSN: 1705:1194:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_4DC02FBD-B9C8-4580-A623-37C798F706C6'}). This is an informational message only. No user action is required.
2008-02-03 21:15:10.72 Backup Log was backed up. Database: XXXXAdmin, creation date(time): 2006/12/05(03:05:36), first LSN: 57633:2611:1, last LSN: 57633:2841:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_3F31DBB1-CE2C-4855-AEE0-27C4930612A3'}). This is an informational message only. No user action is required.
2008-02-03 21:15:23.88 Backup Log was backed up. Database: XXXXAdminMaster, creation date(time): 2006/12/04(23:02:59), first LSN: 145073:415:1, last LSN: 145073:436:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_19C7838C-3F8E-40A7-9C96-1ABC17A63532'}). This is an informational message only. No user action is required.
2008-02-03 21:15:34.00 Backup Log was backed up. Database: XXXXCore, creation date(time): 2006/08/29(00:22:15), first LSN: 297811:1267:1, last LSN: 297811:2092:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_3853CFE0-A40E-4613-B43B-1B138AF6D88E'}). This is an informational message only. No user action is required.
2008-02-03 21:15:49.27 Backup Log was backed up. Database: XXXXCoreMaster, creation date(time): 2006/08/30(23:19:17), first LSN: 321108:1274:1, last LSN: 321108:1500:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_A1BE8B9A-777F-450E-9EA3-A62E4B5FA92C'}). This is an informational message only. No user action is required.
2008-02-03 21:16:03.58 Backup Log was backed up. Database: XXXXJournal, creation date(time): 2006/09/15(14:59:02), first LSN: 3180:9115:1, last LSN: 3180:9115:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_2EAF6E64-D690-4638-910C-DAB7D71CF42C'}). This is an informational message only. No user action is required.
2008-02-03 21:16:16.71 Backup Log was backed up. Database: XXXXManagement, creation date(time): 2006/08/29(00:04:09), first LSN: 86940:4760:1, last LSN: 86940:12989:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_443502BE-E3C8-4650-9918-80091BD40906'}). This is an informational message only. No user action is required.
2008-02-03 21:30:01.20 Backup Log was backed up. Database: LogShip_Test, creation date(time): 2007/11/20(20:04:46), first LSN: 1705:1194:1, last LSN: 1705:1194:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_B2939615-6457-421F-8D3D-640CBA36B0EC'}). This is an informational message only. No user action is required.
2008-02-03 21:30:10.19 Backup Log was backed up. Database: XXXXAdmin, creation date(time): 2006/12/05(03:05:36), first LSN: 57633:2841:1, last LSN: 57633:2902:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_35F07FAC-9D42-4846-981A-7288E4F79793'}). This is an informational message only. No user action is required.
2008-02-03 21:30:23.48 Backup Log was backed up. Database: XXXXAdminMaster, creation date(time): 2006/12/04(23:02:59), first LSN: 145073:436:1, last LSN: 145073:443:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_D86598DD-8037-4351-A85A-0996082E0A44'}). This is an informational message only. No user action is required.
2008-02-03 21:30:33.48 Backup Log was backed up. Database: XXXXCore, creation date(time): 2006/08/29(00:22:15), first LSN: 297811:2092:1, last LSN: 297812:263:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_D4E86490-AF1B-4FDF-8ED0-0DC29651E21B'}). This is an informational message only. No user action is required.
2008-02-03 21:30:48.77 Backup Log was backed up. Database: XXXXCoreMaster, creation date(time): 2006/08/30(23:19:17), first LSN: 321108:1500:1, last LSN: 321108:1571:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_B8BCD257-3F6A-483B-85DE-C0D18104394E'}). This is an informational message only. No user action is required.
2008-02-03 21:31:02.18 Backup Log was backed up. Database: XXXXJournal, creation date(time): 2006/09/15(14:59:02), first LSN: 3180:9115:1, last LSN: 3180:9115:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_3E19E3BA-23B7-4F6C-A2D3-6ADC6B9FC0C6'}). This is an informational message only. No user action is required.
2008-02-03 21:31:14.55 Backup Log was backed up. Database: XXXXManagement, creation date(time): 2006/08/29(00:04:09), first LSN: 86940:12989:1, last LSN: 86941:3214:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_A06E6BE7-A5A7-4252-9627-E36DC8CE02D5'}). This is an informational message only. No user action is required.
2008-02-03 21:45:01.26 Backup Error: 3041, Severity: 16, State: 1.
2008-02-03 21:45:01.26 Backup BACKUP failed to complete the command BACKUP LOG dbadmin. Check the backup application log for detailed messages.
2008-02-03 21:45:31.59 Backup Error: 3041, Severity: 16, State: 1.
2008-02-03 21:45:31.59 Backup BACKUP failed to complete the command BACKUP LOG distribution. Check the backup application log for detailed messages.
2008-02-03 21:46:01.92 Backup Log was backed up. Database: LogShip_Test, creation date(time): 2007/11/20(20:04:46), first LSN: 1705:1194:1, last LSN: 1705:1194:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_B38DD142-DDC4-40FE-9485-65159156C087'}). This is an informational message only. No user action is required.
2008-02-03 21:46:10.95 Backup Log was backed up. Database: XXXXAdmin, creation date(time): 2006/12/05(03:05:36), first LSN: 57633:2902:1, last LSN: 57633:2946:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_3646BC4A-ADED-4634-9396-44F90A9E4E69'}). This is an informational message only. No user action is required.
2008-02-03 21:46:24.09 Backup Log was backed up. Database: XXXXAdminMaster, creation date(time): 2006/12/04(23:02:59), first LSN: 145073:443:1, last LSN: 145073:443:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_E9C2032B-5791-4CBA-88D0-4EA9074F0452'}). This is an informational message only. No user action is required.
2008-02-03 21:46:34.15 Backup Log was backed up. Database: XXXXCore, creation date(time): 2006/08/29(00:22:15), first LSN: 297812:263:1, last LSN: 297812:882:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_9C41F653-238D-44A0-846D-AA030214C51D'}). This is an informational message only. No user action is required.
2008-02-03 21:46:49.26 Backup Log was backed up. Database: XXXXCoreMaster, creation date(time): 2006/08/30(23:19:17), first LSN: 321108:1571:1, last LSN: 321108:1668:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_1B25A969-D9CE-4BF6-A386-E13B45AAA183'}). This is an informational message only. No user action is required.
2008-02-03 21:47:02.12 Backup Log was backed up. Database: XXXXJournal, creation date(time): 2006/09/15(14:59:02), first LSN: 3180:9115:1, last LSN: 3180:9115:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_689B0886-1177-4B4E-A644-4E6DD4EF8095'}). This is an informational message only. No user action is required.
2008-02-03 21:47:13.89 Backup Log was backed up. Database: XXXXManagement, creation date(time): 2006/08/29(00:04:09), first LSN: 86941:3214:1, last LSN: 86941:11885:1, number of dump devices: 1, device information: (FILE=1, TYPE=VIRTUAL_DEVICE: {'SQLBACKUP_B92AE5F0-06C0-40B9-956A-53AAE1EB37E4'}). This is an informational message only. No user action is required.

The BACKUP LOGS [*] command runs every 15 minutes, so in this case there were 3 successful executions, followed by an instance attempting to backup the log in dbadmin. The snippet is contiguous, I left nothing out, so you can see there were no recorded instances of an ALTER DATABASE statement.

One thing to note, this server is a publisher and distributor, and the distribution database is also experiencing this issue.

petey · February 5, 2008 1:01AM

Could you please add a job step containing the following script to the backup job?

USE tempdb
IF OBJECT_ID&#40;'##sqbdebug'&#41; IS NOT NULL
	INSERT INTO ##sqbdebug SELECT GETDATE&#40;&#41; refdate, status FROM master..sysdatabases WHERE name = 'dbadmin'
ELSE
	SELECT GETDATE&#40;&#41; refdate, status INTO ##sqbdebug FROM master..sysdatabases WHERE name = 'dbadmin'

USE master

Please let me know the 'status' value when no error occurs, and when the error does occur. Thanks.

KatanaCS · February 5, 2008 1:48PM

Ok, I've added the query as step 1. The next time it fails I'll pull the values from the temp table.

KatanaCS · February 5, 2008 8:08PM

I don't believe I didn't realize this until it happened :roll: ... that query won't work, since the table is automatically cleaned up after the job completes, since there's no longer a reference to it. I changed the code to create a permanent object, so now it will capture and remain. :P

petey · February 5, 2008 9:03PM

Good point, I forgot about that.

KatanaCS · February 13, 2008 1:52PM

I don't know what happened, but since I added that step, the job took 6 days to encounter another failure, instead of the numerous times per day. Here's the data in that table:
status | count
4259848 | 745

petey · February 14, 2008 2:18AM

You mean that the status value did not change at all, both when SQL Backup ignored that database and when it chose that database, to perform a transaction log backup?

Could you please add another column to the log table to store the recovery model as returned by SQL Server e.g.

SELECT GETDATE() refdate, status, DATABASEPROPERTYEX('dbadmin', 'recovery') FROM master..sysdatabases WHERE name = 'dbadmin'

Thanks.

KatanaCS · February 14, 2008 1:39PM

Correct, the status value didn't change, which supports why it didn't show in the SQL error log.

I've added the extra column.

KatanaCS · February 15, 2008 5:26PM

Ok, we have an error again:

SQL Backup log file 5.2.0.2825
2/15/2008 2:15:00 PM: Backing up dbadmin (transaction log) to:
2/15/2008 2:15:00 PM: d:\MSSQL\Backup\dbadmin\LOG_dbadmin_20080215141500.sqb

2/15/2008 2:15:00 PM: BACKUP LOG [dbadmin] TO DISK = '<AUTO>' WITH NAME = '<AUTO>', DESCRIPTION = '<AUTO>', INIT, ERASEFILES = 5, MAILTO_ONERROR = '<<emailaddress>>', COPYTO = '\\<<servername>>\SQLBackup$\<SERVER>\<DATABASE>\', LOGTO = 'D:\MSSQL\Backup\\_LogFiles', FILEOPTIONS = 1, COMPRESSION = 1

2/15/2008 2:15:30 PM: VDI error 1010: Failed to get configuration from server. Check that the SQL Server instance is running, and that you have the SQL Server Systems Administrator server role. Error code: (-2139684861: The api was waiting and the timeout interval had elapsed.)
2/15/2008 2:15:30 PM: SQL error 3013: BACKUP LOG is terminating abnormally.
2/15/2008 2:15:30 PM: SQL error 4208: The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE.

And here are the most recent results from the debug table:
refdate status recoverymodel
2008-02-15 14:15:00.213 4259848 SIMPLE
2008-02-15 14:00:01.300 4259848 SIMPLE

KatanaCS · February 20, 2008 2:02PM

Just wanted to bump this one, it's still happening.

petey · February 21, 2008 12:43AM

I do not know the cause of the problem, as all the status and recovery values seem ok.

Could you pls download a debug copy of SQBCoreService.exe from here:

http://www.yohz.com/downloads/SQBCoreService_6397.zip

Stop the SQL Backup Agent service, replace the existing SQBCoreService.exe with the one in this archive (preferably rename the existing one), and restart the service.

Everytime SQL Backup encounters a BACKUP LOGS [*] statement, it now logs the database list it uses internally to a file named SQBCoreService_log.txt, which is created in the SQL Backup folder.

The next time the error occurs, please send me that file, together with the time of the error. Thanks.

KatanaCS · February 21, 2008 1:24PM

Ok, I have the new EXE in place.

Thanks for the help!

KatanaCS · February 21, 2008 2:25PM

Just got an error, and here are the last two sessions worth of data from the log file:

2/21/2008 10:45:01 AM : dbadmin:SIMPLE:0:0
2/21/2008 10:45:01 AM : distribution:SIMPLE:0:0
2/21/2008 10:45:01 AM : LogShip_Test:BULK_LOGGED:0:0
2/21/2008 10:45:01 AM : master:SIMPLE:0:0
2/21/2008 10:45:01 AM : model:SIMPLE:0:0
2/21/2008 10:45:01 AM : msdb:SIMPLE:0:0
2/21/2008 10:45:01 AM : tempdb:SIMPLE:0:0
2/21/2008 10:45:01 AM : ThrivaAdmin:BULK_LOGGED:0:0
2/21/2008 10:45:01 AM : ThrivaAdminMaster:BULK_LOGGED:0:0
2/21/2008 10:45:01 AM : ThrivaCore:BULK_LOGGED:0:0
2/21/2008 10:45:01 AM : ThrivaCoreMaster:BULK_LOGGED:0:0
2/21/2008 10:45:01 AM : ThrivaJournal:BULK_LOGGED:0:0
2/21/2008 10:45:01 AM : ThrivaManagement:BULK_LOGGED:0:0
2/21/2008 11:00:01 AM : dbadmin::0:
2/21/2008 11:00:01 AM : distribution::0:
2/21/2008 11:00:01 AM : LogShip_Test:BULK_LOGGED:0:0
2/21/2008 11:00:01 AM : master:SIMPLE:0:0
2/21/2008 11:00:01 AM : model:SIMPLE:0:0
2/21/2008 11:00:01 AM : msdb:SIMPLE:0:0
2/21/2008 11:00:01 AM : tempdb:SIMPLE:0:0
2/21/2008 11:00:01 AM : ThrivaAdmin::0:
2/21/2008 11:00:01 AM : ThrivaAdminMaster::0:
2/21/2008 11:00:01 AM : ThrivaCore:BULK_LOGGED:0:0
2/21/2008 11:00:01 AM : ThrivaCoreMaster::0:
2/21/2008 11:00:01 AM : ThrivaJournal::0:
2/21/2008 11:00:01 AM : ThrivaManagement::0:

It would seem the recovery model value wasn't captured on the run with the error.

petey · February 21, 2008 7:32PM

Thanks for the details, I'll have to find out what's going wrong.

Could you please revert to the original SQBCoreService.exe? Thanks.

petey · February 27, 2008 5:37AM

Could you please download another debug copy of the service app from here: http://www.yohz.com/downloads/SQBCoreService_6397b.zip, and replace the existing one with this?

This copy logs a couple of additional values. Please post details of the last couple of runs as you did previously, when the error next happens.

Thanks, and I apologize for troubling you such but I can't figure out what's going wrong.

KatanaCS · February 27, 2008 2:03PM

Ok, I've put this into place.

It's no trouble, it's obviously some odd hidden bug, such as "if it's Tuesday and it's raining, do something obscure ...". I'm just glad you guys are so responsive! 8)

KatanaCS · February 27, 2008 2:33PM

Here's the output from the file:

2/27/2008 11:00:01 AM : dbadmin:SIMPLE:4259848:4259848:0:0
2/27/2008 11:00:01 AM : distribution:SIMPLE:65544:65544:0:0
2/27/2008 11:00:01 AM : LogShip_Test:BULK_LOGGED:4259844:4259844:0:0
2/27/2008 11:00:01 AM : master:SIMPLE:65544:65544:0:0
2/27/2008 11:00:01 AM : model:SIMPLE:4259848:4259848:0:0
2/27/2008 11:00:01 AM : msdb:SIMPLE:65544:65544:0:0
2/27/2008 11:00:01 AM : tempdb:SIMPLE:8:8:0:0
2/27/2008 11:00:01 AM : ThrivaAdmin:BULK_LOGGED:20:20:0:0
2/27/2008 11:00:01 AM : ThrivaAdminMaster:BULK_LOGGED:4194324:4194324:0:0
2/27/2008 11:00:01 AM : ThrivaCore:BULK_LOGGED:20:20:0:0
2/27/2008 11:00:01 AM : ThrivaCoreMaster:BULK_LOGGED:20:20:0:0
2/27/2008 11:00:01 AM : ThrivaJournal:BULK_LOGGED:65540:65540:0:0
2/27/2008 11:00:01 AM : ThrivaManagement:BULK_LOGGED:20:20:0:0
2/27/2008 11:00:33 AM : dbadmin:SIMPLE:4259848:4259848:0:0
2/27/2008 11:00:33 AM : distribution:SIMPLE:65544:65544:0:0
2/27/2008 11:00:33 AM : LogShip_Test:BULK_LOGGED:4259844:4259844:0:0
2/27/2008 11:00:33 AM : master:SIMPLE:65544:65544:0:0
2/27/2008 11:00:33 AM : model:SIMPLE:4259848:4259848:0:0
2/27/2008 11:00:33 AM : msdb:SIMPLE:65544:65544:0:0
2/27/2008 11:00:33 AM : tempdb:SIMPLE:8:8:0:0
2/27/2008 11:00:33 AM : ThrivaAdmin:BULK_LOGGED:20:20:0:0
2/27/2008 11:00:33 AM : ThrivaAdminMaster:BULK_LOGGED:4194324:4194324:0:0
2/27/2008 11:00:33 AM : ThrivaCore:BULK_LOGGED:20:20:0:0
2/27/2008 11:00:33 AM : ThrivaCoreMaster:BULK_LOGGED:20:20:0:0
2/27/2008 11:00:33 AM : ThrivaJournal:BULK_LOGGED:65540:65540:0:0
2/27/2008 11:00:33 AM : ThrivaManagement:BULK_LOGGED:20:20:0:0
2/27/2008 11:15:01 AM : dbadmin:SIMPLE:4259848:4259848:0:0
2/27/2008 11:15:01 AM : distribution:SIMPLE:65544:65544:0:0
2/27/2008 11:15:01 AM : LogShip_Test:BULK_LOGGED:4259844:4259844:0:0
2/27/2008 11:15:01 AM : master:SIMPLE:65544:65544:0:0
2/27/2008 11:15:01 AM : model:SIMPLE:4259848:4259848:0:0
2/27/2008 11:15:01 AM : msdb:SIMPLE:65544:65544:0:0
2/27/2008 11:15:01 AM : tempdb:SIMPLE:8:8:0:0
2/27/2008 11:15:01 AM : ThrivaAdmin:BULK_LOGGED:20:20:0:0
2/27/2008 11:15:01 AM : ThrivaAdminMaster:BULK_LOGGED:4194324:4194324:0:0
2/27/2008 11:15:01 AM : ThrivaCore:BULK_LOGGED:20:20:0:0
2/27/2008 11:15:01 AM : ThrivaCoreMaster:BULK_LOGGED:20:20:0:0
2/27/2008 11:15:01 AM : ThrivaJournal:BULK_LOGGED:65540:65540:0:0
2/27/2008 11:15:01 AM : ThrivaManagement:BULK_LOGGED:20:20:0:0
2/27/2008 11:30:01 AM : dbadmin::4259848:-1:0:
2/27/2008 11:30:01 AM : distribution::65544:-1:0:
2/27/2008 11:30:01 AM : LogShip_Test:BULK_LOGGED:4259844:4259844:0:0
2/27/2008 11:30:01 AM : master:SIMPLE:65544:65544:0:0
2/27/2008 11:30:01 AM : model:SIMPLE:4259848:4259848:0:0
2/27/2008 11:30:01 AM : msdb:SIMPLE:65544:65544:0:0
2/27/2008 11:30:01 AM : tempdb:SIMPLE:8:8:0:0
2/27/2008 11:30:01 AM : ThrivaAdmin::20:-1:0:
2/27/2008 11:30:01 AM : ThrivaAdminMaster::4194324:-1:0:
2/27/2008 11:30:01 AM : ThrivaCore:BULK_LOGGED:20:20:0:0
2/27/2008 11:30:01 AM : ThrivaCoreMaster::20:-1:0:
2/27/2008 11:30:01 AM : ThrivaJournal::65540:-1:0:
2/27/2008 11:30:01 AM : ThrivaManagement::20:-1:0:

petey · March 3, 2008 3:45AM

Could you please download this copy (http://www.yohz.com/downloads/SQBCoreService_6397c.zip) and let me know if the error still occurs?

Thanks.

KatanaCS · March 3, 2008 1:31PM

Ok, I replaced it and ran to test, but it's no longer writing to SQBCoreService_log.txt; is it supposed to?

petey · March 4, 2008 12:26AM

No, that version will not create a SQBCoreService_log.txt file. Thanks.

KatanaCS · March 18, 2008 5:48PM

Well, it's been 2 weeks since I started using the new EXE and we haven't had an error on that server. Looks like it worked!

I have a number of other servers where the error is happening; what are my next steps for fixing those? Should I put this version into place and wait for a future release, or something else?

Thanks!!

petey · March 18, 2008 8:05PM

The next release will contain that fix. The copy that you have, SQBCoreService_6397c.zip, is not an official release but a patch version that has not undergone the full regression tests. It is up to you if you want to use it.

I do not have an estimated release date for the next version.

Thanks.

KatanaCS · March 19, 2008 2:22PM

Yeah, had a hunch that was the case. 8)

Thanks for all your help!!

wayneph · July 22, 2008 12:15PM

I am having a similar issue on one of my SQL 2005 Servers. We have databases that are in SIMPLE recovery occasionally attempt to perform LOG backups.

One slight difference is that we use BACKUP LOG EXCLUDE '...' where we explitly exclude a few databases that are on a separate plan. Since it works most of the time, I assume that it should work similar to the BACKUP LOG [*] command regarding SIMPLE databases that aren't explicitly excluded. I have double checked our DDL triggers and there haven't been any ALTER DATABASE commands run that would change the Recovery Model.

We are currently running on version 5.3.0.178. We're getting all of the backups we need, but it's a pain having to go out and look at the failures just to see that it fails on a database it shouldn't have even attempted.

Is there a new version that already includes this fix, or any word on when the next version will be released?

Thanks.

petey · July 23, 2008 2:13AM

You can download a version that addresses this issue from here. Run the SQL Backup server components installer on the affected servers.

Andrew Hodge · August 29, 2008 10:33AM

Just experienced this issue as well. Is the fixed version listed here supported?

petey · August 29, 2008 12:38PM

Is the fixed version listed here supported?

Yes it is.

Backup Logs [*] throws errors with databases in SIMPLE mode

Comments

Product Learning

Community Forums

Events & Friends

Simple Talk