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.
From: Noveljic Nenad <nenad.noveljic@xxxxxxxxxxxx>
Sent: Thursday, March 15, 2018 7:54 AM
To: andysayer@xxxxxxxxx; arian@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: Thoughts on implicit/auto COMMITs
The setting is called the read_committed_snapshot which is set to off by
default. This means that readers are blocking writers. Some applications might
even rely on this behavior.
After setting read_committed_snapshot to on SQL Server will start to behave
like Oracle in this respect. Row versions will be stored in the tempdb in such
case.
Nenad
HYPERLINK
"https://urldefense.proofpoint.com/v2/url?u=http-3A__nenadnoveljic.com_blog_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=N2hWu5HFsaIjmMkjQbnlokJ7uinNZMgPVk8rqPT9esM&m=N2jhkTXmnzLLf0vy6CeiJ1kcmV1PW1GK0w_vcN7wS4w&s=vVgM07ureLRUyGe1dgJVpTmqbIigwSzNrIypiwvOexw&e="http://nenadnoveljic.com/blog/
From: HYPERLINK
"mailto:oracle-l-bounce@xxxxxxxxxxxxx"oracle-l-bounce@xxxxxxxxxxxxx ;
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Andy Sayer
Sent: Donnerstag, 15. März 2018 12:19
To: HYPERLINK "mailto:arian@xxxxxxxxx"arian@xxxxxxxxx
Cc: HYPERLINK "mailto:oracle-l@xxxxxxxxxxxxx"oracle-l@xxxxxxxxxxxxx
Subject: Re: Thoughts on implicit/auto COMMITs
In ye olde regions of SQL Server land, writers block readers. This has spawned
many silly workarounds like
Commit constantly
If a transaction is open for more than a second it must be killed
I believe there is some setting in more recent versions to prevent this. The
workarounds are so blindly followed as best practise that the greener grass is
a mystery to some.
Obviously this just doesn’t apply in the sane land of Oracle, writers don’t
block readers.
Regards,
Andrew
On Thu, 15 Mar 2018 at 09:13, Arian Stijf <HYPERLINK
"mailto:arian@xxxxxxxxx"arian@xxxxxxxxx> wrote:
Hi,
in my opinion this breaks the A(tomicity) of ACID.
E.g. a transaction consisting of two dependent inserts (Parent/child),
and the first insert is commited before the second, then the database
crashes.
Regards,
Arian
On 14-Mar-18 16:57, Rich J wrote:
Hey all,
As a solo DBA responsible for a number of SQL Servers in addition to
Oracle, I try to read up on both. One of the (more respected) SQL
Server team blogs had this entry:
HYPERLINK
"https://urldefense.proofpoint.com/v2/url?u=https-3A__www.brentozar.com_archive_2018_02_set-2Dimplicit-5Ftransactions-2Done-2Dhell-2Dbad-2Didea_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=N2hWu5HFsaIjmMkjQbnlokJ7uinNZMgPVk8rqPT9esM&m=N2jhkTXmnzLLf0vy6CeiJ1kcmV1PW1GK0w_vcN7wS4w&s=PyZyN7Prv057c2HZgi0EyA2t1MeBzR9TL1RSIhYyAeo&e="https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/
..where they advocate the default auto-commit because otherwise the
row (or page, or table) is locked should someone forget to COMMIT.
This seems like an extraordinarily bad idea for anything but ad-hoc or
one-off DML (without getting into a sidebar on that particular
practice), whether Oracle or SQL Server or whatever.
Or is it just me and some old-fashioned narrow RDBMS thinking?
Rich