isn't that supposed to be flashback query? :) 

--- Gene Sais <[EMAIL PROTECTED]> wrote:
> maybe 10i will allow table pt in time recovery :)
> 
> >>> [EMAIL PROTECTED] 05/25/02 05:53PM >>>
> you mean the export? it's a lot easier to recover a single table from
> an export and let everyone else keep working. AFAIK, Oracle still
> doesn't do table-level recovery, the lowest granularity is
> tablespace.
> 
> I could be wrong.
> 
> Also, exports are good at letting you clone users and application
> schemas
> 
> --- Kevin Lange <[EMAIL PROTECTED]> wrote:
> > If you truely mean that ALL of your databases are in ArchiveLog
> Mode,
> > why
> > would you do that to your Test and Dev databases ?
> > 
> > -----Original Message-----
> > Sent: Friday, May 24, 2002 2:33 PM
> > To: Multiple recipients of list ORACLE-L
> > 
> > 
> > my backup strategy, fwiw:
> > 
> > prod - cold monthly, hot 2x week, exp weekly.
> > test - cold, hot, exp occassional, always can refresh from prod.
> > dev - cold & hot occassional, exp daily.
> > 
> > all dbs are in archivelogmode!
> > 
> > gene
> > 
> > >>> [EMAIL PROTECTED] 05/24/02 03:04PM >>>
> > lets not forget the classic "exp".
> > 
> > 1. Production database (where you can't lose a single
> > transaction) - ARCHIVEMODE absolutely
> > 
> > 2. Development database (few hrs of transactions ok to
> > lose) - cold backups
> > 
> > 3. Development database (no schema changes, say an
> > application is being developed with a tool such as
> > using Oracle designer) - a simple 'exp un/pwd' of the
> > user, is the simplest, quickest, lightest, least
> > headache,... may also be considered.
> > 
> > Keith
> > 
> >  
> > 
> > Date: Fri, 24 May 2002 09:12:02 -0800 
> > To: "Multiple recipients of list ORACLE-L"
> > <[EMAIL PROTECTED]> 
> > Reply-to: [EMAIL PROTECTED] 
> > Address  | Add to Address Book 
> > Organization: Fat City Network Services, San Diego,
> > California 
> >  
> >          
> > Hi Tim and Connor, 
> > 
> > Thanks you all for your very helpful feedback.  I do
> > appreciate it very much.  In fact, we are in
> > development at this point, so the database is small
> > and transaction volume is very low.  Therefore, my
> > choice for primary backup method is the cold backups. 
> > However, to safeguard against unsual things, which
> > might happen to the database, I will take your advice
> > to run my database in ARCHIVELOG mode. The hot backup
> > will be used.  Again, thanks for your very quick
> > responses.  
> > 
> > Regards, 
> > 
> > Trang 
> > 
> >   Tim Gorman <[EMAIL PROTECTED]> wrote: 
> > 
> > Trang,
> >  
> > Theoretically, the online redo log files are be
> > necessary, but the world has a habit of making a
> > shambles of the theoretical.  Let's say, in the event
> > that you automate your Friday script, you'll probably
> > come to realize that SHUTDOWN IMMEDIATE is far from
> > perfect (as well as far from immediate!).  Over time,
> > you'll probably construct some kind of "fail-safe"
> > mechanism to SHUTDOWN ABORT if the initial SHUTDOWN
> > IMMEDIATE doesn't shut down after a period of time. 
> > Pretty standard thing that DBAs have been writing for
> > years.  Hopefully, after the SHUTDOWN ABORT they also
> > STARTUP RESTRICT and then SHUTDOWN NORMAL, but you
> > can't count on it...
> >  
> > So, here's the point:  what if you take a cold backup
> > in NOARCHIVELOG mode after a SHUTDOWN ABORT (that
> > should have been a SHUTDOWN IMMEDIATE and wasn't) and
> > you have *not* backed up those online redo log files? 
> > Answer: unusable backup.  So, back up everything:  all
> > datafiles, controlfiles, and online redo logfiles. 
> > The latter are not too big anyway -- what's the point
> > of excluding them?
> >  
> > It is wise to take a cold backup after a clean
> > shutdown, but you can even get a valid backup after a
> > SHUTDOWN ABORT or a crash if you've backed up the
> > online redo archive log files.  When you restart
> > Oracle, an instance recovery will occur automatically,
> > and you might not even know it.  Just be certain that
> > the instance is truly "dead" when you take your "cold"
> > backup...
> >  
> > With regards to switching between ARCHIVELOG and
> > NOARCHIVELOG, it's a waste of effort from a
> > recoverability standpoint.  At most it may be
> > interesting, but as soon as you switch out of
> > ARCHIVELOG mode, nothing you've done while in
> > ARCHIVELOG mode is valid anymore.  Leave it one way or
> > the other, and then leave it...
> >  
> > ...just my $0.02...
> >  
> > Another $0.02:  use RMAN for your cold backups.  Then
> > you won't forget anything, because RMAN will remember
> > for you...
> >  
> > Hope this helps...
> >  
> > -Tim
> > ----- Original Message ----- 
> > To: Multiple recipients of list ORACLE-L 
> > Sent: Thursday, May 23, 2002 5:33 PM
> > 
> > 
> > Hi All,
> > 
> > I need to perform a consistent backup for my whole
> > database every Friday by using operating system
> > utilities.  My database has been currently operating
> > in NOARCHIVELOG mode, so the only files need to be
> > backed up are datafiles, control files, the
> > initialization parameter file and other oracle product
> > initialization files (Based on Oracle8.1.6 Backup and
> > Recovery Guide).  Since the files in this type of
> > backup are all consistent and do not need recovery, so
> > the online logs are not needed.  Since online redo
> > logs is very crucial for recovery, so my question is
> > do I need to back up the online redo log files as I
> > choose to perform cold backup type for my entire
> > database weekly?  Here is step by step what I did to
> > back up the whole database:
> > 
> > after the database was closed cleanly and all the
> > above mentioned files had been backed up into the
> > tape.  I had to restart the database and mount but not
> > open, then switched between NOARCHIVELOG mode to
> > ARCHIVELOG mode in order to archive the online redo
> > log files.  Finally, I copied all archived redo log
> > files into the tape while the database was open and
> > operated in ARCHIVELOG mode.  when it was all done, I
> > then switched  the database back to NOARCHIVELOG mode.
> >  Just wondered whether my procedure to perform a whole
> > consistent database backup is correct?  Am I safe to
> > this point? Your help is greatly appreciated it. Your
> > help is greatly appreciated.
> > 
> > Thanks in advance,
> > 
> > Trang
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > LAUNCH - Your Yahoo! Music Experience
> > http://launch.yahoo.com 
> > -- 
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com 
> > -- 
> > Author: Keith Peterson
> >   INET: [EMAIL PROTECTED] 
> > 
> > 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: [EMAIL PROTECTED] (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).
> > -- 
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com 
> > -- 
> > Author: Gene Sais
> >   INET: [EMAIL PROTECTED] 
> > 
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Rachel Carmichael
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to