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;

Common issue in Golden Gate along with Solution

 Common issue in Golden Gate along with Solution

1. Processes Startup Issues
❗Problem:
GoldenGate processes (like Extract or Replicat) fail to start due to missing parameters, port issues, or environment settings.

🧪 Example:
GGSCI> start extract EXT1
ERROR: Missing required parameter: USERID
✅ Solution:
Check the parameter file:
GGSCI> edit params EXT1
Ensure you have the required lines like:
USERID ggs_admin, PASSWORD ggs_pwd
TABLE schema.table;
USERID ggs_admin, PASSWORD ggs_pwd
TABLE schema.table;
Also, make sure the GoldenGate home and environment variables (like LD_LIBRARY_PATH) are set correctly:
echo $ORACLE_HOME
echo $LD_LIBRARY_PATH
Check if the Manager process is running:
GGSCI> info mgr
GGSCI> start mgr

🔹 2. Data Not Getting Captured
❗Problem:
Extract is running but no data is captured in the trail files.

🧪 Example:
GGSCI> stats extract EXT1, totalsonly
Shows 0 inserts/updates/deletes even though source table has changes.

✅ Solution:
Check if the table is included in the Extract parameter file:
TABLE hr.employees;

Supplemental logging may not be enabled on the source:
ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
Check if the database is in ARCHIVELOG mode:
ARCHIVE LOG LIST;
Ensure DDL include/exclude rules aren't filtering it out.

🔹 3. Data Not Getting Applied onto Target DB
❗Problem:
Replicat is running, but target database is not getting updated.

🧪 Example:
GGSCI> stats replicat REP1, totalsonly
Shows 0 operations, even though trail files exist.

✅ Solution:
Check if trail file path is correct in Replicat parameters:
EXTTRAIL ./dirdat/aa
Validate table mapping:
MAP hr.employees, TARGET hr.employees;
Check for errors in the report file:
GGSCI> view report REP1
Use logdump to inspect the trail file and confirm it contains valid data.

🔹 4. Data Integrity Issues
❗Problem:
Rows are missing, duplicated, or mismatched between source and target.

🧪 Example:
Target has duplicate rows or missing foreign key entries.

✅ Solution:
Use HANDLECOLLISIONS temporarily for mismatch scenarios during initial sync:
HANDLECOLLISIONS
Use Oracle GoldenGate Veridata or run SQL MINUS to compare source/target data:
SELECT * FROM source_table
MINUS
SELECT * FROM target_table;
If using bidirectional replication, enable REPERROR (default, discard) to avoid looping conflicts and use TRIGGERSUPPRESS.

Use BATCHSQL in Replicat for better performance and consistency on large updates.