Pythian Group

Hello Community!

In this post:

• InSync11 – Oracle Conference!
• RAC SIG ANZ – way to find each other!
• Other ways to find your RAC SIG ANZ fellows!

InSync11 – Oracle Conference!

This post is addressed to all RAC SIG members who is planning to participate in the InSync11 conference this August in Sydney Australia! InSync11 is organized by Oracle Community for Oracle Community and is one of the biggest Oracle technology dedicated events in Australia and New Zealand region. If you are in the area by August 16th and haven’t considered participating yet, you should! This is a wonderful opportunity to learn from others, listen to experts from around the world and meet face to face people from your networks (including RAC SIG).

RAC SIG ANZ – way to find each other!

There are 130 members from Australia and New Zealand region in RAC Special Interest Group today! I am sure that many of the members will participate in the InSync11!
Read the rest of this entry . . .

I decided to reprise my commentary on Oracle RAC and the gv$ views after reading Patrick’s comments on my previous post. It is always encouraging to know that someone is kind enough to read your work and provide insightful feedback – many thanks to him!

I can use a script now to find the locks in a RAC environment, but until this point I couldn’t have told you how the script actually works. Frankly, the documentation that I found on Metalink is dry and boring for such an important (and sometimes entertaining) subject as locks.

There are two questions that I wanted to answer here: Can you use the gv$ views with a non-RAC environment? What do the WHERE clauses in a good block-checking script do?

First, can you use the gv$ views to check for locks when you have a single-instance, non-RAC database? The reason this question is prevalent in my mind is that we just completed an 11.5.9 application clone (with RAC enabled on the source environment but not on the target) for a customer who has been busy purging data from the new environment. When a performance issue arose, one of the first things that we did was to see if there were any locks. We employed the same script that had been developed to tell us if there were locks on our RAC-enabled instances — and the script returned no records. At the time, I thought that perhaps the gv$ views would not be populated in a non-RAC database. I tested this by executing the following SQL statements on the non-RAC database:

select sid, id1, id2 from v$lock minus select sid, id1, id2 from gv$lock;

select sid, serial# from v$session minus select sid, serial# from gv$session;

Read the rest of this entry . . .