If you are going to increase the BUFPoolsize parameter make sure you do it
based on
the amount of System Memory (MB). 'An optimal setting for the database
buffer pool is one in which the cache hit percentage is greater than or
equal to 98%. If you have enough memory, increase in 1MB increments. A cache
hit percentage greater than 99% is an indication that the proper BUFPoolsize
has been reached. While increasing BUFPoolsize, care must be taken not to
cause paging in the virtual memory system. Monitor system memory usage to
check for any increased paging after the BUFPoolsize change. (Use the RESET
BUFP command to reset the cache hit statistics.)'

Regards,

Demetrius Malbrough
UNIX/TSM Administrator




-----Original Message-----
From: William F. Colwell [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 25, 2002 1:13 PM
To: [EMAIL PROTECTED]
Subject: Re: Database Specs


Joe - the number of volumes isn't the problem.  You need to increase the
bufpoolsize in the server
dsm.opt file.  Here is a 'q db f=d' from my system.  The bufpoolsize
parameter becomes the
'buffer pool pages' value in the q db.

Bill Colwell
- - -
tsm: NEW_ADSM_SERVER_ON_PORT_1600>q db f=d

          Available Space (MB): 166,860
        Assigned Capacity (MB): 166,860
        Maximum Extension (MB): 0
        Maximum Reduction (MB): 18,640
             Page Size (bytes): 4,096
            Total Usable Pages: 42,716,160
                    Used Pages: 37,947,974
                      Pct Util: 88.8
                 Max. Pct Util: 88.8
              Physical Volumes: 45
             Buffer Pool Pages: 65,536
         Total Buffer Requests: 194,057,057
                Cache Hit Pct.: 98.44
               Cache Wait Pct.: 0.00
           Backup in Progress?: No
    Type of Backup In Progress:
  Incrementals Since Last Full: 5
Changed Since Last Backup (MB): 1,542.07
            Percentage Changed: 1.04
Last Complete Backup Date/Time: 01/24/2002 15:49:51
- - -
At 12:54 PM 1/25/2002 -0500, you wrote:
>I'm running TSM v 4.1.3 on System\390.  My database is 47G and spread
across 25 physical volumes (gets a 78% cache hit / not so great).
>
>One of my performance and tuning books recommends not spreading your
database over more than 12 physical volumes.  Could anyone explain why?
What kind of performance/utilazation "hit" am I going to
>incur by having my db spread across 25 volumes?
>
>Regards,
>Joe Wholey
>TGA Distributed Data Services
>Merrill Lynch
>Phone: 212-647-3018
>Page:  888-637-7450
>E-mail: [EMAIL PROTECTED]

----------
Bill Colwell
C. S. Draper Lab
Cambridge Ma.

Reply via email to