Posts mit dem Label Philosophy werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Philosophy werden angezeigt. Alle Posts anzeigen

2017-07-07

The Slow Tires

Once there was a man with a car. On this car he had 4 tires.
As the car is a modern one it has a nice board computer which collects many measurements. One is the rotation per minute of the tires.
One day it took more time for the man to get home than usually. So he decided to check his car's computer for any values which could lead to that delay.
After some minutes searching he made an alarming observation: This days average rotations per minute of the tires were much lower than the values of the day before. So he did a quick check if he found some errors in the computers log, but as everything seemed ok he was puzzled.
The shop where he bought the tires was still open and so he went there and ask a technician to check if the tires were ok, as they were slower today than yesterday. A technician checked correct pressure and even made sure the tire balancing was ok.
But there still was the lower rotation per minute for this day, and no explanation.
Next to the tire retailer there was a garage, which owner was friends with the technician of the tire shop. He agreed to check the car, if there was anything he could find about this days slow tires. But there wasn't anything. No errors, motor control all ok, the shock absorbers were even less utilised this day than the previous day.
During the investigation our man tried to remember if anything has been different to the previous day. He remembered some things: the day before he had lunch, which he skipped on this day to get home early. And even the coke in the cup holder was empty. So in theory the car should even be lighter than the day before. He told the two engineers about his memories, but they didn't care about some decagram changes in weight. At least the mechanic confirmed the average rotation was slower on this day. It matched the slower rotation in the gearbox, something which was not available for a customer in the cars memory. So the measurement was correct.
All three men were puzzled. But the mechanic had a friend in highway administration who had access to the highways measurements. Maybe there wa a technical issue there?
But the highway was in good shape, quite similar as the day before. Nothing was broken, all signs working ok. No accident reported. Asphalt temperature was slightly higher than the day before, but perfect within the tires comfort zone. The mechanic got one more information from his friend: Highway administration was more pleased about this day, as the utilisation was higher when the man went home on this day compared to his yesterdays commute, but still within acceptable boundaries to avoid heavy complains.
Now the men had checked virtually everything which came to their mind: tires, many components of the car, highway. Everything fine, no errors or accidents, totally within acceptable boundaries.
Big data, big confusion.
The tire retailer grabbed his smartphone in frustration to check new gossip in the app of his preferred local radio station. By accident he hit the traffic tab with his calloused fingers and saw a nice histogram of the traffic in highway segments around the city. At the travel time of our man on this day there were much more cars in his highway segment than at the day before. He showed this nice graph to the others and slowly it all made sense:
They all know from own experience, more cars on the highway will lead to slower average speed at some filling level. Traffic is still smooth but the individual just can't do high speed anymore, regardless of legal limitations or police.
Of course at this point the utilization increases, as from the highway administration perspective, there are more tires on the road now. Even when each one rotates slightly slower, the total sum of all of them is higher than a single car at highest speed ever could create.
Our man just could not drive as fast as yesterday as many other cars were in his way.
And the tires could not rotate faster for exactly that reason.
With all this insight our mechanic once again called his friend and asked him if he know a way to improve the situation. The answer was simple:
Build a dedicated highway for you. Never share it with anyone. Not even with your best friend. IT will go perfect most of the time. But the one day you want to do the surprise birthday party, exactly this friend will be on the highway ahead of you and block all your best intended efforts.

I'm sorry for all who love the english language - if you want to translate this to proper english, please do so and inform me, I'll remove this content and link to yours!


2011-07-18

estimated plan stability

Sometimes I am searching for any method to solve a problem. And after some investigations, mailing lists, direct contact of much smarter people, I come to the conclusion:
It's just not possible!
(Or at least not within reasonable effort).

One of these problems, or more precise questions is:
How likely is the current explain plan for a given SQL statement to change?
I call this

estimated plan stability


Unfortunately there is currently no such feature but at least I can give some examples, what I would like to have:
  • E-rows vs. A-rows
    If they differ a lot (in any line of the execution plan) it might be a hint the plan is far away from reality, or in risk to change?
    Of course for A-rows gather_plan_statistics or similar is needed.

  • Best so far in 10053 trace

    If you ever have analysed a 10053 trace, you might know the line starting with Best so far ....
    If the 2nd best is not far from the 1st, I assume small changes in the data might lead to a different execution plan.

  • Binds outside histogram boundaries

    If a bind variable is outside of the min/max values of a histogram, the optimiser tries to guess how many rows it will get from this predicate/filter. Of course this can be horrible wrong, and should be also shown by my 1st suggestion.


These are only 3 possibilities. They should show some areas of information where I'd like Oracle to collect and provide more data than they do at the moment. Probably they would also be valuable for others? Any other suggestions out there?


2011-06-01

Artist of Farmer?

This morning I read a twitter message by Jeff Smith (aka @hillibillitoad):
OH: "Once we get our system running, we don't touch it." Yeah, that generally works pretty good.
I like Jeffs tweets, blogs and comments as he is a very smart guy and still keeps his mind open for other ideas.
In this particular case I have to contradict, but I was not able to condense it into 140 chars.



Most people in the IT business seems to follow the sentence "never touch a running system" like a commandment. For me this often sounds like the "please don't touch" in an art museum.



This brings me to an interesting question: Do these 'most people' see themselves as artists, and their work as art?


Let me give you another picture:


Imagine a farmer which seeds the crops in spring, did really everything right and then sits down and does not touch his running system. You might guess his harvest?



So what's the big difference here?
Artwork most of the time is first created for a dedicated purpose. As long as the purpose does not change, it's expected to satisfy this purpose.
The purpose of an artwork slowly changes, I'm quite sure most of the time it can be measured in decades or centuries.
Also plants are seeded for a dedicated purpose. But their purpose is the rapid change. To live, to growth, to get harvested after some time. So the farmer has to look after his crops all the time. In the best case, he even can improve and steer the change to his advance.
For me the big difference between an artist ('don't touch') and a farmer ('care and steer') is the timescale of the changes. If you expect your work to be never changed (and in a definition of 'life' things which do not change are just dead) prevent them from any interaction.
I prefer living systems. So I take the duty and care for them.

2010-03-17

Job, hobby or passion?

In my last post I summarized the answers I got on a mailing list for the short question:
what ist the fastest SQL you can create?
maybe the most remarkable answer was
I think y'all need a hobby- and one that doesn't include oracle!


Well, maybe I have to answer. Which is not that easy.
Let's try to confine a little bit: Let's start with Job. I see a job as a work which I get paid for. So i need a job to make a living.
At first view a hobby is a totally contradiction to a Job: I do it at my own will and possible even spend money to do it. A hobby is something I do to have fun.
But sometimes it's not that easy.
Even if job and hobby are a contradiction in money and choice, they are not imperatively a contradiction in fun.
Assume, you have a job which at the same time is fun. Why not enjoy this: instead of paying for fun, you get paid for! Maybe it's ok if I call it an avocation?
Of course, it's not that easy all the time, but nothing is that easy, not even a hobby ;-)
I see one more bonus in this situation: I assume I'm quite good in the tasks I get paid for. And at least at the moment I get a fair salary. I hope, both will at least stay at this level for a long time.

This all leads me to an answer:
I have a job in IT, especially Oracle. Why do I need a hobby?