MySQL's Response to Oracle's Moves

mAriuZ writes "I've recently written two articles on this topic for Database Journal, the earlier, written after the InnoDB purchase, entitled Oracle's purchase of InnoDB, their release of Oracle Express, and the effect on MySQL, and the most recent, just after the Sleepycat purchase, entitled Pressure on MySQL increases as Oracle purchases Sleepycat, with more to come. Since I only do a monthly column for Database Journal, and things change quite quickly, I thought I'd post a few more thoughts on the topic."

Comments

Bruce Perens' thoughts on the subject

[Anonymous Coward]

Posted as AC to avoid karma whoring...

Does Oracle Understand What It's Buying?

Bruce Perens

Oracle's eaten the only two companies that make transactional database back-ends for MySQL: InnoDB last year, and now Sleepycat Software. The purchases send a message that MySQL won't achieve high-end database features without being beholden to Oracle. But the message is hollow.

When the InnoDB purchase was announced, I asked MySQL CEO Mårten Mickos: you're going to write your own transactional back-end now, aren't you? Mickos is loath to announce that, but it's a no-brainer. The database back-ends in question handle file storage and low-level query operations, don't understand SQL, and are plug-ins - ready to be unplugged and replaced by some new transactional design by MySQL.

What will Oracle have gained once MySQL announces a new transactional back-end? Sleepycat: an excellent, simple, SQL-less embedded database that's been a successful cottage industry for a decade, and InnoDB, which I suppose might produce a back-end for Oracle's own database. And not a bit of discomfort for MySQL.

But MySQL has an alternative to rolling their own back-end: they can continue to use the InnoDB and Sleepycat products under their Open Source licenses, which are valid forever and for anyone, instead of the commercial licenses that MySQL currently has for these products. Because MySQL is a server, physically separate from its client applications, the GPL and its restrictions won't be a consideration for MySQL's customers.

MySQL could slap Oracle in the face by going with the GPL strategy: they wouldn't have to negotiate with Oracle, they could use InnoDB and Sleepycat in perpetuity, and they wouldn't have to pay Oracle a cent. I'd be tempted to take such poetic vengeance. But Oracle, which has tried to buy MySQL before, could trump the GPL strategy by increasing what it offers for MySQL enough to make that purchase go through. CEO Mickos won't dabble at vengeance and will keep looking at offers that - if nothing else - increase the evidence for valuation of his company. But MySQL probably won't merge - they see too large a market, and intend to have it for themselves.

Even an outright purchase of MySQL by Oracle would not prevent anyone from using MySQL's server in a commercial application, without charge. That's possible today if you use an unofficial (and non-GPL) client library to communicate with MySQL. Other companies in the Open Source community would happily provide training and support for MySQL, while an independent Open Source project would evolve to maintain the program.

You can't really buy an Open Source project. The GPL was designed to make it possible for any Open Source participant to circumvent any other party who gets in the way. Other Open Source licenses are similar. Larry Ellison can buy business and influence over an Open Source project, but if he tries to have absolute control, Open Source developers will code elsewhere, replace whatever Larry holds close, and create new businesses.

JBoss, the Open Source J2EE company said to be a $400 Million Oracle acquisition, hardly owns its market today. Commercial Java projects, even those using Open Source code, may develop on JBoss but predominantly deploy on proprietary software from IBM or BEA. Years ago a large contingent of JBoss developers split off into what is now Apache Geronimo project, an eminently viable competitor to JBoss.

If Oracle is true to their history of eating their own ecosystem, they might now use JBoss to go after BEA. BEA moved this week to beef up their own presence in the Open Source community by releasing some previously proprietary work as Open Source. Why? they'll be using Open Source to go after Oracle. Open Source developers smile as proprietary software companies fight each other by collaborating more.

Re:Bruce Perens' thoughts on the subject

[Anonymous Coward]

What if Oracle really do "get it"?

That they understand the point of Open Source and their objective is to improve the standing of these applications by improving support / consulting / training etc (which is where they also plan to make money).

Re:Bruce Perens' thoughts on the subject

[Karzz1]

"The purchases send a message that MySQL won't achieve high-end database features without being beholden to Oracle."

"Even an outright purchase of MySQL by Oracle would not prevent anyone from using MySQL's server in a commercial application, without charge."

"You can't really buy an Open Source project. "

It seems to me that what Oracle is doing is not to try and take over or squash MySQL but rather to buy some more time. InnoDB is already OSS and I had thought Sleepycat was as well. MySQL has already been released under the GPL; no changing that retroactively. Even if Oracle had bought MySQL, the whole thing appears to be an attempt by Oracle to buy time while the new development team learns the innards of MySQL and/or codes a new transaction engine.

MySQL, with or without MySQL AB, will continue to exist and continue to be developed. Don't get me wrong, I am glad they declined the offer, but I don't think Oracle was looking to buy MySQL per se. They were just looking to buy time to keep the heat off.

Just my 2cents.

Re:Bruce Perens' thoughts on the subject

[kpharmer]

> When the InnoDB purchase was announced, I asked MySQL CEO Mårten Mickos: you're going to write your own transactional back-end now,
> aren't you? Mickos is loath to announce that, but it's a no-brainer. The database back-ends in question handle file storage and
> low-level query operations, don't understand SQL, and are plug-ins - ready to be unplugged and replaced by some new transactional design by MySQL.

There's a reason he's loath to do this - it will require revenue to be spent on hiring people who know how to pull this off. Further - it will take him a few *years* to develop a backend as mature as Innodb. As soon as he states this strategy Oracle will likely respond with this message.

> But MySQL has an alternative to rolling their own back-end: they can continue to use the InnoDB and Sleepycat products under their
> Open Source licenses, which are valid forever and for anyone, instead of the commercial licenses that MySQL currently has for these
> products. Because MySQL is a server, physically separate from its client applications, the GPL and its restrictions won't be a
> consideration for MySQL's customers.

Great, so the backend would be even further removed from the rest of their database. Rather than being ingenious, this split between MySQL and its storage engines causes:
    - inconsistencies for users (storage pool specific ddl)
    - poor resource utilization for servers (separate memory pools)
    - difficulty for optimizer to consider storage engine specifics in query plan
    - difficulty in mixing multiple storage engines within single query
    - necessity in getting storage engine providers to support MySQL features
        - partitioned tables?
        - online changes?
        - how about ability to add a column without copying & reloading all rows?

> Open Source developers will code elsewhere, replace whatever Larry holds close, and create new businesses.

Unfortunately, powerful databases are large and complex beasts, and take years to get right. As much as I can understand why folks would flee from Larry, I think he'd be quite pleased if the mysql team were to go off and spend another five years recreating it.

As much as I'd like to think that the open source approach can resist this kind of ploy, once a company goes commercial, I really don't think it can. The far safer option now is SQLite for anything small, and Postgresql for anything large. Oracle can't touch these, you don't need a lawyer to determine your licensing costs, etc.

Re:Bruce Perens' thoughts on the subject

[ameoba]

You have to keep in mind that MySQL isn't making money off techies that Get It, they're making money off of Suits. Suits don't want to make long-term commitments to software with a shaky or uncertain future. The fact that these purchases are raising doubts as to MySQL's future is already enough to make Suits (who are already skeptical of OSS) nervous & less likely to send their business to MySQL.

Re:Bruce Perens' thoughts on the subject

[Bruce Perens]

Of course I submitted this piece to Slashdot days ago, only to see it rejected. But the editors don't seem to want to look at original work :-) Only when someone else chews over it does it become worthy for Slashdot. Com'on guys.

Re:Bruce Perens' thoughts on the subject

[Bruce Perens]

InnoDB is not a stand-alone product, so your analysis would not apply to them, I guess.

That leaves us with Sleepycat. To accept your thesis, I would have to accept that Oracle wants to diversify into cottage-industry embedded databases that represent 1/1000 of the market they are used to. This still seems a bit of a stretch.

Thanks

Bruce

Re:Bruce Perens' thoughts on the subject

[Karzz1]

"The fact that these purchases are raising doubts as to MySQL's future..."

I don't believe that to be the case. In fact, if anything, I have to agree with Bruce Perens who states "(MySQL)CEO Mickos won't dabble at vengeance and will keep looking at offers that - if nothing else - increase the evidence for valuation of his company.".

It seems to me that if the "premier" database vendor (Oracle) in the market is looking to buy up a "lesser" database, it implies that the target database is (perceived to be) a threat in some way to the larger vendor; implying that the "lesser" is in fact not lesser. This suggests that MySQL *is* a solid database ready for the enterprise. Not to mention, the GPL version of MySQL is not going anywhere, regardless of what happens to MySQL AB. Its development cycle may be slowed for a bit if MySQL were bought out, but MySQL is too important of an application to too many companies with the budget/talent to let die. Someone will be developing MySQL for the foreseeable future.

Re:Bruce Perens' thoughts on the subject

[Bruce Perens]

There's a reason he's loath to do this - it will require revenue to be spent on hiring people who know how to pull this off.

Yes, but as you can see from the article, he did this anyway. My remaining question is: is this the first hire? I would expect MySQL to have had people working on a new backend for half a year now.

Great, so the backend would be even further removed from the rest of their database.

Actually, there would be no technical changes, only a licensing change. The MySQL server is already separate from the application and need not be separate from the backend.

Rather than being ingenious, this split between MySQL and its storage engines causes [lots of problems]

I accept that. Someone pointed out that MySQL already has their own transactional backend, NDB, which is used only in cluster mode. I guess it's too specialized to replace InnoDB.

Thanks

Bruce

Re:Bruce Perens' thoughts on the subject

[criquet]

It's also quite possible that Oracle is purchasing these simply to be able to slap their name on them as a marketing tactic. Oracle has given away it's software for years from the belief that the more people are exposed to Oracle, the more likely they will be to recommend it for commercial use. If people end up using MySQL and see that Oracle is the transactional engine behind it, if they ever need to move to a more robust backend, they will likely want to stick with Oracle. At least, that's what I suspect Larry wants to believe. And I also believe it makes good sense.

Re:Bruce Perens' thoughts on the subject

[greginnj]

Hmm, maybe they wanted an author with better street-cred on the subject?




Joke, joke... thanks for sharing. I'm never going to whine about having a submission rejected again ... even to myself. Thanks for all the good work, keep up the fight, etc., etc.

Re:Bruce Perens' thoughts on the subject

[digitalunity]

The ironical thing about this is that the future of OSS software is actually *more* secure than anything the closed-source industry could create. MYSQL AB may be sold, and even the MYSQL trademark can be sold. However, MYSQL the database cannot be destroyed by Oracle(except by submarining software patent holders). The loss of the MYSQL trademark to Oracle means only that any fork must have a new name(maybe OURSQL?).

Can the same be said of Oracle? If Oracle falls apart tomorrow due to some massive accounting fraud being publicized, where does that leave all the current Oracle users?

What if your CRM breaks, who will fix it?
What if your Installed Base records are cracked via remote exploit, who can help you?

OSS is not susceptible to the failure of any specific company, it can survive.

Re:Bruce Perens' thoughts on the subject

[jacem]

You have a typo.
Can the same be said of Oracle? If Oracle falls apart tomorrow due to some massive accounting fraud being publicized, where does that leave all the current Oracle users?

You ment to say:

Can the same be said of Oracle? If Oracle falls apart tomorrow due to ANOTHER massive accounting fraud being publicized, where does that leave all the current Oracle users?



JACEM

Re:Bruce Perens' thoughts on the subject

[jacem]

Unfortunately, powerful databases are large and complex beasts, and take years to get right. As much as I can understand why folks would flee from Larry, I think he'd be quite pleased if the mysql team were to go off and spend another five years recreating it.

Being an old fart I remember when MySQL first came out one of its selling features was that it was very small and lightweight. The developer lost some of the powerfull features that the big boys had but that was okay because MySQL was a little DB that you could run on a web server to keep track of Aunt Mildred's recipies and the like.

MySQL has of course since become a huge database with many of the abilities that it original small incarnation didn't need or want.

And now for something completely different

I can't even find what the the license cost for MySQL I have vague recollections of something about $250.00 for a commercial license free for non profit. On the web site there is a $595.00 survice contract, but no mention of a commercial use license.

On Oracle's web site I can get oracle 10 standard edition one for $4995.00 Processor Perpetual and enterprize for $40000.00 Processor perpetual. So I can only assume its double for your dual processor system.

So I can only assume that those of us that need a database and not even a feature rich database will simply move on to something else or pony up the $5000 to $40000 to have a DB to keep track of the CD collection.



JACEM

Re:Bruce Perens' thoughts on the subject

[Anonymous Coward]

"MySQL could slap Oracle in the face by going with the GPL strategy: they wouldn't have to negotiate with Oracle, they could use InnoDB and Sleepycat in perpetuity, and they wouldn't have to pay Oracle a cent."

And I say bullshit to it!

Just look at the quarterly results from MySQL AB. Are they doing well because GPLed MySQL -OR- is their current bussiness coming from commercial licences that can ONLY be granted BECAUSE there are commercial agreements with the "backend storages" copyright holders (double licensing, you know) which now that they are under Oracle's grasp will be no more?

Of course MySQL AB can develop its own transactional engine. The question is WHEN. Will it be tomorrow? The day after tomorrow? Or, more probably, in about a five years span?

And where will be the company by then without the constant revenue the commercial licenses brougth to them?

What Perens (and others) are after is some kind of "guru effect". They are just trying people not to think what exactly the reality for MySQL AB is just know, in hopes for the name's popularity to be untouched while they look for new and different revenue streams.

Re:Bruce Perens' thoughts on the subject

[docbombay]

Just because Oracle is looking to purchase MySQL doesn't mean that the product is "enterprise-ready": it just means that Oracle is aware of the market share that could be gleaned by moving MySQL users into its empire. Don't confuse market savvy with technical proficiency; I could cite a list of acquisitions by large companies of companies with inferior product lines, just to capture an additional market segment -- and some of these purchases were made by Oracle itself.

Re:Bruce Perens' thoughts on the subject

[Tony Hoyle]

Mysql license is $300 per client.

If you have more than 15 users using your database Oracle is cheaper :P

Re:Bruce Perens' thoughts on the subject

[Jamesday]

The cost of a commercial use license for MySQL is $0 - the GPL license applies to commercial use.

There is a cost for commercial redistribution outside your own company if the software relying on it is not open source. If it is GPL or one of the other open source licenses MySQL accepts, the cost of that redistribution license is $0 but you might as well talk to MySQL sales to see if you can come up with some other deal which is mutually beneficial.

Being a non-profit doesn't affect licensing, unless MySQL decides to make a donation of a license, which seems fairly unlikely because the non-profit can already use MySQL free of charge internally with the GPL license.

Re:Bruce Perens' thoughts on the subject

[kpharmer]

> I can't even find what the the license cost for MySQL I have vague recollections of something about $250.00 for a commercial
> license free for non profit. On the web site there is a $595.00 survice contract, but no mention of a commercial use license.

MySQL Network Basic is $600/server/year: https://shop.mysql.com/
You *may* not have to pay anything however. But that depends on GPL/LGPL licensing complexities, and you will probably need a lawyer to know for sure (MySQL AB recommends just buying a license if you're confused).

In comparison, Oracle/DB2/SQL Server are free for small databases, regardless of how you use them. Then if you need to license it can still be cheaper than mysql - since they typically have an initial license (say, $750) and then just 18%/year afterwards. All three of these databases can be *far* more expensive, but db2 in particular can also be cheap in many configurations. I'm running a terabyte-sized data warehouse on about $28k in total licensing. Compared to the cost of the hardware this is nothing.

And of course, postgresql & sql
    - http://www.postgresql.org/
    - http://www.sqlite.org/
are completely free.

> So I can only assume that those of us that need a database and not even a feature rich database will simply move on to something
> else or pony up the $5000 to $40000 to have a DB to keep track of the CD collection.

No, you're fine for several reasons:
    - you can probably get by with the free mysql version for now
    - postgresql is completely free
    - sqlite is completely free - and is probably the best choice for a tiny project like this
    - oracle is completely free for something of this size
    - db2 is completely free for something of this size
    - sql server is completely free for something of this size

Unless of course you're talking about building a competitor to cdnow, in which case you will face some costs ;-)

Re:Bruce Perens' thoughts on the subject

[jaseuk]

MySQL development is the result of a _handful_ of clued up people, if you lose those key developers they are not easily replaced. The same is true for most technically challenging OSS projects. It's worth remembering that MySQL doesn't really accept too much community GPL input in order to protect their commercial dual licensing arrangements, so there is not already the committed developer base ready to take over the project. It's quite probable that the project would stall terminally if MySQL were somehow sabotaged by Oracle.

Personally I don't quite see Oracle being too interested in destroying MySQL. MySQL has a knack for giving users without a great deal of database experience an easy introduction into SQL. Every person who learns their way around MySQL is a potential Oracle customer, they won't want to interfere with that. If a customer goes with MySQL for free, it's better for them than the customer going the other way and putting money in Microsofts pocket for SQL Server.

The real benefit that MySQL has that Oracle would somehow want to leverage is that MySQL is a standard feature with any web host. Windows based web hosting is gaining in popularity but can't match MySQL for this marketshare.

Jason.

Re:Bruce Perens' thoughts on the subject

[metallic]

Do you ever feel like you are standing at the end of a runway... because that joke just flew right over your head :)

Re:Bruce Perens' thoughts on the subject

[mdfst13]

"The fact that these purchases are raising doubts as to MySQL's future is already enough to make Suits (who are already skeptical of OSS) nervous & less likely to send their business to MySQL."

It's easy to spin it the other way. MySQL's future is now guaranteed. They can go with the cheap version now and the Oracle supported version later.

Re:Bruce Perens' thoughts on the subject

[Squeebee]

And where exactly did you read that?

Re:Bruce Perens' thoughts on the subject

[tinkertim]

Funny you should mention sqlite. Just a few posts above this someone was mentioning a possible purchase of zend.

PHP5 is (well was) exciting to me because it was taking advantage of sqlite. I write stuff to run on clusters and if I can avoid ANY database with a client / server overhead I try to, thats my job.

But now all of a sudden I see sqlite support, zend possible buyout .. waaaa lions and tigers and bears oh my! Now my beloved sqlite fail safe could also be in jeoprady? Or was php just catching up with the times?

I really, really hate open source politics like this. So how about bash. You know, the bourne (again) shell? Is that about to be bough slighted screwed or otherwise drawn and quartered? I'm about to just say bash-q-l here I come and assemble my content with echo.

sed, select .. same thing. Screw em both.

Re:Bruce Perens' thoughts on the subject

[kpharmer]

How does a zend buyout affect sqlite? Sqlite is public domain, and has a nice little community around it.

Just out of curiosity, why php?

Re:Bruce Perens' thoughts on the subject

[tinkertim]

>> Just out of curiosity, why php?

2 reasons:

I lean heavily on PHP because most of the people I work with know it, or they know enough C/Perl to get through it. Lots of admins getting hired that get lost in bash scripts. I'm sick of getting out of bed to fix things just because someone can't muddle through sed. PHP lets me sleep more. Between the baby in the crib and the one's working the help desk I'm getting a bit puffy eyed..

I'm often tasked with taking php/mysql applications and modifying them as needed to work more efficiently on a SSI HA setup. I'm using sqlite to keep tabs on my node loads and other stuff so the scripts can be more empathetic to the cluster. Sure its kind of the better mousetrap but it works well. PHP's going to make it easier for me to make things everyone can work on. :)

Using PHP/Sqlite I can better track sessions, how many times a given ip block/range/address has requested something, and all kinds of other stuff. I like having sql but I don't like taxing services that are supposed to be for visitors to accomplish back end tasks.

>> Sqlite is public domain, and has a nice little community around it.

I know, and I'm honestly having fun with it and making bosses happy. Its got a fantastic community. I really, really hope it keeps it because its getting more and more attention. And that's when notoriously things kind of go downhill. And also when they get purchased or otherwise mangled.

I guess you could say that was a sort of selfish sigh. If it was just php adding support, or just sqlite getting more attention I wouldn't be worried. Both , well , I hope it continues the way it has been.

That was a real "oh, no!" .. not a jab at zend or sqlite. :) I probably worry too much. Lots of time invested in the stuff I do and last year was a big year for a few of my favorite up and comings. I guess in the same breath I could say I hope the Xen community stays coherent too :)

Off my soapbox, sowwy.

Re:Bruce Perens' thoughts on the subject

[kpharmer]

> I lean heavily on PHP because most of the people I work with know it, or they know enough C/Perl to get through it. Lots of admins
> getting hired that get lost in bash scripts. I'm sick of getting out of bed to fix things just because someone can't muddle through
> sed. PHP lets me sleep more. Between the baby in the crib and the one's working the help desk I'm getting a bit puffy eyed..

understandable - i think folks often underestimate value of a large pool of potential programmers :-)

I've got a data warehousing project that used php for the exact same reason. Then went with python on the backend instead of java for similar reasons. Well, we actually had java programmers to start with, but it was faster to train new folks on python and build the ETL solution than to just build it in java.

> SSI HA setup

what's this? I've worked on MPP machines like SP2s, but not familiar with this term...

Re:Bruce Perens' thoughts on the subject

[tinkertim]

Open SSI configured to make one (or more) services highly available. Though I and those I work for sometimes have two broadly different defintions of "high availability" heheh I'm told thats the word for it.

SSI stands for single system image, consists of init (commonly later known as director) nodes and processing nodes. Its not truly a Beowulf class 1 cluster, but close.

If you like Debian, you'd like Debian + OpenSSI :) PHP really lends well to the scripts that help to tune these (and keep them running smoothly). My grand evil genius plan is to eventually port all of these nifty little tools I make over to low level (portable) C to be more efficient and smaller.

PHP lends well to that too :)

NewSQL

[ExE122]

I really like this move of bringing Jim Starkey aboard. I've heard his name before, and I think he will really point MySQL's new engine in the right direction.

From the interview, I see that he is a big fan of Java. I've only worked with a slightly older version of MySQL but I feel that Java support is where MySQL is lagging behind Oracle. While MySQL works with a JDBC connection, an Oracle database seems to return faster results and more functional result sets. And I don't know too much about how well MySQL stores java code, but I know the newer versions of Oracle have really added some neat functionality with that.

I'm definitely looking forward to seeing where MySQL is headed and I'm glad they're standing up to Oracle's monopolizing.

Re:NewSQL

[ceeam]

Just to add my 2 info-cents... Jim Starkey is basically the father of Interbase/FirebirdSQL DB (over 20 years ago). Borland did not do very well in marketing it but Interbase was truly revolutionary in many ways - superb transactions handling, no locks, any locks, until they are absolutely needed etc... And InnoDB copied many ideas from there, for example (if you try and benchmarks some scenarios between FB and MySQL/InnoDB the results are very, very similar). And BTW, the word "blob" is invented by Jim Starkey too.

Now I wonder what impact Jim Starkey joining MySQL will have on FB development?

Re:NewSQL

[beru777]

The thing is, they also have bought the product Jim Starkey has been working on for most of his time during the last 6 years. Netfrastructure is a revolutionary development platform for the web, integrating a database engine, a Java virtual machine, a full text search engine, and an HTML templating engine all into a single product.

Re:NewSQL

[natophonic]

While MySQL works with a JDBC connection, an Oracle database seems to return faster results and more functional result sets. And I don't know too much about how well MySQL stores java code, but I know the newer versions of Oracle have really added some neat functionality with that.

Actually the reason MySQL sucks is because it doesn't integrate well with AJAX.
[/snark]

Aside from the low, low price, what gave MySQL the intial jump on Oracle and other 'mature' RDBMS is that it was much faster for simple things. This because it didn't include the kitchen sink of 10 years of "bright ideas" to synergize the enterprise with scalable robustness. You can include in this set of bright ideas, things like transactions (which many complex database applications really can't do without), and things like running a JVM within the database. No one has ever been able to coherently explain to me why it would be a good idea to do the latter (save as some workaround to a convoluted/broken legacy database they don't have the option of fixing).

Sometimes all you need is "SELECT ... FROM ... WHERE ..." Hopefully MySQL doesn't lose sight of that. From the looks of it, they'd do better to work on securing a backend storage engine that Ellison can't buy out from under them, than to keep adding feature bulletpoints to glossy four-color datasheets.

Re:NewSQL

[BigZee]

Running java inside a database is the same reason you'd run any processing within the database - speed. I've seen many examples of developers, happily producing application code that runs a simple database query and then manipulates that data within the client. They are then surprised when performance is dreadful. When they try to tune their database query they find that there is nothing wrong with it. What is a problem though is that they are transfering data, piecemeal back and forth. What they could have done instead was to write a stored procedure in pl/sql (oracles native processing language) or java. The improvements in processing data within the database can be massive. This is the reason for doing processing within the database. Allowing java as a processing engine was Oracle giving developers a bit of flexability in their langauge choice.

Re:NewSQL

[jalet]

> revolutionary development platform for the web

"Revolutionary" ?

You mean like... Zope ? Zope became Free Software around 1998 IIRC, and existed even before.

Re:NewSQL

[hypersql]

I hereby claim ownership of the name NewSQL (http://newsql.sf.net/) and demand that you pay me a license fee to use this name a subject in your posts ;-) Just joking.

Otherwise I agree. Maybe the next MySQL kernel should be written in Java? Before people are shouting 'too slow' they should have a look at the performance numbers: http://polepos.sf.net/.

At least I think that Java is fast enough for a database engine, otherwise I wouldn't write my 3 engine in Java (1th was Hypersonic SQL, 2nd PointBase Micro, and 3th H2 (http://www.h2database.com/).

Thomas

Re:NewSQL

[killjoe]

"Now I wonder what impact Jim Starkey joining MySQL will have on FB development?"

He says he will be available to answer questions but there is no doubt it's going to have a huge impact. Lucky for firebird project vulcan is pretty much done and the merging of the 3.0 and vulcan codebases has begun.

Firebird 3 is going to be a hell of a database server.

Re:NewSQL

[killjoe]

Aaah zope.

Never before in the history of IT has so much innovation and potential gone unrealized.

Maybe Zope3 will fix it. God I certainly hope so.

Re:NewSQL

[kpharmer]

> This because it didn't include the kitchen sink of 10 years of "bright ideas" to synergize the enterprise with scalable robustness.
> You can include in this set of bright ideas, things like transactions (which many complex database applications really can't
> do without), and things like running a JVM within the database. No one has ever been able to coherently explain to me why it would
> be a good idea to do the latter (save as some workaround to a convoluted/broken legacy database they don't have the option of fixing).

You're mixing two different classes of database features:

essential - features that have been relational standard fare for about 24+ years. While you *could* develop a database without these features you will be wasting a vast amount of time in almost all cases: you'll be continually reinventing the wheel, won't be able to port any applications to it, and even simple queries will be difficult. In other words, don't even waste your time unless you're merely putting together a recipe database.
    - transactions
    - views
    - unions
    - subselects
    - highly standard sql
    - temp tables
    - etc

optional - more recent database features (ok, well for many of them 10+ years). These aren't critical IMHO, but without them it will seriously limit what you can do with the database. Without some of them support for third-party applications will suffer and you simply won't be able to port some apps.
    - jvm in the database
    - xml support
    - clustering
    - partitioning
    - query parallelism
    - stored procedures
    - triggers
    - user-defined functions
    - materialized views
    - automatic query rewrite
    - online backups
    - online maintenance
    - etc

Regarding JVM in the database - in my opinion this is a result of a couple of things - the desire to integrate the database more closely with the app, to enable developers to use the same technology in the database as in their application, etc.

For an example of one possible use - I've just found myself recommending java stored procedures on a db2 database - in order for us to give a stored procedure interface to another team to develop against. I don't trust them to write queries, and our prior application (php) isn't ideal for creating an integration layer. So, even though I typically avoid running business logic of this type in the database, it's an example of how that feature will allow us to easily transition two applications to a single api.

Re:NewSQL

[jalet]

If I could, I'd mod you up !

Re:NewSQL

[Anonymous Coward]

Now I wonder what impact Jim Starkey joining MySQL will have on FB development?

Not a lot. Why? Because Jim's role wasn't that large anymore. More on why he joined in
http://blog.upscene.com/martijn/index.php?entry=en try060220-223024my blog entry for today.

--
Martijn Tonies

Re:NewSQL

[beru777]

Well is Zope a full-blown RDBMS ? No. Does it integrate a Java Virtual Machine ? No. And how does it perform ? It's completely written in Python...

The only site I used that was built with Zope was discogs.com and it had to be rewritten in PHP to meet the load and functional requirements once it started to grow...

So maybe there are reasons why Zope never took off...

Re:NewSQL

[jalet]

Zope is a full-blown object database, with connectors to most if not all existing relational databases. Zope doesn't need to integrate a Java Virtual Machine, Python is way ahead of Java in functionnalities and ease of use. Zope is not entirely written in Python, since some routines are written in C.

That being said, Zope IS a resource hog, but comparing it with PHP is a joke. You are comparing apples and oranges here. And for the inabilities to meet the functional requirements, the problem is probably more with the developers who didn't knew Zope enough and knew PHP well.

Re:NewSQL

[metallic]

A lot of the reason for MySQL's popularity was also the fact that it was extremely simple to use and that it ran natively on Windows. That's what kept me using it for so long before I transitioned to a much better database like PostgreSQL.

Re:NewSQL

[Anonymous Coward]

things like running a JVM within the database. No one has ever been able to coherently explain to me why it would be a good idea to do the latter
1. Faster execution for computational stored procedures
2. Consistency across SQL platforms: implement scalar functions/UDFs in Java if you have several flavors of SQL database

Let's hope the best

[Rock-n-Rolf]

I'm looking forward to see MySQL come up with a real good open source transactional engine. MySQL has done a very good job in my point of view for the community, and besides that employes a fair amout of people. Getting a good engine as response to Oracles maneuver would be great.
My company uses the commercial version of MySQL in projects here and then, and I'd like to see it on more critical projects as well.

Re:Let's hope the best

[Shawn is an Asshole]

Personally, I'm hoping that PostgreSQL takes all of this as a notice to make their DBMS easier to use for new users. I use PostgreSQL heavily and it's an excellent DBMS, but for a new user it's quite difficult to set up.

Re:Let's hope the best

[bigtrike]

What's so hard about typing a couple words to install the package?

Re:Let's hope the best

[bigtrike]

The TIMESTAMP data type has varying properties, depending on the MySQL version and the SQL mode the server is running in. These properties are described later in this section. http://dev.mysql.com/doc/refman/5.1/en/datetime.ht ml

You expect good work from the same people who wrote such poorly planned code that it necessitated this kind of text in the manual? Even if MySQL wasn't a featureless pile of garbage, it's only really usable for in house and GPL applications due to licensing restrictions.

Re:Let's hope the best

[Shawn is an Asshole]

PostgreSQL requires more work than that. By default it uses ident authentication which, ihmo, isn't good. For example, if you install phpPgAdmin you can log in as any user simply by typing in the username and anything you want for the username. Not cool. Enabling proper auth such as md5 isn't very easy for a n00b.

http://developer.apple.com/internet/opensource/pos tgres.html

Re:Let's hope the best

[boneshintai]

The default configuration could be a bit better, though it is improving. It still has a very conservative memory usage default.

Now that autovacuum is part of postmaster (as of 8.1) it really is almost zero administration for simple databases.

The psql command line client could copy some features from the mysql client:

DESCRIBE and SHOW foo are more intuitive and consistent than \d commands. This can be implemented in the psql client; it's not an SQL query and shouldn't be. Similar for QUIT or EXIT.

There is only one reason for these purchases

[Anonymous Coward]

I know a bunch of people who work at Oracle and they all agree: Oracle is 100% focused internally on SAP. Other theories may be interesting intellectual exercises, but Oracle is trying to kill MySQL because SAP wanted to use MySQL as an option for their systems to prevent customers from buying an Oracle database.

Oracle and SAP are in the middle of a nuclear exchange here, and Oracle in particular doesn't care one bit how much money it costs them or what collateral damage in the open source space is inflicted. Their PR people may say otherwise, but its not a big secret there.

Re:There is only one reason for these purchases

[Matt Perry]

But SAP already had their own database which they later open-sourced and then MySQL started to use. Why abondon that DB?

As a MySQL shop...

[localman]

These moves have concerned me. We use InnoDB and have purchased hotbackup licenses for all our machines. Last year when we switched to IBM Power servers running Linux, we were able to talk to Heikki and Pekka directly and have them compile special versions for us (until then they never had a Power/Linux version). I doubt that such service would be common for long under Oracle.

I guess MySQL can just keep on with the latest GPL version and fork it if needed to keep things going. But one of the key Enterprise features of InnoDB is the hotbackup, which allows you to create a clean snapshot of the entire database without taking it down. This is pretty much a required piece of software and it is not GPL. As I mentioned we already own a perpetual non-server bound license, so hopefully Oracle will honor that. But that's the piece MySQL should worry about, and attempt to recreate. We would not have been able to stick with MySQL without that software.

Cheers.

Re:As a MySQL shop...

[bubulubugoth]

What is the difference between a hotbackup and mysqludmp?

Mysqldump doesnt take the DB down also... and why replication isnt an option as a hotbackup.

Master/Slave replication at Mysql is lean and easy to setup... and doenst add much overhead to the DB...

Re:As a MySQL shop...

[shirai]

You can do the equivalent of a hot backup without any special software by replicating your database to another server. When you need the backup, you stop the replication and make a backup of the copy. After you reconnect the replication, the replication server will catch up again.

This is documented in the excellent book "High Performance MySQL" by O'Reilly. One of the authors is a database guru at Yahoo.

We were using MS SQL and, while I was interested in open source databases, did not have the confidence to use an open source database until reading this book. I know many will point me to PostgreSQL too, but the tools and the references for MySQL were better.

Re:As a MySQL shop...

[Jamesday]

The problem with InnoDB Hot Backup for enterprise use is that it adds lots of load to the server it's backing up and that's not so good for a mission-critical server. IMO it's usually better to back up from a slave instead, so the main server isn't affected.

That's not to say that InnoDB Hot Backup isn't useful - it certainly is in various situations. But it's not something I'd normally choose to use if I already had mission-critical systems with the three servers such systems really need for utmost availability.

I'm sure that for you it was the best choice to make.

Re:As a MySQL shop...

[arivanov]

Exactly.

This has been the part which pisses me off most about InnoDB. You cannot back it up online and the MySQL backup facilities introduced with 4.x are completely b0rken for it. At least in the GPL version. As a result I have had to write backup facilities of my own for the InnoDB databases we use (RT for once requires InnoDB)

Whatever MySQL will use and write it expect that it will not deliberately remove the backup facility to sell it as a special non-GPL addon. While MySQL has been known to withold some features from the GPL versions it has never shipped deliberate crippleware (and database without backup facilities is crippleware).

So as far as InnoDB is concerned - good buy and good riddance.

BerkleyDB is a different matter. It is heavily used as an embedded database. MySQL is only a minor use for it. In fact it has replaced Oracle as the dabatase of choice for telecommunications projects like high-end switches, network equipment, etc. Most of these used to have an Oracle backend 7 years ago. Not any more. Nowdays it is BDB turf. While there are replacements for it very few of them are as fully featured as BDB 3.x and higher.

Re:As a MySQL shop...

[Jamesday]

If you want a consistent backup, one locks the database for writes, the other doesn't. Both add lots of load to the server they are working with.

Re:As a MySQL shop...

[Anonymous Coward]

> Mysqldump doesnt take the DB down also

It does. It locks tables while it's running. Don't ever use it on a production system since you'll get users very upset when their systems unexpectedly lock-up for very long periods of time. For our main transaction table, it takes mysqldump about 9 hours to complete. There's no way to use that on a production system.

We also can't use replication since that would require shutting down our main server for almost an entire week to copy the data to our remote site to setup the initial copy of the databases.

MySQL just isn't ready yet to be used. You can't even backup the damn thing. The only thing we can do is backup the ibdata files and hope for MySQL is smart enough to sort out the problems if we have to do a restore. It's a horrible way for a database vendor to treat their customers.

Re:As a MySQL shop...

[Dan Ost]

but the tools and the references for MySQL were better.

Is this generally considered to be true?

There appear to be more 3rd party books about MySQL than PostgreSQL, but I suspect that's largely because the official documentation for PostgreSQL is so good to begin with.

Re:As a MySQL shop...

[Anonymous Coward]

>>> "Mysqldump doesnt take the DB down also"

>>> "It does. It locks tables while it's running. Don't ever use it on a production system since you'll get users very upset when their systems unexpectedly lock-up for very long periods of time. For our main transaction table, it takes mysqldump about 9 hours to complete. There's no way to use that on a production system."

You are doing it all wrong then - I can mysqldump from our MySQL server with almost zero locking... The dump is consistent, complete and intact. Nothing to it. Look at the HA book or take a gander at the mysqldump online manual - it is all there.

Re:As a MySQL shop...

[IdleTime]

You are running a production system and haven't even tried to restore the backups you take in order to verify that you can get your company's data back when disaster happens? geezzz...

Talk about doing your job with your resignation filled out and signed. It's just the date that is missing!

Re:As a MySQL shop...

[Heikki_Tuuri]

Localman,

Innobase Oy still does all the InnoDB Hot Backup sales through our website.

Do not be afraid to order :).

Best regards,

Heikki

Re:As a MySQL shop...

[Anonymous Coward]

> Talk about doing your job with your resignation filled out and signed

Talk about a narrow point of view! Why would you assume it's IT's fault? It is the management that has made the decision to stick with MySQL. I can only do what I'm allowed to do. We can't run mysqldump and there's no way to setup replication with the poor way MySQL does it, so this is what we're stuck with. Management knows about the problem.

If something does happen, then we'll just do what we did five years ago when Oracle quit on us and the Oracle backups wouldn't work. We'll revert back to our filed paper copies. That's when we switched to MySQL after Oracle left us high and dry. If we're going to get screwed, might as well get screwed for less money.

Re:As a MySQL shop...

[localman]

Thanks for the input, replication is an important part of any large MySQL installation. We already run four replicated servers, and one is indeed used for backup as you describe. But what happens when replication breaks? This happens to us a few times a year for various reasons. When that happens the slaves go out of sync and it is often impossible to get things back to normal.

The only way to get replication back up cleanly is with a fresh copy of the master from after the event that caused replication to break. The fastest way to do this is to shut down the master DB and the site and copy the data files. For a database our size, this takes about 40 minutes, which is generally an unacceptable amount of downtime. Alternately, we can run a hotbackup with no downtime, and have a clean copy to replicate from in about 5 hours. That is obviously preferred. So I think hotbackup is still a required piece of software for any serious enterprise operation on MySQL.

Cheers.

Re:As a MySQL shop...

[Anonymous Coward]

> I can mysqldump from our MySQL server with almost zero locking

You need to reread the documentation. It specifically states that it locks a table when dumping. That is what I described. That is not "almost zero." That is why large databases are unavailable for hours when running mysqldump.

> mysqldump online manual

The documentation disagrees with your wild claim. Try again.

Besides we've paid for the MySQL support contract, and the experts disagree with you. Lenz Grimmer and Mark Mathews both disagree with your claim.

Re:As a MySQL shop...

[billcopc]

For backups, can't you just do a conventional "export" into Insert statements ? Sure, it's inefficient compared to a binary copy, but it works without taking anything down. Mind you, my largest Mysql DB is only 4gb's on disk (around 6 gb in Insert form). For all my uses, this method works just fine.

Re:As a MySQL shop...

[statusbar]

I tried that once. It was enlightening to see a mysql dump refuse to load into a fresh mysql installation because:

1) The table had a column marked as 'unique'

and

2) The data in the column in that table was NOT unique.

yet the first installation of mysql allowed it! (version 4.1)

jeff

Re:As a MySQL shop...

[IdleTime]

What exactly are your backup needs? Volume? Frequency? Locations?

Re:As a MySQL shop...

[Anonymous Coward]

That is why I will never willingly touch MySQL again. It's just too scary that they ignore certain rules (such as the unique that you point out. I'm not going to create a laundry list here since it's been a while since I've used MySQL) so that you really don't know what data goes into the database. And to make matters worse, they change these things willy-nilly with new versions. postgres for me - that's a real DB (though for enterprise, nothing beats Oracle).

Re:As a MySQL shop...

[Anonymous Coward]

> can't you just do a conventional "export" into Insert statements ?

No, because you have to read lock the table, like mysqldump does. In our case, even with a dozen 15k RPM drives, it takes about 9 hours to dump our main transaction table. Unless you're a small company that can shutdown for 9 hours a day, doing backups that way just doesn't work.

Re:As a MySQL shop...

[Anonymous Coward]

> What exactly are your backup needs? Volume?

We have about 800Gbytes of data spread across 12 147Gbyte 15k RPM drives. The largest table is about 400Gbytes. That table takes over 8 hours to backup using mysqldump. We cannot change the db structure since we do not own the source code to the application that uses it.

> Frequency?

Once a day would be good enough because then we could use update logs to rebuild from there. The catch is that we have production equipment that reads the database 24/7 and we have customers in both Asia and Europe so there isn't any time we can take the system down. We do shutdown two days a year (July 4 and Christmas day), and I can run mysqldump on those days.

> Locations?

The db is mainly used in one location. We have two sites connected with a T1, but because of the way MySQL replication is setup, you have to shutdown both servers and copy all of the data to the other site before starting the replication. With the amount of data we have, we could never get the replication started. About four years ago I did get replication running by driving a server to the office, copying the data, then driving the server back. The problem with that was it only ran for a week before replication got hosed due to a problem with a duplicate key.

We've already used our service contract to talk to the MySQL guys. Their suggestions were to just disrupt service. Well Management has decided they'd rather risk downtime due to a failure rather than have guaranteed downtime each day. That's their decision.

Re:As a MySQL shop...

[IdleTime]

Table: In Oracle you can partition the data, I'm sure it would have been possible and hence the amount of data needed to back up each time would be minimized.

Frequency: With the right backup scheme, you would only back up changes since last backup, the amount of time should be a lot shorter than for the whole database.

Locations: So you need to keep synchronized databases on different physical locations? Oracle streams is designed for this purpose.

Not sure which version of Oracle you had, but your problems dont even break a sweat on my forehead. I solve more complicated Oracle issues on a daily basis. Inital setup is done from backups, rest is done via streams replication. No need to shut down to replicate.

Re:As a MySQL shop...

[Jamesday]

To get a consistend dump you'll need to use FLUSH TABLES WITH READ LOCK. That takes a lock which blocks all updates until the dump is complete and the lock is released. Please see manual page http://dev.mysql.com/doc/refman/5.0/en/backup.html .

Re:As a MySQL shop...

[Anonymous Coward]

You're in a bind but it's one of your own creation. You're supposed to think about backups and redundancy and failover when creating the application and setting up your system. Yes, you have a problem today but MySQL didn't create that problem. You did - or perhaps not you yourself, but whoever set up the system without doing that. What was the backup plan when this was first set up?

Options you could have used if you'd thought about this when setting up your systems include:

• DRBD to do block level mirroring. Used by LiveJournal for a critical server pair.
• Hardware RAID 10 and taking one set of drives offline to back them up. Commonly used by banks.
• Replication with at least two slaves. Used by Wikipedia (400GB) and LiveJournal (may be out of date information - may all be DRBD now).
• InnoDB Hot Backup from a second system (slave or DRBD)
• Application level copying. Used by Wikipedia for some backup dumps.

Since you have two days a year when you can set things up, I suggest learning about DRBD and considering using it to get you out of this situation.

A single duplicate record error does not break replication. It stops it until a human has corrected the source of the problem and told it to resume. The problem is typically an application server which writes to a slave which isn't set to read only mode.

Re:As a MySQL shop...

[nojomofo]

So your management has decided that they'd rather put the entire operation at risk rather than shell out $100k (give or take) for Oracle? Yikes. Time for you to get a new job - because when the shit hits the fan, they're not going to remember that it was management's decision not to (a) take things down to get good backups or (b) pay for a db that allows you to backup and keep your uptime. They're going to blame the DBA and say that it was your responsibility.

Good managers realize this sort of tradeoff before it's too late (penny wise). Bad managers realize it only after it's too late, and then pass the blame (pound foolish). Guess which kind you have.

Re:As a MySQL shop...

[Fulcrum of Evil]

The problem with InnoDB Hot Backup for enterprise use is that it adds lots of load to the server it's backing up and that's not so good for a mission-critical server. IMO it's usually better to back up from a slave instead, so the main server isn't affected.

My understanding of databases may be somewhat limited, but can't you just do the following without additional tools?

1. set up spare DB and push redo logs from the primary DB to it.
2. When it's time for a backup, pause the redo log stuff and let the current log finish being applied.
3. Back up the spare DB, noting which redo log it's on.
4. restart the redo log application.

Re:As a MySQL shop...

[rgigger]

How can blocking updates for the duration of the backup be considered a legitimate way to handle this situation. Just switch to postgres. No rediculous limitations like no hot backup. No weird dual licencing that will cause chaos once some big company buys a third party licenced component. No need for a commercial licence unless what you want is actual support, not just the right to link with the drivers.

Honestly I don't know how people deal with all that. I switched about 4 or 5 years ago and have never looked back.

Re:As a MySQL shop...

[localman]

Well, I can understand your frustration, but I don't want to bash InnoDB. I think InnoDB is the best table handler for MySQL, and the fact that it offers a hotbackup at all is great, and at a very reasonable price. So I can't get behind the "good riddance" sentiment. I just hope that the Oracle buyout doesn't end up killing off InnoDB and hotbackup.

Cheers.

Re:As a MySQL shop...

[localman]

Others have answered this, but I'll throw in a few words, too. I used bad terminology when I said "take the DB down". You don't have to take the DB down to use mysqldump. But if you want a consistent database copy that can be used to start up replication on a slave, you have to lock all the tables. This is fine if your DB is doing nothing but reads, but our DB gets hundreds of writes per second. So locking the tables for the 2+ hours it takes to dump is not an option. As I said, the fastest thing to get a replication slave up is to stop the DB and do a raw copy of the data files. The only way to do it without locking or taking the DB down is with hotbackup. Which is a fine product. I'm just worried about Oracle continuing to support and improve InnoDB.

Cheers.

Re:As a MySQL shop...

[localman]

I don't know anything about Postgres, so please use it if you like it, but I just wanted to correct some confusion here: the problem that is being discussed in this thread is not a problem with MySQL if you use hotbackup. That was my original point. You can take a live backup whenever you want without locking anything. You just need to use that bit of commercial software. It's just that Oracle bought the company that writes hotbackup, and it's not GPL. So that's a little concerning. We'll see what develops, though.

Cheers.

Re:As a MySQL shop...

[localman]

All true. FYI, we do our backups off a replicated server. And we don't use hotbackup for that, we just stop replication, take the backup, then bring replication back up. Quick clean backup.

The thing we use InnoDB for is to start a new replicated server if something goes wrong with replication. The fact that something can go wrong with replication on a regular basis is probably a deficiency in MySQL. In practice it happens a few times per year for us. When that happens, hotbackup seems to be the only way to get the slaves back in sync with the master without any downtime.

Cheers.

Re:As a MySQL shop...

[localman]

Hello Heikki,

Good to hear from you. I certainly didn't intend to imply any problems with your product. Actually Zappos just bought 5+ Linux/Power and Linux/x86 licenses for hotbackup a few months ago. We're very happy with how everything is working. I'd still love to see InnoDB level replication though (unbreakable, less disk writes (no MySQL bin log, etc.) :)

My only concern was where Oracle will take the product over time. Having been part of large corporate buyout in the past *cough* LinkExchange *cough* Microsoft *cough*, I personally fear they don't work out as well as hoped. But I still hope that InnoDB and hotbackup continue to be developed and improved.

Thanks for the great product, and best of luck,
Jonathan FIeld

Re:As a MySQL shop...

[localman]

If you had problems with Oracle and now problems with MySQL, I'm going to say as gently as I can that you're probably not using things correctly.

Having worked with MySQL on a high volume site for six years now, I can admit it has many shortcomings. But there are many ways to back it up. Some of the posts below elaborate, but in our system:

1. buy hotbackup. make a backup while the DB is running, use that backup to start replication.
2. as often as you like, stop the replication slave, mysqldump or cp the files, start replication back up.

This works very well. The only problem is that if any write thread on the master is killed, replication will break and you'll have to use hotbackup again to get a new one started. In general one shouldn't kill writing threads, but hey, it's the real world and these things happen.

The above has worked well for Zappos. Our DB isn't as large (200GB) but I don't imagine it wouldn't work for you.

Cheers.

Re:As a MySQL shop...

[localman]

Oh, and if you're taking requests, fulltext search on InnoDB would also be most welcome ;)

Cheers.

Re:As a MySQL shop...

[Anonymous Coward]

Hotbackup is completely unnecessary and was a way for Hekki to make some money. There are several options around this which are easy to implement:

1. Replicate to a backup server. Take the db down and bring it backup on its internal interface so that the master cannot connect. Do your backup, then bring it back online.

2. Use a logical volume manager. You said you use LVM2. LVM2 will let you create consistent snampshots of the file system. Create a snapshot during the time you want to make the backup, backing up only the data directly. You can use that as your backup, or copy to your backup server, bring it online, and do a mysqldump from there.

3. With ZFS coming of age, move to Solaris and do ZFS snapshots or replication. This will give you the greatest overall performance with the least inconvenience or overhead.

There are probably more ways than this, but any of these three options are suitable alternatives.

Re:As a MySQL shop...

[Anonymous Coward]

You honestly think that the publishers of the world, willing to publish any rewrite of the manual that they think will sell, would actually say 'oh, the Postgres documentation is so awesome that there's no point to publishing books'??

These guys have been publishing rewrites of fine documentation for years. They don't publish more Postgres books because they don't see enough userbase/marketshare.

Re:As a MySQL shop...

[Dan Ost]

Any idea how well the _Practical_PostgreSQL_ book from O'Reilly has sold?

Re:As a MySQL shop...

[Jamesday]

The InnoDB Hot Backup tool is made and sold by Innobase and provides a revenue stream from those who purchase it. It's one way to pay for permanently employed developers who are making their living only from development, not spending time on support work.

MySQL is different from PostgreSQL and provides different ways of doing things, like ubiquitous replication under the same license as the server. So that tends to be the way to go with larger MySQL setups, those you can't just back up in a second or ten witout anybody noticing.

Re:As a MySQL shop...

[Jamesday]

Would be interesting to look for patterns in what causes those problems on the master/application side. I don't actually expect replication to stop as you're describing, but there are ways (like filling the master disk and leaving no room for the binary log) that human error causes it. Human error is, by a large margin, the largest cause of replication pain I see... Not saying this applies to you though - you clearly know what you're doing, so your case involves more detective work. :)

Re:As a MySQL shop...

[localman]

Actually, it's usually the same thing. One time did we run out of disk space (and smacked our heads). But the rest of the time it is caused by killing a query that is doing a write. Obviously we shouldn't do this -- but a couple of times it has become necessary. For example, there will be a long running UPDATE that is causing all queries to a particular table to block. Not a complex query, either -- but one that normally completes in a fraction of a second. Not sure exactly why that happens, but I've seen it more than once. In that case we kill that thread and things go back to normal, but replication breaks. Sometimes we can figure out what updates need to take place on the slaves and we can restart replication, sometimes we can't. Again, this is rare: only 2 or 3 times per year, but in those cases hotbackup saves the day :)

Cheers.

Re:As a MySQL shop...

[Jamesday]

I had a chance to chat about this with the head of MySQL's support group today and we're wondering whether this is with MyISAM or InnoDB? Also, how exactly does it break, with what errors? Wondering if there's a way it can be made to handle it more gracefully.

If you happen to have a MySQL support contract, can you open a support issue on this the next time it happens and link back to this discussion so it can be investigated that way? Could use a bug report but the support side helps the flow of things.

Re:As a MySQL shop...

[localman]

Thanks for the followup.

This is with InnoDB. Basically whenever you kill a thread on the master that is performing a write, the slaves stop with an error that I don't recall precicely off hand, but basically says that "the master may be in an inconsistent state" and it tells you the query that was killed, and tells you to use "set global sql_slave_skip_counter = 1" to restart replication after you've corrected things. And this is what we usually do. Sometimes it works, but sometimes it can get messy, and even when replication is running again the consistency with the master is questionable, or even obviously wrong. Sometimes it will continue running that way, sometimes you'll start getting sporadic errors with duplicate key warnings and such.

Much the way InnoDB handles killed transactions cleanly, I imagine there would be a way for replication to do the same. But it seems replication is not so tightly integrated with InnoDB? So you can end up with a query in the log where it is unknown if it really completed on the master or not. In a perfect world, the query would never get written to the update log unless it completed, and the master would always do a complete rollback if it was killed in the middle.

And while they're at it, it would be great if the slaves could get themselves up to sync automatically starting from an empty DB (or even an inconsistent one) :) And for replication to run directly off the innodb logs, so that another disk write to the update log wasn't necessary :)

Heh, okay, back to work for me. I don't have MySQL support at the moment. I do have InnoDB support. I'll submit it as a bug report, but it seems to be something that they already know about (given the detailed error message).

Cheers.

GPL prevents this

[slackaddict]

Like Bruce Perens said, "you can't really buy an Open Source project." The developers can take their code, fork it, and keep working on it under another project name, if they want.

Oracle's latest "purchases" of these Open Source projects will not threaten MySQL at all. You can't apply for-profit, closed source takeover pressure to OSS code. The GPL prevents exactly this by keeping the source freely available and open.

Re:GPL prevents this

[xtracto]

Sure but, how many of the *real* applications (OpenOffice, mySQL, Eclipse, etc) would fail misserably if the corporations that are throwing money at them to develop them will fail when they stopped?

Do not confuse yourself, all the OpenSource applications that are worth something are product of some kind of closed source (for profit) application whose corporation saw more value in it as PR stunt than as software product.

Yeah, burn my freaking karma, I do not care, I slashdot does not accept thoughts outside the Anti-MS Pro-Linus lamewebos.

got plenty of karma here.

Re:GPL prevents this

[Eivind Eklund]

Ha ha ha ha. MySQL is an open source RELEASE - it is not an open source COMMUNITY. Effectively everybody that can hack MySQL work for MySQL AB, and the development process is run inside MySQL AB - it isn't set up to run as a community process. So, the transition would take a lot of time - and losing maybe two years of forward progress on this would most likely kill MySQL, market-wise.

Eivind.

Re:GPL prevents this

[Dan Ost]

I agree that there are lots of open source apps that support your claim, but the apps I use more than any others, vim, gcc, make, etc, are counterexamples. Linux itself, while it certainly has corporate support, would continue if all current corporate suport disappeared.

Re:GPL prevents this

[Dausha]

"Oracle's latest 'purchases' of these Open Source projects will not threaten MySQL at all. You can't apply for-profit, closed source takeover pressure to OSS code. The GPL prevents exactly this by keeping the source freely available and open."

No true, Oracle can rescend the license. The GPL is a license given by the copyright owner that allows you to use the intellectual property. That license can be rescended and all future versions of that software are closed. If you are not already working on a fork of the GPL'd code, then you may have a harder time enforcing the license. When you have built off a GPL'd license, you can probably use equitable estoppel to prevent your license from being terminated. GPL is not public domain, and the copyright holder should be able to control his own product and say "any further use of this property is denied."

This is a case of smothering. MySQL is caught in a bind that reduces its creditiblity at a critical time. Very strategic move on Oracle's part because MySQL is clearly on the rout. The message is "if you do not own the critical element of your enterprise, then you are at a marked disadvantage." Of course, this is practially Business 101--own it, before your competition does.

That said, I support OSS fully, and advocate it when possible. I'm sure MySQL will rebound.

Re:GPL prevents this

[Anonymous Coward]

Even if they could do so (estopped), they cnnot because the GPL expressly says they cannot.

Re:GPL prevents this

[slackaddict]

Linux and OSS will go on, not quite in the same way, but it would go on without corporate support.

Re:GPL prevents this

[slackaddict]

You're wrong - just because MySQL *could* be delayed doesn't mean that it will. Besides, how many production servers are constantly updating to the latest and greatest version of each software package that comes out. You have some machines out there that have years of uptime running the same software that the machine was installed with, plus the occasional security patch.

Re:GPL prevents this

[slackaddict]

It doesn't matter if Oracle rescends the license for all future versions because the current versions will be protected and can be forked. MySQL will continue to go forward in a new form and a new name, but it will be the same project. You won't be able to kill it.

Re:GPL prevents this

[Anonymous Coward]

Heikki is a very crucial person for the future development of InnoDB.
He is InnoDB!. Without him, there is no bright future for InnoDB.

Re:GPL prevents this

[jbolden]

Do not confuse yourself, all the OpenSource applications that are worth something are product of some kind of closed source (for profit) application whose corporation saw more value in it as PR stunt than as software product.

Well then:
KDE
Gnome
KOffice
GCC
X.org/Xwindoes/XFree86
Perl
Apache
Bash
Diff/RCS/CVS
Mail/Sendmail (and all that followed)

I could go on

Re:GPL prevents this

[Heikki_Tuuri]

Now you are underestimating other Innobase Oy engineers :). We have 4 and 1/2 top developers working here to make InnoDB even better.

Regards,

Heikki Tuuri

Re:GPL prevents this

[trparky]

You can pretty much bet that if a hostile corporate takeover were to occur at MySQL, some employee would be whipping out his USB drive and downloading all the source to it and the next day, you will find a SourceForge.net Project Page for the new project fork.

Re:GPL prevents this

[xtracto]

For a moment, I was going to look the web for references to answer to your post but, I am feeling very apathic and lazy.

It will be enough to say that, a lot of the software you mentioned was product of some people working at some University (meaning it was at least partially FUNDED by the tax payers). As an example, with gnome, was concieved by Miguel de Icaza while he was working in UNAM, which is a public University in Mexico. A lot of work was done there.

Then, there is KDE (and Koffice), which is based on the QT windowing api, from a corporation that gives their work for free. Same with Gnome, which toolkit came from GTK, the Gimp Toolkit. The Gimp was made by people at Berkeley (again, funded by government).

Again, with all the X implementations, they are being funded in one way or another by corporations.

What I want to conclude is, as in my original post, that no one of us would spend that much time for free. It is not possible in our current economic model.

I am sorry to break your bubble but that is the truth, the only thing that people is doing for free is the maintainance of some of the programs, and even that sometimes is not done well. And in other cases people must get paid to do it (as in OpenOffice) because nobody would like to touch that software.

Re:GPL prevents this

[killjoe]

"Sure but, how many of the *real* applications (OpenOffice, mySQL, Eclipse, etc) would fail misserably if the corporations that are throwing money at them to develop them will fail when they stopped?"

Two words and a symbol for you.

interbase -> firebird.

Any more questions?

Re:GPL prevents this

[jbolden]

I don't see how taxpayer funded research at a university qualifies for:

1) product of some kind of closed source
2) (for profit) application
3) whose corporation saw more value in it as PR stunt than as software product

Consider your point refuted. This new point that most open source developers are not aristocrats and thus need some sort of job is pretty obvious. It is also far weaker than the original claim.

Re:GPL prevents this

[Tim C]

The copyright holder can change the licence at any time, yes, but it does not (and cannot) apply to existing releases. As long as one person has a copy of the source licenced under the GPL, it's still free.

GPL is not public domain, and the copyright holder should be able to control his own product and say "any further use of this property is denied."

Again, the copyright holder can say "as of version x.y.z I'm changing the licence", but it does not and cannot apply to previous versions. Further, if they've accepted patches from third parties, they have to either get the agreement of those third parties to the licence change, or remove the code.

So yes, it's possible to buy an open source project and close it off, but no, you can't prevent someone from taking an existing release and running with it.

Re:GPL prevents this

[Anonymous Coward]

Friendly competition betwen storage engine makers sounds like an excellent idea for customers. Perhaps more difficult for storage engine makers. :-)

Re:GPL prevents this

[ChaosDiscord]

So, the transition would take a lot of time - and losing maybe two years of forward progress on this would most likely kill MySQL, market-wise.

Part of the reason MySQL succeeded in the first place is that for huge numbers of small or mid-level users, databases are a solved problem. Sure, faster is better, but any modern database is Good Enough. MySQL lagged in significant functionality befind Postgres for years, but MySQL was Good Enough (and happened to be easier to set up that Postgres) so people deployed it. Maybe its not Enterprise worthy, but if it's good enough to drive Slashdot, it's good enough for lots and lots of real world uses. MySQL's advancement may be delayed, it may not break into larger scale projects quite as quickly, but it's hardly going to kill MySQL. The only thing that might kill MySQL is if more powerful databases become and easy to deploy. Even then, MySQL's mindshare so powerful, I doubt it. Why experiment with someone new that promises features you've never noticed were missing when you can keep using what is known to work. This same mindset allowed Internet Explorer to coast for years and even now Firefox faces an uphill battle.

Re:GPL prevents this

[ChaosDiscord]

Do not confuse yourself, all the OpenSource applications that are worth something are product of some kind of closed source (for profit) application whose corporation saw more value in it as PR stunt than as software product.

"All" is a strong word. Sure, there is Eclipse. Which many people use to develop C and C++, typically using Stallman's baby gcc. There is MySQL, but who is MySQL's biggest free competitor? The equally open Postgress, born as a research project. Out curiousity, where is the corporation that created the very effective GIMP? Maybe the GIMP isn't ready to replace Photoshop for many professionals, but for the millions of people tweaking their family photos or making simple web pages it's more powerful than tools like Photoshop Elements. Like Apple's browser, Safari? Built on top of KHTML, the core KDE's Konqueror. Need a freely available multi-protocol instant messenger client? GAIM is quite popular, even in Windows. Need a printing system powerful enough that Apple adopted it as their standard? How about CUPS?

That some useful applications came from corporations doesn't mean all did.

Re:GPL prevents this

[larry bagina]

the GPL mysql source code is already mirrored plenty of places. MySQL's copy of the code is NOT under a GPL license. They release a version to the public as GPL, but their internal version is under a non-FREE license and contains functionality, improvements, optimizations, etc. which the GPL version does not have.

Re:GPL prevents this

[Jamesday]

There's one difference: a cursor library for the mysql command line client, which provides somewhat better support for scrollback and such.

Beyond that, the differences in Certified and non-Certified are related to more extensive testing, including more extensive regression testing and leaving time for problems to be discovered in the public GPL version before certification.

If you believe that there are other differences, please let me know what you think they are so I can tell you specifically that each is wrong.

Re:GPL prevents this

[Eivind Eklund]

MySQL could well not be delayed by the present moves (Oracle buying out InnoDB and Berkeley DB). However, there is no way that MySQL would not be delayed by the abrupt removal of MySQL AB - in effect, removing all the developers that are presently capable of working on MySQL. The question is only how much it would be delayed, and whether that would be a permanent delay, or development pace would pick up with a new kind of community.

My (conditional) estimate is that an abrupt removal would require about two years to recoup development speed, assuming transition to a normal open source form. This is the time necessary for new people to learn the codebase, adjustments of the culture to mesh with those people, etc. If a significant number of different companies employed people to work on this, and some of them were brilliant leaders, things might mesh faster. If a single employer hired a high quality team to work on this (staying with an open source codebase with a closed process), things might mesh faster. However, no matter what happened, there'd be a period where development speed was significantly lower.

The background I have for making the estimates is having seen how other open source projects have worked out, having participated in large open source projects (I'm a fairly inactive FreeBSD committer), having specifically studied the team dynamics of open source projects, having seen how the MySQL community is, having programmed for over 20 years, the last 13 of them full time, including having done my stint as a consultant for fixing development teams.

There is no silver bullet. MySQL would be hit for a period of time. It might come out stronger or it might diminish significantly. Having spent years catering to the whims of MySQL, I personally would hope the latter - I believe PostgreSQL would serve most of us better (preferably with some forceful personality or resourceful uncle making upgrades easier.)

Eivind.

Re:GPL prevents this

[Eivind Eklund]

Part of the reason MySQL succeeded in the first place is that for huge numbers of small or mid-level users, databases are a solved problem. Sure, faster is better, but any modern database is Good Enough. MySQL lagged in significant functionality befind Postgres for years, but MySQL was Good Enough (and happened to be easier to set up that Postgres) so people deployed it.

Easier setup and a period of higher speed and a period where there were a few icky bugs in PostgreSQL, plus "fake" benchmarks (MySQL censored the benchmarks, actually publishing *different* benchmarks against each competitor, only showing those where MySQL was faster.)

I formulated myself badly above: What I was thinking of when I said "killing it market-wise" was from the view of enterprise deployment, and from the view of development. I don't think working on the MySQL codebase would be particularly attractive, given the overall higher capability and easier use for development of the PostgreSQL codebase. I also think people would associate MySQL with an unstable development process.

That's just my guess, though, and may be wishful thinking. I've been forced to work a lot with MySQL (due to previous deployment choices at my present employer), and I have developed a strong antipathy towards it after all the pain it has caused me. I much prefer working with PostgreSQL.

Eivind.

MySQL gets the next great thing after Firebird?

[Jamesday]

Jim Starkey said that he'd been working on a new engine for the last six years but couldn't integrate it fully with Firebird because of architectual problems. MySQL has an architecture designed to accept pluggable storage engines, so MySQL might end up with what he thinks is the next great performance improvement after Firebird.

Re:MySQL gets the next great thing after Firebird?

[Anonymous Coward]

I dont think it was architectural problems that prevented integration. Netfrastructure was Jim's private development (before Interbase was open sourced and became Firebird). He isnt really interested in giving it away for free. He really only came back to work on some Firebird related work because of a contract to do so.

Netfrastructure wasnt really developed as a general purpose database engine. Rather it is targeted at web applications... it integreates a database engine, a jvm, and some stuff for serving pages. You should read some of these: http://netfrastructure.com/main.nfs?a=netfraweb&o= whitepapers

Whether that is a direct fit for MySQL is another question. It doesnt really matter, as Jim has the knowledge and experience to develop another transaction engine from scratch if he is given the time and free rein. If he isnt given free rein, there will likely be fireworks ;-)

Re:MySQL gets the next great thing after Firebird?

[Jamesday]

Thanks. Already read some. :) Architecture was the reason he gave in his announcement, so who am I to disagree? :)

I will disagree on some things, like the outdated claim that RAM is cheap, when now it is CPU which is cheap and using a core or two for compression is a good deal. :)

Re:MySQL gets the next great thing after Firebird?

[rkuris]

I don't understand why MySQL doesn't just aquire one of the existing closed-source database backend companies and do the integration work. Seems like [shameless plug] Unify's DataServer product [/shameless plug] might make a good choice. Another possibility is Birdstep's RDM.

Unify's product has a detachable SQL engine and Birdstep doesn't even have an SQL engine.

Re:MySQL gets the next great thing after Firebird?

[Jamesday]

No reason MySQL can't be doing ten things simultaneously.

Even if MySQL itself did nothing, I expect to see lots more storage engines over the next 6-18 months, just exploiting the run-time pluggable storage engine architecture in 5.1.

Want an engine optimised for storage in flash media, CD-ROM, for searching, for geospatial work, access to an old Oracle table, access to Access .. you name it, if someone has a need, they could use a storage engine if that would be the easiest way to integrate it. No reason for MySQL to do these things - it's easy enough that customers with the need can and do.

MySQL spatial data support

[Lord Satri]

In regards to MySQL being more and more competitive in the geospatial area, there was an announcement last week about OGR and GDAL compatilibity for MySQL. With geospatial getting everywhere (you know; RFID, Google Earth, GPS, ...), this is great news for MySQL.

Re:MySQL spatial data support

[ivoras]

It would have been even better if MySQL got it earlier (like PostgreSQL did from the start). It's a shame that MySQL started getting cool (and necessary!) features only now when the market pressure on its company increased. Prior to this, it was practically stagnating.

Wrong: It's the Other Way Around

[segedunum]

The pressure is ALL on Oracle. The reason why they're doing all this is because they're scared. The vast majority of companies out there running Oracle really are beginning to realise that they DO NOT need to spend anywhere near the amount they do on Oracle. They've heard of Postgres and especially MySQL, and MySQL are sufficiently cheap enough where companies get the right support they need without Postgres being any sort of threat - just a good old fashioned competitor.

Oracle have overinflated revenues and profits based on crap software, and they've been doing it for years. Their management and configuration tools are utter crap as well considering what people are paying. I don't know what they do in that company all day. Good riddance as far as I'm concerned.

The guy who wrote this article (possible an Oracle fan) is simply putting some positive spin on some pretty panic moves from Oracle. It isn't going to make a blind bit of difference to MySQL, or Postgres for that matter.

Re:Wrong: It's the Other Way Around

[cruachan]

Oracle have overinflated revenues and profits based on crap software, and they've been doing it for years.

Oh dear, looks like we have a MySQL weenie here. Oracle my well be pumping their revenue stream for every dollar they can get, and like IBM their salesmen used to be notorious for turning up for meetings without a price list (it's depends Sir :-). But crap software? Hardly. Oracle plummeled MySQL into the dust in quality before MySQL even existed. Oracle has had transactions and atomicity since version 6 in the early 1990s, a full and elegent procedural SQL language since around that time, SQL that supports concepts such as subselects and everything else needed so a dba could support a mission-critical company database and sleep easy at night.

Oh, and did I mention the support? When I was a dba I knew I could ring support up, at any time of the day or night, and I would get an answer to a question and a fix/work-around for any problem. Truly impressive.

MySQL has it's place and it's useful for many things - although generally as a database it's still pretty crap. Postgres is much much better and is now a serious alternative to Oracle, SQL Server and DB2. But to dismiss Oracle as crap frankly just says in large flashing letters that you've never used a real database for a serious application.

Re:Wrong: It's the Other Way Around

[doleman]

Oracle and MySQL are the two DBs with which I've worked extensively as a development administrator. From a very high-level/general standpoint, my basic comment is this: When I've used Oracle, my life has been complicated; when MySQL, I don't even have to think about the data.

The power of Oracle for certain applications cannot be denied, but as has been pointed-out, more people are realizing every day they have no need for that kind of horsepower. As a former colleague of mine was fond of pointing-out, it's like taking a 747 out of the hanger to make a trip to the corner stop-n-shop.

MySQL once filled what could've been called a "niche" market. But now, as more people understand what sort of back-end functionality they really need, that "niche" is looking more and more like a pervasive, critical marketplace. Oracle sees that and they are reacting. They are not positioned all that well to go toe-to-toe in the marketplace that is familiar territory to MySQL. My feeling is that what's going-on now is just "shots across the bow" leading-up to the big battle. How it all settles-out is anybody's guess.

Re:Wrong: It's the Other Way Around

[w0lver]

Oracle has had a great product since about Oracle 7, I do not disagree there. However, there a few counters to a number of your points. First, not every application needs Oracle and the power it brings to the table. Many applications today just need persistence of a few dozen tables. They will never need PL/SQL and the few times they do they just might code that logic into their application instead of proprietary language. Yeah, PL/SQL is faster but most applications don't require that level of performance.

Second, Oracle has become a beast. The tuning a production database has become near black magic. I had a project where it was all Oracle and a Oracle-recommended consultant was brought in to help increase performance. The bill was $7000 for two days and we had decreased performance. Oracle paid the bill after bitching and a new consultant was brought in this time $8200 with T&E and no real increase. This fight took another two months and three escalations before that was refunded. Third consultant was much more truthful and gave a things to test over time and told us that the sheer number of parameters to play with and their inter-dependencies make tuning very difficult and impossible for one person to know all the variations without years of dedication. Many companies don't have the resources (staff, money, time) to run Oracle.

The support for MySQL is good, better than most software companies these days. Not to mention, at $4995 it has been cheaper than an Oracle dev license until Express.

MySQL isn't crap; it just is not at the same tier at Oracle. IMHO, MySQL is easier to set up and use than Postgres. Postgres had the advantage with more features than MySQL, but that distance is much, much smaller with the release of MySQL 5.0. It's ironic that you slam MySQL for support yet say Postgres is better, commercial support for MySQL exists. The user community for MySQL is large and also very helpful.

Reality is that you need to select the right database that fits your architecture. Creating a massive data mart which millions of dollars depend the availability of the data, might want to think Oracle. Running a website that needs storage for a 100,000 user profiles, I bet MySQL would fit your needs. Blindly dismissing any technology instead of evaluating attributes based on business and technology needs is just dumb.

Re:Wrong: It's the Other Way Around

[Anonymous Coward]

> "although generally as a database it's still pretty crap"

Uhuh.. That's why companies like google and mythic (dark age of camelot) uses it.

5.x supports subselects and views, and from what I'm told stored procedures as well.

Omfg-teh-crappy-db!

Re:Wrong: It's the Other Way Around

[jbolden]

Oracle, crap software? For the last 20+ years (including right now) Oracle has been way ahead of everyone in RDMS technology. Postgres is implementing features from Oracle 7/8. They aren't anywhere near Oracle 10. I suggest you take a look at what Oracle does before making silly comments like this.

Re:Wrong: It's the Other Way Around

[jbolden]

I can't believe you are seriously arguing the tuning tools on MySQL are anywhere near the ones on Oracle. Oracle has whole tuning libraries, tuning subsystems, autotuning components, performance analyzers.... Just for starters look up "statspack", "Performance report" in your oracle docs and tell me where MySQL has anything like this.

Oh and sending some guy for 2 days is not how you tune a database. You have a full time on staff DBA that works with your development team, understands the data and understands how the system is being used. Oracle 10 does an excellent job of self tuning (again an advantage over MySQL). To beat the automated routines takes time.

Re:Wrong: It's the Other Way Around

[segedunum]

Oh dear, looks like we have a MySQL weenie here.

Looks like we have an Oracle weenie.

But crap software? Hardly.

Hmmmm. Where's the graphical management tools?

Re:Wrong: It's the Other Way Around

[segedunum]

I can't believe you are seriously arguing the tuning tools on MySQL are anywhere near the ones on Oracle.

You're overinflating the need for Oracle. The vast majority of companies do not need whole tuning libraries and tools.

You have a full time on staff DBA that works with your development team, understands the data and understands how the system is being used. Oracle 10 does an excellent job of self tuning (again an advantage over MySQL). To beat the automated routines takes time.

The vast majority of companies do no need it.

Re:Wrong: It's the Other Way Around

[segedunum]

I suggest you take a look at what Oracle does before making silly comments like this.

I suggest you look at what people need before posting comments like this. Take a look at the management tools available for MySQL, Postgres and SQL Server generally available.

Re:Wrong: It's the Other Way Around

[w0lver]

Thanks for the condensing tone, did you really read what I said? When did I say that "the tuning tools on MySQL are anywhere near the ones on Oracle", I didn't. What I said is that Oracle is difficult to tune and takes specialized staff. "Full time on staff DBA that works with your development team, understands the data and understands how the system is being used" is great and goes so far, when you need to get greater performance, a expensive and rare person is required. BTW, what does a Oracle "Full time on staff DBA" cost? My point is that MySQL is much simpler and doesn't require the staff and expense of an Oracle. Sometimes a lightweight and simple system is going to get you the bang for the buck you need versus a heavy complicated system. My whole post was to point out that there are tradeoffs and just bashing MySQL without looking a context is bigoted.

Re:Wrong: It's the Other Way Around

[w0lver]

Hmmmm. Where's the graphical management tools? Well if you were a real DBA, Oracle's OEM would be good enough for you... ;) However, if you want to spend another $6,000+ there are tools like Quest Central.

Re:Wrong: It's the Other Way Around

[jbolden]

Sure lets take a look at them. Name any area of database management. Show me how MySQL or Postgres's tools are in fact better (better in this context means: more feature rich, more powerful, leading to higher utilization rates for hardware).

And I don't care what people need. The point being debated is whether Oracle is "crap" not whether most database users can get away with very low end products. Heck the most commonly utilized database is a list in Word so this point isn't even worth discussing.

Re:Wrong: It's the Other Way Around

[jbolden]

You gave a two paragraph story about tuning and how it was unsuccesful. This has been preceeded by: "The tuning a production database has become near black magic". I think it was reasonable to consider this a direct criticism of Oracle tuning.

Saying that Oracle is a more expensive product that takes more skilled and more expensive staff is accurate. Insuating that Oracle isn't in virtually every sense from a technical perspective the surperior product is inaccurate. A Lamborghini is a better product than a Mustang, a Mustang costs 2% as much and that is only reason it outsells Lamborghini. Oracle is a DBMS for database professionals. If a company doesn't have database professionals they shouldn't be using Oracle. Professional tools are better (but harder to use) than consummer level tools.

I don't see why people pretend this is a very clear case.

A full time DBA will run you $65-150k. Fully loaded $100-200k. Most large companies (which is who should be using Oracle) have a half dozen or more of these on staff.

Re:Wrong: It's the Other Way Around

[jbolden]

How is "do not need it" the point under debate? Oracle is designed for when you do need it. The idea that because MySQL doesn't have this capacity its better is simply silly.

Re:Wrong: It's the Other Way Around

[segedunum]

How is "do not need it" the point under debate?

Because that's what the original point was if you'd read the original comment. Many people simply don't need everything in Oracle that they are paying for. People are now realising that more.

Re:Wrong: It's the Other Way Around

[Stu Charlton]

More likely, people don't understand what they're paying for in Oracle because the developers are too lazy to understand it, and decide to build those features themselves.

This may sound condescending, but it is very prevalent in the Java community, for example. People just don't understand how much they're getting and treat the database as a dumb object store. If that's all it is, sure, use MySQL. But I am quite confident that a team that understands Oracle will be tremendously more productive and have a more performing, scalable application than if they used it as a dumb store (the way you would use MySQL, which couldn't do inner queries until recently, for example).

Re:Wrong: It's the Other Way Around

[Stu Charlton]

But a full-time DBA can manage many, many Oracle instances. Operations DBAs, generally speaking, are responsible for uptime, and periodic operational tuning. It takes a different kind of DBA or even Oracle-experienced developer to understand how to write and tune SQL and design an optimal I/O layout.

Are you suggesting that MySQL doesn't require a DBA? The physics and computer science under the covers is the same... If you push MySQL to the same degree many customers push their Oracle databases, you're going to need professional help.

Re:Wrong: It's the Other Way Around

[jbolden]

I would add that if you are going to use Oracle as a dumb object store you would be far better off with an object-oriented database rather than a relational database. Its only when you have more than one app hitting the same data that object-relational makes more sense than pure object-oriented.

So even as a dumb object store MySQL doesn't a lot of sense.

Re:Wrong: It's the Other Way Around

[jbolden]

I saw the message below and you may want to re-post so GP sees it. However I still can respond.

I'm not so sure with the statistical optimizer that traditional SQL developer can really do much to tune in most cases. As long as the statistics are good its rare that hints would matter (especially given long term maintenance and issues of runtime utilization) and most are pretty obvious at this point. Back in the days when Oracle was rule based, yes this would make a difference. Again if the system runs one type of query almost all the time.... but then the DBA would know how to tune.

Incidentally, since this is a MySQL thread, MySQL has made some progress in this direction see Statistics System Tables. My guess is that because of this it also holds true for MySQL that SQL tuning is passe.

Guess its like Coke in green bottles or hand written assembler :)

Re:Wrong: It's the Other Way Around

[TangoCharlie]

You're right about Oracle being under pressure.... but the pressure is not
from MySQL, or Postgres, it's from M$ SQL.

Oracle sees M$ essentially giving away M$ SQL for education, development and non-commercial users. When starting on a new project, most people will start with the "easy" and "safe" option. That option is becoming M$ SQL. Oracle knows that once people have got used to one system, they're loathed to switch.

Note, that M$'s stratagy also hits at MySQL and Postgres: WHy bother to start with MySQL when M$'s SQL is "free" too?

MySQL to adopt Firebird architecture

[Anonymous Coward]

See: http://www.firebirdnews.org/?p=129

It's more than PR...

[Anonymous Coward]

It's free labor.

Release something as "Open Source".

F/OSS programmers come on board to work on it - for whatever their reason.

Profit!

Take a look at what happened with the JBoss crowd.

Re:But there are other problems

[symbolic]

According to the article, Oracle is also looking at Zend, the makers of PHP...PHP has been used very widely in the implentation of MySQL-based solutions. Granted, PhP isn't the only available option, but all these aquisitions could make for some headaches for a large number of users.

Bear in mind, that Oracle is also planning the release of a low-end product, Oracle Express, presumably to compete with the likes of MySQL and Postgres. I don't think I would ever use or recommend it, because at its core is the beginning of a short road to Oracle's usually-expensive licensing.

So what?

[ajs318]

I know Slashdot users like to bash MySQL, so I will try not to put out any bait.

MySQL and all its components -- including innoDB and BerkeleyDB, which is the Sleepycat product -- are available under Open Source licences {GPL for InnoDB and BSD-like for BDB}. And they will continue to be available under those licences for as long as copyright subsists in any of the code; after which they become Public Domain.

Just because the makers have been bought out, does not mean that there is any threat to the Open Source nature of the code. Quite the reverse, in fact. If Oracle are trying to make the proprietary fork of MySQL more compatible with their own proprietary database, then they must be aware that there is no way they can prevent the open source fork also becoming compatible with their proprietary product.

Oracle have shot themselves in the foot here. There is already plenty of choice of Open Source database server applications; MySQL, PostgreSQL, Firebird, SQLite, Ingres, and so on. This could be the beginning of the end of closed source software. We can only hope!

Re:So what?

[kpharmer]

> Just because the makers have been bought out, does not mean that there is any threat to the Open Source nature of the code. Quite the reverse,
> in fact. If Oracle are trying to make the proprietary fork of MySQL more compatible with their own proprietary database, then they must
> be aware that there is no way they can prevent the open source fork also becoming compatible with their proprietary product.

Right. However, the best option for them is to simply sit on the products. Don't do anything - except maybe raise licensing fees. They'll be able to do that very soon now for innodb. In the meanwhile, MySQL needs innodb to support advanced database features if it is going to be more competitive with Oracle - partitioning, encryption, online maintenance, etc. And if Oracle just refuses to add any of these new features then MySQL really has no where to turn. They're effectively *stopped*. For at least a few years anyway.

> Oracle have shot themselves in the foot here. There is already plenty of choice of Open Source database server
> applications; MySQL, PostgreSQL, Firebird, SQLite, Ingres, and so on.

Sure, but mysql is the market leader, and oracle has completely taken the wind out of its sails. While Postgresql is a better product in almost all ways it doesn't have the PR machine that mysql has - so it would take a couple of years for postgresql to get the same buzz/hype that mysql has going. Of course, oracle can't really hurt postgresql the way it has hurt mysql, but that doesn't matter - harming mysql gives it a good 2-3 year benefit.

> This could be the beginning of the end of closed source software. We can only hope!

I think Oracle is in deep trouble, but really not for another 5-10 years. And I think this actually gives them a couple of extra years.

Re:So what?

[LeeMeador]

If there are any patents involved there could be problems.

An open source project that uses some patents that belong to a company that supports the open source project (or fathers it) does not cause a problem. The company allows the open source project to use the patents for the same reasons it pays people to write code for it.

If that company is bought by another company that cracks down on the patents, a whole-nother situation can result. Of course, they will say "We have to protect our patents or they will become useless."

Re:So what?

[ajs318]

Right. However, the best option for them is to simply sit on the products. Don't do anything - except maybe raise licensing fees. They'll be able to do that very soon now for innodb.

InnoDB is available under the GPL, and that means it's not going anywhere. Last I checked, you didn't have to pay any "licencing fees" to use it. As long as just one person outside Oracle has a copy of the source code, Oracle can't control its distribution. That person is entitled, under the permissions granted by the GPL, to supply it to anybody. They may charge a fee for the distribution -- but anyone who acquires a copy also has distribution rights, and may charge a lesser fee for distribution. That is called "free market capitalism" -- where the value of goods is determined by the price the market can withstand.

This seems to apply even whether the copy was had by fair means or foul, since the licence comes from the copyright holder and not the downstream distributor. If Slippery Joe the Hacker managed to break into Oracle's inner sanctum server and download some GPL source code, paragraph 6 of the GPL says he would be allowed by the copyright holder to distribute it. And if Joe went on to exceed his authority under the GPL, paragraph 4 says that nobody who had already received a copy from him would be affected by the resulting automatic revocation of his licence.

In the meanwhile, MySQL needs innodb to support advanced database features if it is going to be more competitive with Oracle - partitioning, encryption, online maintenance, etc. And if Oracle just refuses to add any of these new features then MySQL really has no where to turn. They're effectively *stopped*. For at least a few years anyway.

If Oracle won't add the features you mention to InnoDB, then somebody else will -- and they will almost certainly licence them under the GPL. That will mean the genie will be well and truly out of the bottle; Oracle cannot control what happens to software that has already been released under the GPL.

Re:So what?

[ajs318]

As long as there is at least one country in the world where software is legally unpatentable, then software patents are not a problem anywhere else in the world.

Re:So what?

[kpharmer]

> Last I checked, you didn't have to pay any "licencing fees" to use it (innodb).

MySQL pays licensing fees to use it for non-gpl work - then passes that on to the customers. I've got no clue how this applies to the odd licensing exceptions, etc but that's my general understanding of the agreement.

> This seems to apply even whether the copy was had by fair means or foul, since the licence comes from the copyright holder and not the downstream distributor.

Sure, good point - I'm not sure where this code exists, but assume that it is available.

> If Oracle won't add the features you mention to InnoDB, then somebody else will

I agree that this could happen for small features, but many of these are huge (partitioning, query parallelism, etc) and won't be added by an individual, but instead a team - consisting of people familiar with this functionality. And not a team spending a few hundred hours, but maybe up to 10 or 20 thousand. And that's just for a single feature like table partitioning. Where do you get such a team from? There are few out there with prior experience. So, maybe you get 1-2 core people from? Oracle, IBM? Actually, the postgresql team would be good to look at here. If not for recruiting, to get an estimate of the time needed to support certain features.

Probably the best

Re:So what?

[ajs318]

I honestly don't know why anybody would pay MySQL for a commercial licence, when they can get a full-featured {well, as full-featured as MySQL ever gets} MySQL for next to nothing under the GPL. I can only think of support as a reason for buying a non-GPL version; but then, there is plenty of independent support out there in the Community, and you don't have to look particularly hard to find it.

Most of the features missing from MySQL have already had to be emulated in the application layer by cunning programmers, and could be ported through to the database engine layer if demand exists. Beside which, I'm not even certain that there's a big market for the really esoteric stuff -- people are already buying vastly over-specced software for their needs. There's a lot of under-speccing going on too, of course. I think this is an inevitable consequence of pret-a-courir software -- one size fits almost nobody. Nobody is complaining about this now, because they aren't aware that any alternative exists. So they might start out using a spreadsheet as a kind of poor man's database; then outgrow that, and end up buying a heavyweight database server with features they are never going to use. Yet an OS, web server, database server and scripting language, which can be had as a set for the taking, plus a few hours of programmer time and a retiring desktop PC, will deliver the required functionality across the entire corporate LAN, not just on one desktop.

There's an emerging market right now for competent people to advise business users who may be about to get {or have already had} their fingers burned, whether by vendor lock-in or licencing costs, on the benefits of Free Software and how to achieve the most painless migration. This will lead to greater use of Free Software; it will eventually become the norm, with the closed-source days regarded as a kind of "dark ages" in the history of computing. And we won't be able to believe we could ever have been so stupid as to allow it.

Then Oracle better be quick (see yahoo-finance)

[lonesometrainer]

SAP has posted very good results lately, has done a good job with natural growth.

Market Cap is nearly the same, but SAP is quickly increasing.

SAP == solid growth whereas ORCL == merger chaos

http://finance.yahoo.com/q/bc?s=SAP&t=3m&l=on&z=m& q=l&c=orcl

my 2 cents

mysqldump --single-transaction

[shani]

Using mysqldump in a single transaction, with:

mysqldump --single-transaction

Allows you to take a clean snapshot of the entire database without taking it down. We've been using this for quite a while now (a couple of years I think). You need to use 4.0.2 or later.

Re:mysqldump --single-transaction

[Fulcrum of Evil]

Allows you to take a clean snapshot of the entire database without taking it down.

How's that affect the undo segment on a busy database?

Re:mysqldump --single-transaction

[localman]

Interesting. I wonder how the performance hit of running that on compares to running hotbackup. Our DB is about 200GB and takes about 5 hours for hotbackup without notable performance degradation.

Also, hotbackup is "smart" enough to lock the couple of MyISAM tables we still use (for fulltext indexing) and so it really does provide a consistent snapshot. --single-transaction doesn't seem to do that.

Still, I'll keep this in mind and try it out. Thanks for the tip!

Cheers.

For Ellison to win, everyone else must lose

[SgtChaireBourne]

It seems to me that what Oracle is doing is not to try and take over or squash MySQL but rather to buy some more time.

I agree that Oracle is just looking to keep the heat off for a bit. But what it does when that time runs out is another question.

Larry Ellison is a very successful strategist, but also most unfortunately he is one of those people that tries to shoehorn his entire view of the universe into a zero sum gain model. The zero sum gain model, a religion among some MBAs, is the believe that theire are either winners or losers and win-win is unthinkable. Larry has demonstrated time and again that it's not enough for him to 'win', everyone else must 'lose' or things are not complete for him.

Maybe Oracle, will 'get it'. I hope it does and if it follows IBM's example, then things could look quite good for both MySQL AB and Oracle.

Oracle just wants _the name_

[Anonymous Coward]

MySQL may be crap, but their marketing dept has done great things over the years.

Get a hold of that trademark, and you'll own the low-end market for quite some time to come.

Huh?

[PCM2]

Oracle is trying to kill MySQL because SAP wanted to use MySQL as an option for their systems to prevent customers from buying an Oracle database.

This is a typical kneejerk reaction, and I keep hearing it, but it doesn't make any sense to me. Oracle isn't stupid. Oracle knows that:

• Oracle can't "kill" MySQL so long as it's open source.
• It would be a waste of time, money, and energy to kill MySQL when PostgreSQL, Ingres, and Firebird all still exist.
• There will always be customers who want to use open source because it costs nothing and it's pointless for a company that wants people to pay for software to pursue those customers.

Besides, why would Oracle want to kill MySQL so it can be the de facto back end for SAP? Not only would it not work (as mentioned above) but Oracle isn't really interested in being the back end for SAP. In the long run, Oracle wants to be SAP.

Read my other comments on this topic here and here.

Re:Huh?

[PhilipPeake]

You don't seem to get it.

SAP customers mostly won't use free, unsupported software. They are betting their existence on the SAP products and all their ancilliary supporting infrastructure (such as the database) working. They want guarantees.

They could get those guarantees from "MySQL the company", but not from "MySQL as dowloaded from the net".

Oracle now basically control the backend that SAP relies upon, and Oracle can manipulate various aspects of both DBs to make their own SAP cometitive products look attractive. SAP can no longer point to MySQL as a backup solution in the case of problems with Oracle.

The references to PostGreSQL and Ingress are really red herrings - as far as I know SAP has never suggested that they might be suitable backends for SAP, and its unlikely that they will do any work in that direction as Oracle could pull the rug out from under them again in the same way.

This is a BIG blow for SAP -- unless SAP want to either get into the DB business themselves, or make their own DB backend for SAP, which would probably not be attractive to their customers.

Re:Huh?

[kcbrown]

The references to PostGreSQL and Ingress are really red herrings - as far as I know SAP has never suggested that they might be suitable backends for SAP, and its unlikely that they will do any work in that direction as Oracle could pull the rug out from under them again in the same way.

Uh, no. PostgreSQL isn't owned by any company. Because of that, Oracle can't do the same thing to it that it did to MySQL. That makes it an excellent possible backend for SAP, if SAP needed such a thing.

Furthermore, it's under the BSD license, so SAP wouldn't even need to redistribute the source in order to make use of it.

Re:Huh?

[Fulcrum of Evil]

They could get those guarantees from "MySQL the company", but not from "MySQL as dowloaded from the net".

Couldn't they also get those guarantees from MySQL support, the third party company with a solid reputation (assuming such an animal exists)?

Re:Huh?

[Anonymous Coward]

while this is likely true, the PHBs don't think this way. they would rather pay $1,000,000 to be like everyone else and have a fall guy other than him/herself that get something equal in value with a 1% chance of hickups that could be laid on their lap and cost them their job.

the PHBs are mostly interested in keeping their j-o-bs, and if that means burning a million bucks to create a fall guy everyone else uses, then consider the million bucks burned.

i run on knowledge and general principle, so PHBs don't really understand me too well.

then again, i'm their fall guy, so they feel a little safe when i dictate the technology i use to implement my applications.

I just commented this on LWN...

[hummassa]

but, IF Oracle really wants to shaft MySQL AB, all they have to do is introduce subtle bugs on newer versions of InnoDB and BDB, preferably while doing nice updates and security fixes... the potential for wrongdoing here is infinite.

Re:I just commented this on LWN...

[trparky]

That's why the OSS community has something called "code review". Thousands of eyeballs pour over the code looking for exactly that, bugs and then fix them.

Wouldn't it seem a bit fishy that all of a sudden, something broke yet last week it worked and it suddenly broke right after Oracle made a patch for InnoDB? You can't tell me that people won't be pointing fingers at Oracle, because they most definitely will be.

Re:I just commented this on LWN...

[Paradise Pete]

That's why the OSS community has something called "code review". Thousands of eyeballs pour over the code looking for exactly that, bugs and then fix them.

I think you overestimate the eyeball count. I doubt there has ever been any open source project anywhere that has had a thousand different people study the code.

Re:I just commented this on LWN...

[Eivind Eklund]

Parts of the BSD and Linux kernels, I'd guess. Apart from that, it's fairly seldom we look at code unless it's to change it, and the standard review count may be 4-5 people (if that much).

I personally think there are other reasons for why Open Source is so effective, having to do with lack of time pressure, chosing not to do something if it is too complicated, and the feedback that review give on coding style.

Eivind.

Oracle helping Open Source? I don't think so

[hypersql]

I don't think Oracle wants to play in the Open Source field as the article suggests. They will probably try to kill/hurt the competitors and get as much customers from them as possible. Maybe Oracle will offer a free version of the software (InnoDB / BerkelyDB / PHP / JBoss), but I don't think they will do it like Sun with OpenOffice. Or IBM with Eclipse / Linux. Oracle doesn't need to do it, because they have the market share already (unlike Sun and IBM). Oracle just wants to keep the market share, and keep MySQL small.

Oracle tried to buy MySQL, and because they can't (probably MySQL just wants too much money), they try to hurt them as much as they can. Oracle must be really scared of MySQL. When they buy Zend, they will probably try to charge for it, and LAMP will become LAM.

Oracle bought Innobase just to hurt MySQL. I think Oracle will try to make as much money from InnoDB as they can (converting customers to Oracle) and then try to kill InnoDB. Probably MySQL tired to buy Innobase, but Oracle just offered more money.

Then they bought Sleepycat to hurt MySQL, and to use the technology and get more customers (the main customers of BerkleyDB are not from MySQL). So Sleepycat will probably survive, but the Oracle will poison it so MySQL can't use it. MaxDB now assumes a much more important role, and MySQL should be working on integrating it as quickly as possible I don't agree. MaxDB is a different database engine, including parser and so on. Probably it's a huge, ugly, complicated mountain of source code. Integrating such a thing is hard, really hard. If it's done in a hurry it means hacking and patching. This will lead to bugs, stability problems, slow performance. And if that happens, people will loose faith in MySQL. It could in fact mean the end of MySQL if they do that and if fails.

Better would be actually: grab a few database kernel developers (Jim Starkey for example), and write a new kernel. Probably even better (if MySQL has enough money): build 3 teams, one doing MaxDB refactoring, and two writing a new kernel. Then after some time integrate the best one, and throw away the rest. I heard Oracle did such 'competitive development' in the past.

Oracle Express: this is not a response to MySQL, it's a response to SQL Server Express Edition.

About other databases: I think PostgreSQL has the best position as an open source db, but don't really feel that Firebird is anywhere close. Firebird lacks a lot of features, and development is slow. Well let's see.

Thomas Mueller, author of Hypersonic SQL, PointBase Micro, and (lately) the H2 Database Eninge (http://www.h2database.com/).

Re:Oracle helping Open Source? I don't think so

[Anonymous Coward]

MaxDB is indeed a huge mountain of source code and software. And furthermore, it is again joint,
this time with SAP, not their very own piece of software they now surely get with Jim Starkey.
(Not that SAP would be bought by Oracle, though :).

And by the way, Oracle tried to buy MySQL too:

http://news.com.com/Oracle+tried+to+buy+open-sourc e+MySQL/2100-7344_3-6040197.html

The problem is only that at the time the will get it, probably this will be 3 years away ... a lot
of time for all competitors ...

Go PostgreSQL!

[nbritton]

This would be the best thing to ever happen to PostgreSQL, MySQL is a POS.

Re:Go PostgreSQL!

[Anonymous Coward]

Yea, I figured that was going to happen... it's true though. PostgreSQL has always been the better option of the two and PostgreSQL is a better and closer replacement for Oracle, MySQL was never even in the runnings.

They already did

[Anonymous Coward]

SAP already made a free backend DB of their own - google SAPDB. MySQL is probably better, and SAP was moving that way but Oracle has bought the hackers and any IP actually owned by MySQL AB (which is a lot of it I think). So yes, SAP can start-up from scratch with the source, but Oracle can close the next version (to an extent) and can prevent the experts working for SAP.

Plus Oracle can give the MySQL people access to the Oracle code, to put whatever's really better about MySQL into Oracle (and taint them for open source code writing forever in the process).

Re:They already did

[PCM2]

Actually, MySQL is not "better" than SAP DB. If it were, then MySQL wouldn't have bought SAP DB. (That's right, SAP sold SAP DB to MySQL and it's now marketed as a product called MaxDB.)

There is more to the relationship between SAP the company and MySQL the company than SAP wanting its customers to run MySQL -- in fact that idea, on its face, seems a little absurd.

Re:They already did

[Anonymous Coward]

SAP DB is certified for use with SAP. MySQL is fast. MySQL when capable of being certified for SAP will be the best of both. SAP is funding MySQL significantly so the future here is pretty easy to predict.

Terrible article summary

[Raenex]

The title leaves you looking for MySql's response to the recent Oracle purchases. Can you find it in the first link? Nope, not a single, concrete action from MySql is mentioned, just lots of speculation/analysis. How about the second link? Nope, just more analysis. How about the *third* link, entitled "more thoughts"? Yes, finally! That should have been the first link given in the article, and really the only link he needed to give, since the first two articles are mentioned in the third.

It's all about control

[Anonymous Coward]

I don't think Oracle wants to eat MySQL's lunch just yet. They will keep advancing both BerkeleyDB and InnoDB and keep them (sort of) free until Oracle comes up with its own alternative to MySQL.

And get this: it will be fully compatible with MySQL storage to ease transition (migration would mean simply firing up new server processes on top of existing MySQL databases).

"Are you using MySQL? Well, then just upgrade to MyOracle. It's fully compatible with MySQL storage, so no migration is necessary. And it's also free with more features (support costs extra)."

Oracle isn't anti-OSS

[rsavela]

I don't think that Oracle is really anti-Open Source. They have released a ton of stuff, most importantly to me: o Big memory pages for the Linux Kernel (helps with TLB misses for shared memory) o OCFS 2, a very good clustered filesystem. o Firewire code o Async I/O linux support Oracle was probably the first major database to run on Linux (version 7 worked, version 8.0 was supported). That was almost 10 years ago. Sun used to be the bread-and butter platform for Oracle. Linux has basically replaced it. Oracle already owns the database market. Most SAP sites already use Oracle as the database. The reality is, no matter how good their database is, they won't make any more money from it. Feature-wise, Oracle is more than 10 years ahead of MySQL. These are features I use all the time, every day. Oracle Fin Apps is the only place their business can grow. While it isn't a great product, neither is SAP R/3. These are big bits of software. Fin Apps 11iR10.2 is about 50GB of install media. (That is a lot of code). With Oracle's acquisition of Peoplesoft and JD Edwards, SAP is really the only competetion.

Re:Oracle isn't anti-OSS

[TallMatthew]

Sun used to be the bread-and butter platform for Oracle. Linux has basically replaced it

This is why Oracle chose to be "pro" open source in the first place. They knew if they could get their product running on Linux, they would have an easier time selling software licenses. Those $50k-$100k Sun enterprise purchase reqs were killing them. Once the economy started to bubble, their $50k-$100k licensing fees were getting lost in the shuffle. Ta Da! Linux servers are far less expensive, making the bundle far more attractive from a cost perspective. Not to mention why should they hand all that business to Sun when it's their product that's driving the hardware purchase in the first place?

And it worked. Oracle thrives. Sun suffers.

Oracle, like every other company with their toes in the open source bath water, is doing it to make money. There's an end game with these purchases. Being that Oracle and mysql are competitors, it's probably to squash. Witness the Peoplesoft "acquisition".

Just Say No Drama

[Anonymous Coward]

just say no to the drama and hello to postgresql's good karma.

And, furthermore,

[hummassa]

There are subtle ways to introduce bugs, one line at a time, spread over a dozen different patches... If the idiot that broke kernel.org had worked on a lot of stuff in the kernel, seemlingly legitimaly at first, he could have slipped that vulnerability quite easily.

Re:And, furthermore,

[Paradise Pete]

I think you must have replied to the wrong post, but I don't dispute what you say. Vulnerabilites can be slipped in, legitimaly or otherwise.

[OT?] I was "completing" your post...

[hummassa]

in response to the grantparent post.

let's get real

[Stu Charlton]

The ironical thing about this is that the future of OSS software is actually *more* secure than anything the closed-source industry could create.

This is true for cases of "dead" or "dying" products, where there isn't market incentive to keep maintaining and supporting the product based on the revenue it generates. It's arguably why Netscape was originally open sourced and eventually spun off into a non-profit foundation.

Whereas in cases where there still is market demand, it's very common for another company to step in and maintain/support the codebase.

Even in cases of small proprietary software companies, large customers often request that small software companies put their code in escrow as a hedge against their viability -- they'll then either take on the maintanence themselves or sell it to someone who wants to. The software industry has been doing this for a long time.

Can the same be said of Oracle? If Oracle falls apart tomorrow due to some massive accounting fraud being publicized, where does that leave all the current Oracle users?

Another company would step in to take on maintanence and support of the product. This would likely consist of most of the old Oracle employees. Sure, there is risk there, but since we're talking about "worst case scenarios", there's risk in an open source project too, which usually relies on a small number of core developers. If they leave, it's not guaranteed that people with the same level of talent and productivity will quickly step up to take the project over.

What if your CRM breaks, who will fix it?

Not necessarily the OSS community. The problem with any community is that it evolves, maintains, and fixes what it wants to -- it doesn't have to listen to customers that are not also contributors. This is reflective of the old attitude of "if you don't like it, submit a patch, or fork it". To a large customer, that's not good enough.

Of course, open source arguably provides a free escrow. Customers could just take the code and support it themselves or pay a 3rd party to maintain it and evolve it in a closed-source manner, since GPL2 and their ilk are only about redistribution. This is how Google and other software-as-a-service companies can exploit open-source... but I digress.

But the point is that a large commercial customer typically prefers a contractually-obligated entity to perform front-line maintenance and support -- they often want to be insulated from the community, unless they already have enough of a brain-trust invested in the community (which is historically pretty rare).

correction

[Stu Charlton]

This was intended to be a response to the grandparent; I realize the parent was defending Oracle.

very insightful

[Stu Charlton]

This is exactly what Oracle is doing. SAP is a ripe target -- they're doing well, but they're a lumbering giant, without the competitive zeal that Larry brings. Having said that, the sight of 10,000 Germans targeting you can be pretty daunting. :-)

I might add that Oracle is hedging this with their investment in their Fusion middleware. It's clear the Fusion strategy is a distraction; it's not their main thrust, otherwise they'd have much tighter timelines. But it's just enough to keep BEA and IBM on their toes -- enough to give BEA a headache due to its relative size, enough to trounce Sun where needed, but not enough to displace IBM. There remains the risk that there will be a middleware renaissance due to software-as-service, SOA, etc., where companies will realize they don't have to spend millions on a rip-and-replace with SAP/Oracle apps/Siebel/Peoplesoft.

Thank you

[theolein]

This is the sanest reply I've yet to read in this dreamfest. Oracle would not buy DB software to compete against what they already own. Oracle would buy DB software to kill a competitor in the application space, since SAP is squarely where Oracle wants to be but doesn't look like they'll be getting because of the chaos of their peoplesoft and siebel takeovers.

However, all is not lost. SAP can continue to run on Oracle, MS SQL server and DB2, none of which Oracle is going to kill in the near future, and SAP could certify Postgres if they wanted a free/open alternative.