Top 60 Oracle Blogs

Recent comments

July 2008

Planning for Birmingham….

Or should I say ‘Brum’?

Well, I’ve just been notified that one of my abstract submissions, “Introduction to Locks and Enqueues”, has been accepted by the UKOUG for the 2008 Annual Conference, coming up in December.  I’m really looking forward to it.  This will be my 4th year attending.  It’s also the first year the conference will be expanded to a full 5-day week.  There’s bound to be a ton of great material.  I have to say, even for someone coming from overseas, this conference is well worth your time and money.

See you in Birmingham, er, Brum!

Oracle Locator Express

If you do much work with the Oracle database on Windows, and you have 1+N Oracle homes installed, you've probably lamented the fact that the Oracle Home Switcher is no longer included with Oracle.

I can't recall exactly what the tool was called or which version Oracle was at when it ceased to be a part of the installation. I do know that it doesn't work with 10g+.

A little tool called Oracle Locater Express fills this niche nicely, and it does work with 10g. Sorry, have not yet tried it with 11g.

"Oracle Locator Express"

I've used it for several months without issue, save one minor glitch.

Sometimes Oracle 10g Homes are not displayed properly in the list of Oracle Homes to choose from. Other than that, no complaints

Advanced Oracle Troubleshooting Guide, Part 8: Even more detailed latch troubleshooting using LatchProfX

In my last AOT post I published my LatchProf script which is able to sample detailed latchholder data from V$LATCHHOLDER.

Latchprof allows you to drill down into your latching problems at session level (which V$LATCH, V$LATCH_PARENT and V$LATCH_CHILDREN can’t do). It allows you to get valuable details about individual sessions who are holding a latch the most, therefore likely contributing to the latch contention problem the most.

Closed database and WITH subquery

Here’s an interesting issue I found when running a query using WITH subquery factoring when database was not open (it was in NOMOUNT mode in current case).
As you probably know you can query DUAL table when database is not open, but in this case the actual query is made against X$DUAL as seen below:
SQL> select * from dual; ADDR INDX INST_ID DUM -------- ---------- ---------- --- 051ED14C 0 1 X SQL> When you have above fields when querying from DUAL then you know your database is probably not open.


A good day today. I was privileged enough to be at the paper selection day for the UKOUG conference in December 2008. For those who don’t know what happens, and perhaps suspect some sort of elite giving themselves presentation slots, here is roughly how it works. 
Firstly a reasonably large group of reviewers from around the world, [...]

hope for the future

So there I was this morning sitting on the tube (UK underground rail system) when a young student got on an sat down beside me. Obviously being both English and a commuter I couldn’t possibly speak to her!, but I did sneak a look at what she was reading. These turned out to be the notes she had made on her course that she was now going over presumably in preparation for exams. The notes this morning were on normal forms, entity relationship and data modelling. 
So there we go, a young female student of IT would be pretty good in itself, the fact that she was studying relational theory was the icing on the cake. There is hope ladies and gentlemen, there is hope.  

Advanced Oracle Troubleshooting Guide, Part 7: Sampling latch holder statistics using LatchProf

I have been too busy since getting back from vacation, thus no posts for a while. But I hope the waiting was worthwhile as I present you LatchProf, a tool for digging in to latch contention problems – using plain SQL and sqlplus!

As, I’m still busy, I make it short.

LatchProf is a script similar to WaitProf, only it samples latch holder statistics from V$LATCHHOLDER. As V$LATCHHOLDER contains a SID column (with session ID of a latch holder) it becomes possible to find who is hitting a latch the most (a way to prove that crappy monitoring tools which constantly scan through V$SQL DO cause library cache latch contention themselves).

The 3 step program

Richard Foote updated his blog today with a description of the 3 step process for troubleshooting technical problems with business systems. Briefly his 3 steps are

  1.  Identify an actual problem that needs addressing, one that’s problematic to the business, not one that only exists in some statistic or in one’s imagination
  2.  Determine what’s actually causing the problem as identified in Step 1.
  3.  Address the specific issue as identified in Step 2.

This started as a comment, but grew a bit. I suspect that most of the time the ‘difficulty’ lies in step 1. Identifying a problem that is causing drag on your employers business. This requires at least: 

  1. understanding the business in the first place.
  2. specifying to a high degree of certainty the issue.
  3. quantifying the impact.

IT staff are notoriously bad at 1) and 3) and business staff are notoriously bad at 2) and 3). For example some colleagues of mine went to a meeting with business users of a core system that has historically suffered significant downtime. We identified and made some infrastructure changes that have reduced the downtime by approximately 40 days a year (that’s right this system was running at circa 80% availability).  The system has been running in it’s new configuration at over 99% availability, and helpdesk calls have all but vanished. The meeting was quite difficult since the business users wanted to complain about the stability of the system. In particular they were upset with the 99% availability statistics because they felt that the stats did not reflect reality, which was that occasionally data was ‘lost’ or application sessions were apparently hung. The fact that other users could continue to work did not mean that the service was available.