Moigration from Oracle 10g to Db2 8.2

[Ashish Patankar]

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.

[Bob Jones]

"Larry" <La***@nospam.n et> wrote in message news:ZI******** *****@fe08.lga. ..

Bob Jones wrote:

This is NOT the point which you are completely missing. The original
responder called the move from Oracle to DB2 a downgrade ... not a
migration. That was without knowing anything about what the OP's app
looks like. That is a mischaracteriza tion.

Yes, that's what I would call it. Didn't I specifically say "depending on
what 10g features are used"?

Yes you did ... but you also said "Dude, Oracle 8i to DB2 8.2 is a
migration. Oracle 10g to DB2 8.2 is a downgrade and migration.". Operative
phrase "... IS a downgrade and migration". That's a different claim than
saying "depending on ...".

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.

It seems to be quite clear to me but again I am no lawyer.

The same could be said about moving from certain DB2 configurations to
Oracle.

No, it could not. Most DBAs with experience with both brands will tell
you otherwise.

Is that why Oracle has such a significant install base in the highly
parallel shared-nothing enterprise data warehouse market?

I thought that was considered by you as an architectural difference. Not any
more?

DB2 is a few years behind Oracle and mainframe is decades behind UNIX and
Windows.

I'd like some of what you're smoking. Once again you're drawing what
sounds like an incontrovertibl e conclusion when it really depends.

I have been smoking the flame of my management who found out the project of
migrating to DB2 was a mistake.

[Bob Jones]

"Serge Rielau" <sr*****@ca.ibm .com> wrote in message
news:4e******** *****@individua l.net...

Bob Jones wrote:

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.
Perhaps you can elaborate on how these features/functionalities are
implemented in DB2.

1. Dropping a table column.
2. Creating a bitmap index.
3. Moving an index from one tablespace to another or having indexes for a
table placed in different tablespaces.
4. Changing default tablespace for an index.
5. Flashbacks
6. Loading a table into a tablespace without affecting other objects in
the same tablespace on mainframe.

Can't comment on point 6 (mainframe admin question). Of all the other
points the only point that is relevant for migrating an app is point 5.

This is not about migration. This is about downgrade.
Flashbacks are cute. If you want to do long term versioning stamp rows,
voila. No harm done. At least that way the app is in conrol when data is
rolled of.
But to get back to stickers. The move in DB2 is to reduce the number of
tablespaces, not to increase it. I must say that I personally don't like
this choice to the nth degree. While one can call it feature rich, one can
also call it complex. Today's users and average admins do not have the
skill it takes on average.
I fail to see the value of separating index and data table spaces in
general.

Tables and indexes often have different storage requirements. Separating
them makes sense. Some DBAs would do it just for readability. The ability to
do 3 and 4 is very basic in Oracle, nothing complex about it.
DROP COLUMN btw is in DB2 Viper. So get the best mileage out of the
deficiency while you can ;-)

This was available back in Oracle 8i.
DB2 customers don't ask for bitmap indexes, apparently not needed by the
masses and very likely not by the OP either.

Hmmm, I wonder if Oracle customers asked for it before it was available?

[Serge Rielau]

Bob Jones wrote:

Tables and indexes often have different storage requirements. Separating
them makes sense. Some DBAs would do it just for readability. The ability to
do 3 and 4 is very basic in Oracle, nothing complex about it.

Readability? What's readable about adding additional objects into the
mix? Also keep in mind that todays storage is not as stupid as it used
to. What was right and proper 10 years ago may be obsolete today and
harmful tomorrow.
If there is nothing complex about laying out your indexes, tablespaces
etc, etc. why is it such a popular topic in the Oracle forum as Mark
points out? Should be nothing to talk about, eh?

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

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/

[Knut Stolze]

Nice flame war...

Bob Jones wrote:

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.

Then you can also say: DB2 V5.1 to Oracle 10g is a downgrade and migration -
depending on which DB2 features you were using.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany

[Ian]

Serge Rielau wrote:

Ian wrote:

Serge Rielau wrote:

Data placement IMHO falls into that category.
This is true, up to a limit. Spending time to try and isolate I/O
from tables/indexes/temp/etc. is one thing. But understanding how
your data is laid out on a SAN is still very relevant.

I have seen small data warehouses absolutely CRAWL (constant 95%
I/O wait) when no one bothered to pay attention to how tablespaces,
filesystems and LUNs map to physical disks in a SAN. And this
happens a LOT.

The rule of thumb is: strip everything across everything.

Meaning, 'Stripe all *DB2* data across all storage paths'. I have no
problems with this.
If your storage admin dedicates 2 disks to DB2 then there isn't much
help to be had. ;-)
That's true. But my point is that there needs to be some understanding
between the different people.

If you have 2 large SAN volumes (i.e. LUNs), but the UNIX admin
creates 30 file systems and then the DBA (somewhat understandably)
spreads every tablespaces containers across all 30 file systems, you
will be in for problems.

BTW, I got, after posting my "proclamati on", a tad scared and consulted
with our DMS (Data management services) folks and got the content
confirmed.
I paraphrase wat I was told:
"A good(!) DBA may be able to boost performance by 10% compared to DB2's
built in algorithms, but that same DBA is likely to gain a lot more by
tuning the schema itself (create/drop indices, etc...) rather than
wasting his/her time on data placement."

I'm certainly not disputing this. I'm just trying to draw a distinction
between data placement within the database and container placement on
logical -> physical devices.

[Brian Tkatch]

Ian wrote:

Brian Tkatch wrote:

It is called "Assembly" which is "assembled" by the "Assembler" .
"Assembler" code would be some form of meta-language that doesn't
exist.

One of my many pet pieves. :)

You mean peeves. :) Couldn't resist.

Heh. I knew i shouldn't have typed that. :)

B.

[Brian Tkatch]

Serge Rielau wrote:

Ian wrote:

Serge Rielau wrote:

Data placement IMHO falls into that category.
This is true, up to a limit. Spending time to try and isolate I/O
from tables/indexes/temp/etc. is one thing. But understanding how
your data is laid out on a SAN is still very relevant.

I have seen small data warehouses absolutely CRAWL (constant 95%
I/O wait) when no one bothered to pay attention to how tablespaces,
filesystems and LUNs map to physical disks in a SAN. And this
happens a LOT.

The rule of thumb is: strip everything across everything.
If your storage admin dedicates 2 disks to DB2 then there isn't much
help to be had. ;-)

BTW, I got, after posting my "proclamati on", a tad scared and consulted
with our DMS (Data management services) folks and got the content confirmed.
I paraphrase wat I was told:
"A good(!) DBA may be able to boost performance by 10% compared to DB2's
built in algorithms, but that same DBA is likely to gain a lot more by
tuning the schema itself (create/drop indices, etc...) rather than
wasting his/her time on data placement."

And doing both would be better and better.

B.


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

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/

[Bob Jones]

"Serge Rielau" <sr*****@ca.ibm .com> wrote in message
news:4e******** *****@individua l.net...

Bob Jones wrote:

Tables and indexes often have different storage requirements. Separating
them makes sense. Some DBAs would do it just for readability. The ability
to do 3 and 4 is very basic in Oracle, nothing complex about it.

Readability? What's readable about adding additional objects into the mix?
That's what I would like to ask. What is so readable about mixing tables and
indexes in one tablespace?
Also keep in mind that todays storage is not as stupid as it used to. What
was right and proper 10 years ago may be obsolete today and harmful
tomorrow.
I am talking about storage configurations for tablespaces, not disk storage.
If there is nothing complex about laying out your indexes, tablespaces
etc, etc. why is it such a popular topic in the Oracle forum as Mark
points out? Should be nothing to talk about, eh?

They are talking about performance issues, not simply the ability to place
indexes in different tablespaces or change default space for indexes.
If there is no point to separate tables and indexes, why even DB2 let you
specify index spaces?

[Bob Jones]

"Knut Stolze" <st****@de.ibm. com> wrote in message
news:e6******** **@lc03.rz.uni-jena.de...

Nice flame war...

Bob Jones wrote:

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.

Then you can also say: DB2 V5.1 to Oracle 10g is a downgrade and
migration -
depending on which DB2 features you were using.

You mean better features or just features? I would really like to hear an
example.

[Serge Rielau]

Bob Jones wrote:

"Serge Rielau" <sr*****@ca.ibm .com> wrote in message
news:4e******** *****@individua l.net...

Bob Jones wrote:

Tables and indexes often have different storage requirements. Separating
them makes sense. Some DBAs would do it just for readability. The ability
to do 3 and 4 is very basic in Oracle, nothing complex about it.

Readability? What's readable about adding additional objects into the mix?

That's what I would like to ask. What is so readable about mixing tables and
indexes in one tablespace?

I for the life of it don't get ho wthe word "readable" applies to any of
that. Are we talking DDl script here or what? Some GUI display? They are talking about performance issues, not simply the ability to place indexes in different tablespaces or change default space for indexes.
If there is no point to separate tables and indexes, why even DB2 let you
specify index spaces?

Prior to DB2 Viper there is a limit to the size of a tablespace and thus
an upper limit to the size of a given table.
Having to share the space with the indexes further reduces the available
space.
Also, as I said earlier what was right 10 years ago is not that relevant
anymore.
The direction in DB2 is to reduce complexity.
Keep in mind that the dominating cost nowadays is not hardware or
software. It is labor cost. If the DBA has to spend time worrying about
where to place DB objects that's expensive.
If other vendors believe in knobs to get that last percent, that's not
bad, but it doesn't make our choice towards simplicity wrong either.
Keeps the market interesting if anything.

I recall "call for papers" to conferences with three primary topics:
Performance, Performance, Performance

I don't agree that performance is everything.
We don't drive race cars to work either. Not even on the Autobahn.

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

IOD Conference
http://www.ibm.com/software/data/ond...ness/conf2006/