Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Common Oracle RDBMS Misconceptions

Re: Common Oracle RDBMS Misconceptions

From: Stephane Faroult <sfaroult_at_oriole.com>
Date: Tue, 26 Jun 2001 12:52:25 -0700
Message-ID: <F001.00338E38.20010626122623@fatcity.com>

"Jesse, Rich" wrote:
>
> Hi Jeremiah,
>
> First, I believe it's a misconception that on a Unix system there can be no
> data lost in an Oracle DB from a system crash. This HAS to be a function of
> "syncer", doesn't it? And, therefore, until syncer decides any buffer
> writes actually go to disk, transactions can be toast. Granted, this is a
> very short time, but the possibility would still exist for a standalone
> Oracle DB, especially for one with a high transaction count. But I haven't
> seen any "official" info, whether true or false, from Oracle about this.
> Comments, anyone???
>
> Second, I hope you're going to have explanations and/or qualifications (even
> brief ones!) about the misconceptions somewhere on your website? There's a
> few in your list that have me intrigued!
>
> Thanks!
> Rich Jesse System/Database Administrator
> Rich.Jesse_at_qtiworld.com Quad/Tech International, Sussex, WI USA
>

I got my information 15 years ago, but ... In fact, Oracle used to claim that they were using some undocumented Unix system calls (fflush() would have looked fine to me, but it musn't be subtle enough) to force Unix to sync and to return 'Committed' when your transaction is actually written to disk (I'd like to precise to the redo log files but they weren't any then). I have indeed met some systems where the said calls had probably not been implemented (or the Oracle charm offensive had not be enough to have it disclosed) and it was specifically specified in the installation guide that you HAD to use raw devices if you wanted to be certain not to lose a transaction. In fact 'lost transaction' doesn't mean that you do not lose any update, it just means that once you have got the acknowledgment from Oracle that it has been validated your change is safe.

Concerning misconceptions, I find the topic interesting but tricky. There are some obvious misconceptions. There are also misconceptions today which were the plain truth some releases ago (some versions ago sometimes) - and may no longer be misconceptions in the future, so they have to be stamped with a version number. Oracle themselves have originated a number of misconceptions (eg, version 6.0 'automatically increasing extent size by a factor of 1.5 will solve fragmentation problems' - for a while, even rollback segments were submitted to the PCTINCREASE rule, totally insane as they soon noticed). Some good ideas never take off, or are dumped. Curious to find out how many of Oracle9i fancy features will prove, in the long term, to have been misconceptions. I guess I am growing more and more sceptical.

My 0.02 cents.

-- 
Regards,

Stephane Faroult
Oriole Corporation
Voice:  +44  (0) 7050-696-269 
Fax:    +44  (0) 7050-696-449 
Performance Tools & Free Scripts
--------------------------------------------------------------
http://www.oriole.com, designed by Oracle DBAs for Oracle DBAs
--------------------------------------------------------------
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Stephane Faroult
  INET: sfaroult_at_oriole.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Tue Jun 26 2001 - 14:52:25 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US