View Single Post

   
  #9 (permalink)  
Old 02-27-2008, 07:14 AM
Larry
 
Posts: n/a
Default Re: Moigration from Oracle 10g to Db2 8.2

DA Morgan wrote:
> Larry wrote:
>
>> DA Morgan wrote:
>>
>>> Curious wrote:
>>>
>>>> Bob Jones wrote:
>>>>
>>>>> "Ashish Patankar" <ashishpatankar@gmail.com> wrote in message
>>>>> news:1149142524.394632.226950@j55g2000cwa.googlegr oups.com...
>>>>>
>>>>>> I want to migrate my Oracle 10g database to Db2. I want some
>>>>>> documentation for the comparision between these to databases. I also
>>>>>> want to know which features of Oracle 10g are supported by Db2 and
>>>>>> which are not supported.
>>>>>>
>>>>>
>>>>>
>>>>> Dude, Oracle 8i to DB2 8.2 is a migration. Oracle 10g to DB2 8.2 is
>>>>> a downgrade and migration. Depending on what 10g features are used,
>>>>> you may find more or fewer things not supported or different in DB2.
>>>>>
>>>> Such as?
>>>
>>>
>>>
>>> The list is nearly endless. You won't find packages, either built-in or
>>> user defined. You won't a fraction of the instrumentation. You won't
>>> find multiversion read consistency. You won't find a shared-everything
>>> architecture (unless on a mainframe version). You won't find 1/2 of
>>> Oracle's table types or half of Oracle's index types. As I said, the
>>> list is very very long.
>>>
>>> Which doesn't mean you need those Oracle features. But if you do you
>>> will not find them in DB2 8.2.

>>
>> Daniel ... you know as well as I do that these are primarily
>> architectural differences between Oracle and DB2.

>
>
> MVCC is more than just architecture. And the 848 built-in packages in
> 10.2.0.2 are far more than fluff. They are tuning metrics. They are
> HTTP and TCP. They are on-line rebuild capabilities. They are
> partitioning by hash, range, and list. They are resumable transactions.
> They are spatial mapping. They are BLOB compression. They are Advanced
> Queuing and Streams Replication.
>
> Architectural differences? I thinks not.
>
> Which, as I said, does not mean that someone will need these
> capabilities. But if they do ... it is something they should consider.

As usual, Daniel ... now you are saying something else.

Your original statement was "You won't find packages, either built-in or
user defined. You won't a fraction of the instrumentation. You won't
find multiversion read consistency. You won't find a shared-everything
architecture (unless on a mainframe version). You won't find 1/2 of
Oracle's table types or half of Oracle's index types. As I said, the
list is very very long."

The "packages" statement was very non-specific ... and now that you've
managed to cleverly get more specific ... depending upon what you are
talking about, you may or may not find the same or comparable functions
in DB2. The bulk of your statement ... at least the bulk of what was
specific enough to be intelligible ... was devoted to
architectural/implementation differences (shared-everything and
multi-version read consistency), not features and you won't pull the
wool over anyone's eyes here.

We're talking migration here. We're talking that you can often
accomplish the same thing with two different databases ... using similar
features or substitute functionality that one vendor has chosen to
implement somewhat differently.

Larry Edelstein
Reply With Quote