Item Subject: disk pool space reserved for compressed data
     I am truely shocked here... I would have thought, seeing how this is
     comming from IBM that the answer would be "purchase more disks" and
     the shame of it is I would agree....   I'm running three adsm
     environments and building two more and on each I've plopped down 200GB
     disk pools... YES, I do back up a large SAP DB as a matter of fact
     with the test, quality, training, and on and on... SAP regions I
     backup about 10 large SAP DB's... and a whole bunch of other
     servers...  I don't know any details here but if they are only backing
     up one SAP DB I would say they aren't taking advantage of ADSM and
     they sould buy enough dasd to cover their main need and then expand
     ADSM's use to other machines to take advantage of the resources....
     That's pretty much how I've ended up where I am today... started with
     covering a need (our limit was time only... not $$$'s) once SAP's
     needs were met it was no problem filling the spare time on the server
     by backing up other machines... then the other backups went so well
     that node admin's wanted to switch more of their nodes to adsm and we
     max'ed out that environment... which brought us to new adsm
     environments... which spread the word of adsm further... and on and on
     to 5 servers, 4 ATL's, bunch of 3590's, and a whole bunch of disks...
     Nothing is going to waste....
     later
          Dwight



______________________________ Reply Separator _________________________________
Subject: disk pool space reserved for compressed data
Author:  ADSM-L (ADSM-L AT VM.MARIST DOT EDU) at unix,sh
Date:    1/6/97 3:22 PM


Customer backs up an AT&T SAP R/3 database with the Backint API client
using multiple concurrent sessions (client is a 8 processor CPU and
FDDI network).
Because the whole backup must fit on a disk storage pool, client
compression is switched on. The compression rate is very high.
The compressed files need only 25 % of the original space.
The files to be backed up are large database files.

We found the following problem :
When the client starts to transfer such a big file, the server
seems to reserve disk pool space in the size of the original
client file. When all 8 sessions want to start the transfer,
there is not enough space on the server side to hold all the
client files in their original size. This results in media-wait
conditions for some of the sessions. When the first sessions has
ended transferring their files that need actually much less space
because of the compression rate, the sessions in the media-wait
can reserve the requested server space and begin transferring
files.
So the problem is : the server storage is large enough
to hold all client files in compressed form but not large enough
to temporary reserve space for uncompressed files.
So the possible level of parallelism is reduced in this
installation.

Is there any way to solve this problem ?

Frank Hoehnel
IBM Dresden/Germany