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

KatanaCSKatanaCS Posts: 24 Bronze 2
edited August 29, 2008 12:38PM in SQL Backup Previous Versions
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

Comments

  • 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.
    Chris
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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.
    Chris
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    Ok, I've added the query as step 1. The next time it fails I'll pull the values from the temp table.
    Chris
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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
    Chris
  • peteypetey Posts: 2,358 New member
    Good point, I forgot about that.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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
    Chris
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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.
    Chris
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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
    Chris
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    Just wanted to bump this one, it's still happening.
    Chris
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    Ok, I have the new EXE in place.

    Thanks for the help!
    Chris
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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.
    Chris
  • peteypetey Posts: 2,358 New member
    Thanks for the details, I'll have to find out what's going wrong.

    Could you please revert to the original SQBCoreService.exe? Thanks.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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)
    Chris
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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:
    Chris
  • peteypetey Posts: 2,358 New member
    Could you please download this copy (http://www.yohz.com/downloads/SQBCoreService_6397c.zip) and let me know if the error still occurs?

    Thanks.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    Ok, I replaced it and ran to test, but it's no longer writing to SQBCoreService_log.txt; is it supposed to?
    Chris
  • peteypetey Posts: 2,358 New member
    No, that version will not create a SQBCoreService_log.txt file. Thanks.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    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!!
    Chris
  • peteypetey Posts: 2,358 New member
    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.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • KatanaCSKatanaCS Posts: 24 Bronze 2
    Yeah, had a hunch that was the case. 8)

    Thanks for all your help!!
    Chris
  • 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.
    --wayne
  • peteypetey Posts: 2,358 New member
    You can download a version that addresses this issue from here. Run the SQL Backup server components installer on the affected servers.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • Just experienced this issue as well. Is the fixed version listed here supported?
  • peteypetey Posts: 2,358 New member
    Is the fixed version listed here supported?
    Yes it is.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
Sign In or Register to comment.