FAQ
Hello:
I have a question about enqueues, we have oracle 9.2.0.6 on a HP UX..
here is a extract on an statspack report

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
enqueue 4,515 10,582 36.10

but on the enqueue details there is no indication of a significant wait.

Avg Wt Wait
Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
-- ------------ ------------ -----------
----------- ------------- ------------
TX 435,219 435,219 0 154
156.29 24
SQ 7,062 7,062 0 760
3.69 3
CU 6,743 6,743 0 1
10.00 0
HW 770 770 0 1
.00 0
-------------------------------------------------------------

so how can i know what was the DB waiting for

TIA

Search Discussions

  • David Sharples at Oct 20, 2005 at 10:11 am
    http://www.oracleadvice.com/Tips/enqueue.htm
    On 10/20/05, Alfonso León wrote:


    so how can i know what was the DB waiting for
    --
    http://www.freelists.org/webpage/oracle-l
  • Alfonso León at Oct 20, 2005 at 10:27 am
    I'm sorry but this article wasn't useful.

    The system stats (stats$system_event) indicates a enqueue wait but the
    enqueue detail (stats$enqueue_stats) doesn't. why? any other
    suggestion?
    On 10/20/05, David Sharples wrote:
    http://www.oracleadvice.com/Tips/enqueue.htm

    On 10/20/05, Alfonso León wrote:

    so how can i know what was the DB waiting for
    --
    Alfonso Leon
    --
    http://www.freelists.org/webpage/oracle-l
  • David Sharples at Oct 20, 2005 at 10:30 am
    what does this return wait, if you have an enqueue wait it till show it here
    select * from v$enqueue_stat where total_wait# > 0;
    On 10/20/05, Alfonso León wrote:

    I'm sorry but this article wasn't useful.
    --
    http://www.freelists.org/webpage/oracle-l
  • Amit poddar at Oct 20, 2005 at 10:32 am
    Check v$enqueue_stat

    Check Oracle documentation for the column descriptions

    amit

    Alfonso León wrote:
    Hello:
    I have a question about enqueues, we have oracle 9.2.0.6 on a HP UX..
    here is a extract on an statspack report

    Top 5 Timed Events
    ~~~~~~~~~~~~~~~~~~ % Total
    Event Waits Time (s) Ela Time
    -------------------------------------------- ------------ ----------- --------
    enqueue 4,515 10,582 36.10

    but on the enqueue details there is no indication of a significant wait.


    Avg Wt Wait
    Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
    -- ------------ ------------ -----------
    ----------- ------------- ------------
    TX 435,219 435,219 0 154
    156.29 24
    SQ 7,062 7,062 0 760
    3.69 3
    CU 6,743 6,743 0 1
    10.00 0
    HW 770 770 0 1
    .00 0
    -------------------------------------------------------------

    so how can i know what was the DB waiting for

    TIA
    --
    Alfonso Leon
    --
    http://www.freelists.org/webpage/oracle-l

    --
    http://www.freelists.org/webpage/oracle-l
  • Gogala, Mladen at Oct 20, 2005 at 10:39 am
    Alfonso, you're referring to the fact that there is an outrageous difference
    in the time waiting and the time spent in locks. As anybody can tell you,
    STATSPACK is not very useful. What STATSPACK will give you is a crude
    pointer where to look. To actually determine the cause of the problem (and I
    assume that there is one) you will still have to locate the problem session
    (sessions?) and see what is it (what are they) waiting for and which locks
    are problematic. The top 5 events section in the SP-report is constructed by
    querying V$SYSTEM_EVENT at the stime of each snapshot and then subtracting
    one from another. There is O'Reilly book called "Optimizing
    Oracle For Performance" which explains how time accounting can be
    problematic even within a single trace file, and, of course, even more so in
    a thing like STATSPACK which essentially queries tables unprotected by any
    relational integrity mechanism and computes something that should be an
    overall picture of a system over a period of time. Relating data from
    V$SYSTEM_EVENT and V$LOCK from an overview provided by STATSPACK is a waste
    of time.

    --
    Mladen Gogala
    Ext. 121

    -----Original Message-----
    From: Alfonso León
    Sent: Thursday, October 20, 2005 11:03 AM
    To: oracle-l
    Subject: enqueue in statspack

    Hello:
    I have a question about enqueues, we have oracle 9.2.0.6 on a HP UX..
    here is a extract on an statspack report

    Top 5 Timed Events

    ~~~~~~~~~~~~~~~~~~ % Total
    Event Waits Time (s) Ela Time
    -------------------------------------------- ------------ -----------
    --------
    enqueue 4,515 10,582 36.10

    but on the enqueue details there is no indication of a significant wait.

    Avg Wt Wait
    Eq Requests Succ Gets Failed Gets Waits Time (ms) Time
    (s)
    -- ------------ ------------ -----------
    ----------- ------------- ------------
    TX 435,219 435,219 0 154
    156.29 24
    SQ 7,062 7,062 0 760
    3.69 3
    CU 6,743 6,743 0 1
    10.00 0
    HW 770 770 0 1
    .00 0
    -------------------------------------------------------------

    so how can i know what was the DB waiting for

    TIA

    --
    Alfonso Leon
    --
    http://www.freelists.org/webpage/oracle-l

    --
    http://www.freelists.org/webpage/oracle-l
  • Bobak, Mark at Oct 20, 2005 at 10:46 am
    I very much agree w/ what Mladen has to say here.


    To take it a step further, though, once the TX enqueue wait has occurred, it's impossible to determine what the root cause was, which of course is what you need to do to solve the problem. It is probably worth actively monitoring the process that's giving you problems, trying to catch it in the act. Some of the information you'll want to make a note of is:

    What mode (S, X, something else?) is the TX lock waiting on?
    What SQL statement caused your session to start waiting?
    What session are you waiting on?

    There are a couple of ways to capture this info. You may try a 10046 trace if you're comfortable with that, or you may query V$LOCK, V$SESSION_WAIT and V$SQL. Once you have that info, you may be able to piece together what's happening and where things are going wrong.


    Hope that helps,


    -Mark

    Van: oracle-l-bounce_at_freelists.org namens Gogala, Mladen
    Verzonden: do 10/20/2005 5:35
    Aan: 'aleon68_at_gmail.com'; oracle-l
    Onderwerp: RE: enqueue in statspack

    Alfonso, you're referring to the fact that there is an outrageous difference in the time waiting and the time spent in locks. As anybody can tell you, STATSPACK is not very useful. What STATSPACK will give you is a crude

    pointer where to look. To actually determine the cause of the problem (and I assume that there is one) you will still have to locate the problem session (sessions?) and see what is it (what are they) waiting for and which locks are problematic. The top 5 events section in the SP-report is constructed by querying V$SYSTEM_EVENT at the stime of each snapshot and then subtracting one from another. There is O'Reilly book called "Optimizing

    Oracle For Performance" which explains how time accounting can be problematic even within a single trace file, and, of course, even more so in

    a thing like STATSPACK which essentially queries tables unprotected by any
    relational integrity mechanism and computes something that should be an overall picture of a system over a period of time. Relating data from V$SYSTEM_EVENT and V$LOCK from an overview provided by STATSPACK is a waste of time.

    --
    Mladen Gogala
    Ext. 121

    -----Original Message-----
    From: Alfonso León
    Sent: Thursday, October 20, 2005 11:03 AM
    To: oracle-l
    Subject: enqueue in statspack

    Hello:
    I have a question about enqueues, we have oracle 9.2.0.6 on a HP UX..
    here is a extract on an statspack report

    Top 5 Timed Events
    ~~~~~~~~~~~~~~~~~~ % Total
    Event Waits Time (s) Ela Time
    -------------------------------------------- ------------ ----------- --------
    enqueue 4,515 10,582 36.10

    but on the enqueue details there is no indication of a significant wait.

    Avg Wt Wait
    Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
    -- ------------ ------------ -----------
    ----------- ------------- ------------
    TX 435,219 435,219 0 154
    156.29 24
    SQ 7,062 7,062 0 760
    3.69 3
    CU 6,743 6,743 0 1
    10.00 0
    HW 770 770 0 1
    .00 0
    -------------------------------------------------------------

    so how can i know what was the DB waiting for

    TIA
    --
    Alfonso Leon
    --
    http://www.freelists.org/webpage/oracle-l

    --
    http://www.freelists.org/webpage/oracle-l
  • Alfonso León at Oct 21, 2005 at 11:03 am
    thanks for your answers.

    This is the explanation I got from the oracle forum

    From: Kristian Myllymäki 21-Oct-05 15:32
    Subject: Re : enqueue difference between system events and enqueue stat

    If a session is waiting for an enqueue request, the TIME_WAITED_MICRO
    in v$system_event is incremented for every three seconds (when an
    enqueue timeout occurs). However, v$enqueue_stat is only incremented
    after the session has acquired or cancelled the enqueue resource
    request.

    This means that during the enqueue request, v$system_event will show
    higher values than v$enqueue_stat. So if you have had long running
    enqueue requests that haven't been acquired in your statspack snapshot
    window, the snapshot of v$system_event will show higher values than
    v$enqueue_stat.

    You could try to span more statspack snapshots in your report, and see
    if the values still differ.

    /Kristian
    On 10/20/05, Bobak, Mark wrote:
    I very much agree w/ what Mladen has to say here.

    To take it a step further, though, once the TX enqueue wait has occurred, it's impossible to determine what the root cause was, which of course is what you need to do to solve the problem. It is probably worth actively monitoring the process that's giving you problems, trying to catch it in the act. Some of the information you'll want to make a note of is:
    - What mode (S, X, something else?) is the TX lock waiting on?
    - What SQL statement caused your session to start waiting?
    - What session are you waiting on?

    There are a couple of ways to capture this info. You may try a 10046 trace if you're comfortable with that, or you may query V$LOCK, V$SESSION_WAIT and V$SQL. Once you have that info, you may be able to piece together what's happening and where things are going wrong.

    Hope that helps,

    -Mark

    ________________________________

    Van: oracle-l-bounce_at_freelists.org namens Gogala, Mladen
    Verzonden: do 10/20/2005 5:35
    Aan: 'aleon68_at_gmail.com'; oracle-l
    Onderwerp: RE: enqueue in statspack



    Alfonso, you're referring to the fact that there is an outrageous difference in the time waiting and the time spent in locks. As anybody can tell you, STATSPACK is not very useful. What STATSPACK will give you is a crude

    pointer where to look. To actually determine the cause of the problem (and I assume that there is one) you will still have to locate the problem session (sessions?) and see what is it (what are they) waiting for and which locks are problematic. The top 5 events section in the SP-report is constructed by querying V$SYSTEM_EVENT at the stime of each snapshot and then subtracting one from another. There is O'Reilly book called "Optimizing

    Oracle For Performance" which explains how time accounting can be problematic even within a single trace file, and, of course, even more so in

    a thing like STATSPACK which essentially queries tables unprotected by any
    relational integrity mechanism and computes something that should be an overall picture of a system over a period of time. Relating data from V$SYSTEM_EVENT and V$LOCK from an overview provided by STATSPACK is a waste of time.

    --
    Mladen Gogala
    Ext. 121

    -----Original Message-----
    From: Alfonso León
    Sent: Thursday, October 20, 2005 11:03 AM
    To: oracle-l
    Subject: enqueue in statspack

    Hello:
    I have a question about enqueues, we have oracle 9.2.0.6 on a HP UX..
    here is a extract on an statspack report

    Top 5 Timed Events
    ~~~~~~~~~~~~~~~~~~ % Total
    Event Waits Time (s) Ela Time
    -------------------------------------------- ------------ ----------- --------
    enqueue 4,515 10,582 36.10

    but on the enqueue details there is no indication of a significant wait.


    Avg Wt Wait
    Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
    -- ------------ ------------ -----------
    ----------- ------------- ------------
    TX 435,219 435,219 0 154
    156.29 24
    SQ 7,062 7,062 0 760
    3.69 3
    CU 6,743 6,743 0 1
    10.00 0
    HW 770 770 0 1
    .00 0
    -------------------------------------------------------------

    so how can i know what was the DB waiting for

    TIA
    --
    Alfonso Leon
    --
    http://www.freelists.org/webpage/oracle-l
    --
    Alfonso Leon
    --
    http://www.freelists.org/webpage/oracle-l
  • Mike Schmitt at Oct 21, 2005 at 11:42 am
    Hi all,

    I was wondering if I could get some advice on the best way to handle
    retention policies as they relate to RMAN and media management
    software. This is for a mixed 9.2 and 10 environment.

    For example, if we wanted to implement a retention policy that looks like
    the following, and has all other backups removed from the tape library.
    - Keep daily full backups for 1 week

    Keep full backups taken on Sunday for 1 month
    Keep 1 backup from every month for 1 year
    Keep all archive logs for 30 days

    I am curious about what others do to handle this? Would it be best to set
    a keep time for each backup that gets run, designating how long that
    particular backup should be retained, or would it be better to have a
    separate script log in and change the catalog to match what you want the
    policy to look like. ( This is for TSM btw, and my impression is that TSM
    mainly leaves retention up to the commands it gets by way of TDP)

    I am currently leaning towards handling this with the keep option, but I
    would appreciate any advice

    Thanks
  • Vitalis Jerome at Oct 22, 2005 at 2:59 am
    Hi Mike,

    Yes, it is the way to go.
    If these are cold backup, it will work flawlessly.

    Otherwise, I observed that the LOG parameter of the KEEP option was
    buggy (our version was Oracle 9i, I can't remember the exact release):
    while the docco said that LOG would keep the archived logs needed to
    make the online backup consistent, in fact it kept *all* logs backed
    up after the related backup.
    So KEEP was not suitable for online backups.

    Regards,
    Jerome
    On 10/21/05, Mike Schmitt wrote:

    Hi all,

    I was wondering if I could get some advice on the best way to handle
    retention policies as they relate to RMAN and media management
    software. This is for a mixed 9.2 and 10 environment.

    For example, if we wanted to implement a retention policy that looks like
    the following, and has all other backups removed from the tape library.
    - Keep daily full backups for 1 week
    - Keep full backups taken on Sunday for 1 month
    - Keep 1 backup from every month for 1 year
    - Keep all archive logs for 30 days

    I am curious about what others do to handle this? Would it be best to set
    a keep time for each backup that gets run, designating how long that
    particular backup should be retained, or would it be better to have a
    separate script log in and change the catalog to match what you want the
    policy to look like. ( This is for TSM btw, and my impression is that TSM
    mainly leaves retention up to the commands it gets by way of TDP)

    I am currently leaning towards handling this with the keep option, but I
    would appreciate any advice

    Thanks





    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l
  • M Rafiq at Oct 21, 2005 at 11:43 am
    I have observed that after applying 9206 patchset it requires more
    enqueue_resources then before. Most of the time default enqueue_resources
    968 were suffecient for most of the databases.

    Is there any reason for that? There is no change in application code.

    Regards
    Rafiq

    From: Alfonso León
    Reply-To: aleon68_at_gmail.com
    CC: oracle-l
    Subject: Re: enqueue in statspack
    Date: Fri, 21 Oct 2005 11:00:58 -0500

    thanks for your answers.

    This is the explanation I got from the oracle forum

    From: Kristian Myllymäki 21-Oct-05 15:32
    Subject: Re : enqueue difference between system events and enqueue stat

    If a session is waiting for an enqueue request, the TIME_WAITED_MICRO
    in v$system_event is incremented for every three seconds (when an
    enqueue timeout occurs). However, v$enqueue_stat is only incremented
    after the session has acquired or cancelled the enqueue resource
    request.

    This means that during the enqueue request, v$system_event will show
    higher values than v$enqueue_stat. So if you have had long running
    enqueue requests that haven't been acquired in your statspack snapshot
    window, the snapshot of v$system_event will show higher values than
    v$enqueue_stat.

    You could try to span more statspack snapshots in your report, and see
    if the values still differ.

    /Kristian
    On 10/20/05, Bobak, Mark wrote:
    I very much agree w/ what Mladen has to say here. >
    To take it a step further, though, once the TX enqueue wait has occurred,
    it's impossible to determine what the root cause was, which of course is
    what you need to do to solve the problem. It is probably worth actively
    monitoring the process that's giving you problems, trying to catch it in the
    act. Some of the information you'll want to make a note of is:
    - What mode (S, X, something else?) is the TX lock waiting on?
    - What SQL statement caused your session to start waiting?
    - What session are you waiting on? >
    There are a couple of ways to capture this info. You may try a 10046
    trace if you're comfortable with that, or you may query V$LOCK,
    V$SESSION_WAIT and V$SQL. Once you have that info, you may be able to piece
    together what's happening and where things are going wrong.
    >
    Hope that helps, >
    -Mark >
    ________________________________ >
    Van: oracle-l-bounce_at_freelists.org namens Gogala, Mladen
    Verzonden: do 10/20/2005 5:35
    Aan: 'aleon68_at_gmail.com'; oracle-l
    Onderwerp: RE: enqueue in statspack
    >
    >
    >
    Alfonso, you're referring to the fact that there is an outrageous
    difference in the time waiting and the time spent in locks. As anybody can
    tell you, STATSPACK is not very useful. What STATSPACK will give you is a
    crude
    >
    pointer where to look. To actually determine the cause of the problem
    (and I assume that there is one) you will still have to locate the problem
    session (sessions?) and see what is it (what are they) waiting for and
    which locks are problematic. The top 5 events section in the SP-report is
    constructed by querying V$SYSTEM_EVENT at the stime of each snapshot and
    then subtracting one from another. There is O'Reilly book called "Optimizing
    >
    Oracle For Performance" which explains how time accounting can be
    problematic even within a single trace file, and, of course, even more so in
    >
    a thing like STATSPACK which essentially queries tables unprotected by any
    relational integrity mechanism and computes something that should be an
    overall picture of a system over a period of time. Relating data from
    V$SYSTEM_EVENT and V$LOCK from an overview provided by STATSPACK is a waste
    of time.
    >
    --
    Mladen Gogala
    Ext. 121 >
    -----Original Message-----
    From: Alfonso León
    Sent: Thursday, October 20, 2005 11:03 AM
    To: oracle-l
    Subject: enqueue in statspack >
    Hello:
    I have a question about enqueues, we have oracle 9.2.0.6 on a HP UX..
    here is a extract on an statspack report >
    Top 5 Timed Events
    ~~~~~~~~~~~~~~~~~~ % Total
    Event Waits Time (s) Ela Time
    -------------------------------------------- ------------ -----------
    enqueue 4,515 10,582 36.10 >
    but on the enqueue details there is no indication of a significant wait.
    >
    >
    Avg Wt Wait
    Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s)
    -- ------------ ------------ -----------
    ----------- ------------- ------------
    TX 435,219 435,219 0 154
    156.29 24
    SQ 7,062 7,062 0 760
    3.69 3
    CU 6,743 6,743 0 1
    10.00 0
    HW 770 770 0 1
    .00 0
    >

    >
    so how can i know what was the DB waiting for >
    TIA
    --
    Alfonso Leon
    --
    http://www.freelists.org/webpage/oracle-l
    >
    >
  • Roger Xu at Oct 27, 2005 at 11:47 am
    I think as long as you keep the backup controlfile, you can always
    restore your RMAN backup to another server.
    You do not have to do cold backup, right?

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Vitalis Jerome
    Sent: Saturday, October 22, 2005 2:57 AM
    To: mschmitt_at_uchicago.edu
    Cc: oracle-l_at_freelists.org
    Subject: Re: RMAN Retention policies

    Hi Mike,

    Yes, it is the way to go.
    If these are cold backup, it will work flawlessly.

    Otherwise, I observed that the LOG parameter of the KEEP option was
    buggy (our version was Oracle 9i, I can't remember the exact release):
    while the docco said that LOG would keep the archived logs needed to
    make the online backup consistent, in fact it kept *all* logs backed up
    after the related backup.
    So KEEP was not suitable for online backups.

    Regards,
    Jerome
    On 10/21/05, Mike Schmitt wrote:

    Hi all,

    I was wondering if I could get some advice on the best way to handle
    retention policies as they relate to RMAN and media management
    software. This is for a mixed 9.2 and 10 environment.

    For example, if we wanted to implement a retention policy that looks
    like the following, and has all other backups removed from the tape library.
    - Keep daily full backups for 1 week
    - Keep full backups taken on Sunday for 1 month
    - Keep 1 backup from every month for 1 year
    - Keep all archive logs for 30 days

    I am curious about what others do to handle this? Would it be best to
    set a keep time for each backup that gets run, designating how long
    that particular backup should be retained, or would it be better to
    have a separate script log in and change the catalog to match what you
    want the policy to look like. ( This is for TSM btw, and my
    impression is that TSM mainly leaves retention up to the commands it
    gets by way of TDP)

    I am currently leaning towards handling this with the keep option, but
    I would appreciate any advice

    Thanks





    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l

    For technical support please email tech_support_at_dp7uptx.com or you can
    call (972)721-8257.
    This email has been scanned for all viruses by the MessageLabs Email
    Security System.

    This e-mail is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. Any review, dissemination, copying, printing or other use of this e-mail by persons or entities other than the addressee is prohibited. If you have received this e-mail in error, please contact the sender immediately and delete the material.
    ____________________________________________________________________
    This email has been scanned for all viruses by the MessageLabs Email Security System. Any questions please call 972-721-8257 or email your request to tech_support_at_dp7uptx.com.
    --
    http://www.freelists.org/webpage/oracle-l
  • T_adolph_at_hotmail.com at Oct 27, 2005 at 4:44 pm
    Hi Mike,

    I'm a bit late on this one *and* I may be stating the obvious, but from:
    - Keep daily full backups for 1 week
    - Keep full backups taken on Sunday for 1 month
    - Keep 1 backup from every month for 1 year
    - Keep all archive logs for 30 days
    is the monthly backup cold / off line? I guess so, if not you must keep all
    archived redos for that time, i.e. a year

    Sorry if that's already been discussed, but I thought better mention it than
    not.

    Cheers
    Tony

    Original Message -----
    From: "Roger Xu"
    To:;
    Cc:
    Sent: Thursday, October 27, 2005 5:42 PM
    Subject: RE: RMAN Retention policies
    I think as long as you keep the backup controlfile, you can always
    restore your RMAN backup to another server.
    You do not have to do cold backup, right?

    -----Original Message-----
    From: oracle-l-bounce_at_freelists.org
    On Behalf Of Vitalis Jerome
    Sent: Saturday, October 22, 2005 2:57 AM
    To: mschmitt_at_uchicago.edu
    Cc: oracle-l_at_freelists.org
    Subject: Re: RMAN Retention policies

    Hi Mike,

    Yes, it is the way to go.
    If these are cold backup, it will work flawlessly.

    Otherwise, I observed that the LOG parameter of the KEEP option was
    buggy (our version was Oracle 9i, I can't remember the exact release):
    while the docco said that LOG would keep the archived logs needed to
    make the online backup consistent, in fact it kept *all* logs backed up
    after the related backup.
    So KEEP was not suitable for online backups.

    Regards,
    Jerome
    On 10/21/05, Mike Schmitt wrote:

    Hi all,

    I was wondering if I could get some advice on the best way to handle
    retention policies as they relate to RMAN and media management
    software. This is for a mixed 9.2 and 10 environment.

    For example, if we wanted to implement a retention policy that looks
    like the following, and has all other backups removed from the tape library.
    - Keep daily full backups for 1 week
    - Keep full backups taken on Sunday for 1 month
    - Keep 1 backup from every month for 1 year
    - Keep all archive logs for 30 days

    I am curious about what others do to handle this? Would it be best to
    set a keep time for each backup that gets run, designating how long
    that particular backup should be retained, or would it be better to
    have a separate script log in and change the catalog to match what you
    want the policy to look like. ( This is for TSM btw, and my
    impression is that TSM mainly leaves retention up to the commands it
    gets by way of TDP)

    I am currently leaning towards handling this with the keep option, but
    I would appreciate any advice

    Thanks





    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l

    For technical support please email tech_support_at_dp7uptx.com or you can
    call (972)721-8257.
    This email has been scanned for all viruses by the MessageLabs Email
    Security System.



    This e-mail is intended solely for the person or entity to which it is
    addressed and may contain confidential and/or privileged information. Any
    review, dissemination, copying, printing or other use of this e-mail by
    persons or entities other than the addressee is prohibited. If you have
    received this e-mail in error, please contact the sender immediately and
    delete the material.
    ____________________________________________________________________
    This email has been scanned for all viruses by the MessageLabs Email
    Security System. Any questions please call 972-721-8257 or email your
    request to tech_support_at_dp7uptx.com.
  • Vitalis Jerome at Oct 28, 2005 at 6:05 am

    is the monthly backup cold / off line? I guess so, if not you must keep all
    archived redos for that time, i.e. a year
    That's not true. You must keep the logs generated during the backups,
    not 1 year worth of logs.
    As I said, it seems that RMAN 9i does not enforce this need
    correctedly (by means of option KEEP LOGS). It keeps *all* subsequent
    logs.

    Jerome
  • NEW pop.tiscali.de at Oct 28, 2005 at 6:41 am
    Hi Jerome,

    If you only keep the logs generated during the backups, then up until what
    time do you expect to recover to? There'll be a gap from Dec 04 til now?
    Or?

    Tony
    ----- Original Message -----
    From: "Vitalis Jerome"
    To:
    Cc:;
    Sent: Friday, October 28, 2005 12:02 PM
    Subject: Re: RMAN Retention policies
    is the monthly backup cold / off line? I guess so, if not you must keep
    all
    archived redos for that time, i.e. a year
    That's not true. You must keep the logs generated during the backups,
    not 1 year worth of logs.
    As I said, it seems that RMAN 9i does not enforce this need
    correctedly (by means of option KEEP LOGS). It keeps *all* subsequent
    logs.

    Jerome
    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l
  • Vitalis Jerome at Oct 28, 2005 at 7:09 am
    Hi Tony!

    Yes exactly, but it is the OP's need I guess:
    - Keep daily full backups for 1 week
    - Keep full backups taken on Sunday for 1 month
    - Keep 1 backup from every month for 1 year
    - Keep all archive logs for 30 days
    He does not want to be able to perform point-in-time recovery over the
    year, just to be able to restore and recover from those backups.

    Jerome
    On 10/28/05, NEW pop.tiscali.de wrote:
    Hi Jerome,

    If you only keep the logs generated during the backups, then up until what
    time do you expect to recover to? There'll be a gap from Dec 04 til now?
    Or?

    Tony
    ----- Original Message -----
    From: "Vitalis Jerome"
    To:
    Cc:;
    Sent: Friday, October 28, 2005 12:02 PM
    Subject: Re: RMAN Retention policies

    is the monthly backup cold / off line? I guess so, if not you must keep
    all
    archived redos for that time, i.e. a year
    That's not true. You must keep the logs generated during the backups,
    not 1 year worth of logs.
    As I said, it seems that RMAN 9i does not enforce this need
    correctedly (by means of option KEEP LOGS). It keeps *all* subsequent
    logs.

    Jerome
    --
    http://www.freelists.org/webpage/oracle-l
    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedOct 20, '05 at 10:05a
activeOct 28, '05 at 7:09a
posts16
users11
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase