July 28, 2004 at 12:25 pm
At my Company, I set up a Maintenence Plan to back up one of our Databases (quite large) prior to the monthend processing. This was to ensure if data needed prior to month end load, data would be avaialble. I can run this myself and it works fine, but as a scheduled job it received this error. Does anyone know the answer to this. Additional info is that I set the plan to delete any backup old than three months, which hasn't been reached yet.
Error received -
July 29, 2004 at 12:03 pm
I've had the very same error occur in the last couple of weeks - I spent some time on the Microsoft Website (Uncle Bill's Domain) and it seems that it relates to the ability of the server to take the database into single-user mode (which it allegedly needs to perform some maintenance tasks (integrity checks in my case)). On my SQL box, it seems that a BackupExec job runs under the NT System Account on the SQL's local OS - this is preventing single-user mode. We are currently looking to kill this BackupExec job for a couple of hours on a Sunday so that the integrity checks can be run. I hope this helps,
Diarmuid.
July 29, 2004 at 12:14 pm
July 29, 2004 at 2:14 pm
Have you checked the maint plan history to see where the failure occured and what may have been successful? I have found that it is very helpful on telling you what went wrong, which for me was usually a wrong setting. Try this article to see if it will help.
http://support.microsoft.com/default.aspx?scid=kb;en-us;288577
July 7, 2005 at 5:48 am
July 7, 2005 at 1:14 pm
Strangely enough - I have since deleted the job, re-created it (exactly the same tasks as before) and all is now running well.
Diarmuid
July 7, 2005 at 8:18 pm
Some days back, me too had the same error in my plan, and on my standby server i deleted some old backups, and then again restarted my job..it worked fine then..i believe it was due to lack of space but the error thrown is misleading..
July 8, 2005 at 8:43 am
I'm having the same problem during the optimization step of one on the db on a server. The server has 300 GB free space and nothing else is running at the time. All of the other db on this server have the same plans (run as the same user, backup to the same directory,) but they all work fine. Any ideas what I'm missing? Thanks.
July 11, 2005 at 9:06 am
July 14, 2005 at 2:13 am
Have a look on this link.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q288577
July 18, 2005 at 12:11 pm
I would personally never use a maint plan - always preferring to write the jobs in clear tsql - beware that sysmaint.exe works as an external process to sql server. Anyway in the maint plan setup there is an option to fix errors on checkdb - don't choose this as this dbcc command rightly needs exclusive single user mode to run - if you checked this box clear it and your maint plan should run.
Generally you need dbo rights to work on integrity / optimisation jobs ( and the agent service needs rights too ) Servers normally have local admin rights ( or close to ) for the server service account and agent service - this allows jobs to run and dbcc commands to run without error. Although it's not ideal to have your server as the local admin of its box you'll find most jobs/activities work much better!!
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 19, 2005 at 10:10 am
Any ideas?
September 14, 2005 at 11:17 am
Did anyone find a solution. I am getting this error, using log shipping, but in the log shipping maintenance job, the backups were successful. The error is coming when the standby server tries to restore the transaction logs. I have no idea what this error means
Thanks,
Aria
October 24, 2005 at 12:49 pm
I've this error on one of my full db backup job. Indeed the error msg didn't help much but I found it in ntevent viewer that my harddisk is full. So just wonder did you guys check the NTEvent log
James
November 10, 2005 at 3:22 am
I was having the same problem when I found this article:
http://support.microsoft.com/?kbid=303229
I am a backup-ignorant but it seems that when the recovery model is set to "simple", then it is not possible to backup the log db (probably because it would be useless). This is why the related scheduled job was failing while the same job for the db (and not the log) was working fine.
I think that the Enterprise Manager should check the recovery model used for the specific database and prevent users to try to backup the log while it is not possible.
Or, perhaps, I should read some books before playing with backups...
Thanks,
Paolo
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply