What is this?

This is basically where I write down stuff that I work with at my job as a GIS Technical Analyst (previously system administrator). I do it because it's practical for documentation purposes (although, I remove stuff that might be a security breach) and I hope it can be of use to someone out there. I frequently search the net for help myself, and this is my way of contributing.

Tuesday, December 22, 2009

HP Data Protector 6.11 post upgrade database cleanup and defrag

I recently upgraded our Data Protector backup software to 6.11 to get the latest and the greatest. Everything seemed to work just fine, but after a few backup runs I noticed that backing up the Data Protector Database did not work as it should. The log said:

[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 {omniback}/tmp folder did the trick though. The backup would go through, but for some reason the backup was unbelievably slow. In fact it would hang for almost 3 hours before even beginning to backup the database. This was not the case on DP 6.0 only one week earlier. omnidbcheck would not report any errors though. Apparently the database needed some cleaning and defragmentation.

I started off running a "omnisv -stop" (to stop all services) and did a cold backup of the whole {omniback}-foldertree. Then I started the services again with "omnisv -start".

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 {omniback}\dcbf and {omniback}\msg
Again I ran "omnidbutil -info"

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.

6 comments:

  1. Deleting the lock file was a great help for me after the upgrade to 6.11.

    Thank you a lot, I admire your site

    ReplyDelete
  2. You rule!
    thanks for the gr8 tips you post.

    ReplyDelete
  3. Hi,

    I 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

    ReplyDelete
  4. Hi,

    I just had a cell manager crash while a IDB backup was running. I had the same problem ....
    Lars

    ReplyDelete
  5. 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.

    Thanks
    If you have the solution please contac me at: vtodaro@gmail.com

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete