If you are managing a partitioned UDB database, I would appreciate any
answer on this:
Lets say that I have a performance problem (query which runs slowly,
locks, etc.) and would like to tune a partitioned UDB installationI.
What would be the methodology of solving the problem?
Would it be better to first examine the whole database behaviour and
then go to the partition level, or would it be better to first check
the relevant partitions and only then go to the database level?
I have experience in Oracle DBA and now moving to UDB. In Oracle one
would first examine the partition level (it is called instance there)
and only then try to figure out problems in the database level (Real
Applications Cluster, in Oracle terms).
Thanks,
Ilan
Mark A - 18 Dec 2007 21:31 GMT
On Dec 18, 10:49 am, ilanshi...@gmail.com wrote:
> If you are managing a partitioned UDB database, I would appreciate any
> answer on this:
[quoted text clipped - 14 lines]
> Thanks,
> Ilan
Are you talking about DPF (data partitioning feature) or range
partitioning?
ilanshiber@gmail.com - 19 Dec 2007 16:59 GMT
> On Dec 18, 10:49 am, ilanshi...@gmail.com wrote:
>
[quoted text clipped - 21 lines]
>
> - Show quoted text -
This would be DPF.
Haider Rizvi - 19 Dec 2007 15:17 GMT
> Lets say that I have a performance problem (query which runs
> slowly, locks, etc.) and would like to tune a partitioned UDB
> installationI. What would be the methodology of solving the
> problem?
As you can imagine it is a combination of the two approaches. But I'd
start first with confirming the local (data partition) configuration
and performance aspects (such as memory parms - bufferpool, sortheaps,
i/o parms - extentsize, prefetchsize, #prefetchers, #cleaners, etc.)
After that you'd want to look at the overall query plan and confirm
that you have a good plan. This may end up with you doing some of more
logical perf tuning work (such as adding indexes, adding mqts, etc.)
Regards,

Signature
Haider