How to Setup non SYS user for Data Guard REDO Transport (Doc ID 3003590.1)

Oracle Database - Enterprise Edition - Version 19.22.0.0.0 and later
Information in this document applies to any platform.

GOAL

The article explains step by step method to setup the DATA GUARD REDO transport with the non SYS user using the parameter REDO_TRANSPORT_USER.
 

SOLUTION

1. Create user for the REDO transport on Primary/PROD,

SQL> create user identified by manager;
SQL> grant connect,sysoper to ;

2. Grants necessary Privilege,

The value of this parameter is case sensitive and must exactly match the value of the USERNAME column of a row in the V$PWFILE_USERS view. The value of the SYSOPER column of the row must also be TRUE.

If this parameter is not specified, then the paswd verifier of the SYS user will be used when a remote paswd file is used for redo transport authentication.

SQL> col username format a22
SQL> select USERNAME, SYSDBA, SYSOPER, SYSBACKUP, SYSDG, SYSKM from V$PWFILE_USERS where USERNAME = '';

3. Assign the created user for REDO transport,

SQL> alter system set redo_transport_user='';

4. Check the REDO transport,

The following select will show any errors.If ERROR is blank and status is VALID then no issue on REDO transport.

SQL> SELECT thread#, dest_id, gvad.status, error, fail_sequence FROM gv$archive_dest gvad, gv$instance gvi WHERE gvad.inst_id = gvi.inst_id AND destination is NOT NULL ORDER BY thread#, dest_id;

SQL> SELECT gvi.thread#, timestamp, message FROM gv$dataguard_status gvds, gv$instance gvi WHERE gvds.inst_id = gvi.inst_id AND severity in ('Error','Fatal') ORDER BY timestamp, thread#;

The following query will determine the current sequence number and the last sequence archived.
If you are remotely archiving using the LGWR process then the archived sequence should be one higher than the current sequence.
If remotely archiving using the ARCH process then the archived sequence should be equal to the current sequence.
The applied sequence information is updated at log switch time. The "Last Applied" value should be checked with the actual last log applied at the standby, only the standby is guaranteed to be correct.

SQL> SELECT cu.thread#, cu.dest_id, la.lastarchived "Last Archived", cu.currentsequence "Current Sequence", appl.lastapplied "Last Applied" FROM (select gvi.thread#, gvd.dest_id, MAX(gvd.log_sequence) currentsequence FROM gv$archive_dest gvd, gv$instance gvi WHERE gvd.status = 'VALID' AND gvi.inst_id = gvd.inst_id GROUP BY thread#, dest_id) cu, (SELECT thread#, dest_id, MAX(sequence#) lastarchived FROM gv$archived_log WHERE resetlogs_change# = (SELECT resetlogs_change# FROM v$database) AND archived = 'YES' GROUP BY thread#, dest_id) la, (SELECT thread#, dest_id, MAX(sequence#) lastapplied FROM gv$archived_log WHERE resetlogs_change# = (SELECT resetlogs_change# FROM v$database) AND applied = 'YES' GROUP BY thread#, dest_id) appl WHERE cu.thread# = la.thread# AND cu.thread# = appl.thread# AND cu.dest_id = la.dest_id AND cu.dest_id = appl.dest_id ORDER BY 1, 2;