Slashdot Mirror
Oracle Lines Up Unbreakable MySQL
munchola writes "MySQL CEO, Marten Mickos, has revealed to CBRonline that Oracle has threatened to provide support for MySQL and is already distributing the open source database. "They have hinted to us that they will," said Mickos, indicating that the database giant is planning to repeat its October 2006 Unbreakable Linux plan, which saw it undercut Red Hat with enterprise Linux support. Despite the competitive threat, Mickos is unmoved. "I hope they do that," he said, noting that it would be seen as an endorsement of the open source database.""
Oh man, how low can you go? Providing support? How DARE they!
Really though, I think people will see it as an endorsement (and more so, people might think that Oracle is losing faith in its flagship product). It's one thing to provide support for Linux, but MySQL is directly competing with Oracle (to a degree). I really don't know what message they're trying to send here, but if it's that people should buy Oracle, I really don't see how this will help.
Anyway, competition is good. If Oracle thinks it can provide better service than MySQL for, well, MySQL, let them! It'll only foster better service on both sides.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
They're not aimed at the same markets. I haven't followed this too closely, but I assume the reason Oracle is interested in MySQL at all is that they're somewhat complimentary products. MySQL is great if you want a lightweight, fast database that doesn't need to be terribly robust.
I doubt MySQL is ever going to have the sort of PL/SQL support Oracle does, and you're not likely to see things like enterprise-class clustering, data partitioning, replication, and so forth. If you added all that to MySQL, it'd wind up just like Oracle - big, complex, and expensive. They occupy opposite ends of the spectrum.
And for what it's worth, I've got an Oracle database on a modest single-processor AMD server with a single hard drive handling about 20 inserts per second with R-tree spatial indexing and it keeps up just fine, with a bit of tuning. Given a real server with multiple drives I'd be able to optimize things much better, but it's just a testbed.
Comparing MySQL to Oracle is a little like comparing a high-performance motorcycle to an M1A2 tank. They'll both get you from point A to point B, but with different levels of cost and safety.
As for Oracle support, it was the main thing we looked forward to at first (this was the mid-90's); but it, too, got worse over time. I would not trust Oracle to properly support MySQL, especially since they have no motivation to push it, and they are not the developers (and in fact are in competition with them).
Dog is my co-pilot.
MySQL make money on support and nothing else. They give the software away for free.
>"Serious question: What exactly is the advantage of Oracle over SQL Server? I asked that to >an Oracle DBA once, and he just got red in the face and stammered about having more options >to configure things the way he wanted. I asked what exactly he configured, and basically >got a lecture on Microsoft being evil. I then asked if he thought Larry Ellison was a >saint, and the conversation just continued to devolve.
>Serious question: why is Oracle considered so much better that SQL Server?"
If you ever run a LARGE datbase at the enterprise level, you will see the difference very quickly. When you are dealing with thousands or tens of thousands of users are millions of records, Oracle will kill SQL Server on performance and response time.
Also as already noted Oracle doesn't limit you to using a Windows server the way SQL Server does.
Having used various versions of Oracle, MySQL, SQL Server, and (God help me) even on occasion Access for the database behind various applications in different jobs, the only 2 I would recommend are Oracle and MySQL depending on the size of the database and the budget of the business buying the product. For small businesses that I have worked in before MySQL is great; it's free, and works well unless you are talking about large data sets or large numbers of users at the same time. For enterprise level systems like those used in government or extremely large organizations give me Oracle any day, but then you are dealing with budgets large enough that the cost of Oracle is easily dealt with.
On the other hand, Oracle 10g is overkill for many shops. MySQL is a great solution for many small databases, and Oracle Support now offers some more legitimacy to the product.
I've seen a number of shops with a situation like this:
Customer: "We're a small shop. We need an RDMBS. We can't afford a DBA. The sales rep said the Oracle Installer is easy to use, and I can install Oracle on my own.
But to install the Oracle *client* , I need to download 3 ISOs, install Xwindows on the server, tunnel Xwindows over SSH. While installing the Oracle Server, the installer crashed out halfway through due to some Java bug. When I tried the installer a second time, the installer refuses to proceed and says that this database already exists.
I called your support line urgently for help, and was transferred not once, not twice but SIX times before they threw my case over over to some department called 'Customer Care' because of a problem with my 'entitlement'. This is my first time calling Oracle Support, so forgive me if I don't understand your byzantine phone support.
I opened this case last Thursday. Today is Tuesday, and I only just heard back from the entitlement department--- I called Saturday, but was told I had to call back Monday (I thought I said this was urgent)--- they finally got back to me with the proper license.
Now that I have the license, can someone please help me with the problem I ran into 5 days ago?
While I was waiting for this problem, my friend came over, installed MySQL in 5 minutes, and created a basic data model in 30 minutes. I can do basic data changes with phpMyAdmin. THIS is what I need. Please tell me why I need to spend $10K on some Oracle 10g Support Licenses?"
"Can of worms? The can is open... the worms are everywhere."
Microsoft SQL Server (which is Sybase in diguise) has an in-memory lock structure; if your transaction acquires too many row locks, your locks are escalated (to page locks or table locks). While these rows are locked, readers are blocked.
Because of this, your are encouraged to keep your SQL Server transactions as short as possible. By default, isql DML commits after every statement, and you must use a BEGIN TRANSACTION/COMMIT if this is not what you want.
Oracle does not use a memory structure for row locks, and Oracle never escalates a lock (although lock types can be converted). Oracle records a pre-DML image of the row in a "rollback" or "undo" area, and any SELECTS against uncommitted DML will silently pull from the old version.
This has a few important implications... you can have long-running transactions and still query the tables safely; transaction volumes are limited not by memory but by disk space; unlike isql, sqlplus requires a "commit" for DML by default; and the "rollback" mechanism has been improved with "undo" segments to allow you to time-travel the database (i.e. show me the contents of this table 3 hours ago).
Synopsis: if you need simultaneous, non-blocking access to the database, steer away from SQL Server (and probably DB2 as well, if I've read correctly).
Postgres is fully ACID compliant
As is MySQL.
has mature support for just about everything
It lacks anlaytic functions.
"Postgres, the only other threat on the first point, was nullified with Oracle's acquisition of the only backend to it with atomic commits"
No, it was the innodb for MySQL that Oracle acquired, this has nothing to do with PostGresQL. Unlike MySQL PostgresQL has always had attomic commits.
If SQLLite has stored procedures, triggers, clustering, job scheduling, remote tables, and user-defined partitioning, then you've something to talk about.
Otherwise, STFU.
Thanks.
Informative? How ironic :-(
Microsoft SQL Server (which is Sybase in diguise)
How many times do we have to repeat it? This was true for old versions, there's not much left in from Sybase nowadays in SQL Server. Please get yourself informed instead of perpetuating wrong informations: http://blogs.msdn.com/euanga/archive/2006/01/19/51 4479.aspx
has an in-memory lock structure;
I have no clue why you point out that the lock structures are in-memory, which is btw good from a performance standpoint, but it doesn't imply anything in how the locking model works.
if your transaction acquires too many row locks, your locks are escalated (to page locks or table locks). While these rows are locked, readers are blocked.
First of all I must point out that readers are, of course, blocked only if the locks they are trying to get are not compatible with other locks being held on the same resource. The simplest case is when a writer has an esclusive lock which is incompatible with a shared lock trying to be granted to a reader. What is important, though, is that this is a perfectly valid model which is very useful in many scenarios. Furthermore it has been extensively documented at the theoretical level for dozens of years including the locking hierarchy escalation model to consume less resources.
Please se also my other comments at another post about this: http://developers.slashdot.org/comments.pl?sid=219 402&cid=17807944
Because of this, your are encouraged to keep your SQL Server transactions as short as possible.
It's not because of this, it's because if your scenario needs such a transactional isolation, it means you have to block and it follows that you need to hold locks for short periods if you want more concurrency.
By default, isql DML commits after every statement, and you must use a BEGIN TRANSACTION/COMMIT if this is not what you want.
Yes, and I'll argue that it's a good idea for several reasons.
First of all, let me clear this out, it is a good reason in a system that implements only locking (no row versioning) because people may leave uncommitted transaction blocking other transactions and the regular maintenance of write-ahead logs.
Secondly, even using a row versioning mechanism you can have problems leaving uncommitted transactions. More precisesly logical problems. What if you update some important metrics and forgot to commit? Maybe someone else makes some decisions based on the previously committed values instead on the new ones. This may or may not have a dramatic impact in your process.
Thirdly, it is required in transactional theory to mark all multi-statement transactions with a begin work and either a commit or rollback work. The way some database systems works is just by opening a transaction behind the scenes which is absolutely not intuitive. Expecially for people learning and when faced with immediate checking transactions (eg. primary key violation, what happens? has the transaction rolled back or only the last command?).
Oracle does not use a memory structure for row locks, and Oracle never escalates a lock (although lock types can be converted). Oracle records a pre-DML image of the row in a "rollback" or "undo" area, and any SELECTS against uncommitted DML will silently pull from the old version.
Again, it doesn't matter whether it's a memory structure or not, nor if it's implemented using logs. It's just a row versioning model, another well known theory for decades. Perfect in many situations, like reporting, but incorrect in many other (think at the classic banking account scenario).
This has a few i
This behavior is perfectly valid. Oracle does the same thing. This is a feature: you, the user, can choose to ROLLBACK or continue on error. Would you want a typo to abort a transaction during interactive use?