Archive for September, 2009
11gR2 new features: SCAN
Posted by Jay Caviness in 11gR2, RAC on September 22nd, 2009
One really nice new feature of 11gR2 is the SCAN (single client access name). A scan is the single point of access for all applications connecting to an 11gR2 RAC cluster and allows consistent connections without the need to know how many nodes are in a cluster. Vips are still used internally, and can still be used for connections, but the initial connection to the cluster is made via a scan. Connections to any database in a cluster will be made via the scan. No longer will a DBA need to create those large, complicated tnsnames.ora or jdbc (thin) connection strings. All can be accessed by a scan:
sqlplus joeuser/joespasswd@dodge-scan:1521/proddb or jdbc:oracle:thin:@dodge-scan:1521/proddb
One scan is needed for each cluster, it is a single DNS entry with three IP addresses attached to the name and set to round-robin (unless using GNS, but that is another post). The IP addresses must be unused (similar to a VIP). A good naming technique would be to name the scan after the cluster it is created for. For example, one of the clusters I use regularly contains three nodes, caravan, stratus and durango, affectionately called the Dodge cluster thus the name of the scan to be used. Once the networking folks have created the DNS entry it is ready to use. The scan is created in the cluster at installation. Note that VIPs are still needed and must still reside in DNS.
Anatomy of a SCAN
How does it all work? A new set of cluster processes called scan listeners will run on three nodes in a cluster. If you have more than three nodes, that is ok, regardless of the number of nodes you have, there will be at most three scan listeners. If any of these clustered processes fail, they are automatically restarted on a new node. When a new connection request is made, the request hits DNS on the scan name, DNS will round robin and choose one of the three IP addresses assigned to that scan name and route it to the correct scan listener. Each scan listener keeps updated cluster load statistics and will then route the request to the appropriate VIP IP which is returned to the requesting service. The requesting service will then connect directly to the returned VIP as in previous versions and the connection is made through a standard listener.
Can connections still be made directly to through the VIPs? Yes, connections via the virtual IP addresses are still supported, though I cannot see a reason to use the old method as yet. Will RAC services work with the scan? Yes, there is no difference in that functionality. SCANs are a layer on top of the old method of connecting to a RAC database and do not interfere with any current methods.
The SCAN provides a simple and effective mean to connect to any and all instances in a cluster without the need to hard code connection information which can change. This has been needed for years and is one of the best new features of 11gR2 to prevent headaches for DBAs in the future.
Slewing the 11gR2 dragon
Posted by Jay Caviness in 11gR2 on September 4th, 2009
One of the first new pieces of 11gR2 I like is the installer, for the grid and RAC install particularly. The feature I like best is the fact that it runs cluster verify and will give the DBA the chance to fix most problems with the fixup scripts. One problem it cannot fix however is a requirement which will pop up on most systems to use the “slewing” option for ntp. The installer simply says to enable slewing with the “-x” option, but that is it. It What is slewing, and how do you set it?
Slewing is an option for the ntp daemon (ie. ntpd -x, xntp -x) to prevent time from moving backwards in large amounts. This slewing will help reduce time changes into multiple small changes, such that they will not impact Oracle Clusterware. While it has been a requirement for a long time with Oracle Clusterware, it is more strongly enforced with 11gR2 as the clusterware is more sensitive now to time changes. (This fact is also shown in the need for Oracle to create CTS (Cluster Time System) which can be created and used on the nodes of a cluster to keep them in sync with each other if NTP is not available or accessible, but that is another post).
Implementing slewing is simple. On Linux, as root, edit the /etc/sysconfig/ntpd file. Generally, it looks something like this:
# Drop root to id 'ntp:ntp' by default. OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid" # Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=no # Additional options for ntpdate NTPDATE_OPTIONS=""
Modify the file to add the “-x” option to ntp
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"
Restart the daemon:
# service ntpd stop Shutting down ntpd: [ OK ] # service ntpd start ntpd: Synchronizing with time server: [ OK ] Starting ntpd: [ OK ] # ps -ef |grep ntp ntp 32051 1 0 10:48 ? 00:00:00 ntpd -x -u ntp:ntp -p /var/run/ntpd.pid
That is it, you can copy this file to all the nodes in your new cluster and restart the daemon. Once done, the installer will cease to bug you with the ntp reminder and you can go on building your new 11gR2 cluster.
11gR2 is Available!
Posted by Jay Caviness in general on September 1st, 2009
Finally! I have been holding my breath on this announcement for almost 18 months since I was invited to be on the RAC/ASM Beta test team for 11gR2. It has been a long road and have had to keep my mouth shut myriad times at Openworld last year and IOUG Collaborate back in May. I have not been this excited about a release since Oracle 10g. This is what a grid is supposed to be. The changes to RAC and ASM alone will take me several posts, but I will get out as much information as I can as quickly as I can.
Let’s just start this way, for RAC, 11gR2 is a quantum shift. 11gR1 is essentially the same clusterware as 10gR2, fixes but no major changes. R2 redefines the game. While you can use the old style RAC clusters, R2 offers the way out of defining nodes by name and number and allows on the fly provisioning across clusters. Other new features include:
1. moving ASM into the cluster (one less Oracle_Home to worrry about)
2. storing OCR and voting disks within ASM
3. the use of a SCAN to remove the need of clients knowing VIPs
4. the use of GNS (Grid Naming Service) to take advantage of Grid Plug’n'Play in expanding a cluster on the fly
5. ASM filesystem (ACFS)
I will delve more into these and other subjects in the near future. I have been working on 11gR2 for quite a while now and while there are lofty expectations, 11gR2 will be there to meet them all.
A word of warning, however, don’t click the video tab on the link above, or you will have to stare at my mug! I couldn’t see a thing without my glasses while being filmed!