cancel
Showing results for 
Search instead for 
Did you mean: 

Oracle restore seems to be idle

Julien_MTL
Level 3

Hi,

We are running a redirected restore(it's a duplicate) on Oracle running on Red Hat. The restore works at what seems to be an okay speed. The restore is initiated from RMAN.

Netbackup master, media and client are 7.1.0.3/4

The restore operation create multiple streams and at the end of each stream restore the operation is just hanging there waiting for something. 

Here is the dbext log showing what I'm talking about.

 

Restore started Thu Jul 19 16:10:40 2012
16:10:46 (72661.001) Restoring from copy 1 of image created 07/17/12 16:39:03
16:10:51 (72661.001) INF - Data socket = 
16:10:51 (72661.001) INF - Name socket = 
16:10:51 (72661.001) INF - Job id = 72661
16:10:52 (72661.001) INF - Backup id = 
16:10:52 (72661.001) INF - Backup time = 1342557543
16:10:52 (72661.001) INF - Policy name = 
16:10:52 (72661.001) INF - Snapshot = 0
16:10:52 (72661.001) INF - Frozen image = 0
16:10:53 (72661.001) INF - Backup copy = 0
16:10:53 (72661.001) INF - Master server = 
16:10:53 (72661.001) INF - Encrypt = 0
16:10:53 (72661.001) INF - Use shared memory = 0
16:10:54 (72661.001) INF - Restore id = 72661.001
16:10:54 (72661.001) INF - Encrypt = 0
16:10:54 (72661.001) INF - Client read timeout = 300
16:10:54 (72661.001) INF - Media mount timeout = 0
16:10:54 (72661.001) INF - client = server B
16:10:55 (72661.001) INF - requesting_client = server B
16:10:55 (72661.001) INF - browse_client = server A
16:11:02 (72661.001) INF - Beginning restore from server media_server to client server B
18:03:57 /xxx_Online<xxx_646:788891936:1>.dbf
18:03:58 /xxx_Online<xxx_646:788891936:1>.dbf
19:32:16 (72661.001) Status of restore from copy 1 of image created 07/17/12 16:39:03 = the requested operation was successfully completed
 
19:32:18 INF - Server status = 0
19:32:18 (72661.xxx) INF - Status = the requested operation was successfully completed.
 
 
Do you know what it could be ? There is nothing going on for 1h30minutes. So the next stream won't be executed at 18:03, but 19:32, which makes the restore longer.
 
Thanks
1 ACCEPTED SOLUTION

Accepted Solutions

Julien_MTL
Level 3

I just find out what happened. The server is a VM and a snapshot was done at 6PM. So vmware tried to quiesce the FS and in the same time the restore froze. When the snapshot was removed, everything resume. 

We rerun the restore and there is only a few minutes now showing between the end writing and the status.

View solution in original post

3 REPLIES 3

Will_Restore
Level 6

perhaps a clue in the alert.log, trace file or something

Julien_MTL
Level 3

I just find out what happened. The server is a VM and a snapshot was done at 6PM. So vmware tried to quiesce the FS and in the same time the restore froze. When the snapshot was removed, everything resume. 

We rerun the restore and there is only a few minutes now showing between the end writing and the status.

Will_Restore
Level 6

good catch