RE: Thoughts on implicit/auto COMMITs
Date: Thu, 15 Mar 2018 14:01:24 +0000
Message-ID: <775_1521122496_5AAA7CC0_775_7768_1_ECDEF0CC6716EC4596FCBC871F48292AB198014B_at_ZRH-S231>
Perhaps it’s worth noting that it’s possible to override the autocommit setting on the session level in the case that you’re doing some ad-hoc DMLs. In fact, there is an option in SQL Server Management Studio that can automatically do that for you.
What you can also do, irrespective of the autocommit database setting, is to explicitly start the transaction, group all of the DMLs in there and finally commit the transaction.
With regard to the locking issues caused by the isolation level, read_committed_snapshot still might be a good option to consider. Of course, after thoroughly clarifying it with the application vendor (that’s exactly what I’ve meant with “Some applications might even rely on this behavior.“).
As a matter of fact, some software vendors, like Atlassian (see https://confluence.atlassian.com/jirakb/health-check-database-isolation-834225506.html ) have already recognized the benefits of row versioning and therefore started to develop the application based on read_committed_snapshot=ON. Also, we’ve massively reduced the locking issues after activating the setting for some of our databases. Again, it has to be a joint effort of the application team and the DBAs.
Nenad
http://nenadnoveljic.com/blog/
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Rich J
Sent: Donnerstag, 15. März 2018 14:24
To: oracle-l_at_freelists.org
Subject: Re: Thoughts on implicit/auto COMMITs
On 2018/03/15 07:34, Jeff Smith wrote:
Brent is a friend and an ex-coworker. He wanted to share the background of this customer's scenario, in case it would help you with yours.
I let Brent know some folks were having...fun...with his take on autocommit.
Jeff
Heh heh heh, I can only imagine. The difference on optimistic vs pessimistic concurrency nailed it though - the default combo of optimistic & implicit transactions makes sense in Oracle, and the default of pessimistic and automatic transactions makes sense in SQL Server. It's when you change only one of those two settings that you're screwed.
The blog post stemmed from an app that had been written by SQL Server people, and then an Oracle guy came in and made a few changes. He switched to implicit transactions without understanding that everybody was doing single-line inserts/updates all over the place in code, not bothering to set transactions. He didn't understand the impact of what he was doing. (Not an Oracle jab by any means - the guy was well-meaning but just not prepared.)
We got called in because performance went straight into the toilet. Even worse, rollbacks were rolling back completely unrelated transactions, and nobody knew why, hahaha.
Ah, that context adds a lot to the assertion. I still disagree that autocommit is a good practice for applications, whether it's Oracle or SQL Server, but I understand where Brent's coming from.
And my intent wasn't to have "fun", but a sanity check for myself. IT changes constantly outside of my narrow focus, and as I've been following Brent's blog for years, that entry offers an opinion that is completely backwards of my understanding of how any modern RDBMS should work.
So, of course, I ask Oracle people about it. :)
Thanks all for the sanity check!
Rich
Please consider the environment before printing this e-mail. Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br>This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.</br>
<br>E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of the Vontobel Group and its affiliates for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.<br/>
</p>
</body>
</html>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Mar 15 2018 - 15:01:24 CET