[Normal] From: DBBDA@dpserv.mydomain.intern "[Database]: dpserv.mydomain.intern" Time: 18.12.2009 14:35:25
STARTING Database HotBackup Disk Agent on dpserv.mydomain.intern "[Database]: dpserv.mydomain.intern".
[Major] From: DBBDA@dpserv.mydomain.intern "[Database]: dpserv.mydomain.intern" Time: 18.12.2009 14:35:25
[81:522] Cannot back up internal database because another database check in progress.
[Warning] From: DBBDA@dpserv.mydomain.intern "[Database]: dpserv.mydomain.intern" Time: 18.12.2009 14:35:26
Cannot un-lock the keystore.
[Major] From: DBBDA@dpserv.mydomain.intern "[Database]: dpserv.mydomain.intern" Time: 18.12.2009 14:35:26
ABORTED Database HotBackup Disk Agent on dpserv.mydomain.intern"[Database]: dpserv.mydomain.intern"
A manual run of omnidbcheck revealed the same thing. I could not find any signs of any other database checks, and a reboot did not help.
Deleting the lock-file (dbcheck.lk) from the
I started off running a "omnisv -stop" (to stop all services) and did a cold backup of the whole
I then ran "omnidbutil -info" which showed the following:
Media Management database space usage:
Space used by Diskspace usage Records used Records total
============================================================================
Devices 96 17 20
Libraries 96 2 5
Cartridges 1184 296 852
Compounds 32 0 12
Pools 64 26 30
Media 160 288 297
Catalog database space usage:
Space used by Diskspace usage Records used Records total
============================================================================
Sessions 352 197 284
Objects 256 517 552
Object versions 10080 5236 7810
Positions 12896 77086 97960
Filenames 3175520 31876226 31876278
Detail catalog binary files usage:
Diskspace usage Size limit DC Directory
============================================================================
2068 4096 C:/Program Files/OmniBack/db40/dcbf
----------------------------------------------------------------------------
2068 4096
Session messages binary files usage:
Diskspace usage Num. of files SMBFs Directory
============================================================================
16 191 C:/Program Files/OmniBack/db40/msg
Serverless integrations binary files usage:
Diskspace usage Num. of files SIBFs Directory
============================================================================
0 0 C:/Program Files/OmniBack/db40/meta
I decided to try and purge unused and obsolete filenames from the database:
"omnidbutil -purge -filenames -force" (took a couple of hours) and another "omnidbutil -info" showed this:
Media Management database space usage:
Space used by Diskspace usage Records used Records total
============================================================================
Devices 96 17 20
Libraries 96 2 5
Cartridges 1184 296 852
Compounds 32 0 12
Pools 64 26 30
Media 160 288 297
Catalog database space usage:
Space used by Diskspace usage Records used Records total
============================================================================
Sessions 352 203 284
Objects 256 517 552
Object versions 10080 5354 7810
Positions 12896 77366 97960
Filenames 3175520 13472221 31876336
Detail catalog binary files usage:
Diskspace usage Size limit DC Directory
============================================================================
2099 4096 C:/Program Files/OmniBack/db40/dcbf
----------------------------------------------------------------------------
2099 4096
Session messages binary files usage:
Diskspace usage Num. of files SMBFs Directory
============================================================================
17 197 C:/Program Files/OmniBack/db40/msg
Serverless integrations binary files usage:
Diskspace usage Num. of files SIBFs Directory
============================================================================
0 0 C:/Program Files/OmniBack/db40/meta
Right, apparently there was a lot of unused filename records.
According to HP the best way to clean up and defrag the database would be to export all records and import them right back in again.
I created two empty folders (f:\dump\dp\cdb and f:\dumå\dp\mmdb) and ran
omnidbutil -writedb -mmdb f:\dumå\dp\mmdb -cdb f:\dump\dp\cdb
followed by:
omnidbutil -readdb -mmdb f:\dumå\dp\mmdb -cdb f:\dump\dp\cdb
I then followed the on-screen instructions and took a backup of
Media Management database space usage:
Space used by Diskspace usage Records used Records total
============================================================================
Devices 96 17 20
Libraries 96 2 5
Cartridges 448 296 297
Compounds 32 0 12
Pools 64 26 30
Media 160 288 297
Catalog database space usage:
Space used by Diskspace usage Records used Records total
============================================================================
Sessions 288 209 212
Objects 256 517 528
Object versions 6688 5450 5460
Positions 10208 77217 77221
Filenames 1319392 13474587 13474618
Detail catalog binary files usage:
Diskspace usage Size limit DC Directory
============================================================================
2135 4096 C:/Program Files/OmniBack/db40/dcbf
----------------------------------------------------------------------------
2135 4096
Session messages binary files usage:
Diskspace usage Num. of files SMBFs Directory
============================================================================
17 203 C:/Program Files/OmniBack/db40/msg
Serverless integrations binary files usage:
Diskspace usage Num. of files SIBFs Directory
============================================================================
0 0 C:/Program Files/OmniBack/db40/meta
Notice that space usage for the catalog datbase/filenames has decreased by 1.8 GB. Nothing seems to be missing when using the DP Cell Manager GUI and running a omnidbcheck now takes 11 minutes! The slight increase in disk space usage is because I had to run a quite large backup before doing the writedb/readdb operation.
Deleting the lock file was a great help for me after the upgrade to 6.11.
ReplyDeleteThank you a lot, I admire your site
You rule!
ReplyDeletethanks for the gr8 tips you post.
Hi,
ReplyDeleteI just made an Update from Data Protector 6.11 on 6.2 and I have the same Problem. I just delete the lock file a the Problem was solved.
Thanks for your post
Christophe
Hi,
ReplyDeleteI just had a cell manager crash while a IDB backup was running. I had the same problem ....
Lars
I have the same problem but my IDB is corrupted there are broken links and has been impossible to recover the IDB to their normal funcionality. Any help I would appreciate, we are looking for an expert that can solve the problem, we do not want to reconstruct the IDB reading the LTOs tapes catalogs.
ReplyDeleteThanks
If you have the solution please contac me at: vtodaro@gmail.com