Learning About Data Guard - Expert Consolidation in Oracle Database 12c - page 319

A further milestone was reached with Oracle 9 i , which introduced the logical standby database and graceful
switchover operations. The previously used standby databases were renamed to physical standby database. It was
also in Oracle 9 i that the standby database feature was renamed to Data Guard. Users of Data Guard were also
given another choice for transmitting redo information to the standby. In addition to the archiver process, which
traditionally shipped information to the standby database after an online redo log was archived, the log writer
process could be used to perform the same task. Standby redo logs were introduced as the counterpart to the primary
database's online redo logs. Instead of having to wait for a complete archived redo log to arrive, the redo stream
could be written into a standby redo log, thus reducing the risk of data loss. Oracle Database 9 i also introduced the
Data Guard broker with support for Enterprise Manager, as well as a command-line tool to simplify the setup and
management of standby databases.
Another noteworthy evolution came with Oracle 10g, when the Real Time Apply feature was integrated into the
database kernel. Using standby redo logs on the standby database server, the redo stream arriving on the destination
could be applied to the standby database immediately, without having to wait for the standby redo log to be archived
and applied. This further reduces the possibility of data loss.
Oracle 11.1 refined the process. Redo could now be compressed for gap resolution, and there was limited
support for heterogeneous Data Guard configurations involving Linux and Windows, and HP-UX. A new type
of standby database has been added to the previously mentioned physical and logical standby databases called
snapshot standby which is covered in more detail below. It was also in Oracle 11.1 that Active Data Guard was
introduced.
Oracle 11.2 extended the number of standby database drastically: up to 30 standby databases are possible, and
Active Data Guard has been enhanced to perform automatic block media recovery and the redo stream can also be
compressed (if you have the necessary license).
Figure 9-1 illustrates the concept which applies since Oracle 11g: redo generated by user activity on the
primary database is transported via the LNS n processes to the standby database's Remote File Server (RFS)
process. Actually it is not the LNS process although it appears as such in v$managed_standby. The processes
for sending redo are now named TT nn for if redo shipping is performed asynchronously. Synchronous redo
transmission will see the LNS n /TT nn processes replaced by LGWR in v$managed_standby.