Thanks... -----Original Message----- From: Malbrough, Demetrius [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 2:30 PM To: [EMAIL PROTECTED] Subject: Re: Database Specs
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.
