FAQ
Oracle 10.2.0.2
RH Linux AS4
No ASM

I just started playing around with Data Guard for the first time this
week. For reasons I won't go into that MAY be related to age, I am
using DGMGRL instead of OEM to manage the broker. The primary is called
daffy and the physical standby is called daffysby. It seems OK in that
I can see transactions get applied to daffysby but DGMGRL gives me a
warning. It has to do with missing standby redo logs (SRLs) on the
primary. I have SRLs in both the primary and the standby. The High
Availability Best Practice guide alludes to putting SRLs in the flash
recovery area (which I have not done at this point) but I am not
convinced that is the issue. I've searched Metalink and the web for
"missing SRLs" with not a whole lot of luck. All the redo logs are the
same size.

My question is does anyone know to get rid of this warning? Can it be
safely ignored? I would think not.

Any/all pointers/links/advice welcome. This is a test environment so I
can try anything.

Thanks,
-joe

(hope this formats ok)

DGMGRL> show database verbose daffy;

Database

Name: daffy
Role: PRIMARY
Enabled: YES

Intended State: ONLINE
Instance(s):
daffy

Current status for "daffy":
Warning: ORA-16801: redo transport-related property is inconsistent with
database setting

DGMGRL> show database daffy 'InconsistentLogXptProps';
INCONSISTENT LOG TRANSPORT PROPERTIES

INSTANCE_NAME STANDBY_NAME PROPERTY_NAME
MEMORY_VALUE BROKER_VALUE
daffy daffysby LogXptMode
(missing SRLs) ASYNC

DGMGRL>

SQL> select instance_name from v$instance;

INSTANCE_NAME

daffy

SQL> select group# ||' - '|| type ||' - '|| member from v$logfile;

GROUP#||'-'||TYPE||'-'||MEMBER

1 - ONLINE - /u02/oradata/daffy/redo01.log
2 - ONLINE - /u02/oradata/daffy/redo02.log
3 - ONLINE - /u02/oradata/daffy/redo03.log
4 - STANDBY - /u02/oradata/daffy/stby_redo04.log
5 - STANDBY - /u02/oradata/daffy/stby_redo05.log
6 - STANDBY - /u02/oradata/daffy/stby_redo06.log

6 rows selected.

SQL>

Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Holdings, LLC, Underwriters at Lloyd's, Syndicate 4242, scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.

Search Discussions

  • Bradd Piontek at Oct 13, 2008 at 1:15 am
    It looks to me like you might have changed a log_archive_dest_n parameter
    via 'alter system' rather than via the dataguard broker. Compare a 'show
    parameter' from sqlplus to a dgmgrl>show database verbose (although you may
    have to go a bit more detailed). When using the broker. there are certain
    parameters related to dataguard that should be managed from the broker
    itself, and not changed outside of it.

    Bradd Piontek
    "Next to doing a good job yourself,

    the greatest joy is in having someone
    else do a first-class job under your
    direction."

    William Feather
    On Fri, Oct 10, 2008 at 10:51 AM, Sweetser, Joe wrote:

    Oracle 10.2.0.2
    RH Linux AS4
    No ASM

    I just started playing around with Data Guard for the first time this
    week. For reasons I won't go into that MAY be related to age, I am
    using DGMGRL instead of OEM to manage the broker. The primary is called
    daffy and the physical standby is called daffysby. It seems OK in that
    I can see transactions get applied to daffysby but DGMGRL gives me a
    warning. It has to do with missing standby redo logs (SRLs) on the
    primary. I have SRLs in both the primary and the standby. The High
    Availability Best Practice guide alludes to putting SRLs in the flash
    recovery area (which I have not done at this point) but I am not
    convinced that is the issue. I've searched Metalink and the web for
    "missing SRLs" with not a whole lot of luck. All the redo logs are the
    same size.

    My question is does anyone know to get rid of this warning? Can it be
    safely ignored? I would think not.

    Any/all pointers/links/advice welcome. This is a test environment so I
    can try anything.

    Thanks,
    -joe

    (hope this formats ok)

    DGMGRL> show database verbose daffy;

    Database
    Name: daffy
    Role: PRIMARY
    Enabled: YES
    Intended State: ONLINE
    Instance(s):
    daffy



    Current status for "daffy":
    Warning: ORA-16801: redo transport-related property is inconsistent with
    database setting


    DGMGRL> show database daffy 'InconsistentLogXptProps';
    INCONSISTENT LOG TRANSPORT PROPERTIES
    INSTANCE_NAME STANDBY_NAME PROPERTY_NAME
    MEMORY_VALUE BROKER_VALUE
    daffy daffysby LogXptMode
    (missing SRLs) ASYNC

    DGMGRL>
    *****************

    SQL> select instance_name from v$instance;

    INSTANCE_NAME
    ------------------------------------------------
    daffy

    SQL> select group# ||' - '|| type ||' - '|| member from v$logfile;

    GROUP#||'-'||TYPE||'-'||MEMBER
    ------------------------------------------------------------------------
    --------
    1 - ONLINE - /u02/oradata/daffy/redo01.log
    2 - ONLINE - /u02/oradata/daffy/redo02.log
    3 - ONLINE - /u02/oradata/daffy/redo03.log
    4 - STANDBY - /u02/oradata/daffy/stby_redo04.log
    5 - STANDBY - /u02/oradata/daffy/stby_redo05.log
    6 - STANDBY - /u02/oradata/daffy/stby_redo06.log

    6 rows selected.

    SQL>
    Confidentiality Note: This message contains information that may be
    confidential and/or privileged. If you are not the intended recipient, you
    should not use, copy, disclose, distribute or take any action based on this
    message. If you have received this message in error, please advise the
    sender immediately by reply email and delete this message. Although ICAT
    Holdings, LLC, Underwriters at Lloyd's, Syndicate 4242, scans e-mail and
    attachments for viruses, it does not guarantee that either are virus-free
    and accepts no liability for any damage sustained as a result of viruses.
    Thank you.

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

    --
    http://www.freelists.org/webpage/oracle-l
  • Sweetser, Joe at Oct 13, 2008 at 2:21 pm
    Not unexpectedly, it ended up be a combination of a few things:


    Not enough standby redo logs - recommended value is one more than
    the number of redo logs
    Missing standby redo logs on the standby database - I expected RMAN
    to create/recreate the SRLs I had created in the primary but the files
    themselves were missing.
    Incompatible settings between the DGMGRL configuration and the
    database - specifically LogXptMode

    Many thanks to Bradd, Finn, and Jason for the help and pointers.


    Now on to the failover attempt! :-)


    -joe

    From: Bradd Piontek
    Sent: Sunday, October 12, 2008 7:16 PM
    To: Sweetser, Joe
    Cc: oracle-l
    Subject: Re: Data Guard question

    It looks to me like you might have changed a log_archive_dest_n
    parameter via 'alter system' rather than via the dataguard broker.
    Compare a 'show parameter' from sqlplus to a dgmgrl>show database
    verbose (although you may have to go a bit more detailed). When using
    the broker. there are certain parameters related to dataguard that
    should be managed from the broker itself, and not changed outside of it.

    Bradd Piontek
    "Next to doing a good job yourself,

    the greatest joy is in having someone
    else do a first-class job under your
    direction."

    William Feather

    On Fri, Oct 10, 2008 at 10:51 AM, Sweetser, Joe
    wrote:

    Oracle 10.2.0.2
    RH Linux AS4
    No ASM

    I just started playing around with Data Guard for the first time
    this
    week. For reasons I won't go into that MAY be related to age, I
    am
    using DGMGRL instead of OEM to manage the broker. The primary
    is called
    daffy and the physical standby is called daffysby. It seems OK
    in that
    I can see transactions get applied to daffysby but DGMGRL gives
    me a
    warning. It has to do with missing standby redo logs (SRLs) on
    the
    primary. I have SRLs in both the primary and the standby. The
    High
    Availability Best Practice guide alludes to putting SRLs in the
    flash
    recovery area (which I have not done at this point) but I am not
    convinced that is the issue. I've searched Metalink and the web
    for
    "missing SRLs" with not a whole lot of luck. All the redo logs
    are the
    same size.

    My question is does anyone know to get rid of this warning? Can
    it be
    safely ignored? I would think not.

    Any/all pointers/links/advice welcome. This is a test
    environment so I
    can try anything.

    Thanks,
    -joe

    (hope this formats ok)

    DGMGRL> show database verbose daffy;

    Database
    Name: daffy
    Role: PRIMARY
    Enabled: YES
    Intended State: ONLINE
    Instance(s):
    daffy

    Current status for "daffy":
    Warning: ORA-16801: redo transport-related property is
    inconsistent with
    database setting

    DGMGRL> show database daffy 'InconsistentLogXptProps';
    INCONSISTENT LOG TRANSPORT PROPERTIES
    INSTANCE_NAME STANDBY_NAME PROPERTY_NAME
    MEMORY_VALUE BROKER_VALUE
    daffy daffysby LogXptMode
    (missing SRLs) ASYNC

    DGMGRL>

    *****************

    SQL> select instance_name from v$instance;

    INSTANCE_NAME
    ------------------------------------------------
    daffy

    SQL> select group# ||' - '|| type ||' - '|| member from

    v$logfile;


    GROUP#||'-'||TYPE||'-'||MEMBER



    1 - ONLINE - /u02/oradata/daffy/redo01.log
    2 - ONLINE - /u02/oradata/daffy/redo02.log
    3 - ONLINE - /u02/oradata/daffy/redo03.log
    4 - STANDBY - /u02/oradata/daffy/stby_redo04.log
    5 - STANDBY - /u02/oradata/daffy/stby_redo05.log
    6 - STANDBY - /u02/oradata/daffy/stby_redo06.log

    6 rows selected.

    SQL>

    Confidentiality Note: This message contains information that may

    be confidential and/or privileged. If you are not the intended
    recipient, you should not use, copy, disclose, distribute or take any
    action based on this message. If you have received this message in
    error, please advise the sender immediately by reply email and delete
    this message. Although ICAT Holdings, LLC, Underwriters at Lloyd's,
    Syndicate 4242, scans e-mail and attachments for viruses, it does not
    guarantee that either are virus-free and accepts no liability for any
    damage sustained as a result of viruses. Thank you.
  • John.Hallas_at_morrisonsplc.co.uk at Oct 13, 2008 at 2:42 pm
    Why does that requirement for an additional srl exist? Is it so that the
    target system can always keep up

    John

    ----- wrote: -----

    To: Bradd Piontek,,

    From: "Sweetser, Joe"
    Sent by:
    Date: 13/10/2008 03:21PM
    cc: oracle-l
    Subject: RE: Data Guard question

    Not unexpectedly, it ended up be a combination of a few things:

    Not enough standby redo logs - recommended value is one more than the
    number of redo logs

    Wm Morrison Supermarkets PLC is registered in England with number 358949. The registered office of the company is situated
    at Gain Lane, Bradford, West Yorkshire BD3 7DL.

    This email and any attachments are intended for the addressee(s) only and may be confidential. If you are not the
    intended recipient, please inform the sender by replying to the email that you have received in error and then destroy
    the email. If you are not the intended recipient, you must not use, disclose, copy or rely on the email or its attachments
    in any way.

    Wm Morrison Supermarkets PLC accepts no liability or responsibility for anything said in the email or its
    attachments and gives no warranty as to accuracy. It is the policy of Wm Morrison Supermarkets PLC not to enter
    into any contractual or other obligations by email.

    Although we have taken steps to ensure the email and its attachments are virus-free, we cannot guarantee this or
    accept any responsibility, and it is the responsibility of recipients to carry out their own virus checks.
  • Sweetser, Joe at Oct 13, 2008 at 2:56 pm
    In a nutshell, I think the answer is yes. Note they are NOT a
    requirement for all DG configurations, though.

    -joe

    From the DG Concepts & Administration manual:

    2.5.2 Standby Redo Logs

    A standby redo log is similar to an online redo log, except that a
    standby redo log is used to store redo data received from another
    database.

    A standby redo log is required if you want to implement:

    The maximum protection and maximum availability levels of
    data protection (described in Section 1.4 and in more detail in Section
    5.6)
    Real-time apply (described in Section 6.2)
    Cascaded destinations (described in Appendix E)

    A standby redo log provides a number of advantages:

    Standby redo log files can reside on raw devices, which may
    be important if either or both the primary and standby databases reside
    in a Real Application Clusters environment.
    Standby redo log files can be multiplexed using multiple
    members, improving reliability over archived log files.
    During a failover, Data Guard can recover and apply more redo
    data from standby redo log files than from the archived log files alone.
    The archiver (ARCn) process or the log writer (LGWR) process
    on the primary database can transmit redo data directly to remote
    standby redo log files, potentially eliminating the need to register a
    partial archived log file (for example, to recover after a standby
    database crashes). See Chapter 5 for more information.

    -----Original Message-----
    From: John.Hallas_at_morrisonsplc.co.uk

    Sent: Monday, October 13, 2008 8:42 AM
    To: Sweetser, Joe
    Cc: oracle-l_at_freelists.org
    Subject: RE: Data Guard question

    Why does that requirement for an additional srl exist? Is it so that the
    target system can always keep up

    John

    ----- wrote: -----

    To: Bradd Piontek,,

    From: "Sweetser, Joe" Sent by:

    Date: 13/10/2008 03:21PM
    cc: oracle-l
    Subject: RE: Data Guard question

    Not unexpectedly, it ended up be a combination of a few things:

    Not enough standby redo logs - recommended value is one more than
    the number of redo logs

    Wm Morrison Supermarkets PLC is registered in England with number
    358949. The registered office of the company is situated at Gain Lane,
    Bradford, West Yorkshire BD3 7DL.

    This email and any attachments are intended for the addressee(s) only
    and may be confidential. If you are not the intended recipient, please
    inform the sender by replying to the email that you have received in
    error and then destroy the email. If you are not the intended recipient,
    you must not use, disclose, copy or rely on the email or its attachments
    in any way.

    Wm Morrison Supermarkets PLC accepts no liability or responsibility for
    anything said in the email or its attachments and gives no warranty as
    to accuracy. It is the policy of Wm Morrison Supermarkets PLC not to
    enter into any contractual or other obligations by email.

    Although we have taken steps to ensure the email and its attachments are
    virus-free, we cannot guarantee this or accept any responsibility, and
    it is the responsibility of recipients to carry out their own virus
    checks.

    Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Holdings, LLC, Underwriters at Lloyd's, Syndicate 4242, scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.

    --
    http://www.freelists.org/webpage/oracle-l
  • Ray Stell at Oct 13, 2008 at 2:50 pm

    On Mon, Oct 13, 2008 at 08:21:19AM -0600, Sweetser, Joe wrote:
    2. Missing standby redo logs on the standby database - I expected RMAN
    to create/recreate the SRLs I had created in the primary but the files
    themselves were missing.
    I noticed on my last passed through this process that the need for the
    stby redo on the standby was not documented in the 11g docs (it explicitly
    says create them on the primary). I accidently saw a msg in the primary
    alert log sometime in the process of building the standby that said:

    Use the following SQL commands on the standby database to create
    standby redo logfiles that match the primary database:

    ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;

    I guess that counts as documentation :)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedOct 10, '08 at 3:51p
activeOct 13, '08 at 2:56p
posts6
users4
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase