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] > > 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: Kevin Lange > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing > Lists > === 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).
