That is not correct. SQL Server you need to start a transaction and then
commit or rollback the transaction. You don't need to use an update
statement to undo your work. (If you did SQLServer wouldn't be ACID.) If
you choose to run in autocommit mode then you would need to do such a thing,
but that forgoes one of the major reasons one buys a commercial database
product; for it's atomicity.(a series of statements either work as a unit or
they do not - all or nothing, the end use shouldn't have to program the
undo.)
Jim
"Kevin Krause" <k_krause.no_spam_at_bellsouth.net> wrote in message
news:3L9Y7.118665$BX4.7693026_at_e3500-atl1.usenetserver.com...
> Actually, in SQL Server, there is no concept of a COMMIT (nor a ROLLBACK).
> Quite different approaches in this area. Oracle is likely doing quite a
bit
> more work here, but is giving you options. If you change your mind using
> SQL Server you would have to issue an UPDATE statement to undo your work
> (easier said than done sometimes) or perform a recovery. In Oracle, if
you
> don't like what you see, you issue a ROLLBACK and voila, clean slate.
>
> Besides what has been recommended you could put the table in NOLOGGING
mode
> to get a little closer comparison.
>
> HTH. -Kevin
>
> "Kendall" <kendallwillets_at_yahoooo.com> wrote in message
> news:pan.2001.12.31.10.31.05.466.8939_at_yahoooo.com...
> > In article <5KZX7.36613$Q66.129567_at_NewsReader>, "Garrick Bigwood"
> > <garrickb_at_software360.com> wrote:
> >
> > > Hello,
> > >
> > Looking at the trace files one of the problems with
> > > Oracle seems to be the amount of physical writes done to datafiles and
> > > rollback files(also redo of course), when I look at the SQL Server
trace
> > > files there does'nt to be any writing done.
> >
> > Just to clarify, are you doing a COMMIT after each update? I don't know
> > exactly how SQL server handles these, but you may be right about delayed
> > i/o. A commit should generate some kind of write to disk.
> >
> > Oracle only requires a write to the redo log on commit; any writes to
> > datafiles are from cache flushing, or a checkpoint. If your SGA is too
> > small you're obviously going to see more I/O. Check the SGA and SQL
> > Server's cache size - they should be the same size for a fair test.
> >
> > Also, how many indexes are on the table/column? Is the column NULL
before
> > update?
>
>
>
- WAS CANCELLED BY =======:
Path: news.uni-stuttgart.de!dns.phoenix-ag.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.media.kyoto-u.ac.jp!newsfeed.mesh.ad.jp!osa.uu.net!dfw.uu.net!sea.uu.net!lax.uu.net!news.navix.net!u.n.a.c.4.n.c.3.l.l.e.r
From: "Jim Kennedy" <kennedy-family_at_attbi.com>
Newsgroups: news.admin.censorship,alt.test,comp.databases.oracle.server
Subject: cmsg cancel <3RlY7.624$dK4.7119_at_rwcrnsc52>
Control: cancel <3RlY7.624$dK4.7119_at_rwcrnsc52>
Date: Wed, 2 Jan 2002 01:56:35 GMT
Organization: Navix Internet Subscribers
Lines: 2
Message-ID: <cancel.3RlY7.624$dK4.7119_at_rwcrnsc52>
NNTP-Posting-Host: 166.102.15.34
X-Trace: iac5.navix.net 1009944084 21023 166.102.15.34 (2 Jan 2002 04:01:24 GMT)
X-Complaints-To: abuse_at_navix.net
NNTP-Posting-Date: 2 Jan 2002 04:01:24 GMT
X-No-Archive: yes
Comment: Dude, where's my NewsAgent?
Xref: news.uni-stuttgart.de control:40277458
autocancel
Received on Tue Jan 01 2002 - 10:54:23 CST
