At 08:42 AM 7/30/01 -0700, you wrote:
>If I understand correctly, UDB on UNIX doesn't let me specify
>partitioning key ranges like OS/390 DB2.
>In OS/390 I can 'point' key ranges to specific partitions. This allows
>me to direct the growth of a table toward the end(highest numbered
>partition), keeping the beginning (low numbered) partitions static. The
>advantage is that I never have to reorg the oldest (lowest numbered)
>partitions. With UDB 7.2, my understanding is that I have to let the
>random assignment to nodes put new rows whereever the hashing algorithm
>chooses. Is this right? If so, is there any plan in IBM to make UDB on
>UNIX more like OS/390 with respect to partition key assignment?
>I'd appreciate your thoughts advice on how to deal with this kind of
>situation.
>Thanks in advance,
>Roy
Roy,
Sorry for the late reply, but I'll try to answer anyway. The hash
partitioning is VERY fast on DB2 UDB EEE. I don't understand why this is a
problem, its just different. To keep from reorging the data, your tables
could be put into append mode, where newly added data is put at the end of
the table. All containers should grow at the same rate, provided you've
not picked a bad partitioning key, such as month number. What exactly is
your situation? Personally, I think that hash partitioning is much better
than range partitioning in many respects - one being that there is less
space monitoring that is needed by DBAs. If a decent key is chosen, data
is spread evenly across all partitions, therefore allowing maximum
retrieval rate, especially for collocated joins. Hope this helps.
Regards,
Steve
___________________________
Steve Mazer
Senior Database Consultant
Fourth Millennium Technologies
IBM DB2 Gold Consultant
=====
To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
For other info (and scripts), see http://people.mn.mediaone.net/scottrmcleod
