It's Still All About The Data

I was recently confronted with another situation where the interface rendered data useless.

A colleague was looking at an execution plan displayed in Oracle Grid Control. Most of the columns (operation, rows, bytes, cost) are either self explanatory or well known. The one that really bothered my colleague was cpu cost for the sort order by operation. The index scan and table look up were measured in the 10s of 1000s, but the sort order by was being measured in 1,000,000s (actually close to 6,000,000). Cost and io cost were less than 20, so the large number really stood out.

What is the unit of measure? According to the documentation for v$sql_plan, the column cpu_cost means "CPU cost of the operation as estimated by the optimizer's cost-based approach". No mention of a unit of measure. And a cpu cost of almost 6,000,000 to sort an expected 12 rows adds 1 to the statement cost.

A number without a unit of measure is just a number.

The second frustration with Grid Control was on the statistics page for a sql statement. I was looking at the top resource consuming user statement and found the information related to executions, cpu time, logical and physical reads, etc. Quite interesting data, but ultimately useless information. The interface fails to provide any temporal context to the numbers.

8,000,000,000 logical reads is certainly impressive, as are 600,000,000 executions. But what is the sampling time frame? An hour, a day, since the last hard parse, since instance startup? Without the relevant time information, the impact of optimization cannot be known.

Temporal context is critical to time relevant numbers.

It's all about the Data!

One of my riding routes is the path along the South Platte River. Because the river has a tendency to run high during the spring melt, signs have been placed at the underpasses to indicate that the path might be underwater. Unfortunately, these signs stay up all year and you quickly learn to ignore them as 99.99% of the time you ride the path is dry and clear. Cyclists become conditioned to ignore these signs, with potentially damaging results when the river rises.

Think about a program that warns you about viruses every time you start your computer. The first few times you run your antivirus program and find nothing. After a few reboots, you begin to ignore the warning...only to have it actually report a virus one day. A virus that takes out all your personal data.

If data displayed is inaccurate or irrelevant, people become conditioned to ignore it. If the data is critical, only display it when the situation requires. If the signs go up only when the path is under water or a box displayed only when a virus is actually found, people will pay attention (or at least are more likely to pay attention).

I recently purchased a car after doing research online. Vehix.com is a pretty good site with lots of cars listed and over 30 filtering options (year, number of doors, trim/style). It did not take long for me to figure out the car I wanted, but searching for a 2005 - 2007 Honda Accord Sedan 4 cylinder automatic transmission EX trim level gray fabric interior was not easy. Although each of these conditions could be specified, it was pretty pointless.

The quality of search on Vehix depends on the quality of data input. It is not unusual to find that Unspecified is the most common subcategory. What is the point of a search category if 90% of the data input is useless for filtering?

In looking for a place to stay for my ride in the Courage Classic Cycling Tour, I used VRBO.com. One of the "features" is a calendar indicating if the unit is available or booked. Unfortunately, this information is often incorrect. Not one of the units I inquired about was available for the time I needed, despite the calendar showing it available. In fact, several of the responses indicated that the unit had been booked for several months!

Interfaces are fluff and noise if the underlying data is not accurate and usable.