Michael,
Yes, I've set up a management class for my SAP BRBACKUPS to go directly to the
2 3590's. I have 2 sessions setup in the initSID.utl file, so 2 backups streams
are established, one to each drive.
I do backup over the SP Parallel Switch with compression turned off in the
client (it is much better to let the 3590 hardware do the compression, in my
opinion, as I have plenty of bandwidth on the switch).
Incidentally, I've heard of a couple of methods to increase throughput again.
1. You can change the rpoolsize and spoolsize settings of the switch from the
default 512k to a higher setting, say, 10MB. This can improve throughput.
2. Another, more interesting option, that I've heard of but not yet tried, is
to setup a storagepool on disk and enable scratch volumes to be used on the
disk pool. You can set the migration of this pool to higmig 1 and lowmig 0. Now
in the initSID.utl you can setup more sessions than you have output devices and
let ADSM migrate this pool to your tape drives. As scratch volumes are created
in the Diskpool ADSM will almost immediatly migrate them to the tape storage
pool. I've heard that ADSM migration is more 'efficient' at migrating data than
writing it direct to tape from a client.
I've still to get detail on exactly how this is setup but I've heard of a site
near me that has been able to get up to 35-38GB h/r using this method.
(migrating to 1 3590).
My limiting factor, on increasing the rate, is that, at present, my SAP R/3
systems are running on 'thin' nodes. These nodes do not have enough cpu
horsepower to push the data out any faster (100% utilised during backup). These
SAP system are development systems but we are going to start installing our
production SAP systems to high nodes. I will be very interested in seeing how
my backups perform from these grunters.
As I am still relatively new to AIX, ADSM and SP (I'm an old VM Sysprog) I am
still learning how this stuff hangs together. I suspect I could probably do
some TCP tuning, but havent had the courage (or time) to look at this.
Time will tell if this is good way to run ADSM SAP R/3 backup, or if the above
ramble isnt worth a pinch of dried parrot poop.
Best Regards,
Peter Zutenis
Principal Systems Programmer.
Philip Morris Information Services Ltd.
Moorabbin, Australia.
|
