SV: Group Buffer Pools Size

Olle Brostrom

SV: Group Buffer Pools Size
In a 4-way DS-system we have the following configuration for the largest pools:

Each BP2 is 200,000 buffers. GBP2 is 1GB
Each BP3 is 300,000 buffers. GBP3 is 3GB

The workload is equal balanced by WLM over the 4 systems, there are no affinities .
The size of your GBP's is very dependent on the amount of updates in the systems and the workload balancing.

Olle

Från: IDUG DB2-L [mailto:[login to unmask email] För Jose Antonio
Skickat: den 29 januari 2010 10:00
Till: [login to unmask email]
Ämne: [DB2-L] Group Buffer Pools Size

Hi!

We are going to increase Group Buffer Pools size from 75Mb to 150Mb each. I think it is not a very big size. In your experience
which sizes are you having in your installations??

Thanks a lot!!!!



__________________________
José A Morcillo Valenciano
Tfno.: +34 965 90 51 43
747-Producción Informática
[cid:[login to unmask email] ] < http://www.cam.es/ >
__________________________




Este correo electrónico es confidencial. Si lo ha recibido por error, por favor

contacte con el remitente y destruya su contenido. Toda la información relativa a

la Protección de Datos de Carácter Personal, se encuentra a su disposición en la

página web www.cam.es , en el apartado Aviso legal



This e-mail is confidential. If you have received this e-mail in error, please contact

the sender and delete it from your system. All information about Personal Data

Protection can be found on the website www.cam.es , in the Legal Disclaimer section


________________________________

[ http://www.idug.org/images/M_images/idug%20na3.jpg ] < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Joel Goldstein

Re: Group Buffer Pools Size
(in response to Olle Brostrom)
Jose,

Are you having performance problems with your GBP's?
That's the only reason to make them bigger, if size alone is the issue.

They are ways to calculate the required size of theGBP's instead of guessing, and just doubling them.

Regards,
Joel


Joel Goldstein
Responsive Systems
IBM Gold Consultant
Buffer Pool Tool for DB2, the worldwide industry standard
Performance software that works...... Predicts IO Rate !!
Predicts Group Buffer Pool performance too
www.responsivesystems.com

Buffer Pool Tool for DB2 on www.LinkedIn.com
Watch the 3-Minute Buffer Pool Tool Movie at: www.responsivesystems.com/Movie1

tel. (732) 972-1261
fax.(732) 972-9416
----- Original Message -----
From: Jose Antonio
Newsgroups: bit.listserv.db2-l
To: [login to unmask email]
Sent: Friday, January 29, 2010 3:59 AM
Subject: [DB2-L] Group Buffer Pools Size


Hi!



We are going to increase Group Buffer Pools size from 75Mb to 150Mb each. I think it is not a very big size. In your experience

which sizes are you having in your installations??



Thanks a lot!!!!







__________________________
José A Morcillo Valenciano
Tfno.: +34 965 90 51 43
747-Producción Informática



__________________________





Este correo electrónico es confidencial. Si lo ha recibido por error, por favor
contacte con el remitente y destruya su contenido. Toda la información relativa a
la Protección de Datos de Carácter Personal, se encuentra a su disposición en la
página web www.cam.es , en el apartado Aviso legal

This e-mail is confidential. If you have received this e-mail in error, please contact
the sender and delete it from your system. All information about Personal Data
Protection can be found on the website www.cam.es , in the Legal Disclaimer section


------------------------------------------------------------------------------



The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Leslie

Re: Group Buffer Pools Size
(in response to Joel Goldstein)
Hi Jose

it is important to size your GBPs so they reflect the workload (systems
interest) in your system.

what is the point of making your GBPs big for the sake of it?

Remember this, all landscapes will be different based on business need,
physical availability (available storage in the CF etc), and more
importantly available $$$.

My opinion is that I would rather have storage available for use in my local
BPs than over allocated in my GBPs. (Lot[s of reasons why here)

(side point - Of course use of new features such as AUTOALTER will also help
you in ensuing the size of your GBPs is kept inline with use.)

Lastly 150mb is not HUGE, we used to have some that were 4 or 500mb (or
more) in a SAP DS system I once built(row level locking, no app split).

also remember that if you have a secondary CF and you increase use in the
Primary you will need to increase available storage in the secondary.

You could lot worse than read the Datasharing in a Nutshell redbook ...

< http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf >
http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf


regards

Leslie


_____

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Jose Antonio
Sent: 29 January 2010 09:00
To: [login to unmask email]
Subject: [DB2-L] Group Buffer Pools Size



Hi!



We are going to increase Group Buffer Pools size from 75Mb to 150Mb each. I
think it is not a very big size. In your experience

which sizes are you having in your installations??



Thanks a lot!!!!








__________________________
José A Morcillo Valenciano
Tfno.: +34 965 90 51 43
747-Producción Informática

< http://www.cam.es/ >

__________________________






Este correo electrónico es confidencial. Si lo ha recibido por error, por
favor

contacte con el remitente y destruya su contenido. Toda la información
relativa a

la Protección de Datos de Carácter Personal, se encuentra a su disposición
en la

página web www.cam.es , en el apartado Aviso legal



This e-mail is confidential. If you have received this e-mail in error,
please contact

the sender and delete it from your system. All information about Personal
Data

Protection can be found on the website www.cam.es , in the Legal Disclaimer
section

_____


< http://www.idug.org/db2-north-america-conference/index.html > IDUG - The
Worldwide DB2 User Community!

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please < http://www.idug.org/register > register
here.

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2654 - Release Date: 01/28/10
19:36:00



_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Jose Antonio

Re: Group Buffer Pools Size
(in response to Leslie)
Thanks Leslie!



I'm agree with you, it's pointless making GBP bigger and bigger. We'll study our needs based on our bussiness.



It was just curiosity...



Thanks again!!



__________________________
José A Morcillo Valenciano
Tfno.: +34 965 90 51 43
747-Producción Informática

< http://www.cam.es/ >

__________________________





________________________________

De: IDUG DB2-L [mailto:[login to unmask email] En nombre de Leslie
Enviado el: lunes, 01 de febrero de 2010 12:51
Para: [login to unmask email]
Asunto: Re: [DB2-L] Group Buffer Pools Size



Hi Jose



it is important to size your GBPs so they reflect the workload (systems interest) in your system.



what is the point of making your GBPs big for the sake of it?



Remember this, all landscapes will be different based on business need, physical availability (available storage in the CF etc), and more importantly available $$$.



My opinion is that I would rather have storage available for use in my local BPs than over allocated in my GBPs. (Lot[s of reasons why here)



(side point - Of course use of new features such as AUTOALTER will also help you in ensuing the size of your GBPs is kept inline with use.)



Lastly 150mb is not HUGE, we used to have some that were 4 or 500mb (or more) in a SAP DS system I once built(row level locking, no app split).



also remember that if you have a secondary CF and you increase use in the Primary you will need to increase available storage in the secondary.



You could lot worse than read the Datasharing in a Nutshell redbook ...



http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf < http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf >





regards



Leslie





________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Jose Antonio
Sent: 29 January 2010 09:00
To: [login to unmask email]
Subject: [DB2-L] Group Buffer Pools Size

Hi!



We are going to increase Group Buffer Pools size from 75Mb to 150Mb each. I think it is not a very big size. In your experience

which sizes are you having in your installations??



Thanks a lot!!!!







__________________________
José A Morcillo Valenciano
Tfno.: +34 965 90 51 43
747-Producción Informática

< http://www.cam.es/ >

__________________________





Este correo electrónico es confidencial. Si lo ha recibido por error, por favor
contacte con el remitente y destruya su contenido. Toda la información relativa a
la Protección de Datos de Carácter Personal, se encuentra a su disposición en la
página web www.cam.es , en el apartado Aviso legal

This e-mail is confidential. If you have received this e-mail in error, please contact
the sender and delete it from your system. All information about Personal Data
Protection can be found on the website www.cam.es , in the Legal Disclaimer section



________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2654 - Release Date: 01/28/10 19:36:00


________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >


Este correo electrónico es confidencial. Si lo ha recibido por error, por favor
contacte con el remitente y destruya su contenido. Toda la información relativa a
la Protección de Datos de Carácter Personal, se encuentra a su disposición en la
página web www.cam.es , en el apartado Aviso legal

This e-mail is confidential. If you have received this e-mail in error, please contact
the sender and delete it from your system. All information about Personal Data
Protection can be found on the website www.cam.es , in the Legal Disclaimer section

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Robert Catterall

Re: Group Buffer Pools Size
(in response to Jose Antonio)
Sorry about the delayed response, Jose -- I got behind on checking DB2-L
posts.

If you have unallocated memory in your CF LPARs, and if structures other
than your GBPs are already adequately sized, it's hard to see the harm in
enlarging one or more GBPs. If you have a GBP for which you see a non-zero
value for "write failures due to lack of storage" (you can get this value
from a DB2 monitor statistics report or online display, or from the output
of a -DISPLAY GROUPBUFFERPOOL DETAIL command), you should definitely make
the GBP bigger (write failures due to lack of storage are an indication of a
GBP thrashing situation). If you see a non-zero value for
"cross-invalidations due to directory reclaim" (this can be obtained via
-DISPLAY GROUPBUFFERPOOL DETAIL), it would probably be a good idea to make
the GBP larger. Cross-invalidations due to directory entry reclaims are an
indication that the GBP does not have enough directory entries. Enlarging
the GBP will result in the GBP having more directory entries (you can also
increase the number of directory entries in the GBP by increasing the ratio
of directory entries to data entries for the GBP, but if you do this without
increasing the size of the GBP you will have fewer data entries and that
could negatively impact performance).

If you don't see any write failures due to lack of GBP storage, and you
don't see any cross invalidations due to directory entry reclaims, a GBP
size increase is not a "must-do," but you could still, or course, make a GBP
larger and you might see a performance benefit from doing so. If you have
zeros for write failures due to lack of storage and for cross-invalidations
due to directory entry reclaims, and you are still interested in enlarging a
GBP, here's what I'd do: using your DB2 monitor, check to see how often a
GBP access to search for a page that was changed by another member results
in a GBP "hit." To do that, get (from a DB2 monitor statistics report, in
the section that contains group buffer pool activity, or from an online
display of GBP activity) these two values: SYN.READS(XI) - DATA RETURNED,
and SYN.READS(XI) - NO DATA RETURN (the fields may have names that differ
slightly from these, depending on the monitor product in use). Divide the
first value by the sum of the two values. For example, if the value for
SYN.READS(XI) - DATA RETURNED is 7000 and the value for SYN.READS(XI) - NO
DATA RETURN is 3000, the ratio is 7000 / (7000 + 3000) = 70%.

SYN.READS(XI) refers to synchronous GBP requests that occur when a member
DB2 subsystem has to look for a page in a GBP because the version of the
page it has cached in its local buffer pool has been invalidated. If you
don't have any cross invalidations due to directory entry reclaims, then
cross invalidations would occur due to page updates. So, if member DB2A
reads in page X from some tablespace or index that is GBP-dependent, it
registers interest in that page via a GBP request. If member DB2B updates
page X, it will write the updated version of page X to the GBP, and the (now
old) version of page X cached locally in a DB2A buffer pool will be marked
invalid. When a process on DB2A requests page X, DB2A will see that its
local copy is invalid and will look for the current version of page X in the
GBP. If it finds the page there, it'll get it in something like 20-30
microseconds. If it doesn't find page X in the GBP (because it was cast out
to disk and the GBP data entry holding the updated page X was subsequently
stolen to make room for a new GBP write), it will retrieve the page from
disk.

So, if you make a GBP bigger and you see that the ratio of SYN.READS(XI) -
DATA RETURNED to (SYN.READS(XI) - DATA RETURNED + SYN.READS(XI) - NO DATA
RETURN) for the member DB2 subsystems has gone up for that GBP, you've
probably helped yourself out, performance-wise, because GBP checks for
current versions of updated pages are more often resulting in "page found"
situations. Getting a page from disk is fast, but getting it from the GBP is
2 orders of magnitude faster (3 orders of magnitude if you have to get the
page from spinning disk versus disk controller cache).

By the way, SYN.READS(NF) - DATA RETURNED and SYN.READS(NF) - NO DATA RETURN
are numbers that aren't so useful in terms of gauging the effect of a GBP
size increase. These reflect GBP reads prompted by "page not found locally"
situations, versus "page found locally, but marked invalid." When a GBP read
is due to page invalidation and you don't have invalidations due to
directory entry reclaims, you know they were caused by page updates by
processes running on other group members. In such cases, the changed pages
(the ones you're looking for when the GBP reads are of the SYN.READS(XI)
variety) had to have been written to the GBP by the page-changing DB2
member, so you should have a reasonably decent chance of finding those pages
in the GBP (depending on how long they stay there, and that's affected by
GBP size increases). For SYN.READS(NF), DB2 is looking in the GBP for a page
it needs and which it doesn't have in a local buffer pool. You have to do
that (prior to getting the page from disk) if the target page set is
GBP-dependent, but a GBP "hit" for such a read is, generally speaking, not
very likely.

Robert


On Mon, Feb 1, 2010 at 7:45 AM, Jose Antonio <[login to unmask email]> wrote:

> Thanks Leslie!
>
>
>
> I’m agree with you, it’s pointless making GBP bigger and bigger. We’ll
> study our needs based on our bussiness.
>
>
>
> It was just curiosity…
>
>
>
> Thanks again!!
>
>
>
> __________________________
> José A Morcillo Valenciano
> Tfno.: +34 965 90 51 43
> 747-Producción Informática
>
> < http://www.cam.es/ >
>
> __________________________
>
>
>
>
> ------------------------------
>
> *De:* IDUG DB2-L [mailto:[login to unmask email] *En nombre de *Leslie
> *Enviado el:* lunes, 01 de febrero de 2010 12:51
> *Para:* [login to unmask email]
> *Asunto:* Re: [DB2-L] Group Buffer Pools Size
>
>
>
> Hi Jose
>
>
>
> it is important to size your GBPs so they reflect the workload (systems
> interest) in your system.
>
>
>
> what is the point of making your GBPs big for the sake of it?
>
>
>
> Remember this, all landscapes will be different based on business need,
> physical availability (available storage in the CF etc), and more
> importantly available $$$.
>
>
>
> My opinion is that I would rather have storage available for use in my
> local BPs than over allocated in my GBPs. (Lot[s of reasons why here)
>
>
>
> (side point - Of course use of new features such as AUTOALTER will also
> help you in ensuing the size of your GBPs is kept inline with use.)
>
>
>
> Lastly 150mb is not HUGE, we used to have some that were 4 or 500mb (or
> more) in a SAP DS system I once built(row level locking, no app split).
>
>
>
> also remember that if you have a secondary CF and you increase use in the
> Primary you will need to increase available storage in the secondary.
>
>
>
> You could lot worse than read the Datasharing in a Nutshell redbook ...
>
>
>
> http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf
>
>
>
>
>
> regards
>
>
>
> Leslie
>
>
>
>
> ------------------------------
>
> *From:* IDUG DB2-L [mailto:[login to unmask email] *On Behalf Of *Jose
> Antonio
> *Sent:* 29 January 2010 09:00
> *To:* [login to unmask email]
> *Subject:* [DB2-L] Group Buffer Pools Size
>
> Hi!
>
>
>
> We are going to increase Group Buffer Pools size from 75Mb to 150Mb each. I
> think it is not a very big size. In your experience
>
> which sizes are you having in your installations??
>
>
>
> Thanks a lot!!!!
>
>
>
>
>
>
>
> __________________________
> José A Morcillo Valenciano
> Tfno.: +34 965 90 51 43
> 747-Producción Informática
>
> < http://www.cam.es/ >
>
> __________________________
>
>
>
>
>
> Este correo electrónico es confidencial. Si lo ha recibido por error, por favor
>
> contacte con el remitente y destruya su contenido. Toda la información relativa a
>
> la Protección de Datos de Carácter Personal, se encuentra a su disposición en la
>
> página web www.cam.es , en el apartado Aviso legal
>
>
>
> This e-mail is confidential. If you have received this e-mail in error, please contact
>
> the sender and delete it from your system. All information about Personal Data
>
> Protection can be found on the website www.cam.es , in the Legal Disclaimer section
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.733 / Virus Database: 271.1.1/2654 - Release Date: 01/28/10
> 19:36:00
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>
> Este correo electrónico es confidencial. Si lo ha recibido por error, por favor
> contacte con el remitente y destruya su contenido. Toda la información relativa a
> la Protección de Datos de Carácter Personal, se encuentra a su disposición en la
> página web www.cam.es , en el apartado Aviso legal
>
> This e-mail is confidential. If you have received this e-mail in error, please contact
> the sender and delete it from your system. All information about Personal Data
> Protection can be found on the website www.cam.es , in the Legal Disclaimer section
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community!] < http://www.idug.org >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>



--
Robert Catterall
Catterall Consulting
www.catterallconsulting.com

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Jose Antonio

Re: Group Buffer Pools Size
(in response to Robert Catterall)
Hi Robert!



Thank you very much for such a clear explanation! We are looking through all this values to decide whether to increase GBP size or

leave with 150Mb



Thanks again and congratulations for your blog!





__________________________
José A Morcillo Valenciano
Tfno.: +34 965 90 51 43
747-Producción Informática

< http://www.cam.es/ >

__________________________





________________________________

De: IDUG DB2-L [mailto:[login to unmask email] En nombre de Robert Catterall
Enviado el: jueves, 04 de febrero de 2010 21:16
Para: [login to unmask email]
Asunto: Re: [DB2-L] Group Buffer Pools Size



Sorry about the delayed response, Jose -- I got behind on checking DB2-L posts.

If you have unallocated memory in your CF LPARs, and if structures other than your GBPs are already adequately sized, it's hard to see the harm in enlarging one or more GBPs. If you have a GBP for which you see a non-zero value for "write failures due to lack of storage" (you can get this value from a DB2 monitor statistics report or online display, or from the output of a -DISPLAY GROUPBUFFERPOOL DETAIL command), you should definitely make the GBP bigger (write failures due to lack of storage are an indication of a GBP thrashing situation). If you see a non-zero value for "cross-invalidations due to directory reclaim" (this can be obtained via -DISPLAY GROUPBUFFERPOOL DETAIL), it would probably be a good idea to make the GBP larger. Cross-invalidations due to directory entry reclaims are an indication that the GBP does not have enough directory entries. Enlarging the GBP will result in the GBP having more directory entries (you can also increase the number of directory entries in the GBP by increasing the ratio of directory entries to data entries for the GBP, but if you do this without increasing the size of the GBP you will have fewer data entries and that could negatively impact performance).

If you don't see any write failures due to lack of GBP storage, and you don't see any cross invalidations due to directory entry reclaims, a GBP size increase is not a "must-do," but you could still, or course, make a GBP larger and you might see a performance benefit from doing so. If you have zeros for write failures due to lack of storage and for cross-invalidations due to directory entry reclaims, and you are still interested in enlarging a GBP, here's what I'd do: using your DB2 monitor, check to see how often a GBP access to search for a page that was changed by another member results in a GBP "hit." To do that, get (from a DB2 monitor statistics report, in the section that contains group buffer pool activity, or from an online display of GBP activity) these two values: SYN.READS(XI) - DATA RETURNED, and SYN.READS(XI) - NO DATA RETURN (the fields may have names that differ slightly from these, depending on the monitor product in use). Divide the first value by the sum of the two values. For example, if the value for SYN.READS(XI) - DATA RETURNED is 7000 and the value for SYN.READS(XI) - NO DATA RETURN is 3000, the ratio is 7000 / (7000 + 3000) = 70%.

SYN.READS(XI) refers to synchronous GBP requests that occur when a member DB2 subsystem has to look for a page in a GBP because the version of the page it has cached in its local buffer pool has been invalidated. If you don't have any cross invalidations due to directory entry reclaims, then cross invalidations would occur due to page updates. So, if member DB2A reads in page X from some tablespace or index that is GBP-dependent, it registers interest in that page via a GBP request. If member DB2B updates page X, it will write the updated version of page X to the GBP, and the (now old) version of page X cached locally in a DB2A buffer pool will be marked invalid. When a process on DB2A requests page X, DB2A will see that its local copy is invalid and will look for the current version of page X in the GBP. If it finds the page there, it'll get it in something like 20-30 microseconds. If it doesn't find page X in the GBP (because it was cast out to disk and the GBP data entry holding the updated page X was subsequently stolen to make room for a new GBP write), it will retrieve the page from disk.

So, if you make a GBP bigger and you see that the ratio of SYN.READS(XI) - DATA RETURNED to (SYN.READS(XI) - DATA RETURNED + SYN.READS(XI) - NO DATA RETURN) for the member DB2 subsystems has gone up for that GBP, you've probably helped yourself out, performance-wise, because GBP checks for current versions of updated pages are more often resulting in "page found" situations. Getting a page from disk is fast, but getting it from the GBP is 2 orders of magnitude faster (3 orders of magnitude if you have to get the page from spinning disk versus disk controller cache).

By the way, SYN.READS(NF) - DATA RETURNED and SYN.READS(NF) - NO DATA RETURN are numbers that aren't so useful in terms of gauging the effect of a GBP size increase. These reflect GBP reads prompted by "page not found locally" situations, versus "page found locally, but marked invalid." When a GBP read is due to page invalidation and you don't have invalidations due to directory entry reclaims, you know they were caused by page updates by processes running on other group members. In such cases, the changed pages (the ones you're looking for when the GBP reads are of the SYN.READS(XI) variety) had to have been written to the GBP by the page-changing DB2 member, so you should have a reasonably decent chance of finding those pages in the GBP (depending on how long they stay there, and that's affected by GBP size increases). For SYN.READS(NF), DB2 is looking in the GBP for a page it needs and which it doesn't have in a local buffer pool. You have to do that (prior to getting the page from disk) if the target page set is GBP-dependent, but a GBP "hit" for such a read is, generally speaking, not very likely.

Robert



On Mon, Feb 1, 2010 at 7:45 AM, Jose Antonio <[login to unmask email]> wrote:

Thanks Leslie!



I'm agree with you, it's pointless making GBP bigger and bigger. We'll study our needs based on our bussiness.



It was just curiosity...



Thanks again!!



__________________________
José A Morcillo Valenciano
Tfno.: +34 965 90 51 43
747-Producción Informática

< http://www.cam.es/ >

__________________________





________________________________

De: IDUG DB2-L [mailto:[login to unmask email] En nombre de Leslie
Enviado el: lunes, 01 de febrero de 2010 12:51
Para: [login to unmask email]
Asunto: Re: [DB2-L] Group Buffer Pools Size



Hi Jose



it is important to size your GBPs so they reflect the workload (systems interest) in your system.



what is the point of making your GBPs big for the sake of it?



Remember this, all landscapes will be different based on business need, physical availability (available storage in the CF etc), and more importantly available $$$.



My opinion is that I would rather have storage available for use in my local BPs than over allocated in my GBPs. (Lot[s of reasons why here)



(side point - Of course use of new features such as AUTOALTER will also help you in ensuing the size of your GBPs is kept inline with use.)



Lastly 150mb is not HUGE, we used to have some that were 4 or 500mb (or more) in a SAP DS system I once built(row level locking, no app split).



also remember that if you have a secondary CF and you increase use in the Primary you will need to increase available storage in the secondary.



You could lot worse than read the Datasharing in a Nutshell redbook ...



http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf < http://www.redbooks.ibm.com/redbooks/pdfs/sg247322.pdf >





regards



Leslie





________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Jose Antonio
Sent: 29 January 2010 09:00
To: [login to unmask email]
Subject: [DB2-L] Group Buffer Pools Size

Hi!



We are going to increase Group Buffer Pools size from 75Mb to 150Mb each. I think it is not a very big size. In your experience

which sizes are you having in your installations??



Thanks a lot!!!!







__________________________
José A Morcillo Valenciano
Tfno.: +34 965 90 51 43
747-Producción Informática

< http://www.cam.es/ >

__________________________





Este correo electrónico es confidencial. Si lo ha recibido por error, por favor
contacte con el remitente y destruya su contenido. Toda la información relativa a
la Protección de Datos de Carácter Personal, se encuentra a su disposición en la
página web www.cam.es , en el apartado Aviso legal


This e-mail is confidential. If you have received this e-mail in error, please contact
the sender and delete it from your system. All information about Personal Data
Protection can be found on the website www.cam.es , in the Legal Disclaimer section



________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2654 - Release Date: 01/28/10 19:36:00



________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

Este correo electrónico es confidencial. Si lo ha recibido por error, por favor
contacte con el remitente y destruya su contenido. Toda la información relativa a
la Protección de Datos de Carácter Personal, se encuentra a su disposición en la
página web www.cam.es , en el apartado Aviso legal

This e-mail is confidential. If you have received this e-mail in error, please contact
the sender and delete it from your system. All information about Personal Data
Protection can be found on the website www.cam.es , in the Legal Disclaimer section



________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >




--
Robert Catterall
Catterall Consulting
www.catterallconsulting.com

________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >


Este correo electrónico es confidencial. Si lo ha recibido por error, por favor
contacte con el remitente y destruya su contenido. Toda la información relativa a
la Protección de Datos de Carácter Personal, se encuentra a su disposición en la
página web www.cam.es , en el apartado Aviso legal

This e-mail is confidential. If you have received this e-mail in error, please contact
the sender and delete it from your system. All information about Personal Data
Protection can be found on the website www.cam.es , in the Legal Disclaimer section

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
** Your only source for independent, unbiased, and trusted DB2 information.

_____________________________________________________________________
http://www.IDUG.org/mentor
How can you expand your staff or do succession planning in this economy?
Mentoring is a proven, economical, way to train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L