Prev: JDBC Interface for passign SQL Array type
Next: Data Logistics of RFID
From: Mark A on 25 Jun 2010 09:44

"ajstorm(a)ca.ibm.com" <ajstorm(a)gmail.com> wrote in message
news:40152b40-fd96-4e17-afc3-390e684b6199(a)y4g2000yqy.googlegroups.com...
> Mark,
>
> I think that is a valuable summary. While I disagree with your ninth
> point, you're certainly entitled to your opinion. My experience with
> hundreds of DB2 customers tells me that hard coded values will not
> work in 99% of cases, which is why we don't document any hard coded
> recommendations. Instead, we've tried hard with STMM to create a
> feature that works well for 100% of customers. Were we 100%
> successful with our first attempt? Has any software product ever been
> released entirely problem-free? No. This is why we're using
> subsequent fixpacks to fix all issues that have been reported by
> customers, such as yourself.
>
> Is STMM in the latest 9.5 and 9.7 fixpacks perfect? It would be
> foolish for me to claim that it is. That being said, the problems you
> mention above have been fixed, and should no longer be a cause for
> concern. From its inception, STMM has provided value for a great
> number of customers and it will continue to do so. Yes, there are/
> were some "gotchas" when running STMM in its first few releases.
> We're hopeful however, that most of the serious problems have been
> resolved.
>
> Thanks,
> Adam

DBA's have had to hard code values for those 4-5 memory heaps since 1990
(until recent releases of DB2 that had STMM), so I am not suggesting
anything new. The defaults were way too low and were not changed via
auto-configure on by default until after the decision was made to develop
STMM (this is the catch-22).

There has not been any documentation in the reference manuals for the last
20 years on what realistic values should be for those 4-5 memory heaps,
which has been a problem for many customers, especially given that the
defaults were so low. Just listing the default and range of possible values
is not sufficient IMO. If you don't like my values, then a couple of
different of scenarios (different types and sizes of databases) could have
been discussed with different values for each scenario. It does not hurt to
over allocate a little bit, since memory is cheap and plentiful these days
and these setting use a very small amount of memory (with exception of
bufferpools, which is a totally different subject). These memory allocations
don't need to be perfect anyway, so long as the defaults are not used.

It comes down to risk vs. reward. For a company without any competent DBA's,
the benefit of STMM may outweigh the risk (especially if they don't have
mission critical DB2 databases). For other companies, the opposite may be
true. I don't understand why IBM is pushing so hard for everyone to use STMM
when it may not be appropriate for every situation at the current time.





From: ajstorm on 25 Jun 2010 15:53
On Jun 25, 9:44 am, "Mark A" <no...(a)nowhere.com> wrote:
> "ajst...(a)ca.ibm.com" <ajst...(a)gmail.com> wrote in message
>
> news:40152b40-fd96-4e17-afc3-390e684b6199(a)y4g2000yqy.googlegroups.com...
>
>
>
> > Mark,
>
> > I think that is a valuable summary.  While I disagree with your ninth
> > point, you're certainly entitled to your opinion.  My experience with
> > hundreds of DB2 customers tells me that hard coded values will not
> > work in 99% of cases, which is why we don't document any hard coded
> > recommendations.  Instead, we've tried hard with STMM to create a
> > feature that works well for 100% of customers.  Were we 100%
> > successful with our first attempt?  Has any software product ever been
> > released entirely problem-free?  No.  This is why we're using
> > subsequent fixpacks to fix all issues that have been reported by
> > customers, such as yourself.
>
> > Is STMM in the latest 9.5 and 9.7 fixpacks perfect?  It would be
> > foolish for me to claim that it is.  That being said, the problems you
> > mention above have been fixed, and should no longer be a cause for
> > concern.  From its inception, STMM has provided value for a great
> > number of customers and it will continue to do so.  Yes, there are/
> > were some "gotchas" when running STMM in its first few releases.
> > We're hopeful however, that most of the serious problems have been
> > resolved.
>
> > Thanks,
> > Adam
>
> DBA's have had to hard code values for those 4-5 memory heaps since 1990
> (until recent releases of DB2 that had STMM), so I am not suggesting
> anything new. The defaults were way too low and were not changed via
> auto-configure on by default until after the decision was made to develop
> STMM (this is the catch-22).
>
> There has not been any documentation in the reference manuals for the last
> 20 years on what realistic values should be for those 4-5 memory heaps,
> which has been a problem for many customers, especially given that the
> defaults were so low. Just listing the default and range of possible values
> is not sufficient IMO. If you don't like my values, then a couple of
> different of scenarios (different types and sizes of databases) could have
> been discussed with different values for each scenario. It does not hurt to
> over allocate a little bit, since memory is cheap and plentiful these days
> and these setting use a very small amount of memory (with exception of
> bufferpools, which is a totally different subject). These memory allocations
> don't need to be perfect anyway, so long as the defaults are not used.

I completely agree with you that our documentation was lacking in this
area for a long time. While we could add to it now, most of the work
has already been done automatically and under the covers (since v9.1
at least), now that the configuration advisor is being run on database
creation. The new defaults (i.e. what will be generated by the
configuration advisor when the database is created) are in the same
ballpark as what you've suggested.

> It comes down to risk vs. reward. For a company without any competent DBA's,
> the benefit of STMM may outweigh the risk (especially if they don't have
> mission critical DB2 databases). For other companies, the opposite may be
> true. I don't understand why IBM is pushing so hard for everyone to use STMM
> when it may not be appropriate for every situation at the current time.

I agree with this too. I think somehow you may have misinterpreted
IBM's stance on STMM. While STMM is enabled by default, customers can
obviously turn it off if they want. In a past post you mentioned that
we're "brow-beating" people into using the feature. As far as I'm
concerned, that's not the case. In all of my interactions with
customers I try to lay out the best uses for STMM, as well as the
cases where it might not be advantageous. For example, I always
mention that if you have a database that is performing well, it might
not be a good idea to enable STMM because you have very little
upside. Additionally, in cases where DBAs are present, and are
experienced in memory tuning, there might not be substantial benefit.
As you mention however, in companies where DBAs aren't experienced, or
do not have the time to tune every single database that gets created,
there is benefit to using STMM.

Thanks,
Adam
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: JDBC Interface for passign SQL Array type
Next: Data Logistics of RFID