DGMGRL: LogXptStatus - ORA-16810, ORA-16737 and ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

I have set up Data Guard on Oracle 10.2.0.3, the logs stopped applying out of the blue and DGMGRL configuration started throwing error:

Error:
DGMGRL> show configuration;

Configuration
Name: APL_primary
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
APL - Primary database
APLSTY - Physical standby database

Current status for "APL_primary":
Warning: ORA-16607: one or more databases have failed


DGMGRL> SHOW DATABASE 'APL' 'StatusReport';
STATUS REPORT
INSTANCE_NAME SEVERITY ERROR_TEXT
APL ERROR ORA-16737: the redo transport service for standby database "APLSTY" has an error
APL WARNING ORA-16715: redo transport-related property LogXptMode of standby database "APLSTY" is inconsistent

DGMGRL> SHOW DATABASE 'APL' 'LogXptStatus';
LOG TRANSPORT STATUS
PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME STATUS
APL APLSTY ORA-12514: TNS:listener does not currently know of service requested in connect descriptor 


Environment:
Oracle Database 10.2.0.3
Primary Database Unique Name: APL
Standby Database Unique Name: APLSTY
Database SID: APL
OS: HP UX Itanium 11.31

Solution:
Make sure the Primary logs are applied to the Standby before enabling the DGMGRL CLI.

Some solutions to try is bounce both Primary and Standby Database completely. Make sure the logs are available physically for the standby to apply. Check if you can connect via SQLPLUS and perform TNSPING to both APL-> APLSTY and vice versa.

Once the standby database is mounted,  Give the below command and it will apply all the logs.
ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE; 

Once all the logs are applied and the standby require the current logfile

SYS@APL SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active

SYS@APL SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Database altered.

SYS@APL SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

SYS@APL SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Database altered


To check the last log applied on standby:
SELECT THREAD#,MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED ='YES' GROUP BY THREAD#;

Now you need to make sure the service names are registered within the database.

Standby Database:
SYS@APL SQL>show parameter service

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      APLSTY
SYS@APL SQL>show parameter db_unique

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_unique_name                       string      APLSTY
SYS@APL SQL>alter system set service_names=APLSTY,APLSTY_XPT scope=both;

System altered.

SYS@APL SQL>show parameter service

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      APLSTY, APLSTY_XPT
SYS@APL SQL>


Primary Database:
SYS@APL SQL>show parameter service

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      APL
SYS@APL SQL>show parameter db_unique

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_unique_name                       string      APL
SYS@APL SQL>alter system set service_names=APL,APL_XPT scope=both;

System altered.

SYS@APL SQL>show parameter service

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
service_names                        string      APL, APL_XPT
SYS@APL SQL>


Once service_names are updated correctly, please restart/reload the listeners on both primary and standby. Test TNSPING, SQLPLUS and make sure logs are getting shipped.

Follow the 'Step By Step How to Recreate Dataguard Broker Configuration ( Doc ID 808783.1 )', to remove and create new DGMGRL configuration.

I made the following changes to the CREATE CONFIGURATION statement - instead of the tnsnames entry, I used the tns details with the configuration.

DGMGRL> CREATE CONFIGURATION 'APLCONF' AS PRIMARY DATABASE IS 'APL' CONNECT IDENTIFIER IS "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=apldb.vaidiyan.com)(PORT=1532)))(CONNECT_DATA=(SID=APL)))";
Configuration "APLCONF" created with primary database "APL"
DGMGRL> ADD DATABASE 'APLSTY' AS CONNECT IDENTIFIER IS "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=aplstbdb.vaidiyan.com)(PORT=1532)))(CONNECT_DATA=(SID=APL)))" MAINTAINED AS PHYSICAL;
Database "APLSTY" added
DGMGRL>

DGMGRL> show configuration;

Configuration
  Name:                APLCONF
  Enabled:             NO
  Protection Mode:     MaxPerformance
  Fast-Start Failover: DISABLED
  Databases:
    APL    - Primary database
    APLSTY - Physical standby database

Current status for "APLCONF":
DISABLED

DGMGRL> enable configuration;


Reference:
Script to Collect Data Guard Primary Site Diagnostic Information for Version 10g and above (Including RAC). ( Doc ID 1577401.1 )
Script to Collect Data Guard Physical and Active Standby Diagnostic Information for Version 10g and above (Including RAC) ( Doc ID 1577406.1 )
Step By Step How to Recreate Dataguard Broker Configuration ( Doc ID 808783.1 )

No comments:

Post a Comment