0 Replies Latest reply on Oct 17, 2013 4:42 PM by user11989003

    Overhead of SCAN


      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.