Comments on: SQL*Net compression

By: Edwin

Edwin — Thu, 16 May 2013 09:25:28 +0000

You asked, ” how come the number of SQL*Net round-trips hasn’t dropped. (I’ll leave the second question for another posting – there’s too much to say in just one note.)”. Was this answered in another post?

I’ve a scenario where bytes sent via SQL*NET is distinctly higher on a one particular database (11G) and another (10G), but roundtrip to/from remains the same. How can a higher number of bytes be transferred in the same amounf of roundtrip?

By: Give Me a Hint – How were These Autotrace Execution Statistics Achieved? « Charles Hooper's Oracle Notes

Mon, 27 Jun 2011 13:38:09 +0000

[...] were transferred over the network in the unhinted version of the query? Could it be a case where SQL*Net compression has helped to strip the repeating columns from adjacent rows in the result set prior to [...]

By: Jonathan Lewis

Jonathan Lewis — Tue, 22 Feb 2011 11:39:47 +0000

Jason,

More importantly, probably, is that if you sort the data to reduce the network volume you need to be sure that the front-end doesn’t care about the order.

However, your point is taken, and comes under the general principle of using whichever resource is spare to reduce the load on the resource that is the bottleneck. If the network is the problem and CPU is available … (which was the case in my Informatica example above).

By: jason

jason — Tue, 22 Feb 2011 03:51:50 +0000

interesting article, but isn’t more overhead put on the server(cpu/memory) as Oracle has to sort data first? I feel this comes at the price of stretching system resource, not sure if it’s worthwhile doing so in reality.

By: SQL Net Compression « Systems Engineering and RDBMS

SQL Net Compression « Systems Engineering and RDBMS — Thu, 10 Jun 2010 18:08:04 +0000

[...] http://jonathanlewis.wordpress.com/2010/05/07/sqlnet-compression/ [...]

By: Jonathan Lewis

Jonathan Lewis — Tue, 08 Jun 2010 22:10:22 +0000

Tim,

I don’t know of any option to disable the feature, and haven’t been able to find anything on Metalink (MOS). Have you tried raising an SR ?

By: Tim Hopkins

Tim Hopkins — Fri, 04 Jun 2010 15:34:44 +0000

In regards to JDBC thin – Using the new tracing added to the 11.2 JDBC driver (enabled using oracle.net.ns.level), against an 11.2.0.1 DB, I can see this form of deduplication occuring.

Unfortunately, I’m looking because we’re intermittently getting a single column replaced by null (ASCII 0) characters. The null characters don’t appear in the actual stream from the server so I’m suspecting it might be something going wrong with this de-dup process.

Does anyone know of a way to disable it to test the theory?

By: Martin Preiss

Martin Preiss — Wed, 02 Jun 2010 08:18:19 +0000

Jonathan,
thank you for the plausible explanation and the test (and by the way for your blog and your books)

By: Jonathan Lewis

Jonathan Lewis — Wed, 02 Jun 2010 07:39:23 +0000

Martin,
I think this may be a result of a fixed overhead for compression (or de-duplication, which might be a slightly better term). I think a row probably has to say “this column is the same as last time”, so I would look for a fixed size token to represent “same as last row”.

Test: create a table of 1,000,000 rows with a constant (e.g. 1000000001) and a variable (e.g. 1000000001 + rownum) column, set a large arraysize (5,000 is the max) then select each column in turn with autotrace traceonly statistics. See if the difference in volume is significant. It is, but there is a minimum volume of data per row which means you don’t see much of a saving with a single column of small numbers.

By: Martin Preiss

Martin Preiss — Wed, 02 Jun 2010 06:48:15 +0000

Jonathan,
when I use your example in my database (10.2.0.4) I get – it’s no surprise – the same results. But when I replace “lpad(dbms_random.string(‘U’,2),40,’X') v1″ by a simple “mod(rownum, 10) v1″ I see that the sorted query transfers a little bit more data than the query without sorting (without order by: 44144 bytes sent via SQL*Net to client; with “order by v1″: 51151 bytes sent via SQL*Net to client). Is this an effect of the small size of the column or does the de-duplication not work with numeric data (or work different)? I have no idea how to test this …

Regards
Martin Preiss