ADSM-L

Re: TSM S/390 performance

2002-12-10 07:53:06
Subject: Re: TSM S/390 performance
From: "MC Matt Cooper (2838)" <Matt.Cooper AT AMGREETINGS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 10 Dec 2002 07:51:19 -0500
Hi,
        TSM controls the use of the DISK pool.  The OS sees it as always
used by TSM but TSM is writing and overlaying it.   The client sends a
information on how big the file is that it is about to send.  TSM then
'reserves space on the disk pool'.  This of course only happens if you are
going to disk.  I was told it is not an issue if you are going direct to
tape.  The problem in this case was in the CLIENT CODE for DB2.  Whenever I
have talked to TSM people about high CPU use and surge like processing they
always ask if you have an bad external TDP (or API).  In my case it was a
bad API that was provided by IBM as a part of DB2.  This problem was fixed
over a year ago for us.
Matt

 -----Original Message-----
From:   Henrry Aranda [mailto:harango AT HOTMAIL DOT COM]
Sent:   Monday, December 09, 2002 6:23 PM
To:     ADSM-L AT VM.MARIST DOT EDU
Subject:        Re: TSM S/390 performance

Hi Mattt,
when you refer to the "internal space allocation process" you mean
that your Disk Storage Pool can grow on behalf of backup clients needing
more space? do you have backups going directly to tape? DB2 backup goes to
disk pool? I4m interested in your case because it seems that it has not
happened to anybody else (or nobody else is aware of it), so, i4d like to
know more about your environment, if you can tell.

Thanks for your help.

Henry Aranda Gonzales

>From: "MC Matt Cooper (2838)" <Matt.Cooper AT AMGREETINGS DOT COM>
>Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: TSM S/390 performance
>Date: Mon, 9 Dec 2002 07:58:05 -0500
>
>Hi Henrrry,
>          I had a similar type problem.   It was traced back to a DB2
>backup.
>It was a matter of the TSM server getting a bad size estimate and not
>properly saving enough disk space.  It would then have to keep going though
>the internal space allocation process.  It made TSM look very surgy in its
>response time and CPU utilization went way up.   I am not sure why your MVS
>people see going to tape as the problem.  But the FREEZING looks very
>similar.
>Matt
>
>  -----Original Message-----
>From:   Henrry Aranda [mailto:harango AT HOTMAIL DOT COM]
>Sent:   Friday, December 06, 2002 2:26 PM
>To:     ADSM-L AT VM.MARIST DOT EDU
>Subject:        TSM S/390 performance
>
>Hi list,
>environ is TSM server 4.1.2.12 on S/390 with 3494 library connected
>via FICON, 3590E tape drives, 60+ SQL Servers using TDP 2.2 and Oracle
>server on AIX 5.1 with 1,5TB of backup data (no Oracle TDP is being used),
>the 390 is connected via gigabit ethernet to the clients, the issue is when
>the backup sequence starts at night, the TSM server process "freezes" from
>time to time, that is, it doesn4t receives data nor responds to command
>line, it lasts for some seconds and then it comes to live again, have you
>seen this kind of behavior before? it doesn4t prevent the backups to
>complete but affects the total backup window and we are trying to isolate
>the error, 390 guys say that it seems that this "contention" occurs when
>TSM
>tries to access 3590 drives, is it normal? did I misconfigured something?
>
>Any comment will be helpful.
>
>Thanks
>
>Luis Tapia
>
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus

<Prev in Thread] Current Thread [Next in Thread>