TCPIP Networks for DBAs
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

TCPIP Networks for DBAs

on

  • 5,723 views

Everything DBAs should know about TCPIP networks - captures, firewalls, roundtrips, latency and bandwidth.

Everything DBAs should know about TCPIP networks - captures, firewalls, roundtrips, latency and bandwidth.

Statistics

Views

Total Views
5,723
Views on SlideShare
5,654
Embed Views
69

Actions

Likes
5
Downloads
234
Comments
0

4 Embeds 69

http://www.linkedin.com 28
http://www.slideshare.net 27
https://www.linkedin.com 13
http://www.lmodules.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.
  • 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
  • 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
  • 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.
  • 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.
  • 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.
  • 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,
  • 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.
  • 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?
  • 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?
  • 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).
  • 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
  • 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.
  • You have dataguard or a similar setup and you need to move large amounts of data to a remote site on a continious basis
  • 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.
  • 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.
  • 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”
  • How much in flight do we need?
  • The magic number is bandwidth times latency – also known as bandwidth delay product.
  • 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.

TCPIP Networks for DBAs Presentation Transcript

  • 1. Everything a DBA Should Know about TCP/IP Networks
    Chen (Gwen) Shapirahttp://prodlife.wordpress.com
  • 2. My Stories
    ORA-12545 on connection to RAC
    Job does not finish running
    Reading 2M rows
    Copying redo logs to DR site
  • 3. Will Show
    Collect hard data – Don’t guess
    When & What to tune
    Back of the envelope calculations
  • 4. ORA-12545 Connecting to RAC
  • 5. Why guess when you canCapture?
  • 6.
  • 7.
  • 8.
  • 9. I want to connect
    Go to that server! Bye!
    Go where???
  • 10. Solutions
    Fix LOCAL_LISTENER
    Fix DNS
  • 11. Batch Job Never Finishes
  • 12. Capture on bothClient & Server
  • 13.
  • 14.
  • 15. Run this procedure
    ACK!
  • 16. Two hours later…
    Hello? Are you alive? No?
    BYE!
    Waiting
  • 17. The firewall is eating my packets!
  • 18. Solutions
    Talk to network admin
    Configure SQLNET.EXPIRE_TIME
    Configure tcp_keepalive_time
  • 19. Give Me 2M Rows ASAP
  • 20. Start with Wait Events
  • 21. SQL*Net Message to client-Meaningless
  • 22. SQL*Net Message from client-Nearly Meaningless
  • 23. Do the numbers make sense?
    Bytes Sent
    Time
    Roundtrips
  • 24. Tune the ArraySize
    Or setFetchSize()
    With 2M rows:
    • Fetch 10 => 200,000 Roundtrips
    • 25. Fetch 5000 => 400 Roundtrips
  • (Don’t) Tune SDU
    Oracle’s buffer – 2K or 8K
    Can set to max – 32K
    Can set to multiple of 1476 byte
    Highly unlikely target
  • 26. Beware:Compulsive Tuning Disorder
  • 27. Get Redo Logs to DR Site
  • 28. Q1: Bandwidth?
  • 29. OC3 => 155 Mb/s => ~ 70G/hour => ~ 60G with headers
  • 30. Key problem:Line utilization
  • 31. Q2: Latency?
    TNSPing Roundtrip time – 500ms
  • 32. Data < 1500 bytes
    500 ms
    ACK
  • 33. Data < 1500 bytes
    ACK
  • 34. 155Mb/s * 500ms=9.6MBytes
  • 35. Advertised Windows
    net.core.wmem_default
    net.core.wmem_max
    net.core.rmem_default
    net.core.rmem_max
  • 36. Congestion Window
    Errors
    Window Size
    Time
  • 37. WAN Accelarator
    $
    $
    $
    $
  • 38. Rememeber
    Collect hard data – Don’t guess
    When & What to tune
    Back of the envelope calculations
  • 39. Questions?