BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

   
Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 

 

 

Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation

 

 


 

 

 

 

 
 

Comparing Real Application Clusters to Oracle Parallel Server

Oracle Tips by Burleson Consulting

It came is no surprise to many industry professionals when Oracle chose to discontinue their Oracle Parallel Server product, which is also known as OPS. The OPS product allowed for a single database to be shared by many Oracle instances, and this architecture was quite good for massively parallel types of applications where the data could be segregated onto these multiple Oracle instances. However, one serious shortcoming of the OPS architecture was the requirement that all data blocks be available to all instances. Hence a cumbersome process called an integrated distributed lock manager, or IDLM, had to constantly be at work in order to “ping” data blocks back and forth between the many instances in an OPS configuration.

This problem of the IDLM was overcome by rearchitecting the OPS product and re-introducing the product under a new name, Real Application Clusters, or RAC. RAC employs a new technology with an Oracle called cash fusion, whereby the data block buffers of all instances within the parallel server configuration reside in a single shared RAM memory region.  By having all data blocks instantly available to all database instances, the problem of IDLM pinging is overcome, and the systems can run faster and far more liable and they could within an OPS architecture.

It's also important to note that there are serious limitations of Oracle's Transaction Application Failover tool. The most serious limitation is that Oracle TAF does not support restarting of any DML statements including inserts updates and delete. For those customers using Oracle PL/SQL packages, all package states are lost, thereby requiring all PL/SQL stored procedures to be re-started from the beginning. The Oracle TAF Product is also not support alter session statements and does not support global temporary tables failover.

The fact that the continuously available solution employs a retry parameter is very scary to many continuous availability professionals. Consumers are demanding systems that will automatically and reliably restart any inflight transactions that might be running during the system failure, and the idea of delayed retries are onerous to people who are counting on continuous availability.

Another important note is that the RAC solution requires downtime in order to upgrade the Oracle software. Oracle is currently working to create a rolling update technology, but for now, RAC systems must be stopped when Oracle upgrades are applied.

  • RAC is far simpler & more reliable than OPS (because of cache fusion)

  • RAC & OPS only protect against instance failure. A failure of disk or the live cache (RAM) will cause catastrophic failure.

Types of TAF failover:

Oracle provides two modes for failover, select failover and session failover.

  • SELECT Failover When SELECT failover is used, Net8 keeps track of any SELECT statements issued in the current transaction. SELECT failover keeps track of how many rows have been fetched back to the client for each cursor associated with a SELECT statement. If connection to the instance is lost, Net8 establishes a connection to a backup instance, re-executes the SELECT statements, and positions the cursors so the client can continue fetching rows as if nothing had happened. SELECT failover can be useful for reporting applications, but that's as sophisticated as TAF gets.

  • SESSION Failover When the connection to an instance is lost, SESSION failover results only in the establishment of a new connection to a backup instance. Any work in progress is lost.

Within these two failover type, Oracle offers two sub-methods:

  • BASIC Failover This is an approach where Oracle connects to back-up instance only after primary connection fails.

  • PRECONNECT Failover This is an approach where Oracle connects to back-up database & primary database. This offers faster failover, but it does this at the expense and added overhead for duplicating the Oracle connections.

It is important to note that there are several limitations of TAF for continuous availability.

  • The effect of any ALTER SESSION statements will be lost.

  • Global temporary tables will be lost.

  • Any PL/SQL package states will be lost.

  • Transactions involving INSERT, UPDATE, or DELETE statements cannot be handled automatically by TAF.

The TAF control parameters are located in the tnsnames.ora file. By default, when a TAF-initiated failover occurs, Net8 will make only one attempt to connect to the backup instance. Using the RETRIES and DELAY parameters, you can change that behavior so that Net8 makes multiple attempts to connect to the backup database. Below we see 20 retries at 30-second intervals:

        (FAILOVER_MODE =
           (TYPE = SELECT)
           (METHOD=PRECONNECT)
           (BACKUP=bkup)
           (RETRIES=20)(DELAY=30)
        ) 

Again, it is somewhat disconcerting to see a situation where RAC must re-try connectivity, especially when the main thrust of RAC is continuous availability.

Monitoring transaction application failover in Oracle9i

With widespread frosty using Real Application Clusters with Transparent Application Failover, the Oracle or databases made significant enhancements to the internal v$ views in order to allow the Oracle administrator to keep track of what's going on within reconnected transactions.

The biggest enhancement is to the v$process view. Several new columns of been added to the v$ process views in order to allow the Remote DBA to see exactly what's going on within the Oracle database.

  • failover_type indicates the type of failover. The values include NONE, SESSION and SELECT.

  • failover_method indicates the method used to establish the backup connection. The values include NONE, BASIC and PRECONNECT. 

  • failed_over Indicates whether or not a session has failed over to the backup connection.  The values are YES and NO.

Here is a sample query to display the failover information.

select
   username,
   sid,
   serial#,
   failover_type,
   failover_method,
   failed_over

from
   v$session;

Here is the output from this query.  Here we see a specific session and its failover information.

USERNAME   SID    SERIAL# FAILOVER_TYPE FAILOVER_M FAI
---------- --- ---------- ------------- ---------- ---
             1          1 NONE          NONE       NO
             2          1 NONE          NONE       NO
             6          1 NONE          NONE       NO
SYSTEM       7        688 SELECT        PRECONNECT YES
             9        110 NONE          NONE       NO
            10        109 NONE          NONE       NO
            15         84 NONE          NONE       NO
            16       1729 NONE          NONE       NO

Now let's wrap up this chapter and move on to more STATSPACK scripts.


This is an excerpt from "Oracle9i High Performance tuning with STATSPACK" by Oracle Press.


If you like Oracle tuning, you may enjoy the new book "Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


Expert Remote DBA

BC is America's oldest and largest Remote DBA Oracle support provider.  Get real Remote DBA experts, call
BC Remote DBA today.

 

   

 

Remote DBA Service
 

Oracle Tuning Book

 

Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

 

 

 

 

 

 

BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracle® is the registered trademark of Oracle Corporation.



Hit Counter