I personally think that the blog author's view is a bit narrow, not yours :)
In any environment, saying that disabling auto-commit is a very bad idea is
at best a risky statement to make. It assumes that people don't know how to
use databases. Perhaps this attitude is more common in the SQL server
world, I don't know. When you start a transaction, you need to end that
transaction. Having a basic understanding of how transactions works is
probably one of the corner stones of being able to call yourself a DBA or a
database developer.
I, for one, would never consider enabling auto-commit for any serious
database application. It restricts what you can do in many ways. I'd want
control over when and how things are committed. What if you want to
validate your data before committing? Nope, you can't, it's already done.
I guess it's a different world out there in SQL server land.
What really got me was this: "The blocking eventually clears up on its own
when the app randomly issues a COMMIT, typically for unrelated reasons." He
must be dealing with some funny applications on his SQL server databases.
I can honestly say I'm glad I never had to deal with it. Always been 100%
Oracle. And the more I read about SQL server, the more glad I am that I
don't have to deal with this :)
On Wed, Mar 14, 2018 at 10:57 PM, Rich J <rjoralist3@xxxxxxxxxxxxxxxxxxxxx>
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:
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
