Path: news.easynews.com!easynews!news.he.net!newsfeed.direct.ca!look.ca!upp1.onvoy!onvoy.com!pln-e!spln!dex!extra.newsguy.com!newsp.newsguy.com!drn From: Thomas Kyte Newsgroups: comp.databases.oracle.server Subject: Re: Continu backup of database Date: 10 Oct 2001 06:40:35 -0700 Organization: Oracle Lines: 40 Message-ID: <9q1j4j0j7l@drn.newsguy.com> References: NNTP-Posting-Host: p-120.newsdawg.com X-Newsreader: Direct Read News 2.90 Xref: easynews comp.databases.oracle.server:120819 X-Received-Date: Wed, 10 Oct 2001 07:49:10 MST (news.easynews.com) In article , johan.lorier@nl.abb.com says... > >Hello, > >one of our customers wants to have 'continu' backup, that is: when one >backup has completed, the next one should immediately be started. The >reason for this is that when a complete recovery from tape has to be >done, the data loss should be minimal. >Are there alternatives to achieve this? (Not too expensive ofcourse, >an identical mirror server is not an option). What are the pro's and >con's of this method (loss of performance, certain risks?). Oracle >8.0.6, WinNT Server 4 SP5. > >Regards, > >Johan we call it "archivelog mode". Pretty much all production databases should be running in this mode. Based on your statements -- I'd have to assume you are in NOarchivelog mode. With archivelog mode, when online redo fills up, we copy it to an archive file. You then get it off to tape (the archive). Now, if you have a media failure -- you restore the last backup and apply all of the archives to "catch that file up" to the rest of them. So, read up on backup and recovery, put the database into archive log mode and you are done. In this fashion, data loss should be zero (if you MULTIPLEX your redo log files on 3 or 4 devices and you multiplex your archives and you get your archives copied to another machine/device to prevent a total failure). -- Thomas Kyte (tkyte@us.oracle.com) http://asktom.oracle.com/ Expert one on one Oracle, programming techniques and solutions for Oracle. http://www.amazon.com/exec/obidos/ASIN/1861004826/ Opinions are mine and do not necessarily reflect those of Oracle Corp