Solving a nasty restore problem (OWSTIMER issue)
Posted by Christian Dam on September 26, 2008
I am not a big fan of the built-in back/restore tool in SharePoint, but I am more or less forced to use it for the following reasons
- some of the customers I work for are using it while they are getting to know SharePoint
- Data Protection Manager 2007 is not perfect either – and not all customers are looking at tools like DocAve/AvePoint
- even the guys in the newly released book Microsoft Office SharePoint 2007 Best Practices are saying good things about it, so who am I to argue
Anyway, to help our customers getting started, I have written a script that fix some of the short commings in the built-in back/restore tool and am thus using it a a few customer sites. So far so good.
This week one the customers were testing the restore procedures and ran into the following problem which turned out to be very tricky to solve.
Restoring a web application with just one content database on a new farm using the “new configuration” restore method in Central Administration resulted in two errors:
- The web Application Restore reported “Object SharePoint <Web App name> failed in event Onrestore. For more information, see the error log located in the backup directory. SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name =<Web App name> Parent=SPWebService is being updated by <Domain\user>, in the OWSTIMER process, on machine <server>. View the tracing log for more information about the conflict.
- Object <new database name> (previous name: <original database name>) failed in event OnPostRestore. For more information, see the error log located in the backup directory. SPException: Cannot attach database to Web application. Use the command line tool or Central Administration pages to attach the database manually to the proper Web Application.
Looking at the sprestore.log log file in the backup directory didn’t reveal any addition information, but the trace logs were very interesting! A lot of similat messages were logged:
09/25/2008 15:52:17.97 OWSTIMER.EXE (0×0860) 0×0868 Windows SharePoint Services Timer 5uuf Monitorable The previous instance of the timer job <job>, id <id guid> for service <service guid> is still running, so the current instance will be skipped. Consider increasing the interval between jobs.
In fact over 23000 of these messages were logged every minut! On a farm that was practically with out any user activity. What is going on!?
Having googled extensively, I didn’t manage to come up with an explanation why this happened but I did find a well, let’s call is a workaround for lack of a better word.
SBS MVP Merv Porter describes in this thread how to make the messages go away.
- Start SharePoint 3.0 Central Administration (you might have to pause the Windows SharePoint Timer service before you can actually get there -especially if you’re using a VPC – for whatever reason, OWSTIMER.EXE can easily soak up whatever CPU cycles you have…)
- Go to Operations
- Under Logging and Reporting, choose Diagnostic Logging
- Under Event Throttling, choose All as the category (this may be unnecessary, as it could be the default, but judging by the amount oflogging, it probably isn’t)
- Under Trace Log, set “Number of log files” to something reasonable – say, 5. You can leave “Number of minutes…” to be 30, unless you want those 5 files to be smaller in size. At the default rate, a 30 minute trace file in my case seems to be about 200MB.
Obviously, you should think twice before decreasing the logging levels in a production environment, but after I made these changes to the logging levels I was able to restore the the Web Application without any problems, and as a positive side effect my Hyper-V image was noticeably quicker!
6 Responses to “Solving a nasty restore problem (OWSTIMER issue)”
Sorry, the comment form is closed at this time.