FW: Performance Tool Question (CONFIO DBFlash ) ...

As per Mr. Deeds request, I'm forwarding this on his behalf, while he wrestles Lotus Notes to the ground and teaches it who's boss.....wait, who is the boss? ;-)  

-----Original Message-----
From: DEEDSD_at_Nationwide.com [mailto:DEEDSD_at_Nationwide.com] Sent: Friday, November 18, 2005 2:21 PM
To: Bobak, Mark
Subject: Re: Performance Tool Question (CONFIO DBFlash ) ...

Oh, good grief. Can Lotus Notes be any more annoying? Can you forward this to the bloody list?
----- Forwarded by Dallas M Deeds/Nationwide/NWIE on 11/18/2005 02:19 PM

                          Dallas M. Deeds

                          DBA                      To:
oracle-l_at_freelists.org                                               
                          Distributed Database     cc:

                          Services                 bcc:

                                                   Subject:    Re:
Performance Tool Question (CONFIO DBFlash ) ...(Document   
                          Phone: 249-9981          link: Dallas Deeds)

                          Fax:  249-2601

                          01-04-33

 

                          11/18/2005 01:59 PM

 

 

I have been using DBFLash for over a year and a half now. I have been extremely happy with the tool. The sampling rate can be increased to 50 samples per second, but there is a point of diminishing returns. I have found that 1or 2 polls per second is perfectly adequate in 99% of my cases.

In practical experience with the tool, I feel that the Confio DBA's response to be accurate. Most of my databases have not been tuned to the point where I need a high polling rate to see the current problems ; - )

I have found that most events in my databases occur frequently enough with long enough waits that what I do miss, I don't need to care about - I have more pressing issues. DBFlash catches things well enough that I am certainly able to target my problems. My main problem is that I have so many databases (478 databases with 6 DBAs at last count) with so many problems, I need a very good targeting tool. I looked at the other 24x7 monitoring tools available, and they either didn't do the job, or the one that could do the job was simply too expensive for me to consider further.

On occasions that I need more data to pin down the root case (like two databases on the opposite ends of db links, both complaining about SQL*Net
waits) 10046 profiling with HOTSOS quickly gets me where I need to be (fixed) in 5 minutes.  

                          "Sam Bootsma"

                          <sbootsma_at_gbrownc.on.ca  T



                          >                        To:

<oracle-l_at_freelists.org>                                             
                                                   cc:

                          Sent by:

                          oracle-l-bounce_at_freelis  bcc:

                          ts.org                   Subject:
Performance Tool         
                                                   Question (CONFIO
DBFlash ) ...                                             
 

 

 

 

                          11/16/2005 04:19 PM

                          Please respond to

                          sbootsma

 

 

I have been reviewing the white papers for the DBFlash product from CONFIO.
I am impressed, but I do have one reservation.

DBFlash works by running a SQL statement (or group of statements) against X$ tables on the monitored database once every second. The data is pulled across the network to a repository on a separate database server and database instance and analyzed. A gui client can then access the repository and tell you which SQL statements are waiting the most, and what wait events the SQL statements are waiting on. It can also do this for database users, OS users, programs, and a few more.

My concern has to do with the frequency of polling (once every second). Oracle records waits in micro seconds, there are 1 million micro-seconds in a second (I think). So a wait can last 10,000 microseconds, and not be picked up by the software. In fact, I would think that most waits would not be picked up by the software because most waits probably start after one snapshot and finish before the start of the next snapshot.

I posed this question to CONFIO, and this is the response from their DBA:

1. With wait event tuning, the events occurring more frequently will be caught by DBFlash. We do statistical sampling which by definition will miss some things. However, the problems, i.e. the wait events happening more frequently or waiting more time, will be caught by DBFLash. In other words, DBFlash will be able to find your problematic waits which is what you want.

What do you guys think? Is the integrity of the performance data questionable because of the "long" delays between polling? Or is the response from CONFIO valid?

Thanks!

Sam Bootsma
George Brown College
sbootsma_at_gbrownc.on.ca
416-415-5000 x4933

--
http://www.freelists.org/webpage/oracle-l