-- 10gR2 & SCAN IPs --

There has been some controversy with 10gR2 about the use of SCAN IPs, I have seen a lot of confusion about it which motivated me to write this article. Let's refresh our memory a little bit with the basis.

• Single client access name (SCAN) is the virtual hostname to provide for all clients connecting to the cluster (as opposed to the vip hostnames in 10g and 11gR1).  
• SCAN is a domain name registered to at least one and up to three IP addresses, either in the domain name service (DNS) or the Grid Naming Service (GNS).
• The real reason behind SCAN is that because the SCAN is associated with the cluster as a whole, rather than to a particular node, the SCAN makes it possible to add or remove nodes from the cluster without needing to reconfigure clients. It also adds location independence for the databases, so that client configuration does not have to depend on which nodes are running a particular database.
• Grid Infrastructure will start local listener LISTENER on all nodes to listen on local VIP, and SCAN listener LISTENER_SCAN1 (up to three cluster wide) to listen on SCAN VIP(s); 11gR2 database by default will set local_listener to local LISTENER, and remote_listener to SCAN listener.
• SCAN listener will be running off GRID_HOME, and by default, in 11gR2 local listener will be running off GRID_HOME as well.

With the SCAN the client sends a request to the SCAN listener, all services in the cluster are registered with the SCAN Listener, the SCAN Listener sends back to the client the address of the local listener on the least loaded node where the service is currently been offered, then the client establishes the connection to the service through the local listener on the node where the service is been offered. 

While 10g/11gR1 SQL*Net does not support certain aspects of this new feature, it is still possible to configure 10g/11gR1 clients and database instances to integrate with 11g R2 SCAN.  In order to make it work you won't will need to have the SCAN VIPs fix, this will not work in the case where the VIP are dynamically allocated via GNS.

 The problem arises because client and database instances with versions < 11g R2 do not support multiple IP addresses associated with the same host name, therefore you can't use the 11gR2 syntax for the remote_listener or the client connect string.  


You still need the SCAN VIPs, SCAN can have between 1 to 3 IPs associated with it, I always recommend 3 because 3 is the maximum number of VIP you will need regardless of the number of nodes in your cluster. It is ok to allocate 2 in the case of you having only 2 nodes as long as you are aware than when you add more nodes you will need an to reconfigure and an additional VIP on the same sub-net as the previous SCAN IPs.   


Please note that as you create the 'local_listener' and remote_listener instance parameters, local_listener should use the node VIP, while the alias for the 'remote_listener' uses the SCAN VIPs same as the setup for 11gR2


LISTENER_10g1 =
         (ADDRESS = (PROTOCOL = TCP) (HOST = node1-vip) (PORT=1521))



LISTENER_10g2 =
         (ADDRESS = (PROTOCOL = TCP) (HOST = node2-vip) (PORT=1521))


LISTENER_GRID =
          (ADDRESS = (PROTOCOL = TCP) (HOST = X.X.X.1) (PORT = 1521))
         (ADDRESS = (PROTOCOL = TCP) (HOST = X.X.X.2) (PORT = 1521))
          (ADDRESS = (PROTOCOL = TCP) (HOST = X.X.X.3) (PORT = 1521))
)


NOTE: Before 11.2 the Oracle Client was configured using ADDRESS_LIST listing all the nodes VIP. When you have a client with this configuration the REMOTE_LISTENER parameter for the pre 11gR2 database needs to list every node VIP plus every SCAN VIP. 


alter system set local_listener='LISTENER_10g1' scope=spfile sid='10G1';
alter system set local_listener='LISTENER_10g2' scope=spfile sid='10G2';
alter system set remote_listener='LISTENER_GRID' scope=spfile sid='*';


Check that you have a CRS service configured in OCR for clients to connect to this database. The client connection string should be similar to.
10G_VIA_SCAN =
  (DESCRIPTION =
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = x.x.x.1)(PORT = 1521))
       (ADDRESS = (PROTOCOL = TCP)(HOST = x.x.x.2)(PORT = 1521))
       (ADDRESS = (PROTOCOL = TCP)(HOST = x.x.x.3)(PORT = 1521))
    )
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = 10G_SCAN)
    )
  )

-- Utilization of Flashback Database as a back out mechanism for Application Deployments (Best Practices) --

Performance observations

 As you have to write to the flashback logs when the database is in flashback mode, you usually have around 5% performance impact especially for OLTP transactions. The impact for large inserts (e.g. batch inserts) or direct loads operations goes from 5% to 40%, this is especially true for 10g, in 11g Oracle introduced “block-new optimization” which significantly relieves that situation.

Best Practices

1. - Set the DB_FLASHBACK_RETENTION_TARGET to a value equal to the farthest time in the past that you wish to be able to recover to.

2.- size the flashback recovery area (FRA), ensure that there is sufficient space allocated to accommodate the flashback database, the flashback logs for the target  retention size and for peak batch rates. A general rule of thumb is that flashback logs get generated approximately at the same rate as redo log.

3. - Configure sufficient I/O bandwidth for FRA, failure to do that will result in high “FLASBACK BUF FREE BY RVWR” wait event and “FLASBACK LOG WRITE” latency of more than 30ms. The easiest way to accomplish this is by placing the flashback logs in the outer portion of the disks or LUNS.

4. - Set the LOG_BUFFER to at least 8MB in order to give the flashback database more buffer space in memory. For large databases consider a range between 32-64 MB.

5. – Set _DB_FLASBACK_LOG_MIN = (11.2.0.3 and above only).

6. - Monitor closely your “Recovery area free space (%).

7. - In Oracle 11.2 onward, you can enable flashback database while the database is open.

8. - It is highly recommended that you use Guarantee Restore Point (GRP) before your deployment.

9. - Enable database flashback when needed and disable it after you are sure the deployment was successful. Please note that every single time you enable or disable flashback database a reset log operation occurs therefor you have a different incarnation of the database, once you get the database out of flashback mode there is no way to move back or forth in time.