ora 16778 redo transport error

 ORA-16778: redo transport error means the Data Guard broker can't send redo logs to standby(s), usually due to network issues, incorrect TNS/listener settings, missing executables, or parameter conflicts, requiring checks in the Alert Log, Broker Log, v$archive_dest_status, and confirming TNS entries on both primary/standby, often resolved by fixing TNS connectivity or restarting processes. 

Common Causes & Solutions:

1. Network Connectivity/TNS Issues:
   • Check: tnsping from primary to standby and vice-versa; check tnsnames.ora and listener.ora for correct hostnames/IPs/ports.
   • Fix: Ensure hostnames resolve, TNS entries match, and listeners are running on both sides.
2. Data Guard Broker Configuration Errors:
   • Check: Use DGMGRL > SHOW CONFIGURATION and SHOW DATABASE for detailed status, check broker log (location varies by Oracle version).
   • Fix: Sometimes a simple restart or re-adding the standby via DGMGRL (after cleaning up duplicates) can resolve broker state issues.
3. Missing or Incorrect Executables/Parameters:
   • Check: Verify necessary Oracle executables (like arcn/arcf for LGWR/ARCn processes) exist and permissions are correct on the standby.
   • Fix: Ensure LOG_ARCHIVE_DEST_n parameters are correctly set on the primary to point to the standby, and FAL_SERVER/FAL_CLIENT are set on both.
4. Primary/Standby State Mismatch:
   • Check: In DGMGRL, see if the standby is disconnected (ORA-16857).
   • Fix: Try ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; and then restart recovery, or even SHUTDOWN and STARTUP the standby. 

Diagnostic Steps:

1. Check Alert Logs: Look for related errors like ORA-12541 (no listener) or network errors in both primary and standby alert_<sid>.log files.
2. Query V$ARCHIVE_DEST_STATUS: On the primary, check this view for specific errors on the standby destination.
3. Use DGMGRL: SHOW CONFIGURATION, SHOW DATABASE, SHOW LOGFILE for status.
4. Verify TNS: Ensure connectivity is solid with tnsping. 

Golden Gate – Extract and Replicat Checkpoint

 In Oracle GoldenGate, checkpoints in the Extract and Replicat processes ensure data consistency and fault tolerance. They record read/write positions, allowing processes to resume after failures without data loss. Checkpoints can be stored in checkpoint tables or files, helping optimize performance and monitor replication progress effectively.

Understanding Checkpoints in Oracle GoldenGate Extract and Replicat

In Oracle GoldenGate, a checkpoint in the Extract process is a mechanism used to record the current read and write positions in the data stream. This ensures data consistency, fault tolerance, and recovery in case of failures.

 What is a Checkpoint in Extract?

A checkpoint is a record of the current position in the source database’s transaction log (like the redo log in Oracle or transaction log in SQL Server) that the Extract process has read and processed.

 Purpose of Checkpoints

1. Fault Tolerance: If the Extract process stops or crashes, it can resume from the last checkpoint instead of starting over.
2. Data Consistency: Ensures that no transactions are missed or duplicated.
3. Performance Optimization: Helps manage memory and disk usage by purging old data that has already been processed.

 Types of Checkpoints in Extract

1. Read Checkpoint:
   • Marks the position in the transaction log where Extract last read.
   • Ensures Extract knows where to resume reading after a restart.
2. Write Checkpoint:
   • Marks the position in the trail file where Extract last wrote data.
   • Ensures that data is not written twice or skipped.

 Where Are Checkpoints Stored?

• Checkpoint Table (recommended): A table in the database that stores checkpoint information.
• Checkpoint Files: Local files on disk used when a checkpoint table is not configured.

 How It Works (Simplified Flow)

1. Extract reads from the source database log.
2. It processes the data and writes it to a trail file.
3. After writing, it updates the checkpoint to reflect the new position.
4. If Extract is restarted, it resumes from the last checkpoint.

Check the restore point with the following command:

Info all   -- Give all process running
OR 

INFO <extract_name> showch

OR 

INFO EXTRACT <extract_name>, SHOWCH

Give information as:

• Current read and write checkpoint positions
• Trail file details
• Recovery checkpoint
• Oldest unprocessed transaction
• Checkpoint table (if used)

What is a Replicat Checkpoint?

A Replicat checkpoint records the position in the trail file from which the Replicat process last successfully applied a transaction to the target database.

 Purpose of Replicat Checkpoints

1. Recovery: If Replicat stops or crashes, it can resume from the last checkpoint without reapplying already committed transactions.
2. Data Integrity: Prevents duplication or loss of data during replication.
3. Monitoring: Helps administrators track replication lag and performance.

Types of Checkpoints in Replicat

1. Read Checkpoint:
   • The position in the trail file that Replicat has read up to.
2. Write Checkpoint:
   • The position in the target database where Replicat has successfully applied changes.

Where Are Replicat Checkpoints Stored?

• Checkpoint Table (recommended): A table in the target database.
• Checkpoint Files: Local files on disk (used if checkpoint table is not configured). Checkpoint files on disk in the dirchk sub directory of the Oracle Golden Gate directory.

Use this command in GGSCI:

INFO REPLICAT <replicat_name>, SHOWCH

Note: Replicat keeps track of the last CSN/SCN from the source that has been applied to the target using a checkpoint.

Check checkpoint table at target database:

SELECT GROUP_NAME,GROUP_KEY,LAST_UPDATE_TS,LOG_CSN,LOG_CMPLT_CSN from gguser.chkpt;

RESTORE A LOSS OF CONTROLFILES USING AUTOBACKUP IN ORACLE 19C#

 #Rsolve ORA-00210,ORA-00202,ORA-27041 AND RESTORE A LOSS OF CONTROLFILES USING AUTOBACKUP IN ORACLE 19C#

step 1: Check the RMAN configuration and control file and back-up feature is ON.

SQL> rman target /
RMAN> show all;

status: CONFIGURATION CONTROLFILE AUTOBACKUP ON;

step 2: simulate a failure to remove the control file when the database is running.

SQL>select name from v$controlfile;
host>cd /u01/app/oracle/INDBBA
host> rm -rf controlfile1.ctl
host>rm -rf controlfile02.ctl

then check the status of control files:

SQL>SELECT TABLESPACE _NAME FRON DBA_DATA_FILES;
SQL>SHUTDOWN IMMEDIATE;
ORA-00210 : cannot open the specified control file.
SQL>SHUT ABORT;
ORACLE instance shut down

step 3: keep the database in NOMOUNT stage and restore the controlfile.

SQL>STARTUP NOMOUNT;

step 4: since we are not using a RMAN CATLOG we need to to set the DBID.
host> rman target /
RMAN> SET DBID=936024966;
RMAN>restore controlfile from AUTOBACKUP;

step 5: mount and recover the database

RMAN> ALTER DATABASE NOMOUNT;
RMAN> RECOVER DATABASE;

step 6: open the database using restogs option

RMAN> alter database open resetlogs;
SQL>STARTUP NOMOUNT;
SQL>SELECT OPEN_MODE, NAME FRON V$DATABASE;