469,271 Members | 1,785 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,271 developers. It's quick & easy.

BP: blocked vs non-blocked

In 9.1 (Linux 64 bit) when a buffer pool is set to self-tuning, does this
imply that the blocked versus non-blocked aspect is also self-tuning?
If not, what is a good rule of thumb for a 64 bit system using the Linux
file system for containers for the tablespace using that buffer pool?

Thanks
nat
Aug 23 '06 #1
4 1704
Ian
natG wrote:
In 9.1 (Linux 64 bit) when a buffer pool is set to self-tuning, does this
imply that the blocked versus non-blocked aspect is also self-tuning?
If not, what is a good rule of thumb for a 64 bit system using the Linux
file system for containers for the tablespace using that buffer pool?
Going from memory, but I am pretty sure that STMM does not affect the
block size or number of block pages in a bufferpool.

I have heard a rule of thumb of 2-3% of a bufferpool being allocated
to the block-based area.

FYI, block-based bufferpools are useful for data warehousing and large
batch jobs because they allow the prefetchers to handle sequential
prefetch requests more efficiently. If your app doesn't do a lot of
sequential prefetching, then this won't be a useful feature.
Aug 24 '06 #2
On Thu, 24 Aug 2006 00:56:50 -0700, Ian wrote:
<snip>
FYI, block-based bufferpools are useful for data warehousing and large
batch jobs because they allow the prefetchers to handle sequential
prefetch requests more efficiently. If your app doesn't do a lot of
sequential prefetching, then this won't be a useful feature.
This is exactly my project. Tons of inserts into a warehouse.
I don't understand what you say regarding prefetching. I thought that
prefetching helps mainly for SELECTS, *reading*. From what you say it
seems like it helps inserts?
On a related issue, since normally nothing is ever deleted from this db, I
have all tables' APPEND flag on. Does this factor in into the rule of
percentage of blocked versus non-blocked?

Thanks.
-nat

Aug 24 '06 #3
Ian
natG wrote:
On Thu, 24 Aug 2006 00:56:50 -0700, Ian wrote:
><snip>
FYI, block-based bufferpools are useful for data warehousing and large
batch jobs because they allow the prefetchers to handle sequential
prefetch requests more efficiently. If your app doesn't do a lot of
sequential prefetching, then this won't be a useful feature.
This is exactly my project. Tons of inserts into a warehouse.
I don't understand what you say regarding prefetching. I thought that
prefetching helps mainly for SELECTS, *reading*. From what you say it
seems like it helps inserts?
Sequential prefetch = reading data: the DB2 prefetchers detect when a
query is requesting sequential pages of data from a tablespace, and then
will start automatically fetching pages (under the assumption that the
query will request them).

On a related issue, since normally nothing is ever deleted from this db, I
have all tables' APPEND flag on. Does this factor in into the rule of
percentage of blocked versus non-blocked?
No. Block-based bufferpools are for reading, not writing.

Aug 25 '06 #4

Ian wrote:
Going from memory, but I am pretty sure that STMM does not affect the
block size or number of block pages in a bufferpool.
This is correct. In fact, you cant manually change the size of the
block area without restarting the database.

jsoh

Aug 28 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Mario | last post: by
25 posts views Thread by Yves Glodt | last post: by
32 posts views Thread by Adrian Herscu | last post: by
8 posts views Thread by Bern McCarty | last post: by
14 posts views Thread by Patrick Kowalzick | last post: by
399 posts views Thread by =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.