[Oracle-l] 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

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.

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.

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.

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 :)