oracle - mysql comparison

[Alex Filonov]

Re: oracle - mysql comparison

"VC" <boston103@hotm ail.com> wrote in message news:<%ViJc.917 42$XM6.50454@at tbi_s53>...[color=blue]
> Pls. see below:
>
> "Alex Filonov" <afilonov@yahoo .com> wrote in message
> news:336da121.0 407141111.67a9a b79@posting.goo gle.com...[color=green]
> > "VC" <boston103@hotm ail.com> wrote in message[/color]
> news:<KbZIc.816 43$Oq2.30187@at tbi_s52>...[color=green][color=darkred]
> > > Hello,
> > >
> > > Please see in-line:
> > >
> > > "Alex Filonov" <afilonov@yahoo .com> wrote in message
> > > news:336da121.0 407131327.363b8 e5a@posting.goo gle.com...
> > > > As for consistency (I suppose you mean read-only), it's implemented in
> > > > ProgreSQL, another Open Source DB engine. BTW, other commercial RMBDS
> > > > (DB2, MSSQL) don't have read-only consistency and sell pretty well at
> > > that.
> > >
> > > Please define 'read-only consistency' and elaborate a bit on why DB2[/color][/color]
> and[color=green][color=darkred]
> > > MSSQL don't have it.
> > >[/color]
> >
> > Read-only consistency is defined well enough in Oracle Concepts document.
> > In short, it means that result of any query reflects commited data in the
> > tables as of time when the query was submitted, without locking any[/color]
> objects[color=green]
> > in the database (readers don't block writers, writers don't block[/color]
> readers).[color=green]
> >[/color]
>
> Ah, that's what you mean. In this narrow sense, yes, you are right. A
> more correct way would be to say that Oracle implements a variety of
> multiversion concurrency control with 'read consistency' being just a part
> of the mechanism.
>
> DB2 and MSSQL naturally do not have this kind of 'read consistency' (in a
> narrow sense) since they implement an entirely different concurrency model
> which prevent neither from producing fully consistent results, read or
> otherwise, in a proper isolation mode/level.
>[/color]

According to some information M$ is going to implement read-only
consistency (Oracle style) in the next version. As for correct concurrency
model, I remember one project, when data warehouse was build using MSSQL,
everything was almost OK, management was pleased immensely. Until they
started running reports. When management found out that reports practically
stopped online work, mood changed.
[color=blue]
>
> VC[/color]

[Alex Filonov]

Re: oracle - mysql comparison

"VC" <boston103@hotm ail.com> wrote in message news:<l9DJc.987 00$XM6.25133@at tbi_s53>...[color=blue]
> "Alex Filonov" <afilonov@yahoo .com> wrote in message
> news:336da121.0 407150733.5db6d e1@posting.goog le.com...
>[color=green]
> > According to some information M$ is going to implement read-only
> > consistency (Oracle style) in the next version.[/color]
>
> Yes, MS SQL Server is going to have multiversion concurrency control (the
> latest Yukon beta actually already has it). It'll be exposed to the user as
> SNAPSHOT isolation level.
>[color=green]
> >As for correct concurrency
> > model,[/color]
>
> A correct concurrency control/model ensures that all the permitted
> transactions are serializable. In this sense, databases like DB2 or MSSQL
> implement a correct concurrency model albeit at the expense of lower
> concurrency in some circumstances. Funnily enough, none of the Oracle
> isolation levels can make the same promise, i.e. ensure serializable
> transaction histories, in any of its isolation levels. Usually, it's quite
> easy to obtain correct results by augmenting an isolation level with
> something like 'select for update', though..
>[/color]

Hm, what about SERIALIZABLE isolation level in Oracle? I don't see that
it's any different from similar isolation level in MSSQL.
[color=blue][color=green]
> >I remember one project, when data warehouse was build using MSSQL,
> > everything was almost OK, management was pleased immensely. Until they
> > started running reports. When management found out that reports[/color]
> practically[color=green]
> > stopped online work, mood changed.[/color]
>
> Well, there are several possible responses to this anecdote:
>
> 1. If the described system was a true data warehouse/DSS, then there
> should not have been a problem at all since there should have been no OLTP
> activity by definition.
>[/color]

Well, this is an example of real life different from the theory. Happens all
the time.
[color=blue]
> 2. On the other hand, if the implementation was a mixed OLTP/DSS project,
> then judging by your story, the database architect was not qualified to
> design a system like that. His/her being surprised that a locking
> scheduler's reads block writes, and vice versa, is akin to a swimmer's being
> amazed that water is wet. There are several well-known approaches to the
> reporting problem such as replicating the main database to a reporting
> database, transaction log shipping, scheduling reports off-hours, etc.
>[/color]

Yeah, right. Now, tell me where to find managers who understand what
kind of DB architects they really need. And who prefer architects
proposing more expensive, although correct, solutions. And, of course,
offline reporting (and all solutions you propose are actually variants of
it) is not always what customer wants.
[color=blue]
> VC[/color]

[VC]

Re: oracle - mysql comparison


"Alex Filonov" <afilonov@yahoo .com> wrote in message
news:336da121.0 407160845.6603c 310@posting.goo gle.com...[color=blue]
> "VC" <boston103@hotm ail.com> wrote in message[/color]
news:<l9DJc.987 00$XM6.25133@at tbi_s53>...[color=blue][color=green]
> > "Alex Filonov" <afilonov@yahoo .com> wrote in message
> > news:336da121.0 407150733.5db6d e1@posting.goog le.com...
> >[color=darkred]
> > >As for correct concurrency
> > > model,[/color]
> >
> > A correct concurrency control/model ensures that all the permitted
> > transactions are serializable. In this sense, databases like DB2 or[/color][/color]
MSSQL[color=blue][color=green]
> > implement a correct concurrency model albeit at the expense of lower
> > concurrency in some circumstances. Funnily enough, none of the Oracle
> > isolation levels can make the same promise, i.e. ensure serializable
> > transaction histories, in any of its isolation levels. Usually, it's[/color][/color]
quite[color=blue][color=green]
> > easy to obtain correct results by augmenting an isolation level with
> > something like 'select for update', though..
> >[/color]
>
> Hm, what about SERIALIZABLE isolation level in Oracle? I don't see that
> it's any different from similar isolation level in MSSQL.
>[/color]

Oracle does not have SERIALIZABLE despite their assurances to the contrary.
It's trivial to imagine a transaction history where Oracle's SERIALIZABLE
won't produce correct results. For starters, try 'insert into t1 select
max(ID)+1 from t1'. The issue with Oracle's serializable being not quite
what it's labeled was discussed extensively in this newsgroup a couple of
years ago. Unfortunately, I do not remeber the subject name -- something
to do with airline reservations.
[color=blue][color=green]
> > 2. On the other hand, if the implementation was a mixed OLTP/DSS[/color][/color]
project,[color=blue][color=green]
> > then judging by your story, the database architect was not qualified to
> > design a system like that. His/her being surprised that a locking
> > scheduler's reads block writes, and vice versa, is akin to a swimmer's[/color][/color]
being[color=blue][color=green]
> > amazed that water is wet. There are several well-known approaches to the
> > reporting problem such as replicating the main database to a reporting
> > database, transaction log shipping, scheduling reports off-hours, etc.
> >[/color]
>
> Yeah, right. Now, tell me where to find managers who understand what
> kind of DB architects they really need. And who prefer architects
> proposing more expensive, although correct, solutions.[/color]

Well, one can hardly blame the hammer if one wants to use it as a
screwdriver can one ? Oracle has quite a few pecularities of its own that
can jeopardize a project if those responsible for design/implementation have
no clue as to what they are doing.
[color=blue]
>And, of course,
> offline reporting (and all solutions you propose are actually variants of
> it) is not always what customer wants.[/color]

What's wrong with those solutions for long running reports, quick queries
not being a problem ? Besides, the situation is not very much different
from running a long report under Oracle where the results won't be actual
due to the very nature of the beast -- 'read consistency'.

There is no argument that a multiversioning scheduler provides higher
concurrency in many cases, after all that's its raison d'etre, but one
should not forget about trade-offs/pitfalls and think that alternative,
locking, approaches won't work.
[color=blue]
>[color=green]
> > VC[/color][/color]

[michael newport]

Re: oracle - mysql comparison

Jon,

check out www.ca.com for Ingres, its the same strength as Oracle but
will shortly be OpenSource.

Regards
Michael Newport

[color=blue]
> hey all,
>
> I realize that this question might pop up from time to time, but I
> haven't seen it a while and things might of changed, so -
>
> Right now (July 2004) how does mysql stand up in comparison to oracle?
> We are seriously considering migrating our multi-processor oracle
> system to mysql to save on licensing costs, and would need several
> features that mysql may or may not have:
>
> - replication
> - archive logging
> - interoperabilit y with oracle/database links with oracle
> - PL/SQL type language/stored procedures
> - roles
> - oracle migration scripts/conversion
> - embedded java API
> - partitioning/tablespace assignment
> - import/export tools
> - equivalent oracle datatypes
> - multi-processor support
> - performance (relatively equivalent or better)
>
> In addition, have any oracle DBAs out there gone through the
> conversion process between mysql and oracle? If so, what were the
> gotchas/catches that you went through? What are features that are
> there that you like or feel are missing? I apologize in advance for
> the cross-post, but I did want to get as wide a range of opinion as
> possible..
>
> Thanks much,
>
> jon[/color]

[VC]

Re: oracle - mysql comparison


"Alex Filonov" <afilonov@yahoo .com> wrote in message
news:336da121.0 407150733.5db6d e1@posting.goog le.com...
[color=blue]
> According to some information M$ is going to implement read-only
> consistency (Oracle style) in the next version.[/color]

Yes, MS SQL Server is going to have multiversion concurrency control (the
latest Yukon beta actually already has it). It'll be exposed to the user as
SNAPSHOT isolation level.
[color=blue]
>As for correct concurrency
> model,[/color]

A correct concurrency control/model ensures that all the permitted
transactions are serializable. In this sense, databases like DB2 or MSSQL
implement a correct concurrency model albeit at the expense of lower
concurrency in some circumstances. Funnily enough, none of the Oracle
isolation levels can make the same promise, i.e. ensure serializable
transaction histories, in any of its isolation levels. Usually, it's quite
easy to obtain correct results by augmenting an isolation level with
something like 'select for update', though..
[color=blue]
>I remember one project, when data warehouse was build using MSSQL,
> everything was almost OK, management was pleased immensely. Until they
> started running reports. When management found out that reports[/color]
practically[color=blue]
> stopped online work, mood changed.[/color]

Well, there are several possible responses to this anecdote:

1. If the described system was a true data warehouse/DSS, then there
should not have been a problem at all since there should have been no OLTP
activity by definition.

2. On the other hand, if the implementation was a mixed OLTP/DSS project,
then judging by your story, the database architect was not qualified to
design a system like that. His/her being surprised that a locking
scheduler's reads block writes, and vice versa, is akin to a swimmer's being
amazed that water is wet. There are several well-known approaches to the
reporting problem such as replicating the main database to a reporting
database, transaction log shipping, scheduling reports off-hours, etc.

VC

[Daniel Morgan]

Re: oracle - mysql comparison

VC wrote:
[color=blue]
> A correct concurrency control/model ensures that all the permitted
> transactions are serializable. In this sense, databases like DB2 or MSSQL
> implement a correct concurrency model albeit at the expense of lower
> concurrency in some circumstances. Funnily enough, none of the Oracle
> isolation levels can make the same promise, i.e. ensure serializable
> transaction histories, in any of its isolation levels. Usually, it's quite
> easy to obtain correct results by augmenting an isolation level with
> something like 'select for update', though..[/color]

And if this is true why, exactly, would anyone care at the expense of
being able to extract an accurate answer from a database without
performing table locks on all resources?

Daniel Morgan

[VC]

Re: oracle - mysql comparison

Hello Daniel,

"Daniel Morgan" <damorgan@x.was hington.edu> wrote in message
news:1089945278 .134355@yasure. ..[color=blue]
> VC wrote:
>[color=green]
> > A correct concurrency control/model ensures that all the permitted
> > transactions are serializable. In this sense, databases like DB2 or[/color][/color]
MSSQL[color=blue][color=green]
> > implement a correct concurrency model albeit at the expense of lower
> > concurrency in some circumstances. Funnily enough, none of the Oracle
> > isolation levels can make the same promise, i.e. ensure serializable
> > transaction histories, in any of its isolation levels. Usually, it's[/color][/color]
quite[color=blue][color=green]
> > easy to obtain correct results by augmenting an isolation level with
> > something like 'select for update', though..[/color]
>
> And if this is true why, exactly, would anyone care at the expense of
> being able to extract an accurate answer from a database without
> performing table locks on all resources?
>[/color]

I am not sure what specific part of my message the word *this* ('if this is
true') refers to, but assuming it's the last sentence then you surely know
that 'select for update' takes write (TX) lock on all the rows involed A
locking scheduler would take *read* row level locks in similar circumstances
automatically. If my interpretaion is incorrect, please elaborate.

VC
[color=blue]
> Daniel Morgan
>[/color]

[Alex Filonov]

Re: oracle - mysql comparison

"VC" <boston103@hotm ail.com> wrote in message news:<l9DJc.987 00$XM6.25133@at tbi_s53>...[color=blue]
> "Alex Filonov" <afilonov@yahoo .com> wrote in message
> news:336da121.0 407150733.5db6d e1@posting.goog le.com...
>[color=green]
> > According to some information M$ is going to implement read-only
> > consistency (Oracle style) in the next version.[/color]
>
> Yes, MS SQL Server is going to have multiversion concurrency control (the
> latest Yukon beta actually already has it). It'll be exposed to the user as
> SNAPSHOT isolation level.
>[color=green]
> >As for correct concurrency
> > model,[/color]
>
> A correct concurrency control/model ensures that all the permitted
> transactions are serializable. In this sense, databases like DB2 or MSSQL
> implement a correct concurrency model albeit at the expense of lower
> concurrency in some circumstances. Funnily enough, none of the Oracle
> isolation levels can make the same promise, i.e. ensure serializable
> transaction histories, in any of its isolation levels. Usually, it's quite
> easy to obtain correct results by augmenting an isolation level with
> something like 'select for update', though..
>[/color]

Hm, what about SERIALIZABLE isolation level in Oracle? I don't see that
it's any different from similar isolation level in MSSQL.
[color=blue][color=green]
> >I remember one project, when data warehouse was build using MSSQL,
> > everything was almost OK, management was pleased immensely. Until they
> > started running reports. When management found out that reports[/color]
> practically[color=green]
> > stopped online work, mood changed.[/color]
>
> Well, there are several possible responses to this anecdote:
>
> 1. If the described system was a true data warehouse/DSS, then there
> should not have been a problem at all since there should have been no OLTP
> activity by definition.
>[/color]

Well, this is an example of real life different from the theory. Happens all
the time.
[color=blue]
> 2. On the other hand, if the implementation was a mixed OLTP/DSS project,
> then judging by your story, the database architect was not qualified to
> design a system like that. His/her being surprised that a locking
> scheduler's reads block writes, and vice versa, is akin to a swimmer's being
> amazed that water is wet. There are several well-known approaches to the
> reporting problem such as replicating the main database to a reporting
> database, transaction log shipping, scheduling reports off-hours, etc.
>[/color]

Yeah, right. Now, tell me where to find managers who understand what
kind of DB architects they really need. And who prefer architects
proposing more expensive, although correct, solutions. And, of course,
offline reporting (and all solutions you propose are actually variants of
it) is not always what customer wants.
[color=blue]
> VC[/color]

[VC]

Re: oracle - mysql comparison


"Alex Filonov" <afilonov@yahoo .com> wrote in message
news:336da121.0 407160845.6603c 310@posting.goo gle.com...[color=blue]
> "VC" <boston103@hotm ail.com> wrote in message[/color]
news:<l9DJc.987 00$XM6.25133@at tbi_s53>...[color=blue][color=green]
> > "Alex Filonov" <afilonov@yahoo .com> wrote in message
> > news:336da121.0 407150733.5db6d e1@posting.goog le.com...
> >[color=darkred]
> > >As for correct concurrency
> > > model,[/color]
> >
> > A correct concurrency control/model ensures that all the permitted
> > transactions are serializable. In this sense, databases like DB2 or[/color][/color]
MSSQL[color=blue][color=green]
> > implement a correct concurrency model albeit at the expense of lower
> > concurrency in some circumstances. Funnily enough, none of the Oracle
> > isolation levels can make the same promise, i.e. ensure serializable
> > transaction histories, in any of its isolation levels. Usually, it's[/color][/color]
quite[color=blue][color=green]
> > easy to obtain correct results by augmenting an isolation level with
> > something like 'select for update', though..
> >[/color]
>
> Hm, what about SERIALIZABLE isolation level in Oracle? I don't see that
> it's any different from similar isolation level in MSSQL.
>[/color]

Oracle does not have SERIALIZABLE despite their assurances to the contrary.
It's trivial to imagine a transaction history where Oracle's SERIALIZABLE
won't produce correct results. For starters, try 'insert into t1 select
max(ID)+1 from t1'. The issue with Oracle's serializable being not quite
what it's labeled was discussed extensively in this newsgroup a couple of
years ago. Unfortunately, I do not remeber the subject name -- something
to do with airline reservations.
[color=blue][color=green]
> > 2. On the other hand, if the implementation was a mixed OLTP/DSS[/color][/color]
project,[color=blue][color=green]
> > then judging by your story, the database architect was not qualified to
> > design a system like that. His/her being surprised that a locking
> > scheduler's reads block writes, and vice versa, is akin to a swimmer's[/color][/color]
being[color=blue][color=green]
> > amazed that water is wet. There are several well-known approaches to the
> > reporting problem such as replicating the main database to a reporting
> > database, transaction log shipping, scheduling reports off-hours, etc.
> >[/color]
>
> Yeah, right. Now, tell me where to find managers who understand what
> kind of DB architects they really need. And who prefer architects
> proposing more expensive, although correct, solutions.[/color]

Well, one can hardly blame the hammer if one wants to use it as a
screwdriver can one ? Oracle has quite a few pecularities of its own that
can jeopardize a project if those responsible for design/implementation have
no clue as to what they are doing.
[color=blue]
>And, of course,
> offline reporting (and all solutions you propose are actually variants of
> it) is not always what customer wants.[/color]

What's wrong with those solutions for long running reports, quick queries
not being a problem ? Besides, the situation is not very much different
from running a long report under Oracle where the results won't be actual
due to the very nature of the beast -- 'read consistency'.

There is no argument that a multiversioning scheduler provides higher
concurrency in many cases, after all that's its raison d'etre, but one
should not forget about trade-offs/pitfalls and think that alternative,
locking, approaches won't work.
[color=blue]
>[color=green]
> > VC[/color][/color]

[Daniel Morgan]

Re: oracle - mysql comparison

VC wrote:
[color=blue]
> Hello Daniel,
>
> "Daniel Morgan" <damorgan@x.was hington.edu> wrote in message
> news:1089945278 .134355@yasure. ..
>[color=green]
>>VC wrote:
>>
>>[color=darkred]
>>>A correct concurrency control/model ensures that all the permitted
>>>transactio ns are serializable. In this sense, databases like DB2 or[/color][/color]
>
> MSSQL
>[color=green][color=darkred]
>>>implement a correct concurrency model albeit at the expense of lower
>>>concurrenc y in some circumstances. Funnily enough, none of the Oracle
>>>isolation levels can make the same promise, i.e. ensure serializable
>>>transactio n histories, in any of its isolation levels. Usually, it's[/color][/color]
>
> quite
>[color=green][color=darkred]
>>>easy to obtain correct results by augmenting an isolation level with
>>>something like 'select for update', though..[/color]
>>
>>And if this is true why, exactly, would anyone care at the expense of
>>being able to extract an accurate answer from a database without
>>performing table locks on all resources?
>>[/color]
>
>
> I am not sure what specific part of my message the word *this* ('if this is
> true') refers to, but assuming it's the last sentence then you surely know
> that 'select for update' takes write (TX) lock on all the rows involed A
> locking scheduler would take *read* row level locks in similar circumstances
> automatically. If my interpretaion is incorrect, please elaborate.
>
> VC[/color]

My point is that in all of the other databases to which you have
referred it is impossible to get a result set consistent to a
point-in-time without locking the resources (not at the row level but at
the table level).

Something I would think far more important than anything you brought up.

In Oracle this can be achieved without any locking.

Daniel Morgan

[michael newport]

Re: oracle - mysql comparison

Jon,

check out www.ca.com for Ingres, its the same strength as Oracle but
will shortly be OpenSource.

Regards
Michael Newport

[color=blue]
> hey all,
>
> I realize that this question might pop up from time to time, but I
> haven't seen it a while and things might of changed, so -
>
> Right now (July 2004) how does mysql stand up in comparison to oracle?
> We are seriously considering migrating our multi-processor oracle
> system to mysql to save on licensing costs, and would need several
> features that mysql may or may not have:
>
> - replication
> - archive logging
> - interoperabilit y with oracle/database links with oracle
> - PL/SQL type language/stored procedures
> - roles
> - oracle migration scripts/conversion
> - embedded java API
> - partitioning/tablespace assignment
> - import/export tools
> - equivalent oracle datatypes
> - multi-processor support
> - performance (relatively equivalent or better)
>
> In addition, have any oracle DBAs out there gone through the
> conversion process between mysql and oracle? If so, what were the
> gotchas/catches that you went through? What are features that are
> there that you like or feel are missing? I apologize in advance for
> the cross-post, but I did want to get as wide a range of opinion as
> possible..
>
> Thanks much,
>
> jon[/color]

[Daniel Morgan]

Re: oracle - mysql comparison



michael newport wrote:
[color=blue]
> Jon,
>
> check out www.ca.com for Ingres, its the same strength as Oracle but
> will shortly be OpenSource.
>
> Regards
> Michael Newport[/color]

And by 'strength' you mean?

Daniel Morgan

[Jim Kennedy]

Re: oracle - mysql comparison


"Daniel Morgan" <damorgan@x.was hington.edu> wrote in message
news:1090027361 .387590@yasure. ..[color=blue]
>
>
> michael newport wrote:
>[color=green]
> > Jon,
> >
> > check out www.ca.com for Ingres, its the same strength as Oracle but
> > will shortly be OpenSource.
> >
> > Regards
> > Michael Newport[/color]
>
> And by 'strength' you mean?
>
> Daniel Morgan
>[/color]
I think he means it is good at locking. It has a strong locking mechanism.
Last time I used Ingress (quite a few years ago) an insert into a table
would lock the whole table! Why? It had page level locks and inserting a
record into a table with a primary key locks the entire index which means
only 1 person at a time could insert records. You had to commit to release
the locks. So don't have long running transactions. Leads to bad
programming practices; developers putting the system into autocommit mode.
(yeach)
Jim

[Daniel Morgan]

Re: oracle - mysql comparison

VC wrote:
[color=blue]
> Hello Daniel,
>
> "Daniel Morgan" <damorgan@x.was hington.edu> wrote in message
> news:1089945278 .134355@yasure. ..
>[color=green]
>>VC wrote:
>>
>>[color=darkred]
>>>A correct concurrency control/model ensures that all the permitted
>>>transactio ns are serializable. In this sense, databases like DB2 or[/color][/color]
>
> MSSQL
>[color=green][color=darkred]
>>>implement a correct concurrency model albeit at the expense of lower
>>>concurrenc y in some circumstances. Funnily enough, none of the Oracle
>>>isolation levels can make the same promise, i.e. ensure serializable
>>>transactio n histories, in any of its isolation levels. Usually, it's[/color][/color]
>
> quite
>[color=green][color=darkred]
>>>easy to obtain correct results by augmenting an isolation level with
>>>something like 'select for update', though..[/color]
>>
>>And if this is true why, exactly, would anyone care at the expense of
>>being able to extract an accurate answer from a database without
>>performing table locks on all resources?
>>[/color]
>
>
> I am not sure what specific part of my message the word *this* ('if this is
> true') refers to, but assuming it's the last sentence then you surely know
> that 'select for update' takes write (TX) lock on all the rows involed A
> locking scheduler would take *read* row level locks in similar circumstances
> automatically. If my interpretaion is incorrect, please elaborate.
>
> VC[/color]

My point is that in all of the other databases to which you have
referred it is impossible to get a result set consistent to a
point-in-time without locking the resources (not at the row level but at
the table level).

Something I would think far more important than anything you brought up.

In Oracle this can be achieved without any locking.

Daniel Morgan

[Daniel Morgan]

Re: oracle - mysql comparison



michael newport wrote:
[color=blue]
> Jon,
>
> check out www.ca.com for Ingres, its the same strength as Oracle but
> will shortly be OpenSource.
>
> Regards
> Michael Newport[/color]

And by 'strength' you mean?

Daniel Morgan