LNS wait on SENDREQ Wait Event

LNS wait on SENDREQ means that redo data has not been written to all ASYNC and SYNC redo transport destinations and that the processes on primary databases are waiting. This is basically a network related wait event which means that tuning the network may be beneficial to remove this wait event. The LNS wait on SENDREQ can happen with either the SYNC or ASYNC LGWR attributes.  When using ASYNC transport mode in Oracle 10g r2 and beyond, Oracle recommends allowing for sufficient I/O bandwidth for LNS read I/Os to the online redo logs of the production database.

As per Oracle Doc LNS wait on SENDREQ means :- Total time spent waiting for redo data to be written to all ASYNC and SYNC redo transport destinations.

There can be multiple ways to tune it :-

1) The very first way to tune is to optimize the network, You can set SDU (SESSION DATA UNIT) parameter within an Oracle Net connect descriptor or globally within the sqlnet.ora. For Data Guard broker configurations configure the DEFAULT_SDU_SIZE parameter in the sqlnet.ora file:

DEFAULT_SDU_SIZE=32767

2) Tuning tNS layer for the tcp.nodelay parameter in the protocol.ora file

3) Get a faster network transport such as dark fibre.

4) Change the size of the online redo logs to make the archived redo log smaller, thereby creating smaller archived redo logs.  This will create more frequent, smaller redo log transports that will complete faster.

Monitoring Synchronous Redo Transport Response Time

The V$REDO_DEST_RESP_HISTOGRAM view contains response time data for each redo transport destination. This response time data is maintained for redo transport messages sent via the synchronous redo transport mode.

The data for each destination consists of a series of rows, with one row for each response time. To simplify record keeping, response times are rounded up to the nearest whole second for response times less than 300 seconds. Response times greater than 300 seconds are round up to 600, 1200, 2400, 4800, or 9600 seconds.

Each row contains four columns: FREQUENCY, DURATION, DEST_ID, and TIME.

The FREQUENCY column contains the number of times that a given response time has been observed. The DURATION column corresponds to the response time. The DEST_ID column identifies the destination. The TIME column contains a timestamp taken when the row was last updated.

The response time data in this view is useful for identifying synchronous redo transport mode performance issues that can affect transaction throughput on a redo source database. It is also useful for tuning the NET_TIMEOUT attribute.