why DPF?

[Hardy]

Hi gurus, I know many of you are very senior DBAs and experts from IBM
internal, so I really want to know your advice on this basic topic.
"why dpf?"

usually there's a rumor, em, I believe it's a rumor, that DPF can help
you get greater performance, so even only one server, many IBM
presales will sell DPF feature with the performance story. DPF
license is not a cheap one:)

I believe DPF is much more for scalability than performance.

I believe that only when your data/table is larger than non-DPF can
serve, or you have to use more than one server, you use DPF.

how about your opinion? can you list the reasons you use DPF? Thank
you.

[Serge Rielau]

Re: why DPF?

Hardy wrote:

Hi gurus, I know many of you are very senior DBAs and experts from IBM
internal, so I really want to know your advice on this basic topic.
"why dpf?"
>
usually there's a rumor, em, I believe it's a rumor, that DPF can help
you get greater performance, so even only one server, many IBM
presales will sell DPF feature with the performance story. DPF
license is not a cheap one:)
>
I believe DPF is much more for scalability than performance.
>
I believe that only when your data/table is larger than non-DPF can
serve, or you have to use more than one server, you use DPF.
>
how about your opinion? can you list the reasons you use DPF? Thank
you.
>

With DB2 9 and large rowids, large tablespaces and range partitioning
scalability is hardly and issue anymore.
It is still correct though that on an SMP box it can be beneficial to
have multiple logical data partitions, rather than using SMP parallelism.
To make a long story short for a warehouse that requires multiple CPUs
you will see the recommendation of DPF for performance.
For the best practices I recommend looking into Balanced Configuration
Units (BCU):

http://www.db2mag.com/story/showArticle.jhtml?articleID=180206351

... oh.. and it's not a rumor... for a warehouse a well designed DPF
system will achieve near linear scalability compared to an SMP approach
which delivers diminishing returns.


Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

[Hardy]

Re: why DPF?

With DB2 9 and large rowids, large tablespaces and range partitioning

scalability is hardly and issue anymore.
It is still correct though that on an SMP box it can be beneficial to
have multiple logical data partitions, rather than using SMP parallelism.
To make a long story short for a warehouse that requires multiple CPUs
you will see the recommendation of DPF for performance.
For the best practices I recommend looking into Balanced Configuration
Units (BCU):http://www.db2mag.com/story/showArti...leID=180206351
>
.. oh.. and it's not a rumor... for a warehouse a well designed DPF
system will achieve near linear scalability compared to an SMP approach
which delivers diminishing returns.
>
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

yes, Serge. DPF need more experienced professional to keep the near
linear scalability. In my experience, every time customer complained
DPF delivers worse performance and I always tell them the need for
more design and tuning, then do sth. to fulfill their need.

Actually, we deliver system always according to the BCU methodology
and gain good feedback.

But the problem that if only one server with many CPU and memory, if
the data/table size is not a limit, then what's the best solution?

[Hardy]

Re: why DPF?

On May 8, 10:36 am, Hardy <wyh...@gmail.c omwrote:

With DB2 9 and large rowids, large tablespaces and range partitioning
scalability is hardly and issue anymore.
It is still correct though that on an SMP box it can be beneficial to
have multiple logical data partitions, rather than using SMP parallelism.
To make a long story short for a warehouse that requires multiple CPUs
you will see the recommendation of DPF for performance.
For the best practices I recommend looking into Balanced Configuration
Units (BCU):http://www.db2mag.com/story/showArti...leID=180206351

>

.. oh.. and it's not a rumor... for a warehouse a well designed DPF
system will achieve near linear scalability compared to an SMP approach
which delivers diminishing returns.

>

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

>
yes, Serge. DPF need more experienced professional to keep the near
linear scalability. In my experience, every time customer complained
DPF delivers worse performance and I always tell them the need for
more design and tuning, then do sth. to fulfill their need.
>
Actually, we deliver system always according to the BCU methodology
and gain good feedback.
>
But the problem that if only one server with many CPU and memory, if
the data/table size is not a limit, then what's the best solution?

to keep simple, is the advantage for multi-partition over SMP
parallelism(sur e?,is there any direct data or material) is worth the
big effort on DPF design? especially for a firm without strong skill.

[Hardy]

Re: why DPF?

On May 8, 10:36 am, Hardy <wyh...@gmail.c omwrote:

With DB2 9 and large rowids, large tablespaces and range partitioning
scalability is hardly and issue anymore.
It is still correct though that on an SMP box it can be beneficial to
have multiple logical data partitions, rather than using SMP parallelism.
To make a long story short for a warehouse that requires multiple CPUs
you will see the recommendation of DPF for performance.
For the best practices I recommend looking into Balanced Configuration
Units (BCU):http://www.db2mag.com/story/showArti...leID=180206351

>

.. oh.. and it's not a rumor... for a warehouse a well designed DPF
system will achieve near linear scalability compared to an SMP approach
which delivers diminishing returns.

>

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

>
yes, Serge. DPF need more experienced professional to keep the near
linear scalability. In my experience, every time customer complained
DPF delivers worse performance and I always tell them the need for
more design and tuning, then do sth. to fulfill their need.
>
Actually, we deliver system always according to the BCU methodology
and gain good feedback.
>
But the problem that if only one server with many CPU and memory, if
the data/table size is not a limit, then what's the best solution?

to keep simple, is the advantage for multi-partition over SMP
parallelism(sur e?,is there any direct data or material) is worth the
big effort on DPF design? especially for a firm without strong skill.

[Hardy]

Re: why DPF?

On May 8, 10:36 am, Hardy <wyh...@gmail.c omwrote:

With DB2 9 and large rowids, large tablespaces and range partitioning
scalability is hardly and issue anymore.
It is still correct though that on an SMP box it can be beneficial to
have multiple logical data partitions, rather than using SMP parallelism.
To make a long story short for a warehouse that requires multiple CPUs
you will see the recommendation of DPF for performance.
For the best practices I recommend looking into Balanced Configuration
Units (BCU):http://www.db2mag.com/story/showArti...leID=180206351

>

.. oh.. and it's not a rumor... for a warehouse a well designed DPF
system will achieve near linear scalability compared to an SMP approach
which delivers diminishing returns.

>

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

>
yes, Serge. DPF need more experienced professional to keep the near
linear scalability. In my experience, every time customer complained
DPF delivers worse performance and I always tell them the need for
more design and tuning, then do sth. to fulfill their need.
>
Actually, we deliver system always according to the BCU methodology
and gain good feedback.
>
But the problem that if only one server with many CPU and memory, if
the data/table size is not a limit, then what's the best solution?

to keep simple, is the advantage for multi-partition over SMP
parallelism(sur e?,is there any direct data or material) is worth the
big effort on DPF design? especially for a firm without strong skill.

[Hardy]

Re: why DPF?

On May 8, 10:43 am, Hardy <wyh...@gmail.c omwrote:

On May 8, 10:36 am, Hardy <wyh...@gmail.c omwrote:
>
>
>

With DB2 9 and large rowids, large tablespaces and range partitioning
scalability is hardly and issue anymore.
It is still correct though that on an SMP box it can be beneficial to
have multiple logical data partitions, rather than using SMP parallelism.
To make a long story short for a warehouse that requires multiple CPUs
you will see the recommendation of DPF for performance.
For the best practices I recommend looking into Balanced Configuration
Units (BCU):http://www.db2mag.com/story/showArti...leID=180206351

>

.. oh.. and it's not a rumor... for a warehouse a well designed DPF
system will achieve near linear scalability compared to an SMP approach
which delivers diminishing returns.

>

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

>

yes, Serge. DPF need more experienced professional to keep the near
linear scalability. In my experience, every time customer complained
DPF delivers worse performance and I always tell them the need for
more design and tuning, then do sth. to fulfill their need.

>

Actually, we deliver system always according to the BCU methodology
and gain good feedback.

>

But the problem that if only one server with many CPU and memory, if
the data/table size is not a limit, then what's the best solution?

>
to keep simple, is the advantage for multi-partition over SMP
parallelism(sur e?,is there any direct data or material) is worth the
big effort on DPF design? especially for a firm without strong skill.

sorry, I had a mistake with the submit page and then over-submit...

[Serge Rielau]

Re: why DPF?

Hardy wrote:

to keep simple, is the advantage for multi-partition over SMP
parallelism(sur e?,is there any direct data or material) is worth the
big effort on DPF design? especially for a firm without strong skill.

Let's level set: You are talking about a warehouse/datamart, right?
For OLTP my answer to DPF will nearly always be no.

The next question is growth: Most warehouses keep growing and growing.
So you may start with a 4 way box and get away with it. But in two years
you need to double, etc, etc. The worst thing that can happen is that
your design is not suitable for DPF and you hit the wall because SMP
doesn't scale high enough to where you need to be in 2, 3, 5 years.

I will try to get an expert to post here. My expertise in designing
warehouses has limits.

Also feel free to email me and I'll pass you to the experts.
Cheers
Serge



--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

[Hardy]

Re: why DPF?

On May 8, 7:52 pm, Serge Rielau <srie...@ca.ibm .comwrote:

Hardy wrote:

to keep simple, is the advantage for multi-partition over SMP
parallelism(sur e?,is there any direct data or material) is worth the
big effort on DPF design? especially for a firm without strong skill.

>
Let's level set: You are talking about a warehouse/datamart, right?
For OLTP my answer to DPF will nearly always be no.
>
The next question is growth: Most warehouses keep growing and growing.
So you may start with a 4 way box and get away with it. But in two years
you need to double, etc, etc. The worst thing that can happen is that
your design is not suitable for DPF and you hit the wall because SMP
doesn't scale high enough to where you need to be in 2, 3, 5 years.
>
I will try to get an expert to post here. My expertise in designing
warehouses has limits.
>
Also feel free to email me and I'll pass you to the experts.
Cheers
Serge
>
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Serge, thank you. I'll write you soon.

[Serge Rielau]

Re: why DPF?

Hardy wrote:

Serge, thank you. I'll write you soon.

Yeah, yeah.. that's what SHE said... ;-)

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

[Hardy]

Re: why DPF?

On May 8, 9:42 pm, Serge Rielau <srie...@ca.ibm .comwrote:

Hardy wrote:

Serge, thank you. I'll write you soon.

>
Yeah, yeah.. that's what SHE said... ;-)
>
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

:)
Basicly, I really want to dig out the potential of non-DPF UDB.

For a small server with less CPU and memory, or a strong box such as
p595 with 64c256g, will non-DPF managed the resource well enough?