rch 21, 2001 10:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: SAP and 3494 performance.
>
>
> Why not just set the MIGPROCESS=5 when you lower the migration threshold? Do
> yo find the MOVE DATA more effecient than the MIGRATION processes?
>
> Bill Boyer
> DSS, Inc.
&
x27;s data within the pool...
If the pool is filled by only a single node's data, then only one migration
process will run.
Dwight
-Original Message-
From: William Boyer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 10:26 AM
To: [EMAIL PROTECTED]
Subject: Re: SAP and 3494 p
Another fix, if you're running multiple backup streams from the client, is
to have a MAXSIZE established for the DASD pool. This will cause larger
files to go straight to tape, keeping them off the disk. They don't have
to migrate, and it gives the migration process some time to catch up.
Nick
; From: William Boyer [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 9:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: SAP and 3494 performance.
>
>
> Why not just set the MIGPROCESS=5 when you lower the
> migration threshold? Do
> yo find the MOVE DATA more effec
]
Subject: Re: SAP and 3494 performance.
Why not just set the MIGPROCESS=5 when you lower the migration threshold? Do
yo find the MOVE DATA more effecient than the MIGRATION processes?
Bill Boyer
DSS, Inc.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On
aylor/HAV/SSE)
Subject: Re: SAP and 3494 performance.
Why not just set the MIGPROCESS=5 when you lower the migration threshold? Do
yo find the MOVE DATA more effecient than the MIGRATION processes?
Bill Boyer
DSS, Inc.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL P
--Original Message-
From: bbullock [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 9:38 AM
To: [EMAIL PROTECTED]
Subject: Re: SAP and 3494 performance.
Hmmm, an inventive way to get a large client to multi-thread the
migration to tape. Thanks for the idea, I'll have to lo
, 2001 10:38 AM
To: [EMAIL PROTECTED]
Subject: Re: SAP and 3494 performance.
Hmmm, an inventive way to get a large client to multi-thread the
migration to tape. Thanks for the idea, I'll have to look into writing a
script myself to do it on one of my TSM servers.
Thanks,
Ben Bullock
-
> From: Davidson, Becky [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 7:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: SAP and 3494 performance.
>
>
> We ran into the same issue on the migration so our solution was do two
> things. Our backups start at 4pm.
shion.
-Original Message-
From: Cook, Dwight E [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 1:02 PM
To: [EMAIL PROTECTED]
Subject: Re: SAP and 3494 performance.
Our client is a Sun E10K with ?24 processors? maybe more if that is
possible... it has a bunch
And we have other AIX
little harder... just the
way we do it.
Dwight
-Original Message-
From: Richard L. Rhodes [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 7:23 AM
To: Cook, Dwight E; [EMAIL PROTECTED]
Subject: Re: SAP and 3494 performance.
Thanks for great info!
q) What kind of a client system are
Thanks for great info!
q) What kind of a client system are you using?
- machine type
- # of processors
q) When you say "> don't multiplex with tdp" I'm not sure what you
mean.
- Are you using TDP for SAP?
- Why Not?
Thanks!
Rick
On 20 Mar 2001, at 10:59, Coo
alter to go to diskpool first
use tsm client compression
don't multiplex with tdp
run about 10-20 concurrent client sessions (based on processor ability)
you should see about 4/1 compression
you should see about 11.6 MB/sec data transfer (if things are really OK &
processor can keep up)
you should
How many threads are you using?
Are you using tsm client compression or tdp compression? we found that
client compression killed us on the cpu side.
-Original Message-
From: Francisco Molero [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 9:35 AM
To: [EMAIL PROTECTED]
Subject: S
OK, I'll bite. We don't use the TDB client, we use home grown
scripts that use the standard TSM archive client, but I believe the
bottleneck in your case was the same as mine.
The bottleneck in your scenario is the 100Mb Ethernet interface. In
our testing, we find that a TSM sessi
You have not said by how much compression has reduced the 350 gb
ie. how much data are you actually sending over the network.
6 hours might be very good.
Francisco Molero <[EMAIL PROTECTED]> on 03/20/2001 03:35:06 PM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMA
16 matches
Mail list logo