I only got acceptable export speed when I changed the default buffer size to a high value:

exp user/password buffer=100000000

So, do you think there is some O/S kernel related parameter that I should to review?

Cheers

Thanks for the tips, I’ll check it out …

Cheers

If you think that everything is configured normally, there is no significant network latency nor application think time then you can look deeper – dump the network packets at client with tcpdump (if on linux) and analyze part of the transmission with Wireshark (www.wireshark.org). This will give you SDU/TDU sizes, resends, packet reassemblies and timestamps you need for finding where the time is going IF it’s a network transport issue.

1) time the result network packets are “flying” towards the client
2) client application think time – this is important as if you use some pipe for compression on the fly, the think time may become even longer
3) time the next request packet is “flying” towards the server

Thanks for the response. In fact, I have never faced this kind of problem before. I’m trying to understand why in the local server the export operation took so fast, and why the export operation from a remote machine took so long. 2 or 3 minutes is acceptable, but 1 hour? For 5 years, we have working in a Oracle 10g installed in another server, and this kind of problem have never happened before. The development team used to take exports (exp) and imports (imp) using default buffers size since then, without problems:

exp user/passwrod@service file=file.dmp …

The network analyst of the company made some tests using “scp” Linux commands in order to copy big files from that new Oracle 11g server to another server and vice versa without problems. The speed rate of copying a file was normal as expected (10MB/s) in a 100Mbs network.

The SDU/TDU SQLNet configuration is using the default values. The MTU of the LAN is fine too (1500 bytes).

So, I’m not sure how to find out either what could might causing this delay or contention. Maybe looking at Linux Kernel related network parameters? Maybe taking a test … like connecting a direct crossover cable connection between the server and a client machine?

Well, on next Monday I will try to take more tests …

Thanks.

See taht your session had made 26048 roundtrips during session startup. Now if every roundtrip takes let say 100ms then you’ll have ~2600 seconds of response time there. In fact in your case the time spent waiting for client (next fetch) was ~3000 seconds already. So it’s the network latency combined with high number of fetches/network roundtrips.

How did you perform the export? Make your export buffer size larger, this should reduce number of network roundtrips and response time.

3 weeks ago I finished to configure an Oracle Database 11g (11.1.0.7) 64 bits on a Linux (4 GM RAM), and after some tests, I noticed a SQL low response time. So, I thought … there is something strange happening here:
I made a test in the local server, exporting a table T1 (using the traditional exp utility) that contains around 1 million rows on it. The export operation took less than 10 seconds to complete.

After that, I performed the same export operation in a remote machine. By the way, the remote machine and the Oracle server are currently located at same network.

For my surprise, the export operation took around 1 hour to complete!! I’m not sure where are the bottleneck. Do you believe that there is a contention or something relationed to the network layer? Apparently, the network is fine …

Below, I attached the output of some informations while taking the export from the remote machine. I noticed high values in some informations …

IO – v$sess_io
————–
block_gets = 3
consistent_gets = 52,730
physical_reads = 20,027

WAITS – v$session_event
———————–
SQL*Net message from client > total_waits = 25,635 time_waited = 306,000
SQL*Net message to client > total_waits = 25,635 time_waited = 2
SQL*Net nore data to client > total_waits = 97 time_waited = 0

STATISTICS – v$sesstat
———————-
bytes sent via SQL*Net to client = 146,167,218
bytes received via SQL*Net from client = 299,577
SQL*Net roundtrips to/from client = 26,048

SQL
—
SELECT /*+NESTED_TABLE_GET_REFS+*/
“SCOTT”.”T1″.*
FROM “SCOTT”.”T1″

Cheers

Note that Bob mentioned events from different classes “message FROM client” and “more data TO client”

“SQL*Net more data to client” is supposed to be like “SQL*Net message to client” but only for large responses which span a sqlnet packet size. First packet is still sent back “under” message to client wait event and subsequent packets for that call using more data to client.

Unfortunately the “SQL*Net message to client” time is not accounted properly in Oracle, so it can’t be used for calculating any transfer time.

The “SQL*Net more data to client” is a little different as at least it looks like its instrumented properly (e.g. if the socket write call blocks, that time is accounted).

There are still some unclear pieces, and some research I want to do on this once I get time. When I do, I post the results :)