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.
[EMAIL PROTECTED]
-----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:
- We make a cold backup + verify every weekend, fortunately we are allowed
to stop the database on Saturdays and Sundays.
- We backup all archived logs every night during the week + exports of the
tables to a disk on the server, then copy them to a tape. We never delete
them until a new cold backup is performed, this way I have all the archived
logs copied several times in several tapes every week.
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:[EMAIL PROTECTED]
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.
[EMAIL PROTECTED]
-----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:[EMAIL PROTECTED]
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 bytes
Database mounted.
SVRMGR> recover database until change 10349;
Media recovery complete.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
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: [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.net
--
Author: Fermin Bernaus
INET: [EMAIL PROTECTED]
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: [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.net
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
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: [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).
