Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle Innobase Purchase Impacts MySQL.

Re: Oracle Innobase Purchase Impacts MySQL.

From: Joel Garry <joel-garry_at_home.com>
Date: 20 Oct 2005 14:53:24 -0700
Message-ID: <1129845204.059547.172900@g44g2000cwa.googlegroups.com>

Paul wrote:
> "Joel Garry" <joel-garry_at_home.com> wrote:
> From that site(*)
>
> ----------------
> Looking at :
> http://dev.mysql.com/doc/refman/5.0/en/innodb-multi-versioning.html
>
> "they [undo log records] can be discarded only after there is no
> transaction present for which InnoDB has assigned a snapshot that in a
> consistent read could need the information in the update undo log to
> build an earlier version of a database row."
>
> Suggests that, rather than throw the Ora-1555, Innodb will just keep
> growing the undo log.
>
> "Also, a deletion is treated internally as an update where a special
> bit in the row is set to mark it as deleted."... "Only when InnoDB can
> discard the update undo log record written for the deletion can it
> also physically remove the corresponding row and its index records
> from the database."
>
> The delete processing could offer performance improvements in some
> circumstances. Nothing that couldn't be duplicated outside of the
> standard database functionality. Don't know whether Oracle would have
> any interest in using it.
>
> I don't see that InnoDB has anything amazing on the surface that
> Oracle doesn't have. It is possible that under the hood there is some
> snazzy little algorithm or two which Oracle likes the look of (and
> since it is Open Source I'm sure that some-one at Oracle was paid to
> have a good look). Maybe even one that was worth the money for buying
> the company rather than a licensing arrangement.
>
> Maybe they just wanted to make sure that InnoDB MVCC stuff couldn't be
> licensed or bought up for inclusion in, for example, SQL Server.
> -------------------------
>
>
> Now take a look at
>
> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_mvcc_roman

Oh man, the redo is Oracle's Achilles heel, you lose it, you lose current transactions. From this description, even with the careful writes, you've distributed the heel throughout the body... yeesh. Two points to Oracle for allowing the ability to have only what is required to be mirrored to have to be. Maybe I'm not understanding, but with the described versioning, your file gets corrupt with the recovery info inside it, how could you automatically recover it? With Oracle, the data file gets corrupt, just restore what is necessary with RMAN (which can grab archived logs from a number of places as well as recover particular blocks). The redo gets corrupt - well, that's why you are supposed to have mirrored groups.

Somehow this reminds me of VMS file versioning and what a pain it could be (though I sure missed it for a long time in unix, even sort-of aliasing for it for a while).

>
>
> Note the (remarkable) similarity in language. Seems that Interbase has
> been doing this for 20 years.
>
>
> > Anyways, just having MVCC doesn't mean the implementation is good. I
> > have no clue about this other than how Oracle does it,
>
> Check out the URL, the article's title is "A not-so-very technical
> discussion of Multi Version Concurrency Control", so it's an
> easy-peasy read, and not too long, and with a better implementation
> than Oracle's.
>
>
> > and that
> > SqlServer hasn't got it right yet. I would hope Interbase does it
> > right, too, which would help keep it out of the t*y category.
>
>
> Well, it's being doing that since day one. There is a lot of debate on
> the Interbase and Firebird groups as to why it/they are not taken more
> seriously on the overall db market (share is rumoured (difficult to
> get anybody who would be in a position to know to cough up real
> figures) to be 2%).
>
> There are perhaps two or three reasons for this.
>
> 1) FoxPro, dBase and Paradox - there were various wars between
> Ashton-Tate, Borland and the makers of FoxPro (later taken over by the
> Great Satan (tm)). Ashton-Tate purchased Interbase (previously Groton
> Database systems), but were more of a desktop db company than a
> fully-fledged db server company - basically Interbase, while not
> dropped, didn't receive the highest priority it could have.
>
> 2) Borland purchased Ashton-Tate. The desktop db war was still on, so
> Interbase was again neglected - not totally, but did not recieve
> "full-on" development focus.
>
>
> 3) When Borland *_did_* market it, they made (IMHO) the crucial
> mistake of over-emphasising that it was an embeddable db that one
> could install and forget (which it was), but didn't emphasise enough
> its very real capacities to be a full-on entreprise level db server -
> it was just one that didn't require a full time dba. Ironically, in
> stressing one of its advantages, it was shooting itself in the foot in
> another area.

I think I have an insight to this - see my reference to Kahn in http://groups.google.com/group/comp.os.linux.development.system/msg/ea052004b52e371f?dmode=source&hl=en He just didn't have the "enterprise software" mindset of Larry.

> (*) like the site, but why does the guy have to repeat all the points
> in every subsequent post - irritating, although it does make a web
> forum easier to read - but I *_WAY_* prefer newsgroups.

I prefer newsgroups too. But they have their own repetitive idiosyncracies, wouldn't you say? :-)

jg

-- 
@home.com is bogus.
There is currently no history recorded!
Received on Thu Oct 20 2005 - 16:53:24 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US