FAQ
Hi,

I just appeared in an interview.

When I was asked which filese I will copy for hot backup, I said redo too.

Cause I think they can help us always to recover database upto point of time.

I was pulled a lot, but my only question that if not redo then how
will you recover yr DB upto point of failure, stopped the arguements.

M I true in this case? I have done expoerts in hot backups in
production database.

Can anyone clear my doubts? If u copy couple datafiles in hotback with
begin backup, n yr DB crashes... what will happen? Assume that an
archive log file is generated every 30 minutes and my DB crashed after
15 minutes of Last Archive file generated.

Can I go without REDO Log File ???

Chirag

Search Discussions

  • Zhu chao at Oct 2, 2004 at 4:32 am
    hi,
    If db crash(not corruption), just alter database datafile xxx end
    backup and you can bring up your database.
    If your database corrupted(but online logfile still ok), then you
    can use the online log as the last archived logfile.
    Anyway, it is both ok whether you backup the online redo log file or
    not. Assume you are using "alter system switch logfile/archivelog
    current" and then copy the generated logfile.

    Regards
    On Sat, 2 Oct 2004 14:10:26 +0530, Chirag DBA wrote:
    Hi,

    I just appeared in an interview.

    When I was asked which filese I will copy for hot backup, I said redo too.

    Cause I think they can help us always to recover database upto point of time.

    I was pulled a lot, but my only question that if not redo then how
    will you recover yr DB upto point of failure, stopped the arguements.

    M I true in this case? I have done expoerts in hot backups in
    production database.

    Can anyone clear my doubts? If u copy couple datafiles in hotback with
    begin backup, n yr DB crashes... what will happen? Assume that an
    archive log file is generated every 30 minutes and my DB crashed after
    15 minutes of Last Archive file generated.

    Can I go without REDO Log File ???

    - Chirag
    --
    http://www.freelists.org/webpage/oracle-l
    --
    Regards
    Zhu Chao
    www.cnoug.org
    --
    http://www.freelists.org/webpage/oracle-l
  • Jeremiah Wilton at Oct 2, 2004 at 5:23 am

    On Sat, 2 Oct 2004, Chirag DBA wrote:

    When I was asked which filese I will copy for hot backup, I said redo too.

    Cause I think they can help us always to recover database upto point of time.

    I was pulled a lot, but my only question that if not redo then how
    will you recover yr DB upto point of failure, stopped the arguements.
    Askdba removed from the distribution.

    If you can win the argument, you must be right! Anyway good for you
    for checking on this even though you convinced the interviewers you
    were right.

    The reason that many people recommend against backing up online logs
    during hot/cold backup is twofold:

    If you back up the current online log, you have no guarantee of
    obtaining a clean copy since log writer might be halfway through
    performing a write. You should obtain the most recent log by
    archiving it (archive log current).

    If you restore a backup including the online logs (in their normal
    location) and the controlfile is also restored in the normal location,
    then the restored database can be brought up in such a way that crash
    recovery would take place automatically without prompts, and there
    could be no opportunity to apply archive logs to roll the database
    forward to a future point in time.

    It is likely that you might want to recover past the point in time of
    the backup, thus the online logs would be nowhere near the most
    current logs for the purposes of a restore/recover exercise.
  • Mark W. Farnham at Oct 2, 2004 at 8:49 am
    Just a bit more:

    The first step of recovery is to get a secure copy of whatever the state
    is of the current online redo logs. This is before you restart the instance,
    the files are cold, and it gives you a chance to try again if there is pilot
    error or a physical problem with the machine during recovery. You do this
    before you start hanging tapes or "silvering" from an online backup set. If
    you reach "open resetlogs" and you have a problem, that is when you realize
    you made a silly mistake. I hesitate to call this a backup of the online
    redo logs, since I consider it part of recovery, and see #2.

    It is an unwinnable nearly religious war whether you are better off with
    the online logs on the backup sets. (My particular faith in this matter is
    hotbackups should never include online redo logs, cold backups only if the
    site procedures include step #1 and an alternate reload location naming
    scheme, and only do cold backups if your situation allows time for a
    shutdown normal.) If you do the double dip shutdown (abnormal), startup
    restrict, shutdown normal for cold backups, then no transactions from the
    online logs are needed, so if you happen to reload an entire cold backup
    tape to use for roll forward, all you have done is create risk that the
    online redo logs will be overwritten by a possibly Oracle ignorant computer
    operator. On the other hand, if your "cold backup" is not from a clean
    shutdown, if you try to load it up and start the database you will likely
    need transactions from the online redo logs from the non-clean shutdown. For
    those whose "religion" on this matter differs from mine, I suggest that you
    write the on line redo logs to a separate tape set and see if you ever need
    them in any scenario you can create on your test restore machine. (If you
    don't have a test restore machine, you don't take recovery seriously,
    anyway.) Of course this excludes the well-known fact that the cold backup of
    a shutdown abort is likely to need the online logs, because I advise against
    that particular backup anyway. In the event of a machine crash you have to
    evaluate whether there is time for a complete save before you restart.
    FIRST, get a copy of the online logs just as they are. Then think about a
    complete save set and/or splitting off your third plex before you procedure.
    This is a slippery slope argument where your particular situation and
    resources dictate what you should do. Usually machine crash restarts go
    smoothly because Bill Bridge is a very wise and careful person.

    If you are building internally complete hot backup sets, remember to
    alter system switch logfile after all tablespaces are out of backup, wait
    for archive to complete and include all archived redo logs from the start of
    the first tablespace begin backup through the redo you switched out of after
    the last end backup. If you're paranoid, start one earlier and switch and
    wait twice at the end. These are not really needed, but if the person
    scripting up the copy of arch for the internally complete hot backup set is
    fencepost challenged you still get the right answer.

    (Draw a picture of a barbed wire fence and count the posts and segments of
    fence if you are not familiar with that term.)

    May you sleep well knowing your backup that you never hope to use will work
    because you test it every {day|week|not much longer than that} on your test
    recovery system!

    mwf

    PS: Think about RMAN, but I've got no criticism for those who want to wear a
    belt and braces (suspenders) by having both RMAN backups and "hot" backups.

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Jeremiah Wilton
    Sent: Saturday, October 02, 2004 6:28 AM
    To: Chirag DBA
    Cc: oracle-l_at_freelists.org
    Subject: Re: Question in HOT BACKUP
    On Sat, 2 Oct 2004, Chirag DBA wrote:

    When I was asked which filese I will copy for hot backup, I said redo too.

    Cause I think they can help us always to recover database upto point of time.
    I was pulled a lot, but my only question that if not redo then how
    will you recover yr DB upto point of failure, stopped the arguements.
    Askdba removed from the distribution.

    If you can win the argument, you must be right! Anyway good for you
    for checking on this even though you convinced the interviewers you
    were right.

    The reason that many people recommend against backing up online logs
    during hot/cold backup is twofold:

    If you back up the current online log, you have no guarantee of
    obtaining a clean copy since log writer might be halfway through
    performing a write. You should obtain the most recent log by
    archiving it (archive log current).

    If you restore a backup including the online logs (in their normal
    location) and the controlfile is also restored in the normal location,
    then the restored database can be brought up in such a way that crash
    recovery would take place automatically without prompts, and there
    could be no opportunity to apply archive logs to roll the database
    forward to a future point in time.

    It is likely that you might want to recover past the point in time of
    the backup, thus the online logs would be nowhere near the most
    current logs for the purposes of a restore/recover exercise.
  • Bobak, Mark at Oct 4, 2004 at 8:39 am
    The argument I generally use here is:
    1.) In the case of a hot backup, there is no mechanism
    by which you can get a consistent copy of on-line redo.
    2.) In the case of a cold backup, step 1 is ALWAYS a=20
    clean, normal (non-aborted) shutdown. If that's true,
    then the on-line redo doesn't contain any useful information.

    Given that, never, ever, backup your on-line redo log.

    -Mark

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Mark W. Farnham
    Sent: Saturday, October 02, 2004 9:53 AM
    To: oracle-l_at_freelists.org
    Subject: RE: Question in HOT BACKUP

    Just a bit more:

    The first step of recovery is to get a secure copy of whatever the =
    state
    is of the current online redo logs. This is before you restart the =
    instance,
    the files are cold, and it gives you a chance to try again if there is =
    pilot
    error or a physical problem with the machine during recovery. You do =
    this
    before you start hanging tapes or "silvering" from an online backup set. =
    If
    you reach "open resetlogs" and you have a problem, that is when you =
    realize
    you made a silly mistake. I hesitate to call this a backup of the online
    redo logs, since I consider it part of recovery, and see #2.

    It is an unwinnable nearly religious war whether you are better off =
    with
    the online logs on the backup sets. (My particular faith in this matter =
    is
    hotbackups should never include online redo logs, cold backups only if =
    the
    site procedures include step #1 and an alternate reload location naming
    scheme, and only do cold backups if your situation allows time for a
    shutdown normal.) If you do the double dip shutdown (abnormal), startup
    restrict, shutdown normal for cold backups, then no transactions from =
    the
    online logs are needed, so if you happen to reload an entire cold backup
    tape to use for roll forward, all you have done is create risk that the
    online redo logs will be overwritten by a possibly Oracle ignorant =
    computer
    operator. On the other hand, if your "cold backup" is not from a clean
    shutdown, if you try to load it up and start the database you will =
    likely
    need transactions from the online redo logs from the non-clean shutdown. =
    For
    those whose "religion" on this matter differs from mine, I suggest that =
    you
    write the on line redo logs to a separate tape set and see if you ever =
    need
    them in any scenario you can create on your test restore machine. (If =
    you
    don't have a test restore machine, you don't take recovery seriously,
    anyway.) Of course this excludes the well-known fact that the cold =
    backup of
    a shutdown abort is likely to need the online logs, because I advise =
    against
    that particular backup anyway. In the event of a machine crash you have =
    to
    evaluate whether there is time for a complete save before you restart.
    FIRST, get a copy of the online logs just as they are. Then think about =
    a
    complete save set and/or splitting off your third plex before you =
    procedure.
    This is a slippery slope argument where your particular situation and
    resources dictate what you should do. Usually machine crash restarts go
    smoothly because Bill Bridge is a very wise and careful person.

    If you are building internally complete hot backup sets, remember to
    alter system switch logfile after all tablespaces are out of backup, =
    wait
    for archive to complete and include all archived redo logs from the =
    start of
    the first tablespace begin backup through the redo you switched out of =
    after
    the last end backup. If you're paranoid, start one earlier and switch =
    and
    wait twice at the end. These are not really needed, but if the person
    scripting up the copy of arch for the internally complete hot backup set =
    is
    fencepost challenged you still get the right answer.

    (Draw a picture of a barbed wire fence and count the posts and segments =
    of
    fence if you are not familiar with that term.)

    May you sleep well knowing your backup that you never hope to use will =
    work
    because you test it every {day|week|not much longer than that} on your =
    test
    recovery system!

    mwf

    PS: Think about RMAN, but I've got no criticism for those who want to =
    wear a
    belt and braces (suspenders) by having both RMAN backups and "hot" =
    backups.

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Jeremiah Wilton
    Sent: Saturday, October 02, 2004 6:28 AM
    To: Chirag DBA
    Cc: oracle-l_at_freelists.org
    Subject: Re: Question in HOT BACKUP
    On Sat, 2 Oct 2004, Chirag DBA wrote:

    When I was asked which filese I will copy for hot backup, I said redo = too.
    Cause I think they can help us always to recover database upto point =
    of
    time.
    I was pulled a lot, but my only question that if not redo then how
    will you recover yr DB upto point of failure, stopped the arguements.
    Askdba removed from the distribution.

    If you can win the argument, you must be right! Anyway good for you
    for checking on this even though you convinced the interviewers you
    were right.

    The reason that many people recommend against backing up online logs
    during hot/cold backup is twofold:

    If you back up the current online log, you have no guarantee of
    obtaining a clean copy since log writer might be halfway through
    performing a write. You should obtain the most recent log by
    archiving it (archive log current).

    If you restore a backup including the online logs (in their normal
    location) and the controlfile is also restored in the normal location,
    then the restored database can be brought up in such a way that crash
    recovery would take place automatically without prompts, and there
    could be no opportunity to apply archive logs to roll the database
    forward to a future point in time.

    It is likely that you might want to recover past the point in time of
    the backup, thus the online logs would be nowhere near the most
    current logs for the purposes of a restore/recover exercise.
  • Paul Drake at Oct 4, 2004 at 11:55 am
    NEVER?

    Come on Mark, you should know that one never wants to say "never".

    usually, mostly, generally ...

    Exceptions off the top of my head for your assertion:

    1. prior to applying patchset or performing migration.
    2. to move database to another server and resetlogs is no desired.
    3. Client wants to test disaster recovery restore/recovery without dba

    involvement
    4. It depends ...

    Paul

    On Mon, 4 Oct 2004 09:43:58 -0400, Bobak, Mark
    wrote:
    The argument I generally use here is:
    1.) In the case of a hot backup, there is no mechanism
    by which you can get a consistent copy of on-line redo.
    2.) In the case of a cold backup, step 1 is ALWAYS a=20
    clean, normal (non-aborted) shutdown. If that's true,
    then the on-line redo doesn't contain any useful information.

    Given that, never, ever, backup your on-line redo log.

    -Mark
    --
    http://www.freelists.org/webpage/oracle-l
  • Freeman Robert - IL at Oct 4, 2004 at 12:06 pm
    Given that RMAN does not backup the online redo logs, one might consider
    that this is the ultimate word on the subject from Oracle. :-)

    Robert

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    To: mark.bobak_at_il.proquest.com
    Cc: oracle-l_at_freelists.org
    Sent: 10/4/2004 12:00 PM
    Subject: Re: Question in HOT BACKUP

    NEVER?

    Come on Mark, you should know that one never wants to say "never".

    usually, mostly, generally ...

    Exceptions off the top of my head for your assertion:

    1. prior to applying patchset or performing migration.
    2. to move database to another server and resetlogs is no desired.
    3. Client wants to test disaster recovery restore/recovery without dba

    involvement
    4. It depends ...

    Paul

    On Mon, 4 Oct 2004 09:43:58 -0400, Bobak, Mark
    wrote:
    The argument I generally use here is:
    1.) In the case of a hot backup, there is no mechanism
    by which you can get a consistent copy of on-line redo.
    2.) In the case of a cold backup, step 1 is ALWAYS a=20
    clean, normal (non-aborted) shutdown. If that's true,
    then the on-line redo doesn't contain any useful information.

    Given that, never, ever, backup your on-line redo log.

    -Mark
    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l
  • Bobak, Mark at Oct 4, 2004 at 12:55 pm
    Yes, I thought about that point, Robert. Just another good argument
    against backing up on-line redo.

    My favorite argument is:
    Please describe a valid backup/recovery scenario where a backup
    copy of on-line redo is required to succeed. (Hint, there
    isn't one!)

    Also, I'd argue that anyone who backs it up "just because" or
    "because we want it", is simply demonstrating a lack of underatanding
    of basic backup and recovery principles.

    Ok, that last statement will probably ruffle some feathers....
    Sorry, I don't accept "I don't want to type 'resetlogs'" as a=20
    valid argument.

    -Mark

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Freeman Robert - IL
    Sent: Monday, October 04, 2004 1:11 PM
    To: 'oracle-l_at_freelists.org '
    Subject: RE: Question in HOT BACKUP

    Given that RMAN does not backup the online redo logs, one might consider
    that this is the ultimate word on the subject from Oracle. :-)

    Robert

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    To: mark.bobak_at_il.proquest.com
    Cc: oracle-l_at_freelists.org
    Sent: 10/4/2004 12:00 PM
    Subject: Re: Question in HOT BACKUP

    NEVER?

    Come on Mark, you should know that one never wants to say "never".

    usually, mostly, generally ...

    Exceptions off the top of my head for your assertion:

    1. prior to applying patchset or performing migration.
    2. to move database to another server and resetlogs is no desired.
    3. Client wants to test disaster recovery restore/recovery without dba

    involvement
    4. It depends ...

    Paul

    On Mon, 4 Oct 2004 09:43:58 -0400, Bobak, Mark
    wrote:
    The argument I generally use here is:
    1.) In the case of a hot backup, there is no mechanism
    by which you can get a consistent copy of on-line redo.
    2.) In the case of a cold backup, step 1 is ALWAYS a=3D20
    clean, normal (non-aborted) shutdown. If that's true,
    then the on-line redo doesn't contain any useful information.
    =20
    Given that, never, ever, backup your on-line redo log.
    =20
    -Mark
    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l
  • Jared Still at Oct 4, 2004 at 10:58 pm

    On Mon, 4 Oct 2004 14:00:00 -0400, Bobak, Mark wrote:

    My favorite argument is:
    Please describe a valid backup/recovery scenario where a backup
    copy of on-line redo is required to succeed. (Hint, there
    isn't one!)
    Personally, there have been a few occasions where I have been
    very happy to have copies of the online logs.

    For instance: someone sent me 200G of cold backup tape, but the
    database was not being shutdown cleanly. The online logs were
    needed of course. The folks at the other end would not own up
    to the bad shutdowns until I lifted the relevant bits of the alert.log
    and emailed it to the other "DBA" and the project managers.

    I was thankful for his poor backup practice of backing up the logs,
    it saved us a bit of work.

    He never returned by phone calls after that.;)

    --
    Jared Still
    Certifiable Oracle DBA and Part Time Perl Evangelist
    --
    http://www.freelists.org/webpage/oracle-l
  • Niall Litchfield at Oct 5, 2004 at 4:32 am

    On Mon, 4 Oct 2004 21:02:35 -0700, Jared Still wrote:
    On Mon, 4 Oct 2004 14:00:00 -0400, Bobak, Mark
    wrote:
    My favorite argument is:
    Please describe a valid backup/recovery scenario where a backup
    copy of on-line redo is required to succeed. (Hint, there
    isn't one!)
    Personally, there have been a few occasions where I have been
    very happy to have copies of the online logs.

    For instance: someone sent me 200G of cold backup tape, but the
    database was not being shutdown cleanly. The online logs were
    needed of course. The folks at the other end would not own up
    to the bad shutdowns until I lifted the relevant bits of the alert.log
    and emailed it to the other "DBA" and the project managers.

    I was thankful for his poor backup practice of backing up the logs,
    it saved us a bit of work.
    An interesting counter to the describe a valid backup/recovery
    scenario argument.

    We have an invalid backup/recovery scenario and in that case it is
    useful to follow bad practice.
  • Jared Still at Oct 5, 2004 at 11:47 am

    On Tue, 5 Oct 2004 10:37:16 +0100, Niall Litchfield wrote:
    I was thankful for his poor backup practice of backing up the logs,
    it saved us a bit of work.
    An interesting counter to the describe a valid backup/recovery
    scenario argument.

    We have an invalid backup/recovery scenario and in that case it is
    useful to follow bad practice.
    Well, if the 'we' is changed to 'they', then yes.

    --
    Jared Still
    Certifiable Oracle DBA and Part Time Perl Evangelist
    --
    http://www.freelists.org/webpage/oracle-l
  • Niall Litchfield at Oct 5, 2004 at 1:23 pm
    Sorry Jared - "we" was an incorrect and misleading term to use.
  • John Kanagaraj at Oct 5, 2004 at 7:42 pm
    Niall,
    For instance: someone sent me 200G of cold backup tape, but the
    database was not being shutdown cleanly. The online logs were
    needed of course. The folks at the other end would not own up
    I was thankful for his poor backup practice of backing up the logs,
    it saved us a bit of work.
    I think the keyword here is "Cold backup" (even if it was incorrect). A Cold
    backup _does_ require Online redologs to be backed up, as this is a
    _Total_Image_ of the Database. Although the other DBA was supposed to have
    shutdown before backup, he _did_ backup the redo logs. The fact was there
    this was during a quiescent period when the SCN did not change helped you
    recover... Maybe he did do the right thing and back up the redo logs...

    Fyi... I had a similar situation long ago, when *I* forgot to shutdown
    before a cold backup clone for a demo. My backside was saved because there
    were no transactions (users were told to commit and logoff).

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedOct 2, '04 at 3:35a
activeOct 5, '04 at 7:42p
posts13
users10
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase