ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

This will allow you to do real-time apply, rather than waiting for a log switch.
Creating standby redo logs allows the current redo log on the primary to be written to the standby redo logs on the physical standby.
Data loss is therefore timed in the seconds if you need to failover.

Always create 1 more standby redo log group than the number of redo log groups on the primary.
It is best practice to create them on the primary database as well (in case of switchover).

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 ('F:\ORADATA\DUBETECH\STANDBY10A.LOG') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 ('F:\ORADATA\DUBETECH\STANDBY11A.LOG') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 ('F:\ORADATA\DUBETECH\STANDBY12A.LOG') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 ('F:\ORADATA\DUBETECH\STANDBY13A.LOG') SIZE 50M;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

On Primary Database …

ALTER SYSTEM SWITCH LOGFILE;

Transport and Apply Lag should now always be 0 seconds.

It is very easy to accidentally open a Physical Standby database and doing so records use of Active Data Guard.
You would then need to recreate the physical standby in order to remove this usage from the Oracle views.
There is however an unsupported way to stop this occurring.
I'm not recommending that this is implemented but it is a nice feature to know.
Use a hidden initialisation parameter called “_query_on_physical” and set this to FALSE.
Now if you attempt to open the Physical Standby database you will get the following error message …

ORA-16669: instance cannot be opened because the Active Data Guard option is disabled