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

Home -> Community -> Usenet -> c.d.o.server -> Re: DBWR and LGWR processes, theoretical question

Re: DBWR and LGWR processes, theoretical question

From: Connor McDonald <connor_mcdonald_at_yahoo.com>
Date: Thu, 31 Oct 2002 22:12:14 +0000
Message-ID: <3DC1AABE.48DE@yahoo.com>


Michael Gast wrote:
>
> Hi 'VBuehringer',
>
> thanks for your response.
>
> vob schrieb:
> > so you have found it out, oracle will never work ...
>
> That is not the point. I used Oracle 7 in a complex project and i was
> very satisfied with it. During the ten years the system is running now
> at the customers side, we only had one time to deal with trouble in the
> database due to a hardware failure and we could recover it. Our fortune
> was that the database was running in redo log archive mode (due to our
> proper setup :-) ). There were other hardware failures but Oracle ever
> could recover the database during startup by itself.
>
> > oracle is a technical perfect system and this are the basics
> > which you only need to understand that they work perfectly for you
> >
> > try to learn the new features and use it to its best
> >
> > few examples :
> >
> > - replace sqlldr with external tables ..
> > - replace rollback segments with undo tablespaces
> > - automatic pga management
> > ....
>
> I working on it. I've just studied the concept of external tables and i
> think they are very usefull to solve different flavours of interface
> problems without having the overhead we had before using tools like
> SQLLDR. An easier administration for the rollback theme by switching to
> a reliable new undo concept and for the PGA would be fine. I'm in
> studying it.
>
> > and don't worry that crash recovery will not work ...because their concept
> > is bad this is ridiculous
>
> I don't think that the crash recovery of Oracle will not work. As i
> mentioned before, this is not the point. What i want to understand is
> what i need to do to avoid data loss in cases as described in my initial
> posting. Therefore i need to understand the underlying concepts.
>
> I feel confident that Oracle is much better than most other database
> management systems if it is not the best one - at most in the really
> important point of storing the data in a very reliable way.
>
> For example, they _have_ redo log files. Some other database systems
> even don't have them. In Oracle i can recover my data to a point of time
> later than i started my last backup. And this feature is implemented
> since at least 10 years and it does its job as i know from my own
> experience - this is superb :-)
>
> But, am i on the right side if i use the redo log file duplexing? How
> many groups do i need (in the past i used two groups for both redo log
> and control files on different physical datastores)? Do i need to do
> anything more? What is with the time gap i described in the initial
> posting? Do i need to care with it? How?
>
> --
> All emails sent to this address are never read and never will be
> answered. Sorry, but until someone cleans up the spam mess, that's the
> way it has to be.
>
> E-Mails, die direkt an diese Adresse geschickt werden, lese und
> beantworte ich nicht. Ich bedauere diesen Umstand sehr, kenne derzeit
> aber keine bessere Möglichkeit, um die Spam-Flut abzustellen.
>
> Mit freundlichen Grüßen / Best Regards
> Michael Gast
> SEPP MED GmbH

An easy way to get your head around it is to think of datafiles as purely as performance enhancement. The redo logs ARE the database - but it would be awfully slow to read them from day1 for the simplest queries. The datafiles are not guaranteed to be up to date - they don't have to be - they are just like a "snapshot" of database at a point in time

hth
connor

-- 
==============================
Connor McDonald

http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue..."
Received on Thu Oct 31 2002 - 16:12:14 CST

Original text of this message

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