July 7, 2008
EnterpriseDB’s itemized claims of Oracle compatibility
Obviously, I’m poking around EnterpriseDB’s site this morning (in connection with their status as my client, actually). Anyhow, we all know that one of EnterpriseDB’s core claims is great Oracle-compatibility — but what exactly do they mean by that? I found a fairly clearly laid-out answer, as of last year, in this white paper and and — even more simply — in this blog post summarizing the white paper.
Categories: Emulation, transparency, portability, EnterpriseDB and Postgres Plus, Oracle
Subscribe to our complete feed!
Comments
3 Responses to “EnterpriseDB’s itemized claims of Oracle compatibility”
Leave a Reply
One thing I’ve always wanted to know is whether EnterpriseDB’s Oracle compatibility includes being compatible with Oracle’s unusual isolation mode. Oracle concurrency control works differently from any other DBMS I’ve ever seen. The fact that read locks do not conflict with write locks sounds great, and sometimes is great, but the consequences of the complete set of rules can be rather counterintuitive, and it’s hard to get true ACID behavior. It seems to me that this would be hard to emulate using an underlying DBMS that works in a more conventional fashion.
Daniel,
Actually Oracle’s unusual isolation mode isn’t all that special anymore. And yes, enterpriseDB does support it AFAIK.
Also let’s not confuse concurrency control with isolation. E.g. IBM Informix IDS achieve “readers don block writers and writers don’t block readers” without the need for Snapshot isolation.
In my experience with Oracle migrations teh vast majority of users, in the end require compatible locking behavior. “statement level isolation” (Oracle’s default) provides only “another shade of grey” compared to “cursor stability” in a multi-statement transaction.
Cheers
Serge Rielau
IBM Toronto Lab
Terdata supports readers/writers not blocking each other through the use of ‘access’ or ‘dirty read’ locks. Without this capability being fully exploited by the DBA through appropriate user views a lot of queries spent time queued and not running, and the user just thinks performance is sucky.