Restoring oracle database on SAN-client by RMAN

[ako]

Hello! I am using the last version of NetBackup 6.5.2 on Solaris 10 sparc

I have problem when I am trying restore DB by RMAN to SAN-client.

Backups works fine. Restores work only with files, not RMAN.

In dbclient log on the client folowing errors

09:55:50.161 [19943] <4> SetupShMforRestore: INF - PARENT_ID = 25754, NUM_BUFS = 30, BUF_SIZE = 262144,  BPRD_PORT = 0, IS_MPX_PROTO = 0, IS_MPX_IMAGE = 0
09:55:50.162 [19943] <4> SetupShMforRestore: INF - CINDEX = 0, CURR_BUF = 0, BUF_SEQ = 1, IS_TAPE = 0, SHMID = 2030043171, RESTORE_SVR =
09:55:50.162 [19943] <4> SetupShMforRestore: INF - SHMID = 2030043171, BUF_PTR = 0xffffffff78c00000, BUF_CONTROL = 0xffffffff79380000, ReadyPtr = 0xffffffff79
3802d0, MPX_RES_CNTL = 0xffffffff793802d8
09:55:51.171 [19943] <2> SetupShMforRestore: SharedMemR->SharedMem.qBuffSize 1 <262144>
09:55:51.171 [19943] <2> GetBufForShMRestore: Prepare to wait for curr_buf <0> full
 

09:55:51.181 [19943] <16> GetBufForShMRestore: ERR -  FAT Client process <25754> is gone.
09:55:51.181 [19943] <16> PrepForShMRestore: ERR - failed setting up for shared mem
09:55:51.181 [19943] <16> serverResponse: ERR - failed preping for shared mem restore
09:55:51.181 [19943] <16> RestoreFileObjects: ERR - serverResponse() failed
09:55:51.181 [19943] <4> closeApi: entering closeApi.
 

ps -ef | grep ft54
root 25754     1   0 15:26:02 ?           0:14 /usr/openv/netbackup/bin/nbftclnt
 

How can I debug this situation more deeply?

[sdo]

Try setting verbosity to level 5.

v6.5 Trouble Shooting Guide:

http://seer.entsupport.symantec.com/docs/290230.htm

[ako]

The first thing I've done :)

 I am trying to look in to nbftclient logs, but it seems nothing interesting there:

vxlogview -o 200

09/02/08 12:16:03.072 [FATClientNotificationHandler::handle_timeout] +++ ENTERING +++ : obj = 2fd930 (FATClientNotificationHandler.cpp:97)
09/02/08 12:16:03.073 [FATClientNotificationHandler::updateClusterStatus] +++ ENTERING +++ : obj = 2fd930 (FATClientNotificationHandler.cpp:112)
09/02/08 12:16:03.404 [FATClientNotificationHandler::updateClusterStatus] --- EXITING --- : obj = 2fd930 (FATClientNotificationHandler.cpp:112)
09/02/08 12:16:03.405 [FATClientNotificationHandler::handle_timeout] --- EXITING --- : obj = 2fd930 (FATClientNotificationHandler.cpp:97)
09/02/08 12:21:03.067 [FATClientNotificationHandler::handle_timeout] +++ ENTERING +++ : obj = 2fd930 (FATClientNotificationHandler.cpp:97)
09/02/08 12:21:03.068 [FATClientNotificationHandler::updateClusterStatus] +++ ENTERING +++ : obj = 2fd930 (FATClientNotificationHandler.cpp:112)
09/02/08 12:21:03.419 [FATClientNotificationHandler::updateClusterStatus] --- EXITING --- : obj = 2fd930 (FATClientNotificationHandler.cpp:112)
09/02/08 12:21:03.420 [FATClientNotificationHandler::handle_timeout] --- EXITING --- : obj = 2fd930 (FATClientNotificationHandler.cpp:97)
09/02/08 12:26:03.072 [FATClientNotificationHandler::handle_timeout] +++ ENTERING +++ : obj = 2fd930 (FATClientNotificationHandler.cpp:97)
09/02/08 12:26:03.073 [FATClientNotificationHandler::updateClusterStatus] +++ ENTERING +++ : obj = 2fd930 (FATClientNotificationHandler.cpp:112)
09/02/08 12:26:04.633 [FATClientNotificationHandler::updateClusterStatus] --- EXITING --- : obj = 2fd930 (FATClientNotificationHandler.cpp:112)
09/02/08 12:26:04.633 [FATClientNotificationHandler::handle_timeout] --- EXITING --- : obj = 2fd930 (FATClientNotificationHandler.cpp:97)
09/02/08 12:31:03.068 [FATClientNotificationHandler::handle_timeout] +++ ENTERING +++ : obj = 2fd930 (FATClientNotificationHandler.cpp:97)
09/02/08 12:31:03.068 [FATClientNotificationHandler::updateClusterStatus] +++ ENTERING +++ : obj = 2fd930 (FATClientNotificationHandler.cpp:112)
09/02/08 12:31:03.373 [FATClientNotificationHandler::updateClusterStatus] --- EXITING --- : obj = 2fd930 (FATClientNotificationHandler.cpp:112)
09/02/08 12:31:03.373 [FATClientNotificationHandler::handle_timeout] --- EXITING --- : obj = 2fd930 (FATClientNotificationHandler.cpp:97)
 

[dami]

I would be very interested on how you troubleshoot this further as I will shortly be doing something very similar with NetBackup 6.5.2 and an Oracle 9i RAC.

It may help to increase the Unified logging level (as they seem to be registering something relating to your main  message).

This can be done with the following:

To see the current setting:

/usr/openv/netbackup/bin/vxlogcfg -p 51216 -o Default -l

To set to 6:

/usr/openv/netbackup/bin/vxlogcfg -a -p 51216 -o ALL -s DebugLevel=6 -s DiagnosticLevel=6

back to 0:

/usr/openv/netbackup/bin/vxlogcfg -a -p 51216 -o ALL -s DebugLevel=0 -s DiagnosticLevel=0

Beware though ... these logs get very very hungry for disk space (/usr/openv/logs) once set to 6 ...

[ako]

Unified logging level already 6, but I did'nt find anything new.

[Omar_Villa]

I think you need more buffers

09:55:50.161 [19943] <4> SetupShMforRestore: INF - PARENT_ID = 25754, NUM_BUFS = 30, BUF_SIZE = 262144,  BPRD_PORT = 0, IS_MPX_PROTO = 0, IS_MPX_IMAGE = 0

you only have 30 and the errors are requesting memory

09:55:51.181 [19943] <16> GetBufForShMRestore: ERR -  FAT Client process <25754> is gone.
09:55:51.181 [19943] <16> PrepForShMRestore: ERR - failed setting up for shared mem
09:55:51.181 [19943] <16> serverResponse: ERR - failed preping for shared mem restore

so check if your solaris box haves enough free swap space is common that sometime the /tmp folder get full with logs and bunch of stuff, also increase the NUMBER_DATA_BUFFERS to 128 so you will get the best, this in your media server and review the number of channels that you are trying to use from the Oracle side this can also be an issue if is to high.

hope this helps.

regards

[ako]

Thank you for your replay, but it doesn't help. I've tried on different systems with different configurations, but problem the same. I have some ideas yet. I will write here about further actions.