Serge is exactly right. My customers have suffered when they don't have
a test system (call it a QA system) that is representative of
production. It doesn't have to be an exact replica, but it should be
representative in some proportion.
Now ... let me tell you why you SHOULD be testing performance in a QA
system. It is not unheard of for maintenance (be it OS-related,
DB2-related, or even ISV-related) to affect performance. You want to
apply any changes ... any changes at all to an environment where you can
not only test functionality, but where you can test performance also. In
fact, one of my customers actually has a "benchmark" set of queries/txns
that they established a baseline for and then they run for EVERY SINGLE
change that is made to QA. If a change is made where the difference from
the baseline is significant and unexplained, research and analysis is
conducted to find out why. It could be as simple as an environment
variable that someone forgot to set ... or it could be a bug. You don't
want to find out about this in production ... you want to find out about
these kinds of things before any change every hits production. It
enhances quality of service for your end-users and minimizes outages ...
it is simply good systems management practice and reduces costs (in the
long run) to the business.
Such a QA system should be configured EXACTLY like production in terms
of sw and hw technology, but in terms of size, should be constucted in
some proportion. So for example, if production is a 16-way AIX 5.3
p-series POWER5 server with 8 logical partitions of DB2 DPF V8.2 @ fp 12
on it, perhaps QA should be a 4-way p-series server with the exact same
hw technology (if possible) with AIX 5.3 @ fp12 on it with maybe 2
logical partitions. The data in those 2 logical partitions should be
representative also to be about 1/4 of the total data in production.
That way, you can extrapolate performance results in QA.
Just my 2 cents.
Larry Edelstein
Serge Rielau wrote:
shsandeep wrote:
>Serge,
I totally agree with you.... In fact, you had mentioned this earlier as
well...
But whenever I put this point in front of the management, they ignore it
saying that we are not testing performance in the development
environment. ..
Are there any other benefits of partitioning the DEV database which I can
put forward to them??
Money talks. Collect the amount of damage to the business because of
your current problem and any previous ones you may have encountered.
How are you supposed to track this problem, collect data, experiment if
your only system is production?
All you need are two logical nodes for development/test.
Sure you don't need DPF on the laptops of your app developers. But your
DBA's need access to a scaled down version of the original.
Cheers
Serge
