Subscribe to Posts by Email

Subscriber Count

    701

Disclaimer

All information is offered in good faith and in the hope that it may be of use for educational purpose and for Database community purpose, but is not guaranteed to be correct, up to date or suitable for any particular purpose. db.geeksinsight.com accepts no liability in respect of this information or its use. This site is independent of and does not represent Oracle Corporation in any way. Oracle does not officially sponsor, approve, or endorse this site or its content and if notify any such I am happy to remove. Product and company names mentioned in this website may be the trademarks of their respective owners and published here for informational purpose only. This is my personal blog. The views expressed on these pages are mine and learnt from other blogs and bloggers and to enhance and support the DBA community and this web blog does not represent the thoughts, intentions, plans or strategies of my current employer nor the Oracle and its affiliates or any other companies. And this website does not offer or take profit for providing these content and this is purely non-profit and for educational purpose only. If you see any issues with Content and copy write issues, I am happy to remove if you notify me. Contact Geek DBA Team, via geeksinsights@gmail.com

Pages

Dataguard : Network Tuning Parameters

Whilst, was working on a dataguard network performance issue thought should write something on this.

The most important aspect of the dataguard is network transport, and if the undersized or improper configuration may lead to the redo transport issue and production may show you the log synch waits etc.

The following parameters may be tuned if extra performance is required. Before and after testing should be performed to check the results priory to any Live implementation. Pay attention to log_synch waits in AWR.

Properly Configure TCP Send / Receive Buffer Sizes

Gains have been realised when setting send and receive socket buffer settings up to three times the BDP. BDP is product of the network bandwidth and latency. Socket buffer sizes are set using the Oracle Net parameters RECV_BUF_SIZE and SEND_BUF_SIZE, so that the socket buffer size setting affects only Oracle TCP connections. The operating system may impose limits on the socket buffer size that must be adjusted so Oracle can use larger values. For example, on Linux, the parameters net.core.rmem_max and net.core.wmem_max limit the socket buffer size and must be set larger than RECV_BUF_SIZE and SEND_BUF_SIZE.

Set the send and receive buffer sizes at either the value you calculated or 10 MB, whichever is larger.
For example, if bandwidth is 622 Mbits and latency is 30 ms, then you would calculate the minimum size for the RECV_BUF_SIZE and SEND_BUF_SIZE parameters as follows: 622,000,000 / 8 x 0.030 = 2,332,500 bytes. Then, multiply the BDP 2,332,500 x 3 for a total of 6,997,500.

In this example, you would set the initialisation parameters as follows as the calculated figure is <10 MB.
RECV_BUF_SIZE=10000000
SEND_BUF_SIZE=10000000

Increase SDU Size

With Oracle Net Services it is possible to control data transfer by adjusting the size of the Oracle Net setting for the session data unit (SDU). Oracle testing has shown that setting the SDU to its maximum value of 65535 can improve performance for the SYNC transport. You can set SDU on a per connection basis using the SDU parameter in the local naming configuration file (TNSNAMES.ORA) and the listener configuration file (LISTENER.ORA), or you can set the SDU for all Oracle Net connections with the profile parameter DEFAULT_SDU_SIZE in the SQLNET.ORA file.

Note that the ASYNC transport uses the new streaming protocol and increasing the
SDU size from the default has no performance benefit.

TCP protocol stack

To preempt delays in buffer flushing in the TCP protocol stack, disable the TCP Nagle
algorithm by setting TCP.NODELAY=YES in the SQLNET.ORA file on both the
primary and standby systems. However with this, you'll end up with a larger number of smaller packets on the network, and if latency is a problem, this will make matters worse, not better.

Hope this helps

Comments are closed.