Editor's Notes

1. ORA-12545: Connect failed because target host or object does not exist Can’t connect to Oracle server. Can be anything from misspelled host in TNSNAMES.ORA to mis-configured firewall. Normally it is a reproducible error, but in our case it happened only 50% of the time.
2. Click Capture->Options to get to this screen Select the right interface Add filters If capturing large amounts of data, or over night – configure to stop capture or use ring buffer
3. Now that we know EXACTLY what is the problem, we can look for a solution.If the server is redirecting using the wrong server name (local name instead of a VIP for instance) – fix LOCAL_LISTENER parameterIf the server is redirecting correctly – the DNS should be fixed to allow the client to connect to that server
4. Client connects to server with SQLPLUS and calls a stored procedure. Several hours later and still no reply from server Server no longer shows any session from the client Log table shows that the procedure stopped running in the middle.
5. After two hours the server sent a keep alive. Then few minutes later another one and then few more. When the server received no reply it closed the connection. Oracle rolled back the last statement and closed the session. 8 hours later the client is still waiting for a reply while the server has long forgotten about the whole thing.
6. This is a bit of a guess. I do know that the server is sending keep alives and the client is not receiving them. Obviously they get lost somewhere. Since this is a LAN, the firewall is a likely candidate.
7. Now that we know EXACTLY what is the problem and have the captures to prove it, we can discuss the mystery with the network admin. The discussion is likely to involve the times that jobs run and the firwall connection timeout settings,
8. This event measures the time it takes for Oracle to request the operating system to send a buffer of data to the client. It is all local and normally takes very little time.
9. This event measures the time it took for the message to reach the client, for the client to process it, and for the client reply to reach the server.It is nearly meaningless because it measures too much things and you can’t really know where the time went. That’s why DBAs were taught to ignore it.You can capture on client and server to learn more:When did the server send the messages, how long did they take to arrive, how long until the client sent its replies?
10. Check the statistics – how long did it take to run the query? How much data? How many roundtrips?You are tuning the network so we can assume that nearly all the query time is spent on network Or that you determined with other means how much time is spent on the network. Ask your network admin – I sent 1500K on our LAN and it took 30 secs, is this reasonable? If not, maybe your capture holds clues to the problem. Do you see retransmits? Does the numer of roundtrips make sense?
11. Note that 10 is Java’s default fetch size. The difference in number of roundtrips is huge and has real performance impact.Set the fetch or array size to as high as you can. The only limit is the amount of memory you have for storing the rows (and with SQLPLUS there is a 5000 row limit).
12. There is a lot of advice on the net for tuning SDU, but very little proof that it ever helped improve performance.Set to maximum size (32k) if you want to avoid context switches caused by Oracle filling the bufferSet to a multiple of 1476 bytes to minimize number of packets sentIf you get improvement – let me know
13. Make sure you have a real performance problem *and* that the network times are really the issue before you start fiddling with random knobs. After fiddling with knobs make sure it really improved performance *and* that you know why.
14. You have dataguard or a similar setup and you need to move large amounts of data to a remote site on a continious basis
15. But will we really get 60G?Best way to know is to test. If you are testing for DataGuard, test with Oracle’s file transfer and not SCP since SCP sets its own parameters.If you get less than you expect – maybe you get enough and then you are fine. Only tune if you *need* to move data faster.
16. If you don’t get all the bandwidth you expect, the problem is usually line utilization. Maybe someone else is using the line, but it could be something else.
17. If we wait for each ACK until we send the next packet – we’ll get an amazing 3k/s bandwidth out of our 155M/s line.To get more bandwidth, we need to have more data “in flight”
18. How much in flight do we need?
19. The magic number is bandwidth times latency – also known as bandwidth delay product.
20. You’ve done the math and you need more bandwidth than you can squeeze. Now you have the data to go to your management and ask for a WAN Accelerator – clever device that uses multiple tricks including compression and caching to move data fast across the internet.