Databases exist to store data.  That said, a database is infrequently useful entirely on it's own.  So, managing databases means that we're often interacting with applications that access that data.   Some of the common applications that we work with include Oracle E-Business Suite, Tomcat, Apache and ColdFusion. 

We had an entertaining problem this last week with Apache logging on a Linux server that gave our SAs fits.  The great Google search also failed to find a real solution, so I thought I could post ours here.

First, the problem.  We were seeing all the traffic in the logs originating from the same IP address. We were sure that this was not actually the case.

The ultimate cause of the problem was that the version of apr (Apache Portable Runtime) 0.9.13-1 was installed.  For some reason yum didn't want to update it to 0.9.4-24.9. This version of apr was installed by a handrolled RPM with an older version of apr.

The solution was to force the upgrade of apr with 'rpm -e --nodeps apr apr-util' and 'yum install apr apr-util'. Very strange behavior that 'yum update apr' wouldn't do it.

Maybe it will help someone else.   Happy Friday.

We've been working on lots of new customers and in our spare time writing a few scripts and white papers.  I've added a link to the right to download Chuck Edward's paper on encrypting Oracle traffic with SSH tunnels.  Ed's been working hard on some handy Oracle scripts and I'll have that tarball published sometime this week.  

In the mean time, keep sending referrals our way.  We'd be happy to talk to anyone for 15 or 20 minutes about database management and hosting.  

As proof, I received this in this morning's email --

You and I spoke a few times back in the summer... I was working with $POTENTIAL_CUSTOMER, exploring hostng costs for their web environment. I had been directed to you via the folks at $CURRENT_CUSTOMER, who were currently hosting $POTENTIAL_CUSTOMER's development environment at that time. You were professional and kind enough to share a good bit of your time and knowledge with me. I found you to be very helpful and knowledgeable and therefore kept your contact info on file for future reference....

All potentially identifying info has been removed to protect the innocent.

Lastly, look forward to some info about Blue Gecko at Oracle Day April 9 (not to be confused with our favorite Oracle Days hosted by PSOUG).  

Howdy folks!

Well, it's been a little over a week since we've made our monitoring tools available to the open source community.  It's always a bit interesting to take something used internally and try to package it in such a way that it will be useful to others.   I hope those of you who have downloaded Monocle have had an opportunity to install it and perhaps even give it a run!  If you have questions, please don't be shy!

Great news! 

In a week or two we'll be releasing version 1.1 of Monocle, (we'd hate to be accused of possessing "idle hands".)  We're particularly excited about this release as it integrates Oracle's dbms_server_alert technology with Monocle, (dbms_server_alert technology is the same technology used by Oracle's Grid product.)  The good news is you'll have over 100 new things you can monitor using Monocle/Nagios. The bad news is...  you'll have over 100 new things you can monitor using Monocle/Nagios!  In all seriousness, depending on your situation there are probably a dozen or so of these new dbms_server_alert things you'll want to pay attention to.  Examples of some things you might choose to monitor are:

• Library Cache Hit Ratio - If this is low, you may need to bump up the library cache.
  
• Avg. No. Users Waiting On Concurrency - If this is high you may be experiencing latching and/or locking issues.
  
• Shared Pool Free Pct. - If this is low, you may be headed for the dreaded 4031 - unable to allocate memory error!
  
• Process Limit Pct - If you're close to 100% you'll need to increase "processes" in the init.ora.
  
• Long Table Scans - Doing a lot of these?  You may have some sql to tune!
  
• Hard Parses Per Second - If this is high, you may have an issue with bind variables.

... and so I'm sure, you get the picture.

Whoops!!!

If you're running a version of Oracle 10.1 there's a small bug you should know about:

The job monitor won't compile in Oracle 10.1  You can fix this by editing the package bg_job_monitor.pkg.  

Replace:

       , dsj.schedule_type

With:

      , NULL as dsj.schedule_type

Of course the above will be fixed in version 1.1.

Cheers!

Last week we soft launched our new monitoring product Monocle.  We've been slowly adding more links and publicity to point people to our code repo.  Get Oracle database monitoring here.  (Couldn't resist a bit of SEO linking.) Anyway, this is the official press release.  We're super excited about actually sharing the monitoring infrastructure work we've been doing for the last several years with the open-source community.

 We'll get the primary contributor to write a little post for the blog next week.  He wrote a lot of Monocle documentation you can read in the mean time. 

Alas, Chicago weather is conspiring against us. There won't be travel and presentations this week.