Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> REPOST: Re: Oracle and SQL Server
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?
autocancel Received on Mon Dec 31 2001 - 21:19:03 CST