This discussion is archived
0 Replies Latest reply: Oct 17, 2013 9:42 AM by user11989003 RSS

Overhead of SCAN

user11989003 Newbie
Currently Being Moderated

I'd like to hear your comments on a note I wrote before. Thank you. (When talking about overhead, I don't have actual performance data. Your critique on that would be fully accepted!)


* Overhead of SCAN


SCAN listeners won't use much CPU or memory. But there's

another aspect of overhead: they hand off connections to the regular listeners. If I connect to

the regular listener in a dedicated connection, the listener fork()'s (clone()'s in Linux) and

exec()'s $ORACLE_HOME/bin/oracle. Does the SCAN listener do the same if the least loaded node

happens to be the current node? No. It's still the regular listener that does that. This can be

verified with simple strace. Thus, on a 2-node RAC, 50% of the time this extra hand-off would be

made unnecessary if the SCAN listener itself could spawn a server process. If the database has

frequent client connections and disconnections, this overhead may be non-negligible.


The SCAN listeners also collect load stats of all the nodes. But the regular listeners also do, as

usual. You can see PMON's service update in both SCAN and regular listeners' log files. This extra

load stats collection adds another part of overhead.




* Overhead of DNS


Connecting to SCAN starts with consulting with DNS. Some clients have DNS cache, which relieves

pressure on the DNS server, but they may be disabled in some shops to avoid bugs. If DNS does not

perform well and a client connects to the database very frequently, this extra DNS lookup adds a

non-negligible delay to the end user's experience.


If the firewall sits between the client and the RAC database, not using SCAN reduces 3 IP's to be

open on the firewall, which is generally welcomed by the security personnel.


  • Correct Answers - 10 points
  • Helpful Answers - 5 points