ORA-16532: Data Guard broker configuration does not exist

Cause: A broker operation was requested that required a broker configuration to already be created.

Action: Create a Data Guard broker configuration prior to performing other broker operations.

 Dataguard broker yaratırken standby database'de oluşan hatadır. Çözümü oldukça basit :

  SQL> show parameter dg_

  NAME                                 TYPE        VALUE
  ------------------------------------ ----------- ------------------------------
  dg_broker_config_file1               string
  dg_broker_config_file2               string
  dg_broker_start                      boolean     TRUE

  SQL> alter system set dg_broker_start=false;

  System altered.

  SQL> alter system set dg_broker_config_file1='C:\app\oracle\product\11.2.0\dbhome_1\database\DRESK01.dat';

  System altered.

  SQL> alter system set dg_broker_config_file2='C:\app\oracle\product\11.2.0\dbhome_1\database\DRESK02.dat';

  System altered.

  SQL> alter system set dg_broker_start=true;

  System altered.

Bundan sonra DGMGRL komut satırından tekrar konfigürasyon enable edilir.

  DGMGRL-> enable configuration;

ORA-16829 fast-start failover configuration is lagging

Cause: The fast-start failover target standby database was not within the lag limit specified by the FastStartFailoverLagLimit configuration property. As a result, a fast-start failover could not happen in the event of a primary database failure.

Action: Ensure that the fast-start failover target standby database is running and applying redo data and that the primary database is successfully trasmitting redo data. If this condition persists consider raising the value of the FastStartFailoverLagLimit configuration property.

  
 Lag Limit ile ilgili bir sorun olduğunu göstermekte, yapılacak işlem, diğer hususlarda bir sorun görümüyorsa, LagLimiti biraz artırmak olacaktır :

DGMGRL -> edit configuration set property FastStartFailoverLagLimit =45;

ORA-16571: Data Guard configuration file creation failure

            Tanımı

Cause: The Data Guard broker was unable to create the configuration file on permanent storage.

Action: Verify space, permissions and file name as indicated by the DG_BROKER_CONFIG_FILE[1|2] initialization parameters and retry the operation.

Çözümü

Dataguard broker yaratırken oluşan hatadır. Çözümü oldukça basit :

  SQL> show parameter dg_

  NAME                                 TYPE        VALUE
  ------------------------------------ ----------- ------------------------------
  dg_broker_config_file1               string
  dg_broker_config_file2               string
  dg_broker_start                      boolean     TRUE
  SQL> alter system set dg_broker_start=false;

  System altered.

  SQL> alter system set dg_broker_config_file1='C:\app\oracle\product\11.2.0\dbhome_1\database\DRAAA01.dat';

  System altered.

  SQL> alter system set dg_broker_config_file2='C:\app\oracle\product\11.2.0\dbhome_1\database\DRAAA02.dat';

  System altered.

  SQL> alter system set dg_broker_start=true;

  System altered.
 

ORA-16826 Apply service state is inconsistent with the DelayMins property

ORA-16826: apply service state is inconsistent with the DelayMins property

Cause: This warning was caused by one of the following reasons:

- The apply service was started without specifying the real-time apply option or without the NODELAY option when the DelayMins property was set to zero.

- The apply service was started with the real-time apply option or with the NODELAY option when the DelayMins property was set to a value greater than zero.

Action: Reenable the standby database to allow the broker to restart the apply service with the apply options that are consistent with the specified value of the DelayMins property.

Solution  :

First look at dataguard broker file :
if the error is that :

DG 2008-10-27-12:29:46 0 2 0 RSM: Redo Apply is running without USING CURRENT LOGFILE option while DelayMins=0

 Then, On standby database disable redo apply  :

 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL ;

and enable with this:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

if problem is not solved, you may try these commands on standby database :

 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL ;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT NODELAY;

if problem is still not solved, you may try more cruel solution :

DGMGRL -> disable configuration;
DGMGRL -> enable configuration;

How to resolve MRP stuck issues on a physical database

Solution

Cause 1 : Log transport issues.

Solution 1: Please see NOTE:799353.1 - How to Resolve Error in Remote Archiving

Cause 2 : Firewall caused partial archive log transferred.

Solution 2: Please make sure the following firewall features are disabled.

Cause 3 : ARC process on the primary that is responsible for the heartbeat sticks on the network due to bug 6113783

Solution 3: The bug 6113783 was fixed in 11.2.0.2. You could workaround the issue by killing the arch processes on the primary database.

Cause 4. The standby recovery asked for old sequence # that had been applied to the standby.

Solution 4 : Apply the fix of bug 6029179 or kill the heartbeat arch process of each primary instance if the primary is a RAC database.

Cause 5 Recover from the wrong location. 

Solution 5 Specify standby_archive_dest the same location as log_archive_dest_1 on the physical standby. Use from 'location' attribute in the manual recovery clause. 

Cause 6: All standby redo log files are active on the standby database.

Solution 6: Please make sure you have enough space in the archive location.
log_archive_dest_1 is defined with proper valid_for values and db_unique_name.
standby_archive_dest is specified properly.

Cause 7 : Partial archive log file is applied on the standby database.

Solution 7 Use rman incremental backup method to roll forward your physical standby database.

Cause 8 : The archive log files were transferred to the standby manually, not through data guard log transport service.

Solution 8 Register those archive log files or use manual recovery.

Cause 9 : The archive log files are deleted from the primary before they are shipped and applied to the standby.

Solution 9 Restore archive log files from backup, register them and use managed recovery to recover them; or use manual recovery without registering them.

Cause 10 : New datafiles are added to the primary, but they are not added to the standby automatically.

Solution 10 Add the new datafiles to the standby database manually.

Cause 11 : MRP can stall after control file contention at the standby.

Solution 11 This is fixed in 10.2.0.4. The workaround is to restart the standby.