I haven't tried this yet with ADSM, but I have done tuning on our Epoch
Backup systems to resolve a similar problem.  Assuming it's not due to
SQL*Backtrack, using the "no -a" command in AIX, verify your tcp_sendspace
and tcp_recvspace values on both your clients and server.  I believe that
the default for the SP2 is 16384.  The value itself is not that important,
but the values on both the client and the server must be the same.  If they
are not the same, you can change them with "no -o".  Hope this helps.

Harold

+--------------------------------------------+
|                Harold Rubin                |
|   Senior Member of Technical Staff - UNIX  |
|            Bell Atlantic Mobile            |
| 2000 Corporate Drive, Orangeburg, NY 10962 |
|   Phone: 914-365-7338  Fax: 914-365-5937   |
|        e-mail: hrubin AT mobile.bam DOT com       |
+--------------------------------------------+

-------------------------------------------------
Hi all,
Hi all,

We've been testing with ADSM and SQL*Backtrack to backup an oracle database
and we noticed a *very* slow restore time restoring a full phisical backup.

The configuration is: RS/6000 SP, thin node with ADSM Server 2.1.5.13,
other
hin node with ADSM Client 2.1.0.6, SQL Backtrack 2.2.1 and Oracle 7.3.2. OS
is AIX 4.1.5. Backups are going through the SP switch directly to a 3590.

When we backup, we get about 4MB/sec throughput, but only 800KB/sec on
restores. We notice there is a large amount of idle CPU during restores.

We tried with client and server on the same node using shared memory and we
get close to 3MB/sec on restores, but using tcpip we still get the same
800KB/sec. So it seems to be tcp related, but we have no clue as why it's
only affecting the restores.

Anyone experienced this before?

--
Rui Malheiro,
Rui Malheiro,
6 Mil - Tecnologias de Informacao
URL: <http://www.6mil.pt/>