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 <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:
https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/
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:
..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
--
//www.freelists.org/webpage/oracle-l
