DB2 vs Oracle

[Database Guy]

Daniel Morgan wrote:

> Dollars are dollars. And I didn't say DB2 wasn't a bit cheaper. I have
> found that if one compares apples with apples and negotiates, which is
> what everyone either does or should do, tha the price difference is
> small enough to be inconsequential.

DB2 is more than "a bit" cheaper - it's half the price for the same
level of functionality. And, more important, most people are smart
enough to realise that Oracle will bleed them dry once renewal time
comes up and they've locked you in to their (very) proprietry
database. So list prices do matter very much.

> And if price is your big concern ... run, don't walk, to MySQL.

So when you expressed your concerns about Oracle being overpriced in
an Oracle newsgroup...

"But if rumors are true about Oracle changing its
pricing model ... the 10g license might be cheaper than
the 9i. This is one rumor I hope is true because it
won't just help all of us ... it will help Oracle too."

[Daniel Morgan, 16th September 2003]

....you were really worrying that everyone is moving to mySQL, a
product that definitely isn't comparing apples with apples, and which
you can't possibly match on price? Pull the other one.


DG

[Daniel Morgan]

Ian wrote:

>
> Please don't tell me that you actually trust PC Magazine to complete
> a good comparison of these products. PC Mag has always struck me as
> just a shill for the vendors -- they don't criticize too much for fear
> of losing advertising revenue.

I trust them as much as I trust anyone else doing a benchmark while
taking money from vendors to support their organization's existance.

And that goes for the Transaction Processing Performance Council too. Go
to tpc.org. Click on 'Members' under 'Who We Are'.
Looks like the advertising page in any glossy publication to me.

--
Daniel Morgan
[url]http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp[/url]
[url]http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp[/url]
[email]damorgan@x.washington.edu[/email]
(replace 'x' with a 'u' to reply)

[Mark A]

> > Please don't tell me that you actually trust PC Magazine to complete

> > a good comparison of these products. PC Mag has always struck me as
> > just a shill for the vendors -- they don't criticize too much for fear
> > of losing advertising revenue.

>
> I trust them as much as I trust anyone else doing a benchmark while
> taking money from vendors to support their organization's existance.
>
> And that goes for the Transaction Processing Performance Council too. Go
> to tpc.org. Click on 'Members' under 'Who We Are'.
> Looks like the advertising page in any glossy publication to me.
>
> --
> Daniel Morgan

The TPC benchmarks are conducted by vendors (under the rules of each TPC
benchmark) and supervised by a independent consultant that is approved by
the TPC. This gives the vendor the opportunity to properly tune its own
product. The reason that all the vendors are members is so they can ensure
that the benchmark standards and procedures are fair and unbiased. These
standards have been developed and refined over many years. You can download
the test specifications from their site.

The TPC benchmarks are accepted as a fair test by all those who are members,
which includes IBM, Oracle, and MS. Not so with PC Magazine. I don't
necessarily think that PC magazine is always biased, but they surely are not
competent enough to run a fair test. BTW, no one spends more money on TPC
benchmarking than Oracle.

The fact that you were unaware of the TPC benchmarks until recently, casts
serious doubts about your knowledge of the relative database performance of
each product.

[Fan Ruo Xin]

Thank you, Mark.


Mark A wrote:

> >> Alternatively, with a UNION ALL approach, can you have one
> > >overall set [of indexes] for all the tables ?

> >

> No, the indexes should be the same for each table, but they are tied to each
> table and are not global. If data from multiple tables is required (and
> hence multiple indexes need to be accessed) the access can be done in
> parallel. The optimizer will choose to only access those tables (and
> indexes) needed based on the where clause (or table constraints if you use
> them instead of the where clause in the UNION ALL view).
>
> I don't know how Oracle prices its partitioning/parallel offerings these
> days (although I purchased it about 5 years ago), but the UNION ALL approach
> in DB2 can be implemented without purchasing the more expensive partitioning
> versions of DB2 (EEE or ESE).
>
> [url]http://www7b.boulder.ibm.com/dmdd/library/techarticle/0202zuzarte/0202zuzarte.pdf[/url]
>
> I have used the UNION ALL technique with DB2 and did extensive analysis of
> the access paths using the "explain." I was amazed how well it works.

[Fan Ruo Xin]

The DBAs and developers decide to use it because this is the best way Oracle can provide
for this kind of applications. Does that mean this is the best way?


Daniel Morgan wrote:

> Fan Ruo Xin wrote:
>

> >Not exactly. The introduction of partitioning technology in ORACLE begins with
> >addressing the big size of the user table or index. Oracle has to adjust partitioning
> >technology in order to deal with more and more ROLAP applications.
> >On the other way, DB2 UDB MDC is DESIGNED to address this kind of applications.
> >
> >
> >

> Sorry here but utter nonsense. Partitioning in Oracle is used for what
> developers and DBAs decide to use it for. Not what Oracle
> puts in an advertisement. And I've seen it used in applications from
> AT&T, Boeing, Bank of America, etc. and not once for any
> purpose of than to create an easy to maintain rolling window.
>
> I'd be surprised if most of the people using it would do more than laugh
> if told there was some relationship to ROLAP.
>
> --
> Daniel Morgan
> [url]http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp[/url]
> [url]http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp[/url]
> [email]damorgan@x.washington.edu[/email]
> (replace 'x' with a 'u' to reply)

[Daniel Morgan]

Mark A wrote:

>>>Please don't tell me that you actually trust PC Magazine to complete
>>>a good comparison of these products. PC Mag has always struck me as
>>>just a shill for the vendors -- they don't criticize too much for fear
>>>of losing advertising revenue.
>>>
>>>

>>I trust them as much as I trust anyone else doing a benchmark while
>>taking money from vendors to support their organization's existance.
>>
>>And that goes for the Transaction Processing Performance Council too. Go
>>to tpc.org. Click on 'Members' under 'Who We Are'.
>>Looks like the advertising page in any glossy publication to me.
>>
>>--
>>Daniel Morgan
>>
>>

>
>The TPC benchmarks are conducted by vendors (under the rules of each TPC
>benchmark) and supervised by a independent consultant that is approved by
>the TPC. This gives the vendor the opportunity to properly tune its own
>product. The reason that all the vendors are members is so they can ensure
>that the benchmark standards and procedures are fair and unbiased. These
>standards have been developed and refined over many years. You can download
>the test specifications from their site.
>
>The TPC benchmarks are accepted as a fair test by all those who are members,
>which includes IBM, Oracle, and MS. Not so with PC Magazine. I don't
>necessarily think that PC magazine is always biased, but they surely are not
>competent enough to run a fair test. BTW, no one spends more money on TPC
>benchmarking than Oracle.
>
>The fact that you were unaware of the TPC benchmarks until recently, casts
>serious doubts about your knowledge of the relative database performance of
>each product.
>
>
>

Even you don't believe a typo constitutes lack of knowledge. But what
you might believe is that because the vendors
find something of value the consumer should to. Obviously the vendors do
.... but for the sole purpose of marketing
and advertising. I don't because I think marketing and advertising are
concocted solely to sell things to people that
otherwise might not have had the intelligence to find buy them without
being told what to buy.

--
Daniel Morgan
[url]http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp[/url]
[url]http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp[/url]
[email]damorgan@x.washington.edu[/email]
(replace 'x' with a 'u' to reply)

[Mark A]

>"Daniel Morgan" <damorgan@x.washington.edu

> wrote in message news:1064191467.611977@yasure...
>Even you don't believe a typo constitutes lack of knowledge.
>But what you might believe is that because the vendors
>find something of value the consumer should to. Obviously
>the vendors do ... but for the sole purpose of marketing
>and advertising. I don't because I think marketing and
>advertising are concocted solely to sell things to people that
>otherwise might not have had the intelligence to find buy
>them without being told what to buy.

--

>Daniel Morgan

It wasn't a typo. You repeated the mistake multiple times. Then you did a
goggle search on TPC, then after you found the web site you complained it
was too commercial because the members were vendors.

You knew nothing about TPC until I mentioned on this board. You are not
telling the truth. Have you no shame?

Further, by your comments above, you still don't understand the TPC. It is
the most widely accepted DBMS benchmark available today and is widely
respected by corporate America. The fact that the major DBMS vendors are all
members of the TPC, and they must approve the makeup of the benchmark tests
(with all the associated detail), ensures that no vendor can abuse the
benchmark.

Again you have demonstrated your total ignorance about DBMS performance and
benchmarking.

[Pablo Sanchez]

Daniel Morgan <damorgan@x.washington.edu> wrote in
news:1064191467.611977@yasure:

> Even you don't believe a typo constitutes lack of knowledge. But
> what you might believe is that because the vendors find something
> of value the consumer should to. Obviously the vendors do ... but
> for the sole purpose of marketing and advertising. I don't because
> I think marketing and advertising are concocted solely to sell
> things to people that otherwise might not have had the
> intelligence to find buy them without being told what to buy.

Yet again you are incorrect and to think, you "teach." *gulp*

The TPC's are valuable on several fronts - not that I expect you to
even begin to appreciate what's involved in an effort to product a
TPC number:

Hardware Vendor
---------------
* O/S scalability
* O/S tunes specific to the DBMS
* Hardware scalability

DBMS Vendor
-----------
* DB Tuning handbooks (which make their way to you, the "teacher")
* DB scalability
* DB kernel tuning

Customer
--------
* Benefits from the tuning done by the Hardware and DBMS vendor.
There is no code in DBMS kernels that says - well, not anymore!
<g>

#if TPC_C
<<highly_tuned SQL>>
#endif

* Capacity planning
--
Pablo Sanchez, Blueoak Database Engineering
[url]http://www.blueoakdb.com[/url]

[Daniel Morgan]

Fan Ruo Xin wrote:

>The DBAs and developers decide to use it because this is the best way Oracle can provide
>for this kind of applications. Does that mean this is the best way?
>
>
><snipped>
>

>>Sorry here but utter nonsense. Partitioning in Oracle is used for what
>>developers and DBAs decide to use it for. Not what Oracle
>>puts in an advertisement. And I've seen it used in applications from
>>AT&T, Boeing, Bank of America, etc. and not once for any
>>purpose of than to create an easy to maintain rolling window.
>>
>>I'd be surprised if most of the people using it would do more than laugh
>>if told there was some relationship to ROLAP.
>>
>>--
>>Daniel Morgan
>>[url]http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp[/url]
>>[url]http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp[/url]
>>damorgan@x.washington.edu
>>(replace 'x' with a 'u' to reply)
>>
>>

If you are asking with respect to a rolling window yes. It certainly
helps improve DML performance. But it turns pruning into a
near instantaneous affair. And, I should add, also is used to simplify
backups. Once a partition no longer requires updating the
tablespace is converted to readonly and no further backups are required.

I may disagree with some of the people here on non-technical matters but
I don't wish to be rude. If you have any further Oracle
questions lets take them to c.d.o.server so as not to be off-topic. Thanks.

--
Daniel Morgan
[url]http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp[/url]
[url]http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp[/url]
[email]damorgan@x.washington.edu[/email]
(replace 'x' with a 'u' to reply)

[Fan Ruo Xin]

Daniel Morgan wrote:

>but I don't wish to be rude.

I bet you don't ... if we can call it 'polite' --- when you jump here without understanding
what people are talking about.

/* Why do we need partitioning technology?
We want to decompose a very large table into a couple of smaller parts (partitions)... */
I am wondering I was denied at the first place when I said the root reason of partitioning is
because of the BIG TABLE SIZE or the LARGE VOLUME OF DATA. Do you suggest the Oracle DBA to
build and configure a couple of tablespaces, split a SMALL table into a couple of more
smaller parts in order to take the advantage of the feature - rolling window???

>If you are asking with respect to a rolling window yes. It certainly
>helps improve DML performance. But it turns pruning into a
>near instantaneous affair. And, I should add, also is used to simplify
>backups. Once a partition no longer requires updating the
>tablespace is converted to readonly and no further backups are required.

Please tell me for the DW applications, the No. 1 advantage of partitioning is not because of
improving QUERY PERFORMANCE (I/O, CPU parallelism improving) - but DML PERFORMANCE ???

Please tell me the main reason for rolling out the oldest data is because of SIMPLIFYING THE
BACKUP, not because of the storage can be REUSED by the more recently data.
…

Again, the following is from my previous posting message:
/* Why do we need partitioning technology?
We want to decompose a very large table into a couple of smaller parts (partitions) and
improve I/O, CPU parallelism. */

>I'd be surprised if most of the people using it would do more than
>laugh if told there was some relationship to ROLAP.

May I ask you - in which scenario rolling window is used mostly? That's not fact table? That
has nothing with ROLAP applications?
Again either rolling fact table or rolling MV is not because of the large volume data of the
fact tables or MVs?

>I may disagree with some of the people here on non-technical matters

You did impress me when you were talking the TECHNICAL issue.

[Daniel Morgan]

Fan Ruo Xin wrote:

>Daniel Morgan wrote:
>
>
>

>>but I don't wish to be rude.
>>
>>

>I bet you don't ... if we can call it 'polite' --- when you jump here without understanding
>what people are talking about.
>
>/* Why do we need partitioning technology?
>We want to decompose a very large table into a couple of smaller parts (partitions)... */
>I am wondering I was denied at the first place when I said the root reason of partitioning is
>because of the BIG TABLE SIZE or the LARGE VOLUME OF DATA. Do you suggest the Oracle DBA to
>build and configure a couple of tablespaces, split a SMALL table into a couple of more
>smaller parts in order to take the advantage of the feature - rolling window???
>
>
>
>

>>If you are asking with respect to a rolling window yes. It certainly
>>helps improve DML performance. But it turns pruning into a
>>near instantaneous affair. And, I should add, also is used to simplify
>>backups. Once a partition no longer requires updating the
>>tablespace is converted to readonly and no further backups are required.
>>
>>

>
>Please tell me for the DW applications, the No. 1 advantage of partitioning is not because of
>improving QUERY PERFORMANCE (I/O, CPU parallelism improving) - but DML PERFORMANCE ???
>
>Please tell me the main reason for rolling out the oldest data is because of SIMPLIFYING THE
>BACKUP, not because of the storage can be REUSED by the more recently data.
>...
>
>Again, the following is from my previous posting message:
>/* Why do we need partitioning technology?
>We want to decompose a very large table into a couple of smaller parts (partitions) and
>improve I/O, CPU parallelism. */
>
>
>
>

>>I'd be surprised if most of the people using it would do more than
>>laugh if told there was some relationship to ROLAP.
>>
>>

>May I ask you - in which scenario rolling window is used mostly? That's not fact table? That
>has nothing with ROLAP applications?
>Again either rolling fact table or rolling MV is not because of the large volume data of the
>fact tables or MVs?
>
>
>
>

>>I may disagree with some of the people here on non-technical matters
>>
>>

>You did impress me when you were talking the TECHNICAL issue.
>
>
>

As this relates to Oracle rather than DB2 please repost your question in
the appropriate usenet group.

--
Daniel Morgan
[url]http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp[/url]
[url]http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp[/url]
[email]damorgan@x.washington.edu[/email]
(replace 'x' with a 'u' to reply)

[Ian]

Daniel Morgan wrote:

[trimmed range based partitioning discussion]

>>

> As this relates to Oracle rather than DB2 please repost your question in
> the appropriate usenet group.

Why? Many customers do the equivalent of Oracle range-based artitioning
in DB2 UDB with multiple tables and UNION ALL.

Therefore, the discussion of range-based partitioning is very relevant
in this newsgroup, regardless of the physical implementation.

So, can you answer FRX's questions? I'll restate them here since I
trimmed them off.

1) Why would you use Range Based Partitioning on small tables?
2) Do you roll out old data because you can, or because you have to?
Given infinite storage space, would you still roll out old data?






-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
[url]http://www.newsfeeds.com[/url] - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Daniel Morgan]

Ian wrote:

> Daniel Morgan wrote:
>
> [trimmed range based partitioning discussion]
>

>>>

>> As this relates to Oracle rather than DB2 please repost your question
>> in the appropriate usenet group.

>
>
> Why? Many customers do the equivalent of Oracle range-based artitioning
> in DB2 UDB with multiple tables and UNION ALL.
>
> Therefore, the discussion of range-based partitioning is very relevant
> in this newsgroup, regardless of the physical implementation.
>
> So, can you answer FRX's questions? I'll restate them here since I
> trimmed them off.
>
> 1) Why would you use Range Based Partitioning on small tables?
> 2) Do you roll out old data because you can, or because you have to?
> Given infinite storage space, would you still roll out old data?
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> [url]http://www.newsfeeds.com[/url] - The #1 Newsgroup Service in the World!
> -----== Over 100,000 Newsgroups - 19 Different Servers! =-----

I often use range partitioning on small tables. Here are the main reasons:

The convenience of being able to prune data without the danger of
implementing delete statements
with possibly incorrect WHERE clauses in a production database. Last
time I was at AT&T on a
consulting gig a DBA (and no it wasn't me) accidentally missed on part
of a WHERE clause and the
result was ... to put it gently ... unpleasant. We implemented
partitioning immediately.

The second reason is the ability to place a single table into multiple
tablespaces allowing for the ability
to make partitions read-only. This guaranteed data security and
eliminated the need to back up data
that will never be changed.

With the price of DASD as low as it is I can't imagine why I'd roll out
old data to save space on small
tables. Large ones: Absolutely but not small ones. But in many
situations, for example a client I have in
the retail business, they partition SKUs from year to year so they can
easily get rid of 2002 data when
2003 rolls around which improves data integrity. Someone can't
accidentally pick last-year's SKU or
last year's catalog price. Could it be handled in another way?
Absolutely. But code requires QA testing.
Pruning a partition does not. Which save a lot of time and money.

HTH

--
Daniel Morgan
[url]http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp[/url]
[url]http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp[/url]
[email]damorgan@x.washington.edu[/email]
(replace 'x' with a 'u' to reply)