b/c the dba has to develop and test on occassion :). i like all dbs the same. oracle
is much friendlier to various recoveries in archivelogmode. besides, i generate <
.01% of the archives i generate in prod. i can afford a few mb. again, this is my
strategy, one of many. whether its best or worst, its the one i feel most comfortable
w/.
hth,
gene
ps. exports are very impt to developers. its the easiest way to restore 1 object.
>>> [EMAIL PROTECTED] 05/24/02 04:03PM >>>
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 hat's the point
of excluding them?
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
--------------------------------------------------------------------
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).
