| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Change based recovery
Well I did not tell you that I am regularly backing up all archive logs during the day as well, so that I am not dependant of just one backup made at night, just in case all archived logs were lost because no, we can not afford all people be entering last day's data again, we don't keep trace of most of them and we would have so many problems I don't want to think about that situation!
Thanks to your message I am considering using RMAN :) maybe I'll go for it after summer, if I have the time... thanks again! I suppose it has got the ability to make both incremental and differential backups, but please do not waste your time with me any more, I'll read the manuals when the time arrives!
Regards,
..............................................Fermín Bernaus Berraondo
..............................................
-----Mensaje original-----
De: DENNIS WILLIAMS [mailto:DWILLIAMS_at_LIFETOUCH.COM]
Enviado el: martes, 12 de agosto de 2003 16:39
Para: Multiple recipients of list ORACLE-L
Asunto: RE: Change based recovery
Fermin
Thanks for explaining your situation in more detail. I had a production database in a similar configuration for a couple of years. Just make sure to communicate the risks to everyone involved. The main risk I see is that you are very dependent on the archive logs to bring your database up to date. How much this matters will depend on your application. If users can re-enter data, then the risk is small. If there is no way to recreate the transactions, then the risk is greater. If the risk could be mitigated with more disk space, then this can be a pretty strong selling point to management if it was presented in a way that they could understand it.
The main advantage RMAN could bring to your situation is the ability to perform incremental backups during the week. Only the changed blocks are backed up so for many databases, a much smaller file is produced.
Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Tuesday, August 12, 2003 4:24 AM
To: Multiple recipients of list ORACLE-L
Thank you all for your suggestions. I really have no time for downtime during the week, but we have space to keep the archived logs on disk but not a backup (even a partial hot backup) of the database unless I move it to a tape, which is too much time and resource consuming, so here is what I've been doing until now:
I have at least two sets of tapes (15 tapes counting them all) which I reuse every 2 weeks, so I keep 2 verified cold backups + their archived logs for 2 weeks, which has proved enough for now. We store them in a safety fire proof case in a different building.
As for RMAN I've never tried it, do you think it could help me in any way considering my backup strategy?
Thanks!
Fermin.
-----Mensaje original-----
De: DENNIS WILLIAMS [mailto:DWILLIAMS_at_LIFETOUCH.COM]
Enviado el: lunes, 11 de agosto de 2003 16:40
Para: Multiple recipients of list ORACLE-L
Asunto: RE: Change based recovery
Fermin - And it is always a good idea to keep at least the previous backup
to the last. Often this just costs an extra tape, but could be very useful
in the unlikely case there is something wrong with the most recent back.
With backing up once/week, realize that in a recovery situation, if Oracle
cannot read a single archived redo log, recovery stops at that point. Also,
if you are considering changing your backup strategy, you should consider
RMAN.
Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Monday, August 11, 2003 6:24 AM
To: Multiple recipients of list ORACLE-L
I've been reading your messages with much interest. I have some experience with database administration and I have done many tests, but I've not tried what I am going to expose in this message, maybe you can help. We do cold backups on a regular basis (every weekend) then just backup the archive log every day, then delete them every time a new cold backup is done. We have tested it and if all database files (parameters file, datafiles, control files) except for one control file and the archived logs were lost we could recover the entire database issuing the following commands after restoring all missing files and mounting the database:
SET AUTORECOVERY ON
RECOVER DATABASE
ALTER DATABASE OPEN
My questions are:
1 - Could a complete restore be done even if we lost ALL control files? can we recover the entire database from a cold backup provided we have all archived logs until the failure time?
2 - If the answer is yes, what is the advantage of doing on-line backups of datafiles and control files?
Thanks for your answers, I always learn so much from this list!!
Fermin.
-----Mensaje original-----
De: Hand, Michael T [mailto:HANDM_at_polaroid.com]
Enviado el: viernes, 08 de agosto de 2003 18:10
Para: Multiple recipients of list ORACLE-L
Asunto: RE: Change based recovery
Lisa,
The 3rd option (besides shuting down source database and using a controlfile
trace) is to "alter database backup controlfile to 'filename'; ", use this
file, then proceed with the recovery as Venu suggests. I've used this
method on a hot backup to roll the database forward. Also, don't bother
restoring the redo logs as you will be overwriting / recreating them with
the "alter database open resetlogs". One more thing I noticed. Your until
change number looks to me like an archive sequence number rather than the
SCN it needs to be. Hope this helps.
Mike Hand
-----Original Message-----
Sent: Thursday, August 07, 2003 8:21 AM
To: Multiple recipients of list ORACLE-L
Hi Guys and Gals,
We are currently doing some testing to enable us to move our production
database from one unix box to another.
We are running a 7.3.4 db in archivelog mode. The approach that management
want to use is to restore the database on the new server from a backup and
then roll it forward using the archived redo logs.
I have a full cold back up from last Friday. I have restored the datafiles, controlfiles and redo logs onto our test server from the backup tape, and then ftp'd the archived logs over.
I then do -
SVRMGR> startup mount
ORACLE instance started.
Total System Global Area 258304260 bytes Fixed Size 45092 bytes Variable Size 126925024 bytes Database Buffers 131072000 bytes Redo Buffers 262144 bytesDatabase mounted.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: DENNIS WILLIAMS
INET: DWILLIAMS_at_LIFETOUCH.COM
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (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).
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (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).
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (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).
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services ---------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (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). Received on Wed Aug 13 2003 - 04:04:23 CDT
 |
 |