Trying to do a restore of a database to another server should be a relatively simple process and indeed I'll post some notes on how to do that in my next post. However i had some trouble getting the tape channel to allocate initially and I thought it was worth sharing as none of the notes i found on google resolved the porblem, though they did give some hints that were useful.
All i wanted to do was restore a 'live' database to a 'test' server, the test server was already backing up fine so we knew the tape software (tsm) in out case was all fine. We copied over the configuration folder for the live backups to the test server and expected the channel just to be able to allocate - we knew the config was correct as it was in use in live.
However when i ran the tape allocation command i kept getting this
run {
allocate channel t1 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/tsm/LIVE/conf/tdpo.opt)';
restore spfile;}
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on t1 channel at 01/26/2014 21:25:32
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27000: skgfqsbi: failed to initialize storage subsystem (SBT) layer
Linux-x86_64 Error: 610: Unknown system error
Additional information: 7011
ORA-19511: Error received from media manager layer, error text:
SBT error = 7011, errno = 610, sbtopen: system error
RMAN>
So clearly there is some issue about it talking to the tape software.
After various google searches it seems the file it actually wants is this one
dsmclientV3.cat
Which is there - and is clearly available as it works for the other database.
After much headscratching, changing DSMI related environment variables, LANG's,NLS_LANG's (the list goes on)
I finally figured it out, the way the directory had been copied from the live server to the test one had missed symbolic links.....
The tsm software seems to look for the file in the following location
$DSMI_CONFIG/locale/dsmclientV3.cat
So in the case above it wanted it in
/tsm/LIVE/conf/en_US/dsmclientV3.cat
en_US is a sym link to where the tsm software is actually installed, recreating this fixed the issue.
The LANG setting on Linux though needs to match en_US for this to work correctly, so make sure that this is also correct.
Comments
Post a Comment