Trulogo Oracle Business Intelligence EE
Aug 9-12 SLC, UT
Partners

TruTek
Sign up now!
10g
experts
Utoug

TruTek can help you plan, implement and manage a successful 10g RAC project.

INCREASED TRANSACTION THROUGHPUT ON ORACLE REAL APPLICATION CLUSTERS

In Oracle 8i Oracle Parallel Server (OPS), the concept of cache fusion was introduced.  This functionality was added to reduce pinging blocks via disk to get read consistent views of the blocks on a remote instance.  This functionality greatly reduced the cost of selecting data from an instance who's lock element was in use by another instance. Instead of forcing the owning instance to write its changes to disk (forcing an I/O) so that it can be read on the remote instance, cache fusion will create a copy of  the buffer and ship it across the interconnect to the instance that is selecting  the data.  If inter-instance performance is bad, this operation could actually take longer than just doing an I/O to begin with.  This makes tuning inter-instance performance important.

9i Real Application Clusters has improved the cache fusion design by addressing write/write contention thus increasing speedup and scaleup.  With RAC cache fusion, Oracle has taken further steps to reduce the amount of I/O contention by virtually eliminating the need to 'ping' blocks to disk for locks that are in use but are requested for write access on the remote instance.  Instead, a RAC instance can ship copies of dirty buffers to remote instances for write access.  This functionality is only available when using dba (1:1) releasable locking (setting gc_files_to_locks to 0 for a particular datafile or not setting gc_files_to_locks at all).  Hashed locks still use the ping mechanism and fixed locks have been
eliminated in 9i RAC.  The additional shipping of dirty buffers in 9i RAC adds additional load on the interconnect. 
Again, if inter-instance performance is bad, this operation could actually take longer than just doing an I/O to begin with.  

In an Oracle RAC 10g environment, there is no dependency between Automatic Storage Management (ASM) and Oracle Cluster File System (OCFS).  OCFS is not required if you are using Automatic Storage Management (ASM) for database files. You can use OCFS on Windows( Version 2 on Linux ) for files that ASM does not handle - binaries (shared oracle home), trace files, etc. Alternatively, you could place these files on local file systems even though it's not as convenient given the multiple locations.  If you do not want to use ASM for your database files, you can still use OCFS for database files in Oracle Database 10g.  

The interconnect's purpose is to provide very high bandwith communications between the two servers' global caches. The interconnect show also have very low latency. In practice, Gigabit Ethernet with UDP has proven adequate for most clients.

Transition from Single Instance to RAC
  • The cluster and the cluster software must be installed and configured.  The RAC option must be added using the Oracle Universal Installer, 
  • The existing DB instance must be shut down. 
  • There are no changes necessary on the user data within the database.  
  • A shortage of freelists and freelist groups can cause contention with header blocks of tables and indexes as multiple instances to to share the same block. 
  • Performance problems may require data partitioning. 

Recommendation: apply automatic space segment management to perform these changes automatically.  The free space management will replace the freelists and freelist groups and is better.  The database requires one Redo thread and one Undo tablespace for each instance, which are easily added with SQL commands or with Enterprise Manager tools.

Datafiles will need to be moved to either a clustered file system (CFS) or raw devices so that all nodes can access it.  Also, the MAXINSTANCES parameter in the control file must be greater than or equal to number of instances you will start in the cluster. 

The types of load balancing available currently (9i-10g) occur at connect time. This means that it is very important how one balances connections and what these connections do on a long term basis. Since establishing connections can be very expensive for your application, it is good programming practice to connect once and stay connected. Oracle Net Services provides load balancing or you can use external methods such as hardware based or clusterware solutions.

The following options exist prior to Oracle RAC 10g Release 2 (for 10g Release 2 see ):
Random
Either client side load balancing or hardware based methods will randomize the connections to the instances.
On the negative side this method is unaware of load on the connections or even if they are up meaning they might cause waits on TCP/IP timeouts.
Load Based
Server side load balancing (by the listener) redirects connections by default depending on the RunQ length of each of the instances. This is great for short lived connections. Terrible for persistent connections or login storms. Do not use this method for connections from connection pools or applicaton servers
Session Based
Server side load balancing can also be used to balance the number of connections to each instance. Session count balancing is method used when you set a listener parameter, prefer_least_loaded_node_listener-name=off. Note listener name is the actual name of the listener which is different on each node in your cluster and by default is listener_nodename. Session based load balancing takes into account the number of sessions connected to each node and then distributes the connections to balance the number of sessions across the different nodes.  

Overview of the Load Balancing Advisory

Load balancing distributes work across all of the available RAC database instances. Oracle recommends that applications use persistent connections that span the instances that offer a particular service. Connections are created infrequently and exist for a long duration. Work comes into the system with high frequency, borrows these connections, and exists for a relatively short duration. The load balancing advisory provides advice about how to direct incoming work to the instances that provide the optimal quality of service for that work. This minimizes the need to relocate the work later.

By using the THROUGHPUT or SERVICE_TIME goals, feedback is built in to the system. Work is routed to provide the best service times globally, and routing responds gracefully to changing system conditions. In a steady state, the system approaches equilibrium with improved throughput across all of the RAC instances.

Standard architectures that can use the load balancing advisory include connection load balancing, transaction processing monitors, application servers, connection concentrators, hardware and software load balancers, job schedulers, batch schedulers, and message queuing systems. All of these applications can allocate work.

The load balancing advisory is deployed with key Oracle clients, such as a Listener, the JDBC Implicit Connection Cache 10g, and the ODP.NET Connection Pool. The load balancing advisory is also open for third party subscription by way of ONS.

Configuring Your Environment to Use the Load Balancing Advisory

You can configure your environment to use the load balancing advisory by defining service-level goals for each service for which you want to enable load balancing. This enables the load balancing advisory for that service and FAN load balancing events are published. There are two types of service-level goals for runtime:

  • SERVICE TIME—Attempts to direct work requests to instances according to response time. Load balancing advisory data is based on elapsed time for work done in the service plus available bandwidth to the service. An example for the use of SERVICE TIME is for workloads such as internet shopping where the rate of demand changes:

    EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'OE'  , goal => DBMS_SERVICE.GOAL_SERVICE_TIME - , clb_goal => DBMS_SERVICE.CLB_GOAL_SHORT);  
  • THROUGHPUT—Attempts to direct work requests according to throughput. The load balancing advisory is based on the rate that work is completed in the service plus available bandwidth to the service. An example for the use of THROUGHPUT is for workloads such as batch processes, where the next job starts when the last job completes:

    EXECUTE DBMS_SERVICE.MODIFY_SERVICE (service_name => 'sjob' -         , goal => DBMS_SERVICE.GOAL_SERVICE_TIME -        , clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);  

    Setting the goal to NONE disables load balancing for the service. You can see the goal settings for a service in the data dictionary and in the DBA_SERVICES, V$SERVICES, and V$ACTIVE_SERVICES views.

The 10g Virtual IP Address (VIP) exists on every RAC node for public network communication. All client communication should use the VIPs in their TNS connection descriptions. The TNS ADDRESS_LIST entry should direct clienst to VIPs rather than using hostnames. During normal runtime, the behaviour is the same as hostnames, however when the node goes down or is shutdown the VIP is hosted elsewhere on the cluster, and does not accept connection requests. This results in a silent TCP/IP error and the client fails immediately to the next TNS address. If the network interface fails within the node, the VIP can be configured to use alternate interfaces in the same node. The VIP must use the public interface cards. There is no requirement to purchase additional public interface cards (unless you want to take advantage of within-node card failover.)

Standard Edition RAC

Oracle Database 10g Standard Edition is allowed to use the RAC. For you should read the Oracle Database 10g License Doc for licensing restrictions. Generally the rules are: not more than 4 CPUs in the cluster, and ASM must be used for all database files. Oracle Cluster File System (OCFS) is not supported for use with SE RAC. OCFS2 on linux (where certified with RAC) is supported for Oracle Clusterware files (OCR and Voting Disk) and Oracle Homes. 

Cache Fusion in Oracle9
i allows customers to easily take advantage of the scalability provided by Oracle Real Application Clusters, with little or no reduced performance cost. This allows customers to horizontally scale the database tier as usage and demand continues to grow.

  • Cache Fusion technology
  • Avoid expensive disk I/O
  • Application runs as if it were one large virtual server

TruTek has been implementing Oracle's Real Application Cluster technology since 1995.

Previously, this was called Oracle Parallel Server (OPS).

This is "the solution" for maximum availability and scalability.

Cache Fusion utilizes both local and remote caches for serving all possible types of inter-node transactions

9i ships data blocks
from cache to cache in
read/read, read/write,
write/write.

In 8, only read/write
was handled.

quest smd sun oaug