Please describe your setup (including OS and application versions) and include RMAN script. An example including daemon.log of what you say would be nice.

If you check process list do you see if index backup initiated? When RMAN triggered from client index won't be saved (only when server initiated backup is done that is when index save is triggered if allowed by pool settings).

after i start the group from command line with -vvvv option, daemon.log:

01/24/07 09:22:08 nsrd: savegroup info: starting foobar (with 1 client(s))
01/24/07 09:22:08 nsrd: savegroup info: foobar running on anatolia
01/24/07 09:22:11 nsrd: savegroup info: foobar running on anatolia
01/24/07 09:26:11 nsrd: anatolia:/path/kenan_backup_sbt.rman saving to pool 'TTS' (TTS.Gunluk.02)
01/24/07 09:26:21 nsrd: anatolia:/path/kenan_backup_sbt.rman done saving to pool 'TTS' (TTS.Gunluk.02) 256 KB
01/24/07 09:26:29 nsrd: anatolia:/path/kenan_backup_sbt.rman saving to pool 'TTS' (TTS.Gunluk.02)
01/24/07 09:26:33 nsrd: anatolia:/path/kenan_backup_sbt.rman done saving to pool 'TTS' (TTS.Gunluk.02) 14 MB
01/24/07 09:27:11 nsrd: savegroup info: foobar running on anatolia
01/24/07 09:27:15 nsrd: write completion notice: Writing to volume TTS.Gunluk.02 complete
01/24/07 09:32:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 09:37:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 09:42:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 09:47:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 09:52:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 09:57:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 10:02:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 10:07:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 10:12:12 nsrd: savegroup info: foobar running on anatolia
01/24/07 10:17:13 nsrd: savegroup info: foobar running on anatolia
01/24/07 10:22:13 nsrd: savegroup info: foobar running on anatolia
01/24/07 10:27:13 nsrd: savegroup info: foobar running on anatolia
01/24/07 10:32:13 nsrd: savegroup info: foobar running on anatolia
01/24/07 10:35:09 nsrd: savegroup alert: foobar aborted, total 1 client(s), 0 Hostname(s) Unresolved, 1 Failed, 0 Succeeded. (anatolia Failed)


oracle version : Oracle9i 9.2.0.6
nmo version : 4.1
networker server: version 7.2.2, windows 2003
client : hp-ux 11.11

this is a sample rman script getting online backup:


connect catalog xxx@rman;
connect target xxx@sid;
run {
allocate channel t1 type 'SBT_TAPE' parms 'ENV=(NSR_SERVER=ltoserver, NSR_CLIENT=anatolia, NSR_DATA_VOLUME_POOL=TTS)' CONNECT 'xxx@sid';
backup tablespace tools;
release channel t1;
}

and after backup finished but not ended, this is the ps -ef | grep nsr output from client

root 4304 4303 0 11:33:34 ? 0:00 nsrnmostart -s ltoserver -g foobar -LL -m anatolia -t 116962358
root 4303 4302 0 11:33:34 ? 0:00 /bin/sh /opt/networker/bin/nsrnmo -s ltoserver -g foobar -LL -m
root 3901 1 0 11:33:10 ? 0:00 /opt/networker/bin/nsrexecd
root 4301 3903 0 11:33:34 ? 0:00 /opt/networker/bin/nsrexecd
root 6701 29941 0 11:48:41 pts/3 0:00 grep nsr
root 4302 4301 0 11:33:34 ? 0:00 /bin/sh /opt/networker/bin/nsrnmo -s ltoserver -g foobar -LL -m
root 3903 3901 0 11:33:10 ? 0:00 /opt/networker/bin/nsrexecd

As far as I see it, NMO backup is still running. Please change RMAN script to following and try again:

connect target user/pass@inst
coinnect rcvcat user/pass@inst
 
run {
allocate channel t1 type 'SBT_TAPE' 
send channel t1 "NSR_ENV=(NSR_SERVER=ltoserver, NSR_CLIENT=anatolia, NSR_DATA_VOLUME_POOL=TTS)
allocate channel t2 type 'SBT_TAPE' 
send channel t2 "NSR_ENV=(NSR_SERVER=ltoserver, NSR_CLIENT=anatolia, NSR_DATA_VOLUME_POOL=TTS)
sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';
change archivelog all validate;
backup archivelog all skip inaccessible;
release channel t1;
release channel t2;
resync catalog;
}

Try first to run this from HPUX box (rman cmdfile ) and if it work then try from server. If that works we can proceed to tablespace then.

Hi Kenan,

there is a known bug in nmo4.1 for HPUX systems. If you check on the client you will probably see a high cpu-load after the rman backup finishes.

If so, open a case with EMC and ask for a patch to resolve this issue. Worked for us.

Xander

Hi Xander,

Do you have LGTpa for that one? I guess it would be fixed in 4.2 as we have Oracle on HPUX (both RISC and Itanium) we didn't see that one yet.

Hrvoje,

i tried the script you sent, but nothing was different. again processes in client are still running, but cpu load is normal. we have another hp-ux box with the same oracle, os and nmo version. but nothing is wrong with it.

Try NMO 4.2. Be aware that patch could be required if cluster is running for that version. If not, make sure it is down (cmhaltcl).

i upgraded nmo version to 4.2, tried again. and result is the same. processes aren't terminated. can it be because of a wrong permission of a directory or file so processes can't write. i looked at into /nsr directory but i nothing is different from the other hp-ux box.
or can it be a because of a configuration change in rman ?

Could you please try following, go to that client, log as oracle and run that RMAN script again. I wish to see at which point it breaks and if there is any error at RMAN level too (or waiting). This could be also related to Oracle too.