|
A few months ago we installed AOMEI backupper on a Server 2016 box running the SQL Anywhere service and enabled sync for all the DB files so that we have both a daily full server backup and real time sync backup of the DB files. Now when starting the service after a Windows update reboot it will sometimes fail, up to two or three times, with 'cannot access x.db: another process may be using the file' at a random DB (currently loads about 80 db's) and then proceeds to unload them all and closes. I tried stopping the AOMEI service before starting SQL Anywhere, but that didn't prevent it. I can only assume that a related Windows service (VSS, SDRSVC, WBEngine) may be used by AOMEI and is causing this, but getting these servers up and running in a timely fashion after the ever increasing number of patches is critical. Has anyone else experienced this with backup software when starting the server? Perhaps running Process Monitor and examining the log afterwards? Thanks |
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 11 Jun '19, 18:28
question was seen: 991 times
last updated: 12 Jun '19, 04:52
So you are saying/assuming another process (except dbsrvXX.exe) is using the .db file? In other words, may the backup software access/copy the live production db files?
I can add that maybe few tools from Sysinternals might help with revealing who is accessing the .db file:
https://docs.microsoft.com/en-us/sysinternals/downloads/handle
https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon