DataGuard wait events have changed in 12c:

There are several new features in 12c about Data Guard: cascaded standby, far sync instance. But there are also some architecture changes: new processes and new wait events.
Here is an example of an AWR report of a LogXptMode=’SYNC’ DataGuard configuration in 11g – which means that the log_archive_dest is defined with: ‘LGWR SYNC AFFIRM’
That report comes from a period of time where the primary database was stuck because the standby server had a problem. It’s 11.2.0.2 and the foreground events show that the user sessions are waiting on LGWR:

11g Top 5 Timed Foreground Events

EVENT	WAITS	TIME(S)	AVG WAIT (MS)	% DB TIME	WAIT CLASS
log file sync	17,002	21,113	1242	46.08	Commit
log buffer space	1,322	8,583	6493	18.73	Configuration
buffer busy waits	1,869	4,376	2342	9.55	Concurrency
enq: TX – row lock contention	997	2,105	2111	4.59	Application
DB CPU		1,773		3.87

then we have to go to the background event section in order to see what the LGWR was waiting on:

Background Wait Events

EVENT	WAITS	%TIME -OUTS	TOTAL WAIT TIME (S)	AVG WAIT (MS)	WAITS /TXN	% BG TIME
LNS wait on SENDREQ	17,674	0	2,103	119	1.04	37.50
LGWR-LNS wait on channel	153,447	88	2,094	14	9.03	37.34
log buffer space	17	0	114	6723	0.00	2.04
db file parallel write	52,931	0	105	2	3.12	1.87
enq: CF – contention	16	0	78	4865	0.00	1.39
log file switch completion	4	0	63	15640	0.00	1.12
log file sync	6	0	55	9102	0.00	0.9

In 11g the LNS processes  (Log Network Server) is responsible to send redo to the standby.
Because we are in SYNC we wait for remote acknowlegement.
Nothing new here. But let’s see what has changed in 12c.

12c

In 12c the name of the processes have changed. It’s not LNS anymore, but:

• NSS ships the redo from LGWR to remote standby when we are in SYNC
• NSA ships the redo from online redo logs to standby when we are in ASYNC

and you will see new wait events for them:

• ‘SYNC Remote Write’ for all redo transport waits done by NSS processes
• ‘ASYNC Remote Write’ for all redo tranport waits done by NSA processes

Note that since 11gR2 the writing to online redo logs and to standby are done in parallel. Then, if your network latency is smaller than your disk latency on primary, then you have absolutely no overhead to be in SYNC. You can be in SYNC NOAFFIRM so that the disk latency at standby site do not increase the ‘SYNC Remote Write’ wait. In 12c you can have that in a MaxAvailability configuration with Far Sync Standby.

SYNC Remote Write

So what is the 12c equivalent of the following waits that are symptomatic of SYNC latency:

• LGWR waiting on LNS – wait event ‘LGWR-LNS wait on channel’
• LNS waiting on standby – wait event ‘LNS wait on SENDREQ’

Here they are in picture (using Orachrome Lighty):

• The LGWR is waiting on NSS – wait event is ‘SYNC Remote Write':

• NSS is waiting on redo transport:

If you were monitoring for ‘LNS’ wait events, you have to change it.
Here is the new pattern in an AWR report:

EVENT	WAITS	%TIME -OUTS	TOTAL WAIT TIME (S)	AVG WAIT (MS)	WAITS /TXN	% BG TIME
log buffer space	7	0	896	128023.85	0.00	58.96
SYNC Remote Write	129	0	300	2322.96	0.00	19.72
buffer busy waits	2	0	287	143596.94	0.00	18.89
log file parallel write	116	0	6	48.02	0.00	0.37
Data Guard Broker Wait	5	100	5	1000.26	0.00	0.33
Redo Transport MISC	110	0	2	22.70	0.00	0.16

==========================================================================================