{"id":4515,"date":"2015-04-08T15:11:00","date_gmt":"2015-04-08T13:11:00","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/dataguard-wait-events-have-changed-in-12c\/"},"modified":"2015-04-08T15:11:00","modified_gmt":"2015-04-08T13:11:00","slug":"dataguard-wait-events-have-changed-in-12c","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/dataguard-wait-events-have-changed-in-12c\/","title":{"rendered":"DataGuard wait events have changed in 12c"},"content":{"rendered":"

By Franck Pachot<\/h2>\n

.
\nThere 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.
\nHere 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’
\nThat 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:<\/p>\n

11g Top 5 Timed Foreground Events<\/h4>\n\n\n\n\n\n\n\n\n
Event<\/th>\nWaits<\/th>\nTime(s)<\/th>\nAvg wait (ms)<\/th>\n% DB time<\/th>\nWait Class<\/th>\n<\/tr>\n
log file sync<\/td>\n17,002<\/td>\n21,113<\/td>\n1242<\/td>\n46.08<\/td>\nCommit<\/td>\n<\/tr>\n
log buffer space<\/td>\n1,322<\/td>\n8,583<\/td>\n6493<\/td>\n18.73<\/td>\nConfiguration<\/td>\n<\/tr>\n
buffer busy waits<\/td>\n1,869<\/td>\n4,376<\/td>\n2342<\/td>\n9.55<\/td>\nConcurrency<\/td>\n<\/tr>\n
enq: TX – row lock contention<\/td>\n997<\/td>\n2,105<\/td>\n2111<\/td>\n4.59<\/td>\nApplication<\/td>\n<\/tr>\n
DB CPU<\/td>\n<\/td>\n1,773<\/td>\n<\/td>\n3.87<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

then we have to go to the background event section in order to see what the LGWR was waiting on:<\/p>\n

Background Wait Events<\/h3>\n\n\n\n\n\n\n\n\n\n\n
Event<\/th>\nWaits<\/th>\n%Time -outs<\/th>\nTotal Wait Time (s)<\/th>\nAvg wait (ms)<\/th>\nWaits \/txn<\/th>\n% bg time<\/th>\n<\/tr>\n
LNS wait on SENDREQ<\/td>\n17,674<\/td>\n0<\/td>\n2,103<\/td>\n119<\/td>\n1.04<\/td>\n37.50<\/td>\n<\/tr>\n
LGWR-LNS wait on channel<\/td>\n153,447<\/td>\n88<\/td>\n2,094<\/td>\n14<\/td>\n9.03<\/td>\n37.34<\/td>\n<\/tr>\n
log buffer space<\/td>\n17<\/td>\n0<\/td>\n114<\/td>\n6723<\/td>\n0.00<\/td>\n2.04<\/td>\n<\/tr>\n
db file parallel write<\/td>\n52,931<\/td>\n0<\/td>\n105<\/td>\n2<\/td>\n3.12<\/td>\n1.87<\/td>\n<\/tr>\n
enq: CF – contention<\/td>\n16<\/td>\n0<\/td>\n78<\/td>\n4865<\/td>\n0.00<\/td>\n1.39<\/td>\n<\/tr>\n
log file switch completion<\/td>\n4<\/td>\n0<\/td>\n63<\/td>\n15640<\/td>\n0.00<\/td>\n1.12<\/td>\n<\/tr>\n
log file sync<\/td>\n6<\/td>\n0<\/td>\n55<\/td>\n9102<\/td>\n0.00<\/td>\n0.9<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In 11g the LNS processes \u00a0(Log Network Server) is responsible to send redo to the standby.
\nBecause we are in SYNC we wait for remote acknowlegement.
\nNothing new here. But let’s see what has changed in 12c.<\/p>\n

12c<\/h3>\n

In 12c the name of the processes have changed. It’s not LNS anymore, but:<\/p>\n