Comments on: EnterpriseDB’s itemized claims of Oracle compatibility http://www.dbms2.com/2008/07/07/enterprisedbf-oracle-compatibility/ Choices in data management and analysis Thu, 09 Feb 2012 13:48:12 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: Paul Johnson http://www.dbms2.com/2008/07/07/enterprisedbf-oracle-compatibility/#comment-117913 Paul Johnson Wed, 22 Apr 2009 13:58:43 +0000 http://www.dbms2.com/?p=457#comment-117913 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. 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.

]]> By: Serge Rielau http://www.dbms2.com/2008/07/07/enterprisedbf-oracle-compatibility/#comment-90102 Serge Rielau Tue, 08 Jul 2008 11:25:27 +0000 http://www.dbms2.com/?p=457#comment-90102 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 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

]]> By: Daniel Weinreb http://www.dbms2.com/2008/07/07/enterprisedbf-oracle-compatibility/#comment-90094 Daniel Weinreb Tue, 08 Jul 2008 10:44:35 +0000 http://www.dbms2.com/?p=457#comment-90094 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. 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.

]]>