Re: Convert SAP Oracle Database to IBM DB2 Database??
From: Serge Rielau <srielau_at_ca.ibm.com>
Date: Fri, 08 Feb 2008 11:37:30 -0500
Message-ID: <613eqlF1tflc7U1@mid.individual.net>
>>
>>>>
>>>> What I'm saying is that it is not just superficial ... from a
>>>> technical point-of-view it is mostly incorrect. He needs to learn
>>>> how to read the
>>>> on-line docs.
>>> Well the nice thing about BLOGs is the ability to give feedback.
>>> You are a teacher, no? Teach!
>>>
>>> Cheers
>>> Serge
>>
>> Eaton's blog is basically correct. However he mentions the negatives
>> of the Oracle design, and does not mention the advantages. The
>> greatest advantage of having the symbol table local to the page is
>> that you do not have to do another I/O to read the symbol table - the
>> single block I/O gets the compressed data and the symbols required to
>> uncompress it. Our testing in large scale environments shows that to
>> me more beneficial than the IBM design. There are also additional
>> benefits accrued from not having to expand a single symbol table when
>> the data values grow, etc.
>>
>> So it's horses for courses. We just think our horses are better. YMMV,
>> and as always, test well.
Date: Fri, 08 Feb 2008 11:37:30 -0500
Message-ID: <613eqlF1tflc7U1@mid.individual.net>
DA Morgan wrote:
> Mark Townsend wrote:
>>
>>>>
>>>> What I'm saying is that it is not just superficial ... from a
>>>> technical point-of-view it is mostly incorrect. He needs to learn
>>>> how to read the
>>>> on-line docs.
>>> Well the nice thing about BLOGs is the ability to give feedback.
>>> You are a teacher, no? Teach!
>>>
>>> Cheers
>>> Serge
>>
>> Eaton's blog is basically correct. However he mentions the negatives
>> of the Oracle design, and does not mention the advantages. The
>> greatest advantage of having the symbol table local to the page is
>> that you do not have to do another I/O to read the symbol table - the
>> single block I/O gets the compressed data and the symbols required to
>> uncompress it. Our testing in large scale environments shows that to
>> me more beneficial than the IBM design. There are also additional
>> benefits accrued from not having to expand a single symbol table when
>> the data values grow, etc.
>>
>> So it's horses for courses. We just think our horses are better. YMMV,
>> and as always, test well.
> > I disagree Mark ... unless I know something I'm not supposed to talk > about (so I won't). Yes the symbol table is on a single-block basis. > But the critical information missing from Eaton's blog is the > method used to keep compression from affecting insert performance. > And of course no mention of compressed tablespaces, no mention of > compression without direct path loading, no mention of deduplication, > no mention of compressed indexes, etc.Daniel,
I give you index compression.
Compression without direct path loading in 11g is catch-up.
DB2 9 shipped with it from the start. In DB2 9.5 the system also
automagically create a dictionary once a threshhold in table size is
reached. No initial reorg, load, nothing....
Can't comment on the other points as I don't know their meaning in the context.
Are logs compressed? What about the pages in the buffer pool? We found that the effective doubling in bufferpool has significant impact on either cost of the system (reduced main memory requirements) or performance (better hit ratio).
Cheers
Serge
-- Serge Rielau DB2 Solutions Development IBM Toronto LabReceived on Fri Feb 08 2008 - 10:37:30 CST