DP database locked

Recently a customer called in and told me that he is unable to use it's DataProtector installation. All DP services were running and he could open the DP GUI but as soon as he tried to access the session database or open the Device&Media section, he got the error

"Cannot open database.
Somebody is running omnidbcheck or omnidbutil command!"

I checked twice the running processes but no command running that could lock the database. So to be sure, I rebooted the DP server and tried again but still without luck.

Searching a bit on the internet this seems to be a quite usual error but unforunately there are only a few hints on how to solve this.

Checking for any .lck files in the temp directory was unsuccessful. Exporting and importing the database is also a quite often told solution but this can't work at all because as long as the database thinks it is locked it will never give you the needed access to read out the database. So forget about this "solution".

To cut a long story short, none of the solutions provided on the internet really worked for me. So I decided to uninstall and reinstall DP with the same patch level as before, restore the last successful IDB backup and import it to my installation.

First you need to know on which tape is your last IDB backup. If you don't know, don't be sad, you can easily read it in one of the DP log files. Search for a file called obrindex.dat in the ProgramData\Omniback folder and open it with a text editor. Scroll down to the last line, there is your last IDB backup listed together with the name and barcode of the tape.

Importing the tape takes some time but after that you will be able to restore your IDB. I did and made a strange discovery: along with the IDB folders (db40 and below), an additional folder was restored to the Windows root folder c:\ with a single file falled fnames1.dat and 0kb in size.

Hm, what about that file and why was it restored together with an IDB backup? fnamesX.dat is the file where every backed up file information is stored but these files normally are stored in the db40 folder. The next strange thing is the size of 0kb. This file was definetly empty.

I couldn't imagine that this file is really used by the DP database. More than this, the RDS service started successfully and normally the RDS would never start if a needed file is missing.

Nevertheless, I checked which files the RDS database tries to open while starting and therefore opened the file C:\ProgramData\OmniBack\db40\datafiles\catalog\db_files where all folders and files containing RDS data are listed and voila, there was a reference to the empty fnames1.dat file.

I decided to leave the fnames1.dat file at it's place for now and restarted the DP services. The next time I opened the GUI I was able to get exclusive access to the database.

 

So if you ever run into such a problem and are 100% sure that there is no other process currently locking the database, don't rely on the error message from the DP GUI and check if you have access to all files mentioned in the db_files file, even if the size is 0kb and you have no idea where such files come from :-)

Of course, probably the customer added a fnames extension file in DP to extend it's upfilled fnames.dat and missed to place it in the right directory. This can happen all the time.  

Leave your comments

Post comment as a guest

0
Your comments are subjected to administrator's moderation.
  • No comments found
Powered by Komento
joomla templatesfree joomla templatestemplate joomla
2017  v-strange.de   globbers joomla template