Setting SDU Size (mainly in 11.2)

I’ve recently had some problems getting a change in SDU size to be picked up and I’m writing this post in the hope of saving others some time.

Changing the SDU size is something to consider if you want to get the most out of your network. The situations where it will offer a notable benefit are covered in MOS ID 99715.1^[1].

The 11.2 Net Services Administrator’s Guide and MOS ID 67983.1 (Oracle Net Performance Tuning, which applies to “Oracle Net Services – Version: 8.1.7.4.0 to 11.2.0.1 – Release: 8.1.7 to 11.2”), both list two ways of setting SDU size. One method involves setting SDU in listener.ora (for a statically registered listeners) and the other setting it in sqlnet.ora.

The documentation also states:

If you have configured the listener with a list of targets in the listener.ora file, then the value for SDU in the SID_LIST element overrides the current setting in the sqlnet.ora file when using dedicated server processes.

There is a caveat in the “Purpose” section of MOS ID 67983.1 which seems worth drawing attention to:

Note: This document contains references to obsolete parameters.

If this caveat is intended to alert the reader to what I cover below then I think it would be reasonable to be more explicit. MOS ID 44694.1 also provides examples on setting SDU, but applies to “Oracle Net Services – Version: 8.0.5.0.0 to 11.1.0.6.0”.

It was the subtlties of the applicable versions in the MOS notes listed above and spotting something different in MOS ID 1292915.1 (Scan Listener, Queuesize, SDU, Ports) that led me to get a change in SDU to be effective.

When it comes to establishing the negotiated SDU I have relied on MOS ID 304235.1 and this page from Jonathan Lewis. The latter relates specifically to Oracle 7.3.4.1, but appears to still be relevant.

The system I was originally attempting to enable an increased SDU size on is an 11.2.0.2 Exadata environment, but when things didn’t go as planned I moved to XE 11.2.0.2 in order to experiment. The 11.2.0.2 testing below is from XE and the same approach has been confirmed as effective in the 11.2.0.2 Exadata environment (Enterprise Edition).

I have also carried out tests on 11.2.0.1, 11.1.0.6 and 10.2.0.5 (all Enterprise Edition) and reference to these versions is made where I have observed differences in behaviour.

Testing

1. Validate SDU size used by default (“out of the box”)

1.1. Set “TRACE_LEVEL_LISTENER = ADMIN” in listener.ora (only change to standard configuration)
1.2. Connect via listener^[2]
1.3. Searching for “sdu=” in the trace file reveals the following

2011-09-21 09:11:05.759068 : nsconneg:vsn=314, lov=300, opt=0x41, sdu=8192, tdu=65535, ntc=0xc60e
2011-09-21 09:11:05.759125 : nsconneg:vsn=314, gbl=0x1, sdu=8192, tdu=65535

Which, based the methods referenced above, shows that an SDU of 8192 bytes is used.

2. Setting SDU size in sqlnet.ora

2.1. Setting “DEFAULT_SDU_SIZE = 16384” in sqlnet.ora (both client and server)
2.2. Connect via listener^[2]
2.3. Searching for “sdu=” in the trace file reveals the following

2011-09-21 09:22:41.897852 : nsconneg:vsn=314, lov=300, opt=0x41, sdu=8192, tdu=65535, ntc=0xc60e
2011-09-21 09:22:41.897910 : nsconneg:vsn=314, gbl=0x1, sdu=8192, tdu=65535

… Showing that an SDU of 8192 bytes is used.

2.4. “DEFAULT_SDU_SIZE = 16384” removed from sqlnet.ora

Note: One observation during this test on 11.2.0.1, and earlier, is that when sqlnet.ora is has DEFAULT_SDU_SIZE set the client will attempt to negotiate this SDU size.

3. Setting SDU size in tnsnames.ora

3.1. tnsnames.ora updated to (DESCRIPTION = (SDU = 16384) <–snip–>)
3.2. Connect via listener^[2]
3.3. Searching for “sdu=” in the trace file reveals the following

2011-09-21 09:30:21.498865 : nsconneg:vsn=314, lov=300, opt=0x41, sdu=16384, tdu=65535, ntc=0xc60e
2011-09-21 09:30:21.498925 : nsconneg:vsn=314, gbl=0x1, sdu=8192, tdu=65535

… Showing that SDU of 16384 was requested by the client, but the server would only go to 8192.

4. Setting SDU size in listener.ora (static listener entry)

4.1. listener.ora updated to include (SID_DESC = (SDU = 16384) <–snip–>)
4.2. Connect via listener^[2]
4.3. Searching for “sdu=” in the trace file reveals the following

2011-09-21 09:54:28.324832 : nsconneg:vsn=314, lov=300, opt=0x41, sdu=16384, tdu=65535, ntc=0xc60e
2011-09-21 09:54:28.324890 : nsconneg:vsn=314, gbl=0x1, sdu=8192, tdu=65535

… Showing that SDU of 16384 was requested by the client, but the server would only go to 8192.

4.4. Searching for SDU= in the trace file reveals a number of lines, including the line below, showing the SDU parameter

2011-09-21 09:54:28.339728 : snlpcss:Spawn Oracle completed oracle   (DESCRIPTION=(LOCAL=NO)(SDU=16384)) XE.

I’m taking this as showing that the syntax is not flagged as invalid, but as shown by the previous output, it is not being honored.

4.5. SDU parameter removed from this position in listener.ora

5. Setting SDU size in listener.ora (Listener DESCRIPTION)

5.1. listener.ora updated to include (DESCRIPTION_LIST = (DESCRIPTION = (SDU = 16384) <–snip–>))
5.2. Connect via listener^[2]
5.3. Searching for “sdu=” in the trace file reveals the following

2011-09-21 10:07:08.008144 : nsconneg:vsn=314, lov=300, opt=0x41, sdu=16384, tdu=65535, ntc=0xc60e
2011-09-21 10:07:08.008203 : nsconneg:vsn=314, gbl=0x1, sdu=16384, tdu=65535

… Showing that SDU of 16384 was requested by the client, and the server could match it.

5.4. Searching for SDU= reveals a number of lines, including the line below, showing the SDU parameter

2011-09-21 10:06:39.910083 : nsgllsn:Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))(SDU=16384))

I went on to experiment with combining the placement of SDU within listener.ora, but could not find a situation where placement within SID_DESC was honored.

After working through testing above, and finding my experiences did not match the documentation, I ran further tests on 10.2.0.5, which threw up some more interesting discoveries.

Simply enabling tracing and making a connection gave:

nsconneg: vsn=313, lov=300, opt=0x81, sdu=2048, tdu=32767, ntc=0x7308
nsconneg: vsn=313, gbl=0x81, sdu=2048, tdu=32767

This is expected as the default SDU in 10.2 is 2048 bytes.

Setting DEFAULT_SDU_SIZE = 8192 in sqlnet.ora gave:

nsconneg: vsn=313, lov=300, opt=0xc01, sdu=8192, tdu=32767, ntc=0x7f08
nsconneg: vsn=313, gbl=0xc01, sdu=8192, tdu=32767

OK! So now it’s working as documented and I didn’t even need to restart the listener 🙂

Setting DEFAULT_SDU_SIZE = 16384 in sqlnet.ora gave:

nsconneg: vsn=313, lov=300, opt=0xc01, sdu=16384, tdu=32767, ntc=0x7f08
nsconneg: vsn=313, gbl=0xc01, sdu=8192, tdu=32767

… and just for good measure setting DEFAULT_SDU_SIZE = 8193 in sqlnet.ora gave:

nsconneg: vsn=313, lov=300, opt=0xc01, sdu=8193, tdu=32767, ntc=0x7f08
nsconneg: vsn=313, gbl=0xc01, sdu=8192, tdu=32767

From this I’m concluding that it is not possible to increase the SDU size above 8K via the sqlnet.ora method alone. Values greater than 8192 are picked up the client, but not by the listener (at least until 11.2.0.2, where they are no longer picked up by the client either).

The next thing I wanted to test was setting the SDU size in listener.ora at 10.2.0.5. Try as I might, I could not get adding SDU to listener.ora using the syntax given in the 10.2 documentation to work, i.e.:

SID_LIST_listener_name=
  (SID_LIST=
    (SID_DESC=
     (SDU=16384)
     (SID_NAME=sales)))

However, if used the approach I’d established on 11.2, as below, the SDU size change was picked up by the listener.

LISTENER_listener_name =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (SDU = 16384)
      (ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521))
    )
  )

Key Points (it appears that):

1. SDU size can’t be increased above 8192 in sqlnet.ora and be honored by the listener
2. From 11.2.0.2 changing DEFAULT_SDU_SIZE in sqlnet.ora does not affect the SDU size used by the client or the listener
3. The documented location of the SDU parameter within the listener.ora file in all locations apart from MOS ID 1292915.1 (Scan Listener, Queuesize, SDU, Ports) is not effective

I am not ruling out that I’ve missed something in my testing, so if you read this blog post and have different experiences, particularly with respect to the location of SDU within listener.ora, then I would be very happy to hear from you.
________________

1. The activity I was attempting to speed up by increasing the SDU did not show an improvement even when the increased SDU was successfully implemented (assuming the method used for establishing the SDU, detail above, is appropriate in 11.2.0.2).
   

2. The connection testing to produce trace output for analysis was done using a SYSDBA connection to a database that was shutdown in order to guarantee that my connection was going via the static listener registration.