Log Transport Service
主节点上，日志传输服务主要使用如下几个进程：
1、LGWR
LGWR搜集事务日志，并且更新联机日志。在同步模式下，LGWR直接将redo信息直接传送到备库中的RFS进程，主库在继续进行处理前需要等待备库的确认。在非同步情况下，也是直接将日志信息传递到备库的RFS进程，但是不等待备库的确认信息主库进程可以继续运行处理。
2、ARCH
ARCHn或者是一个SQL session执行了一个归档操作，为了恢复的需要，创建了一个联机日志的拷贝。Archn进程可以在归档的同时，传递日志流到备库的RFS进程。该进程还用于前瞻性检测和解决备库的日志不连续问题(GAP)。
3、FAL
Fetch archive log 只有物理备库才有该进程。
FAL进程提供了一个client/server的机制，用来解决检测在主库产生的连续的归档日志，而在备库接受的归档日志不连续的问题。 该进程只有在需要的时候才会启动，而当工作完成后就关闭了，因此在正常情况下，该进程是无法看见的。 我们可以设置通过LGWR，ARCH进程去传递日志到备库，但是不能两个进程同时传送。
该进程是如何交互的呢？fal_client,fal_server参数的。
Log Apply Service
备库节点上，日志应用进程主要使用如下的进程：
1、RFS remote file server
Rfs进程主要用来接受从主库传送过来的日志信息。对于物理备用数据库而言，RFS进程可以直接将日志写进备用重做日志，也可以直接将日志信息写到归档日志中。为了使用备库重做日志，我们必须创建他们，一般和主库的联机日志大小以及组一样。
2、Arch
只对物理备库，arch进程归档备库重做日志，这些日志以后将被MPR进程应用到备库。
3、MRP managed recovery process
& nbsp
该进程只针对物理备库。该进程应用归档日志到备库。如果我们使用SQL语句启用该进程ALTER DATABASE RECOVER MANAGED STANDBY DATABASE，那么前台进程将会做恢复。如果加上disconnect语句，那么恢复过程将在后台进程，发出该语句的进程可以继续做其他的事情。
4、LSP logical standby process
只有逻辑备库才会有该进程。LSP进程控制着应用归档日志到逻辑备用数据库。