Oracle data Guard status (active/passive)- version 11g

Question

I have 2 servers: Primary (ABCUAT) and Standby (ABCUAT1) configured as Active-Standby DataGuard by previous DBA.

When I took over the system, I think DataGuard was not in sync, but I could not confirm that because the Archive Log List gives me the same log sequence on both server.

Questions:

1. If DataGuard is not in sync, why does the Archive log list show the same sequence number in both server? I thought if the sequence number were the same, it meant the log have been applied to the standby database.
2. How to resume DataGuard if not in sync? The gap seem to be huge according to max(sequence#).

3. I tried to delete some old archive log files with RMAN> delete noprompt expired archivelog all; but got in response:

   specification does not match any archived log in the repository,

   but physically in the directory there are 50GB of files dated year 2018.

Findings:

SYS@ABCUAT>archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     190144
Next log sequence to archive   190146    
Current log sequence           190146

Standby server :

SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     190144
Next log sequence to archive   0
Current log sequence           190146

Primary:

SYS@ABCuat>select max(sequence#) from v$log_history

MAX(SEQUENCE)   190251

Standby server :

SQL> select max(sequence) from v$log_history

MAX(SEQUENCE#)   7421

DataGuard configuration:

DGMGRL> show configuration;
Configuration - dg_config
  Protection Mode: MaxAvailability

  Databases:
    ABCUAT  - Primary database
      Warning: ORA-16629: database reports a different protection level from the protection mode
    ABCUAT1 - Physical standby database (disabled)
Fast-Start Failover: DISABLED

Configuration Status:
WARNING

DGMGRL> show database ABCUAT1

Database - ABCUAT1

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   (unknown)
  Apply Lag:       (unknown)
  Apply Rate:      (unknown)
  Real Time Query: OFF
  Instance(s):
O    ABCUAT1

Answer 1

1. No. The redo (archivelogs) can be transported without applying it on the standby.
2. sequence# alone is not enough. You need to consider resetlogs_change# too.
3. An expired archivelog entry is an archivelog entry that exists in the controlfile, but it does not exist on the disk or the database is unable to access it. Such a command does not delete archivelogs from the filesystem.

The standby database was disabled in the broker configuration. Enable it in dgmgrl:

enable database ABCUAT1;

If you are in luck and the standby has all the necessary logs, it will start processing them and it will eventually catch up to the primary. You should see a decreasing transport/apply lag value instead of unknown. If it is unable to do so, newer errors will be shown.

At this point you may have everything on the standby site which just needs processing. Or you could also have an archive gap when the standby is unable to continue due to missing logs, which you can resolve by restoring the missing logs or rolling forward the standby with an incremental backup or rebuilding the standby. Or the standby could be in a totally different state, like a snapshot standby, without the broker being aware of it.