Well, if you ask many damagement types, they would say it's a myth. :) -----Original Message----- Sent: Monday, March 18, 2002 12:58 PM To: Multiple recipients of list ORACLE-L
John, Yes, and I could kick myself for not thinking of this, mirrors can be a most excellent alternative to backups both production and after a recovery. Of course, it can be an expensive alternative as it requires you to have 2x disk space... :-) But disk is cheap, right...? Or is that yet another Urban Legend??? RF Robert G. Freeman - Oracle8i OCP Oracle DBA Technical Lead CSX Midtier Database Administration The Cigarette Smoking Man: Anyone who can appease a man's conscience can take his freedom away from him. -----Original Message----- Sent: Monday, March 18, 2002 1:18 PM To: Multiple recipients of list ORACLE-L Hi all, Notice the renamed heading - this thread has really taken off! Coming back to the issue: While I agree that you should not open the database until after you backup (hot or cold), I am still rooting for a hot backup. If you know the application well enough, you can perform 'selective hot backup' of a required set of tablespaces that you know will be changed, and continue hot backup of the others after the database is opened up. In a cold backup situation, the whole database is down for backup (including large TEMP tablespaces - 13Gb out of 130 Gb on one of my Production Apps databases!) for a longer duration than is necessary, which does not look too good on your availability reports. (And also remember to switch logfiles so that archivelogs are generated prior to release to users). Having said all that, a soft mirror that can be used exclusively for backup is invaluable. The whole database can be put in backup mode for a short time, the mirror 'broken' and the database backup ended. The mirror can then be used for backup to tape. In addition to this, you also have an online backup available (until the resilver starts) and you work off this disk backup for producting clones. Let me say that again - Invaluable! John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Grace - Getting something we don't deserve Mercy - NOT getting something we deserve Click on 'http://www.needhim.org' for Grace and Mercy that is freely available! ** The opinions and statements above are entirely my own and not those of my employer or clients ** > 1. You do not open the database to users until AFTER you do a > backup (hot or > cold, dosen't mater) at point t2. > > 2. There is a method of recovering a database (8i +) after > RESETLOGS has > been > issued with archived redo logs. I discussed it in my DBA > > > * You *have* to take a COLD backup of the database after using > > resetlogs. > > > (Not required - a Hot backup and archive logs is > adequate. All hot > > backups / > > > archive logs prior to that are invalid, though...) > > > > Consider the following: > > > > Time: > > > > t0: database restored > > t1: database opened with RESETLOGS > > t2: hot backup started ( database in archive log mode ) > > t3: users input very important transactions > > t4: database crashes, and must be restored > > > > How will you recover the transactions from time t3? > > As long as the online redologs are available, this should be > no problem. I > have successfully recovered databases where a log switch did > not occur and > recovery had to use an online redo log. (I am assuming that the lost > datafiles will be restored from this hot backup fresh off the tapes) > > On the other hand, if the online redolog is hosed you have lost the > transactions anyway, _regardless_ of the fact that a Cold > backup was taken. > Then you will have to go back to the _previous_ incarnation > and redo the > restore and then perform a ccf/resetlogs (i.e. back to square > one). If you > have a Cold backup, you restore the cold backup and go on > with life. I.e. in > both cases (availability of cold or hot backup, lost online > redo log), you > have lost transactions... > > Additionally, with a Hot backup and depending on what was > lost, you can at > least perform tablespace/datafile recovery . With a cold > backup, you will > have to restore the whole database.... > > The point I was trying to make was that a Cold backup after a > RESETLOGS does > not serve anything. Maybe there is still a gotcha I have not > been able to > figure out, so Backup/restore Gurus: take a bash at this > logic! I would love > to be corrected. > > (Btw, the previous recovery scenario was on 7.3.4 - things could have > changed since, and I have not been able to test that out...) > > > John Kanagaraj > Oracle Applications DBA > DBSoft Inc > (W): 408-970-7002 > > Grace - Getting something we don't deserve > Mercy - NOT getting something we deserve > > Click on 'http://www.needhim.org' for Grace and Mercy that is freely > available! > > ** The opinions and statements above are entirely my own and > not those of my > employer or clients ** > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: John Kanagaraj > 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: Freeman, Robert > 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: John Kanagaraj 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: Freeman, Robert 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: Ball, Terry 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).
