hi,
It's hard to say why the restore is slow. Also it's hard to say whether
Oracle or TSM or both are causing the problem. I would recommend to turn
on TSM API tracing and look for dsmGetData() Entry, Exit trace points.
Check the time spent between each entry, exit point. If you are seeing
big gaps between entry and exit point it will be most likely TSM or
network is causing the problem. If you see big gaps between exit and
entry point, it's most likely Oracle is causing the problem.
I found an interesting RMAN restore performance problem on Oracle
Metalink web site. The bug number is 1551773 and the description of the
bug is "Rman restore runs very slowly when there are so many rows in the
ckp table". Another restore problem bug number is 1456242, "Many dbwr
wait for 'file identify' during rman restore". May be you can check to
see whether you are running into any of these bug or not.
In order to use shared memory, client and server must be at the same
level. So you must have 64 bit TSM AIX server to use shared memory. If
you have 64 bit TSM server, please see 'Configuring Shared Memory' section
in the TDPO 2.2 manual. It's written for 32 bit AIX but you will have to
do the same for 64 bit also.
regards,
Thiha
>Has anyone experienced the following or have any idea what may be up?
>Server: Oracle 8.1.7 and TSM 4.1 on the same box.
>Client: TDP for Oracle 2.2, 64 bit, commethod TCPIP
>AIX: 4.3
>Time to backup 28 GB using 1 channel: 1 hour 15mins
>Time to restore the same data using 1 channel: 20 hours and only 13 GB
has
>been sent so far.
>The same tdpo.opt file has been used for the rman backup as for the rman
>restore.
>The tape drive has been available the whole time (no media waiting).
>What could be responsible? Any chance this is an Oracle issue?
>(just for interests sake - am I right in thinking the 64 bit API will not
>work with shared memory? There was an indignant message to this effect
>when I tried to use shared mem initially, and I have a notion I've seen
>this in a readme somewhere).
|
