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

 

 


 

 

 

        
 

 Block Transfers Using Cache Fusion - Example
Oracle Tips by Burleson Consulting

Oracle 11g Grid & Real Application Clusters by Rampant TechPress is written by four of the top Oracle database experts (Steve Karam, Bryan Jones, Mike Ault and Madhu Tumma).  The following is an excerpt from the book.

The following is another example of how block shipping takes place. Assume that in a 3-node RAC cluster a typical block (of table ‘salesman’) is brought into Instance 3 by a select operation of user C. Initially, the instance acquires SL0 (shared lock with no past image) and the same Block/Lock-element undergoes many conversions as different users at different instances handle it. The following operations show a clear movement of the blocks among the instances using cache fusion. It also shows the complexity involved. Refer to Figures 2.14 and 2.15.

 

Note: Assumption: Transactions update with commit, but there is no checkpoint until the end.

 

In Stage (1), the data block is read into the buffer of Instance 3 and it opens with an SL0 mode (Shared Local without any past image):

 

select sales_rank from salesman where salesid = 10;

 

This gives a value of 30. Thus, the data block is protected by a resource in shared mode (S) and its role is local (L). This indicates that the block only exists in the local cache of Instance 3.

 

Figure 2.14:  Data Block Shipping using Cache Fusion

In Stage (2), user B issues the same select statement against the salesman table. Instance 2 will need the same block; therefore, the block is shipped from Instance 3 to Instance 2 via the cache fusion interconnect. There is no disk read at this time. Both instances are in shared (S) mode and the role is local (L). So far, no buffer is dirtied.

 

In Stage (3), user B decides to update the row and commit at Instance 2. The new sales rank is 24. At this stage, Instance 2 acquires XL0 (Exclusive Local) at Instance 2 and the share lock is removed on Instance 3.

 

Update salesman set sales_rank = 24

Where salesid = 10;

 

In Stage (4), user A decides to update on Instance 1 the same row, and therefore the block, with the sales rank value of 40. It finds that the block is dirty in Instance 2. Therefore, the data block is shipped to Instance 1 from Instance 2; however, a past image of the data block is created on Instance 2 and the lock mode is also converted to Null with a global role. Instance 2 now has a NG1 (Null Global with past image). At this time, Instance 1 will have exclusive lock with global role (XG0).

 

In Stage (5), user C executes a select on Instance 3 on the same row. The data block from Instance 1 being the most recent copy, it is shipped to Instance 3. As a result, the lock on Instance 1 is converted to shared global with past image (SG1). On the requesting instance (Instance 1), the SG0 lock resource is created.

 

Select sales_rank from salesman

Where salesid = 10;

 

Figure 2.15:  Data Block Shipping Using Cache Fusion

In Stage (6), user B issues the same select against the salesman table on Instance 2. Instance 2 will request a consistent read copy of the buffer from another instance, which happens to be the current master.

 

Therefore, Instance 1 will ship the block to Instance 2, where it will be acquired with SG1. Then, at Instance 1, the lock will be converted to SG1.

 

In Stage (7), user C on Instance C updates the same row. Therefore, Instance 3 acquires an exclusive lock and Instances 1 and 2 will be downgraded to NG1 (Null global with past image). Instance 3 will have exclusive mode with a global role.

 

In Stage (8), the checkpoint is initiated and a write to disk takes place at Instance 3. Instance 1 and Instance 2 will discard their past images. At Instance 3, the lock mode will become exclusive with a local role.

 

The stages above illustrate that consistency is maintained even though the same block is requested at different levels. These operations are transparent to the application. All the mode and role conversions are handled by Oracle without any human configuration.

 

If there are considerable cross-instance updates and queries for the same set of blocks, blocks are moved across without resorting to disk read or disk writes. However, there will be considerable lock conversions, which may be expensive, though they are less expensive than disk read/writes.

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.