Of course, Standby Redo Logs are obligatory if you are using a protection level of Maximum Protection or Maximum Availability, but I think any dba who is even using a dataguard configuration with a protection level of maximum performance would be nuts to not use Standby Redo Logs (SRLs). If it’s all about protecting the data, then basically you will lose less data in the event of having to perform a failover if your configuration has SRLs. When you throw into the mix the ability to send the redo via LGWR you can set up your dataguard environment to provide a high degree of data protection with an absolutely minimal impact on your primary database. When you are using SRLs, the LGWR process on the primary talks to the RFS process on the standby which is responsible for writing the redo information to disk, and it’s therefore the RFS process which writes the information to the SRLs.
Sure, if you need an absolute guarantee of NO data loss then maximum performance may not be the acceptable mode for your organisation, but if you can live with a small window of data loss then maximum performance combined with LGWR transmission and SRLs may be the sweet spot for you. On a 10.2 system running LGWR ASYNC with a Round Trip Time (RTT) of around 15ms between primary and standby sites, I typically see a redo transport lag of a handful of seconds. You also can only use the real time apply mode if you are using SRLs, and this may (or may not) be an added benefit for you.
The syntax for creating your SRLs is very similar to that for creating the online redo logs:
sql> alter database add standby logfile thread 1 group 42 ‘/path/to/logfile’ size 512M;
To delete them:
sql> alter database drop standby logfile group 42;
You can find out information on how the SRLs are configured on your system by looking at the V$logfile or the V$standby_log views.