The golden rule when there is a big crash is :
1. Panic
2. Stop panic
3. Fix the problem
- "Hallas, John" <HallasJ_at_logicae.com> a écrit : >
FOR YOUR INFORMATION
>
> ESIS and EPFAL are now part of Logica. The Internet
> email addresses of the staff has changed to the
> following - lastnameinitial_at_logica.com eg
> SMITHK_at_logica.com. Emails using the old format will
> continue to be delivered until 30th June 2001.
>
> David,
> I support what you say about taking your time
> entirely. In fact at any
> interviews I attend backup/recovery question(s)n are
> always asked. My
> standard answer is the at then first thing I will do
> is go for a cup of
> coffee. After their jaws have finished dropping I
> explain how thinking time
> is required etc.
>
> On a similar theme a few years ago I was
> interviewing for a contract DBA
> and he made the statement along the lines of 'you
> are paying me more because
> I have made mistakes before and I have learnt from
> them so you will be safe
> with me'. ( I am sure he phrased it more eloquently
> than that).
> After the interview the senior manager at the
> interview said that he would
> not have anyone as self-obsessed and over-confident
> as that on board. I
> disagreed and said that what the contractor was
> offering was exactly what we
> wanted. We took him on and he fitted in very well.
> This story fits in with
> the concept of getting a coffee and thinking about
> things first, which is
> all about using your experience well.
>
> John
>
> Logica/ESIS Tel 0115 945 6643
>
> -----Original Message-----
> From: David A. Barbour
> [mailto:dbarbour_at_nucentrix.net]
> Sent: 03 May 2001 18:46
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Fwd: please help
>
> Jared,
>
> I think you hit the nail on the head when you said
> "Best
> practice of
> course is to make a backup of your database in
> it's current
> condition
> prior to restoring it."
>
> Too many recoveries are failures because DBAs tend
> to forget
> basics when
> confronted with the pressures from management,
> users, and
> the
> constraints of time (primary key). I made this
> mistake once
> early on.
> Now if I have a possible recovery scenario, the
> first thing
> I do is take
> a deep breath, get a cup of coffee, and THINK
> about what I'm
> going to do
> before I ever touch the keyboard.
>
> Absent all that, I still make a copy of the redo
> logs
> whenever I do a
> backup. Yeah, you could mess up and apply them
> inadvertently, but
> hopefully you will have practiced recovery
> scenarios (see
> "Training a
> DBA" by Kimberly Smith) and be comfortable with
> your tapes,
> disks,
> commands, systems administrator, etc. At least if
> you've
> got them, and
> everything goes to h*%$ in a handbasket, you can
> always give
> 'them' back
> something.
>
> David A. Barbour
>
>
> Jared Still wrote:
> >
> > Dick,
> >
> > Backing up the redo logs can have some serious
> consequences.
> >
> > Let's say you are restoring the database files,
> and a
> number of
> > archived logs to roll forward through.
> >
> > Following that, you are going to roll forward
> through all
> archived logs
> > that are still online, and then through your
> current redo
> logs for a
> > complete recovery.
> >
> > Restoring old redo logs would render this
> strategy
> ineffective.
> >
> > Backing them up can be a good thing, but it
> would be very
> easy
> > to inadvertently wipe out the current ones when
> restoring
> from tape.
> >
> > Best practice of course is to make a backup of
> your
> database in
> > it's current condition prior to restoring it.
> >
> > It would also be prudent to make copies of the
> redo logs
> locally
> > so you don't have to restore them from tape.
> >
> > Jared
> >
> > On Wednesday 02 May 2001 07:24, dgoulet_at_vicr.com
> wrote:
> > > Jonathan,
> > >
> > > It would appear that your friend has hit
> upon one of
> the problems of
> > > hot backups that everyone misses and actually
> Oracle
> recommends against.
> > > That is backing up your online redo log files
> and doing
> that LAST. The
> > > reason is that there are more than likely
> active
> transactions that were
> > > recorded therein and those logs are not
> available. Can
> he complete the
> > > recovery, maybe if he has the remaining logs
> from the
> active system, I'm
> > > assuming he is recovering to somewhere other
> than his
> production system.
> > > Otherwise his only recourse is OTS.
> > >
> > > Dick Goulet
> > > Oracle Certified 8i DBA
> > >
> > > ____________________Reply
> Separator____________________
> > > Author: Jonathan Gennick
> <jonathan_at_gennick.com>
> > > Date: 5/1/2001 8:55 PM
> > >
> > > Fellow list members, I received the following
> email from
> a
> > > reader a few minutes ago. If you skip down to
> where he
> talks
> > > about backup, you'll see that he's in trouble
> with a
> > > database that won't recover. I've already
> suggested that
> he
> > > open a TAR, and that he supply more specifics
> as to
> error
> > > messages and the like, but maybe someone on
> this list
> can
> > > draw some conclusions from what he's told me
> so far. If
> > > you're good at recovery, have a look at what
> he says.
> I'll
> > > post his email address later if he says its
> ok,
=== message truncated ===
Stéphane Paquette
DBA Oracle, consultant entrepôt de données
Oracle DBA, datawarehouse consultant
stephane_paquette_at_yahoo.com
Do You Yahoo!? -- Pour faire vos courses sur le Net,
Yahoo! Shopping :
http://fr.shopping.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: =?iso-8859-1?q?paquette=20stephane?=
INET: stephane_paquette_at_yahoo.com
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: 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 Mon May 07 2001 - 02:47:14 CDT
