Showing posts with label IDB. Show all posts
Showing posts with label IDB. Show all posts

Tuesday, March 18, 2014

IDB on Exclusive mode

Cannot open Internal Database in exclusive mode


Problem: Cannot open Internal Database in exclusive mode
Cannot backup internal database because another database check in progress
 
Solution 1: Bring down the omni services by typing the below commands

/etc/init.d/omni stop in unix
<omni dirc >/bin> omnisv -stop
Check if there is any hung process
do " ps -ef | grep omni "
if there is any hung process kill the hung sessions

use Kill -9 <process ID >

if there is no hung session , Bring up the omni services up 

/etc/init.d/omni start
check the services are up & running or not 
if all the services are up & running 

go to /opt/omni/sbin 

omnidbutil -clear ( this command will kill the ghost sessions )
you will get the message " Done ! "

to check the IDB database check is still running or not , go to " /opt/omni/sbin "
use " omnidbcheck " command

Now you will not get the message " Database check is in Process "

Now re initiate the IDB backup .... This will run the IDB backup successfully

Solution 2: If still the issue is not resolve by solution 1

log on to the cell manager and go the below path
/var/opt/omni/tmp

you can see a file name " tmp_dbcheck.lk" , Remove that file by using the command

rm tmp_dbcheck.lk

Restart the DP Services , your issue will resolve after performing any of the solutions


Sunday, March 16, 2014

Batch script for " IDB Maintenance & Resolving the Velocis Error " for Windows Servers…

Solution : copy the below script and paste in notepad and save it as " IDB_velosis.bat" file and just click on the file ... 



Your Velocis error and IDB maintenance will be completed in Just-a-click!


Note:- Modify the script according to where [Which Drive/Path] we installed the DataProtector 




Copy the text which in blue color 

echo # IDB Maintenance & Resolving the Velosis Error #

echo # Resolving the Velosis Error #
cd \

D:

cd Program files\omniback\bin

omnisv -status

omnisv -stop

taskkill /IM vbda.exe /F /T
taskkill /IM bsm.exe /F /T
taskkill /IM dbsm.exe /F /T
taskkill /IM vrda.exe /F /T
taskkill /IM uma.exe /F /T
taskkill /IM crs.exe /F /T
taskkill /IM rds.exe /F /T
taskkill /IM mmd.exe /F /T

cd \

cd Program Files\OmniBack\tmp

del CRS.pid
del dbcheck.cdb
del dbcheck.mmdb
del lic.ctx
del mmd.ctx

cd \

cd Program Files\OmniBack\db40\logfiles\syslog

del *.chg
del *.chk

cd \

cd Program Files\OmniBack\db40\datafiles\catalog

rename rdm.bil rdm.bil.old
rename rdm.chi rdm.chi.old

cd \

cd Program Files\OmniBack\bin

echo # Now Bring up the databae

omnisv -start

omnidbutil -clear

omnidbutil -free_locked_devs

echo # IDB Maintanence

omnidbutil -purge -messages 30 -force
omnidbutil -purge -sessions 30 -force
omnidbutil -purge -dcbf -force
omnidbutil -purge -filenames -force

exit


End of the script

Try the same in Testing environment prior to Production, All the best :)

Sunday, February 23, 2014

HP DP - IDB Maintenance

DataProtector IDB Maintenance

Step by Step procedure for IDB Maintenance

White Font à Steps
Green Font à Commands Used
Blue Font à Command O/P

*       Check for any running sessions and abort if required

*       Ensure no backup is running and take the IDB backup using DP.

*       Disable the backup schedules (/sbin/init.d/cron stop, omnitrig -stop)

*       Shutdown the DP with following command

/opt/omni/sbin/omnisv stop

*       Check the omni service (omnisv status)

*       Close the DP GUI & abort all DBSm Sessions

*       Purge DB with below commands.

a.    omnidb -strip

b.    omnidbutil -purge_failed_copies

c.     omnidbutil -purge -filenames -force

d.    omnidbutil -purge –dcbf

*       (If the purge has not finished, but you need to run backups simply stop the purge with omnidbutil -purge_stop and use DP as normal. )

*       Check for a mount point with sufficient space. Usually /var/adm/crash

*       Create two directories MMDB and CDB in /var/adm/crash

mkdir /var/adm/crash/MMDB /var/adm/crash/CDB

*       Start the DP with following command

/opt/omni/sbin/omnisv start

*       Create a copy of the existing sessions, medias, position information etc. with the following command

/omni/db40 # /opt/omni/sbin/omnidbutil -writedb -mmdb /var/adm/crash/MMDB -cdb /var/adm/crash/CDB -no_detail

*       Once the above command is successful without any errors the output will be as below:

/omni/db40 # /opt/omni/sbin/omnidbutil -writedb -mmdb /var/adm/crash/MMDB -cdb /var/adm/crash/CDB -no_detail

10/07/05 12:44:18 Exporting libraries ...

10/07/05 12:44:18 Exporting pools ...

10/07/05 12:44:18 Exporting devices ...

10/07/05 12:44:18 Exporting cartridges ...

10/07/05 12:44:18 Exporting compounds ...

10/07/05 12:44:18 Exporting media ...

10/07/05 12:44:18 Exporting sessions ...

10/07/05 12:44:19 Exporting objects and object versions ...

10/07/05 12:44:23 Exporting positions ...

Please make a copy of following Internal Database directories and

then press ENTER to return Internal Database to normal state:

"/var/opt/omni/db40/msg"

DONE!

*       After successful completion of writedb. Move folders /var/opt/omni/db40/dcbf* folders to /var/opt/omni/db40/dcbf*.old. Note that there can be more than one folder ex. dcbf, dcbf1, dcbf2 etc.

*       Compress the content of the moved folder. This is done just to create space and these folders (dcbf*.old) will be removed later once the maintenance is successful.

*       Restart the DP services using the below commands

/opt/omni/sbin/omnisv stop

/opt/omni/sbin/omnisv start

*       Perform DB Read (Reads and writes to the database) using omnidbutil.

/omni/db40 # /opt/omni/sbin/omnidbutil -readdb -mmdb /var/adm/crash/MMDB -cdb /var/adm/crash/CDB -no_detail

*       The above command will output messages similar to below:

*       /omni/db40 # /opt/omni/sbin/omnidbutil -readdb -mmdb /var/adm/crash/MMDB -cdb /var/adm/crash/CDB -no_detail

Database import will overwrite old database. All data will be lost!

Are you sure (y/n)?y

10/07/05 12:17:53 Importing libraries ...

10/07/05 12:17:53 Importing pools ...

10/07/05 12:17:53 Importing devices ...

10/07/05 12:17:53 Importing compounds ...

10/07/05 12:17:53 Importing cartridges ...

10/07/05 12:17:53 Importing media ...

10/07/05 12:17:53 Importing sessions ...

10/07/05 12:17:53 Importing objects and object versions ...

10/07/05 12:25:27 Importing positions ...

DONE!

*       Run following command omnidbutil -fixmpos

*       Once the above command is successful. Connect to DP through GUI and check the last run sessions.

*       enable the backup schedule (/sbin/init.d/cron start, omnitrig -start)

*       If everything looks fine. You can remove the dcbf*.old directories from /var/opt/omni/db40.

*       Note that once the DB maintenance is complete. All directory/file details will be removed from the database. Hence forth need to import the medias to browse files for any restore operation.


Thursday, February 20, 2014

[12:1165] Internal Database network communication error

Error:

[Critical] From: BSM@cellserver01.in.com "Backup_spec_01"  Time: 2/19/2014 10:14:51 AM
[61:4001]   Error accessing the database, in line 1490, file bcsmutil.c.
Database subsystem reports:
"[12:1165] Internal Database network communication error."

[Major] From: BSM@cellserver01.in.com "Backup_spec_01"  Time: 2/19/2014 10:14:51 AM
[61:4001]   Error accessing the database, in line 3073, file brsmutil.c.
Database subsystem reports:
"Internal error: DbaXXXX functions."


> This is related to RDS service/process running in the cell server which needs immediate attention. Whole site backup would fail if not actioned immediately.
> Restarting the DP services in cell server would eliminate these errors.


# omnisv status
    
ProcName Status [PID]
===============================
rds : Down
crs : Active [20740]
mmd : Active [20738]
kms : Active [20739]
omnitrig: Active
uiproxy : Active [20749]
Sending of traps disabled.
===============================
Status: At least one of Data Protector relevant processes/services is not running.


# omnisv stop
# omnisv start

This is just a workaround to bring the services up. Proper IDB maintenance and patch levels can reduce this situation. Check this link for detailed post on DP IDB Maintenance.