Tmon/DB2 and bufferpool info

TOM (SBCSI) GLASER

Tmon/DB2 and bufferpool info
Tmon/DB2 Users:

I'm looking for a way Tmon/DB2 can tell me if the data I selected from a
table came from the buffer pool or did DB2 have to access dasd to retrieve
it. In the following report, I stopped the table space, started it back up
and ran a query Select * from table_1:

JOBNAME: TMONDB2 ONLINE ANALYSIS THREAD BUFFER POOL DETAIL DATE: 09/15/00
DB2 : DA7A TIME: 14:26:30
COMMAND:

CONN ID: BATCH PLAN : DSNTEP2 DATE : 09/15/00
CORR ID: TG544499 AUTH ID: TG5444 START TIME: 14:16:30.1461
REASON : NORMAL OPID : TG5444 END TIME : 14:16:59.8032
BP ID : BP4K15
BP STATISTICS TOTAL SUCCESSFUL UNSUCCESSFUL
GETPAGES : 1789 1789 0
GETPAGES PER HPOOL PAGES READ : 0.0 N/A N/A
GETPAGES PER I/O PAGES READ : 1.0 N/A N/A
SYNC READ I/O : 2 2 N/A
SYNC READ FROM HIPERPOOL : 0 0 0
SEQUENTIAL PREFETCH REQUEST : 56 56 N/A
LIST PREFETCH REQUEST : 0 0 N/A
DYNAMIC PREFETCH REQUEST : 0 0 N/A
ASYNC PAGES READ : 1785 1785 N/A
ASYNC PAGES READ FROM HIPERPOOL: 0 0 N/A
SYSTEM PAGE UPDATES : 0 0 N/A
SYNC WRITE I/O : 0 0 N/A
SYNC WRITE TO HIPERPOOL : 0 0 0
BUFFER POOL EXPANSIONS : N/A N/A N/A



....the following report shows another select with a bufferpool set to 5000
pages. DB2 did not access the dasd pack:

JOBNAME: TMONDB2 ONLINE ANALYSIS THREAD BUFFER POOL DETAIL DATE: 09/15/00

DB2 : DA7A TIME: 14:27:47

COMMAND:



CONN ID: BATCH PLAN : DSNTEP2 DATE : 09/15/00

CORR ID: TG544499 AUTH ID: TG5444 START TIME: 14:17:01.6545

REASON : NORMAL OPID : TG5444 END TIME : 14:17:32.9570

BP ID : BP4K15

BP STATISTICS TOTAL SUCCESSFUL UNSUCCESSFUL

GETPAGES : 1787 1787 0

GETPAGES PER HPOOL PAGES READ : 0.0 N/A N/A

GETPAGES PER I/O PAGES READ : 0.0 N/A N/A

SYNC READ I/O : 0 0 N/A

SYNC READ FROM HIPERPOOL : 0 0 0

SEQUENTIAL PREFETCH REQUEST : 54 54 N/A

LIST PREFETCH REQUEST : 0 0 N/A

DYNAMIC PREFETCH REQUEST : 0 0 N/A

ASYNC PAGES READ : 0 0 N/A

ASYNC PAGES READ FROM HIPERPOOL: 0 0 N/A

SYSTEM PAGE UPDATES : 0 0 N/A

SYNC WRITE I/O : 0 0 N/A

SYNC WRITE TO HIPERPOOL : 0 0 0

BUFFER POOL EXPANSIONS : N/A N/A N/A


...by looking at these reports, how can I tell if DB2 found the data already
in the bufferpool or if it had to access disk to retrieve the needed data.
The table space contains 1788 active pages. Thanks for any help you can
provide.

Tom Glaser
DB2 Support
SBC Communications
[login to unmask email]



Venkat (PCA) Pillay

Re: Tmon/DB2 and bufferpool info
(in response to TOM (SBCSI) GLASER)
Tom

Look for following two counters "SYNC READ I/O" + "ASYNC PAGES
READ". These two counters tell you how many pages are read from the DASD.

Regards
Venkat Pillay

> -----Original Message-----
> From: GLASER, TOM (SBCSI) [SMTP:[login to unmask email]
> Sent: Monday, September 18, 2000 9:03 AM
> To: [login to unmask email]
> Subject: Tmon/DB2 and bufferpool info
>
> Tmon/DB2 Users:
>
> I'm looking for a way Tmon/DB2 can tell me if the data I selected from a
> table came from the buffer pool or did DB2 have to access dasd to retrieve
> it. In the following report, I stopped the table space, started it back
> up
> and ran a query Select * from table_1:
>
> JOBNAME: TMONDB2 ONLINE ANALYSIS THREAD BUFFER POOL DETAIL DATE:
> 09/15/00
> DB2 : DA7A TIME:
> 14:26:30
> COMMAND:
>
> CONN ID: BATCH PLAN : DSNTEP2 DATE : 09/15/00
> CORR ID: TG544499 AUTH ID: TG5444 START TIME:
> 14:16:30.1461
> REASON : NORMAL OPID : TG5444 END TIME :
> 14:16:59.8032
> BP ID : BP4K15
> BP STATISTICS TOTAL SUCCESSFUL
> UNSUCCESSFUL
> GETPAGES : 1789 1789
> 0
> GETPAGES PER HPOOL PAGES READ : 0.0 N/A
> N/A
> GETPAGES PER I/O PAGES READ : 1.0 N/A
> N/A
> SYNC READ I/O : 2 2
> N/A
> SYNC READ FROM HIPERPOOL : 0 0
> 0
> SEQUENTIAL PREFETCH REQUEST : 56 56
> N/A
> LIST PREFETCH REQUEST : 0 0
> N/A
> DYNAMIC PREFETCH REQUEST : 0 0
> N/A
> ASYNC PAGES READ : 1785 1785
> N/A
> ASYNC PAGES READ FROM HIPERPOOL: 0 0
> N/A
> SYSTEM PAGE UPDATES : 0 0
> N/A
> SYNC WRITE I/O : 0 0
> N/A
> SYNC WRITE TO HIPERPOOL : 0 0
> 0
> BUFFER POOL EXPANSIONS : N/A N/A
> N/A
>
>
>
> ....the following report shows another select with a bufferpool set to
> 5000
> pages. DB2 did not access the dasd pack:
>
> JOBNAME: TMONDB2 ONLINE ANALYSIS THREAD BUFFER POOL DETAIL DATE:
> 09/15/00
>
> DB2 : DA7A TIME:
> 14:27:47
>
> COMMAND:
>
>
>
> CONN ID: BATCH PLAN : DSNTEP2 DATE : 09/15/00
>
> CORR ID: TG544499 AUTH ID: TG5444 START TIME:
> 14:17:01.6545
>
> REASON : NORMAL OPID : TG5444 END TIME :
> 14:17:32.9570
>
> BP ID : BP4K15
>
> BP STATISTICS TOTAL SUCCESSFUL
> UNSUCCESSFUL
>
> GETPAGES : 1787 1787
> 0
>
> GETPAGES PER HPOOL PAGES READ : 0.0 N/A
> N/A
>
> GETPAGES PER I/O PAGES READ : 0.0 N/A
> N/A
>
> SYNC READ I/O : 0 0
> N/A
>
> SYNC READ FROM HIPERPOOL : 0 0
> 0
>
> SEQUENTIAL PREFETCH REQUEST : 54 54
> N/A
>
> LIST PREFETCH REQUEST : 0 0
> N/A
>
> DYNAMIC PREFETCH REQUEST : 0 0
> N/A
>
> ASYNC PAGES READ : 0 0
> N/A
>
> ASYNC PAGES READ FROM HIPERPOOL: 0 0
> N/A
>
> SYSTEM PAGE UPDATES : 0 0
> N/A
>
> SYNC WRITE I/O : 0 0
> N/A
>
> SYNC WRITE TO HIPERPOOL : 0 0
> 0
>
> BUFFER POOL EXPANSIONS : N/A N/A
> N/A
>
>
> ...by looking at these reports, how can I tell if DB2 found the data
> already
> in the bufferpool or if it had to access disk to retrieve the needed data.
> The table space contains 1788 active pages. Thanks for any help you can
> provide.
>
> Tom Glaser
> DB2 Support
> SBC Communications
> [login to unmask email]
>
>
>
>
>



Joel Goldstein

Tmon/DB2 and bufferpool info
(in response to Venkat (PCA) Pillay)
According to your synch i/o and asynch pages read, you, read 1787 pages
from dasd.

Regards,
Joel



Karthik Ganesh

Bufferpool info
(in response to Joel Goldstein)
Hi LIST,

I am a novice to Bufferpool tuning. Had some doubts
where I can justify myself before pointing some to
others.

In my client's place we have singel Bufferpool BP0
allcoated 16000 pages and HP backed by 27000 PAGES. It
seems that all of them are well satified by the
performance & HIT RATIO (which is around 87%) always.
But I am for mutliple BP srategy where I am not able
to justify to my client in detail since I am not
familiar and confident. They say that we will loose
time in the cross memory services while accessing DBM1
address spaces and the Hit ratio will always be the
same. Would some one give some more informations to
overcome this, I agree that the I/O & CPU will be
reduced , but I need more info. I am getting more
details to study further.


Other than this I have got another question. Is the
active page is always the used pages of my allocation
or will it be more? we came across discussion that we
are running out of memory. I see here the BP active
pages are only 40% of the allocation always. How do
you see here the memoery is getting exhausted ?


Thanks in advance for clarifying me the issues.

Regards
Karthik


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/



Susan Bowers

Re: Bufferpool info
(in response to Karthik Ganesh)
There are some really good articles on the following
website (technical papers about DB2):

http://www.multimania.com/db2usa/earticle.htm

One by Martin Hubel called 'It's Time to Re-think Your DB2
Buffer Pool Strategy' may be very helpful to you. There
are several others written specifically about buffer pool
tuning also.


On Fri, 15 Dec 2000 13:15:37 -0800 Karthik Ganesh
<[login to unmask email]> wrote:

> Hi LIST,
>
> I am a novice to Bufferpool tuning. Had some doubts
> where I can justify myself before pointing some to
> others.
>
> In my client's place we have singel Bufferpool BP0
> allcoated 16000 pages and HP backed by 27000 PAGES. It
> seems that all of them are well satified by the
> performance & HIT RATIO (which is around 87%) always.
> But I am for mutliple BP srategy where I am not able
> to justify to my client in detail since I am not
> familiar and confident. They say that we will loose
> time in the cross memory services while accessing DBM1
> address spaces and the Hit ratio will always be the
> same. Would some one give some more informations to
> overcome this, I agree that the I/O & CPU will be
> reduced , but I need more info. I am getting more
> details to study further.
>
>
> Other than this I have got another question. Is the
> active page is always the used pages of my allocation
> or will it be more? we came across discussion that we
> are running out of memory. I see here the BP active
> pages are only 40% of the allocation always. How do
> you see here the memoery is getting exhausted ?
>
>
> Thanks in advance for clarifying me the issues.
>
> Regards
> Karthik
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
>
>
>

----------------------
Susan Bowers
[login to unmask email]
phone: 463-4742
digital/alpha pager: 875-6431



Piontkowski Michael ML

Re: Bufferpool info
(in response to Susan Bowers)
Check Joel's papers & presentations at
http://www.responsivesystems.com


Mike Piontkowski
TP&S Technical Maintenance
Voice: +1 302.886.4612
Fax: +1 302.886.4749


-----Original Message-----
From: Karthik Ganesh [mailto:[login to unmask email]
Sent: Friday, December 15, 2000 16:16
To: [login to unmask email]
Subject: [DB2-L] Bufferpool info


Hi LIST,

I am a novice to Bufferpool tuning. Had some doubts
where I can justify myself before pointing some to
others.

In my client's place we have singel Bufferpool BP0
allcoated 16000 pages and HP backed by 27000 PAGES. It
seems that all of them are well satified by the
performance & HIT RATIO (which is around 87%) always.
But I am for mutliple BP srategy where I am not able
to justify to my client in detail since I am not
familiar and confident. They say that we will loose
time in the cross memory services while accessing DBM1
address spaces and the Hit ratio will always be the
same. Would some one give some more informations to
overcome this, I agree that the I/O & CPU will be
reduced , but I need more info. I am getting more
details to study further.


Other than this I have got another question. Is the
active page is always the used pages of my allocation
or will it be more? we came across discussion that we
are running out of memory. I see here the BP active
pages are only 40% of the allocation always. How do
you see here the memoery is getting exhausted ?


Thanks in advance for clarifying me the issues.

Regards
Karthik


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/








HARBRY ARIZA

Re: Bufferpool info
(in response to Piontkowski Michael ML)
Ganesh:


You'll see the memory is getting exhausted when the number of writes
failures and read failures in the hiperpool is high. (your hiperpool must be
define with CASTOUT=YES to allow the system still these pages if needed).
Check if your hiperpools were define with castout=yes , if not change and
check the hiperpool statistics. If your hiperpool were define define with
castout=no you'll never get writes and read failures onto the hiperpool,

cheers,

harbry



Original Message-----
>From: Karthik Ganesh [mailto:[login to unmask email]
>Sent: Friday, December 15, 2000 16:16
>To: [login to unmask email]
>Subject: [DB2-L] Bufferpool info
>
>
>Hi LIST,
>
>I am a novice to Bufferpool tuning. Had some doubts
>where I can justify myself before pointing some to
>others.
>
>In my client's place we have singel Bufferpool BP0
>allcoated 16000 pages and HP backed by 27000 PAGES. It
>seems that all of them are well satified by the
>performance & HIT RATIO (which is around 87%) always.
>But I am for mutliple BP srategy where I am not able
>to justify to my client in detail since I am not
>familiar and confident. They say that we will loose
>time in the cross memory services while accessing DBM1
>address spaces and the Hit ratio will always be the
>same. Would some one give some more informations to
>overcome this, I agree that the I/O & CPU will be
>reduced , but I need more info. I am getting more
>details to study further.
>
>
>Other than this I have got another question. Is the
>active page is always the used pages of my allocation
>or will it be more? we came across discussion that we
>are running out of memory. I see here the BP active
>pages are only 40% of the allocation always. How do
>you see here the memoery is getting exhausted ?
>
>
>Thanks in advance for clarifying me the issues.
>
>Regards
>Karthik
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Shopping - Thousands of Stores. Millions of Products.
>http://shopping.yahoo.com/
>
>
>
>the
>
>
>
>
>
>
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.



Joel Goldstein

Re: Bufferpool info
(in response to HARBRY ARIZA)
One pool has NOT been the way to get decent performance for 15 years.
You give no indication of a level of system activity... getpages/hour would
be useful

You must be sure you are using the CORRECT system hit ratio formula;
(getpages - Sum of All Pages Read)/Getpages
where sum of all pages read includes pages read into the pool by prefetch
functions.

for HP a good approach is to use the Readback Ratio
Pages read from HP/Pages written to HP .... and even a low ratio like 10%
might still be saving
a lot of I/O.

If you system is on the small side, you may get much better performance
with more pools and
less memory than you currently have allocated. A desired hit ratio for
random indexes is about 95%

You client has no understanding about DB2 by worrying about cross memory
services. Multiple
pools does not impact this, or any other overhead concerns.
Minimally, indexes should be seperated from TS, and sortwork in their own
pool
just for the quick shotgun seperation.

Lastly, you are looking at a filed that is called "current buffers active"
This is really the buffers
that are NOT available. 100% of the buffers are in use 100% of the time.
If this is showing 40%
most of the time, this is far too high. Lower vdwqt to 0.

see www.responsivesystems.com for tuning papers and presentations.

Regards,
Joel
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Message text written by DB2 Data Base Discussion List
>I am a novice to Bufferpool tuning. Had some doubts
where I can justify myself before pointing some to
others.

In my client's place we have singel Bufferpool BP0
allcoated 16000 pages and HP backed by 27000 PAGES. It
seems that all of them are well satified by the
performance & HIT RATIO (which is around 87%) always.
But I am for mutliple BP srategy where I am not able
to justify to my client in detail since I am not
familiar and confident. They say that we will loose
time in the cross memory services while accessing DBM1
address spaces and the Hit ratio will always be the
same. Would some one give some more informations to
overcome this, I agree that the I/O & CPU will be
reduced , but I need more info. I am getting more
details to study further.


Other than this I have got another question. Is the
active page is always the used pages of my allocation
or will it be more? we came across discussion that we
are running out of memory. I see here the BP active
pages are only 40% of the allocation always. How do
you see here the memoery is getting exhausted ?


Thanks in advance for clarifying me the issues.

Regards
Karthik<



Sanjeev (CTS) S

Re: Bufferpool info
(in response to Joel Goldstein)
Hi Karthik,
First of all i am concerned about the 40% active pages. I think in any
workload scenario, it is very high. It should be lowered down. Considering
out of the 40% ,even 5% of the pages are queued for write then it is approx.
800 pages which is high. I think you have to lower the VDWQT to either 0 or
get some number if you are using V6. By separating it to multiple BP, the
writes can be distributed.
Another thing which i have seen that in maintaining the single BP, the main
problem is to assign the values to different threshold. If we use multiple
bufferpool then we can assign the threshold (which should be) on the basis
of the characteristics of the pages it process. For e.g. the large
sequentially accessed pages should have VPSEQT high and for others (like
indexes) you do not always need it to be high. Uses of HP for the kind of BP
maintained is also an issue. After separation you may also find that you
have reduced the amount of HP storage you were using with the single BP. So
start explaining the meaning of different thresholds and its affect to your
client and let them know if there is something which can be improved by
converting it to multiple BP and assigning different series of thresholds.
As Joel suggested, HIT RATIO is the biggest concerned which i also felt
that not correctly calculated by most of the monitors. Look at the correct
formula given by Joel (in his series of articles) for more explaination.
Please look at one more site of Compuware for Chuck Hoover's GREAT series
of presentations and white papers on this. It will be better if you do some
research and get back to us with some more new questions and experiences.

HTH

Regards
Sanjeev

> -----Original Message-----
> From: Karthik Ganesh [SMTP:[login to unmask email]
> Sent: Saturday, December 16, 2000 2:46 AM
> To: [login to unmask email]
> Subject: Bufferpool info
>
> Hi LIST,
>
> I am a novice to Bufferpool tuning. Had some doubts where I can justify
> myself before pointing some to others.
>
> In my client's place we have singel Bufferpool BP0 allcoated 16000 pages
> and HP backed by 27000 PAGES. It seems that all of them are well satified
> by the performance & HIT RATIO (which is around 87%) always. But I am for
> mutliple BP srategy where I am not able to justify to my client in detail
> since I am not familiar and confident. They say that we will loose time in
> the cross memory services while accessing DBM1 address spaces and the Hit
> ratio will always be the same. Would some one give some more informations
> to overcome this, I agree that the I/O & CPU will be reduced , but I need
> more info. I am getting more details to study further.
>
> Other than this I have got another question. Is the active page is always
> the used pages of my allocation or will it be more? we came across
> discussion that we are running out of memory. I see here the BP active
> pages are only 40% of the allocation always. How do you see here the
> memoery is getting exhausted ?
>
>
> Thanks in advance for clarifying me the issues.
>
> Regards
> Karthik
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/
>
>
>
>
>
-----------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------------
This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message. Any unauthorised review, use, disclosure,
dissemination, forwarding, printing or copying of this email or any action taken in
reliance on this e-mail is strictly prohibited and may be unlawful.

Visit us at http://www.cognizant.com
----------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------



Karthik Ganesh

BUFFERPOOL INFO
(in response to Sanjeev (CTS) S)
List,


Thanks a lot for all the information. still trying to
get more informations from my side to dig further. I
will keep you posted as I get one by one.

Joel & list ,

As you have asked for I am enlcosing some of the
informations I have as below:

(These all are collected @ 5 minute intervals AT
DIFFERENT TIMES)

sorry for the Lenghty report.


VP HP
BUFFERS BUFFERS ACTIVE
ALLOC ALLOC BUFFERS
------- ----------- ----------- -
166500 275000 48814
166500 275000 31107
166500 275000 42758
166500 275000 32510



GETPAGE
GETPAGE REQ
REQUEST SEQ
-------- ------------------
13140508 1769096
15718504 1463102
5139068 1426196
1515777 693231

SYNC
READ BUFFER PAGES
IO UPDATE WRITTEN
------- ----------- ----------- -
367756 1844 364722
382528 90115 799343
245077 3966 583547
146115 480 299764

ASYNC
WRITE IMMEDIATE VDWTH
IO WRITE REACHED
------ ----------- -----------
32915 128 2579
75299 123 3968
58367 26 3448
29826 46 8


DWTH DMTH DESTRUCTIVE
REACHED REACHED RD
-------- ----------- -----------
1 0 3400
0 0 19299
0 0 116594
0 0 7628

HP
HP READ
DESTRUCTIVE READ ASYN
DQ SYNC NOADM
----------- ----------- -----------
190 64286 19947
16891 85466 28513
103925 35686 46616
7325 33495 4038


HP HP
READ HP WRT
ASYN WRT ASYN
ADM SYNC NOADM
------- ----------- ----------- -
10335 0 5833
37824 19 5243
221531 6 2312
11056 125 282


HP
WRT
ASYN
ADM
--------
1918072
1958062
1267385
1038345


HP
CASTOUT VPSEQ HPSEQ
ATTRIB THRESHOLD THRESHOLD
------- --------- ---------
Y 80 80
Y 80 80
Y 80 80
Y 80 80




DWQ VDWQ VPPSEQ
THRESHOLD THRESHOLD THRESHOLD
--------- --------- ---------
50 6 40
50 6 40
50 6 40
50 6 40

I am trying to find out more inforamtions about the
other datas to check whether the Ratio are correct.

Thanks in advance for your thoughts and insights.


Thanks list!!!!!


Regards
Karthik

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/



Joel Goldstein

Re: BUFFERPOOL INFO
(in response to Karthik Ganesh)
Since these are 5 minute intervals (?), your Synch I/O rate/sec is > 1200,
and
adding prefetchj I/Os would drive this even higher..
This extremely high, and means there can probably be truly dramatic
performance improvements from pool tuning. Again based on a 5 minute
interval, this is a very large system.... it's totally foolish to try
running a workload
like this from one pool.
Pool tuning should easily save several million I/Os per day, and maybe
$250K per
year in reduced CPU costs for I/O. Now tuning and saving like this does
not
necessarily mean the CPU busy rate will go down. It may go up because you
remove
the I/O constraint.... but the improvement in throughput and productivity
will be significant.

There is a lot of data missing from what you provided... like pages read
by prefetch
functions.... necessary to calculate the system hit ratio.

The pages per write is > 10, but this is driven up by having the db07
objects in the pool.
These must be split out into their own pool as a first step, and then lower
the
vdwqt to 0. I'd also lower the dwqt to 20%.

Lower the vpseqt to 50%, and the hpseqt to 10%... and this should lower the
synch i/o rate.

You also need the number of pages written to the HP and number read back to
calculate
the effectiveness.

Regards,
Joel
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++
Buffer Pool Tool for DB2 - The only product that can Predict the effect
of changes & show how to properly group objects into pools based on
access & WkSet
DASD/Xpert for DB2 - Easily shows all your DASD performance problems,
and recommends tuning options.
Visit www.responsivesystems.com - performance white papers and
presentations
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++

>Message text written by DB2 Data Base Discussion List
>As you have asked for I am enlcosing some of the
>informations I have as below:

(These all are collected @ 5 minute intervals AT
DIFFERENT TIMES)

sorry for the Lenghty report.


VP HP
BUFFERS BUFFERS ACTIVE
ALLOC ALLOC BUFFERS
------- ----------- ----------- -
166500 275000 48814
166500 275000 31107
166500 275000 42758
166500 275000 32510



GETPAGE
GETPAGE REQ
REQUEST SEQ
-------- ------------------
13140508 1769096
15718504 1463102
5139068 1426196
1515777 693231

SYNC
READ BUFFER PAGES
IO UPDATE WRITTEN
------- ----------- ----------- -
367756 1844 364722
382528 90115 799343
245077 3966 583547
146115 480 299764

ASYNC
WRITE IMMEDIATE VDWTH
IO WRITE REACHED
------ ----------- -----------
32915 128 2579
75299 123 3968
58367 26 3448
29826 46 8


DWTH DMTH DESTRUCTIVE
REACHED REACHED RD
-------- ----------- -----------
1 0 3400
0 0 19299
0 0 116594
0 0 7628

HP
HP READ
DESTRUCTIVE READ ASYN
DQ SYNC NOADM
----------- ----------- -----------
190 64286 19947
16891 85466 28513
103925 35686 46616
7325 33495 4038


HP HP
READ HP WRT
ASYN WRT ASYN
ADM SYNC NOADM
------- ----------- ----------- -
10335 0 5833
37824 19 5243
221531 6 2312
11056 125 282


HP
WRT
ASYN
ADM
--------
1918072
1958062
1267385
1038345


HP
CASTOUT VPSEQ HPSEQ
ATTRIB THRESHOLD THRESHOLD
------- --------- ---------
Y 80 80
Y 80 80
Y 80 80
Y 80 80




DWQ VDWQ VPPSEQ
THRESHOLD THRESHOLD THRESHOLD
--------- --------- ---------
50 6 40
50 6 40
50 6 40
50 6 40<