Wednesday, February 28, 2007

What I want to be when I grow up...

A friend of mine sent me an email on Monday:

... Any chance you could talk with my students about blogging and business?  They are undergrads and the class is "Six Degrees: Social Networking & Business". ...

I really liked the idea - so we discussed the topic and today I was the guest speaker in Professor Melander's class at American University:


Which brings me to the title of my post here.  I was so jealous when I found out what job she was doing now - last I talked to her, this was not her job.  I've often said "when I grow up, I want to teach" - she wanted the same thing and now she does...


That is her class and I got to talk to them for an hour today.  It was neat doing a "non-database" talk.  I talked about my initial exposure to online "social networks" - the Usenet news groups.  How that exposure helped me in my job over time - and how it morphed into asktom, the column, the books.  How asktom was a "corporate blog" in its own right (before blogs were cool) and ultimately how came about.  We also talked about the perils and pitfalls of blogging (threatened lawsuits, real lawsuits, differing laws in different places) - but mostly how they can be used as a communication medium - to interact, discuss.

I talked for 30 minutes and we did a question/answer session for 30 minutes.  It was really quite enjoyable.

The future looks good :)

Tuesday, February 27, 2007

Peer to Peer

Wow, now that is a peer to peer set of people there! I was reading Tim Hall's blog and he said he was in this months peer to peer section of Oracle Magazine - along with "with two guys nobody has ever heard of…"

So, I clicked through to see who the two "nobodies" were and just laughed out loud.

Check it out.

What is your FizzBuzz factor...

I was reading "Why Can't Programmers.. Program?" this morning.  It is sad - but near close to true.  I do not believe 199 out of 200 cannot program - but it isn't too far from the truth.  It manifests itself in many ways - from the examples in that article of just not being able to come up with simple algorithms - to my biggest pet peeve.  Not being able to phrase a comprehensible QUESTION

If you don't know how to ask for help solving your problem, that is - if you cannot phrase your problem as a set of specifications, detailed specifications - you'll never get a reasonable answer except purely by luck or accident.  More likely, what you get in response to a poorly framed question is an answer that appears to work (given the poorly specified requirements - typically without any of the boundary value conditions thought out), but doesn't.  And the "but doesn't" part is never discovered until "too late" (when it becomes impossible to fix due to "management says we cannot touch the code").

Anyway, when I read their FizzBuzz "specification", I immediately thought of how I would solve it :)  Using SQL of course!

ops$tkyte%ORA10GR2> with data
2 as
3 (select level l
4 from dual
5 connect by level <= 100)
6 select l,
7 case when mod(l,3)=0
8 then case when mod(l,5)=0
9 then 'FizzBuzz'
10 else 'Fizz'
11 end
12 when mod(l,5)=0
13 then 'Buzz'
14 else to_char(l)
15 end fb
16 from data
17 /

---------- ----------------------------------------
1 1
2 2
3 Fizz
4 4
5 Buzz
6 Fizz
7 7
8 8
9 Fizz
10 Buzz
11 11
12 Fizz
13 13
14 14
15 FizzBuzz
90 FizzBuzz
91 91
92 92
93 Fizz
94 94
95 Buzz
96 Fizz
97 97
98 98
99 Fizz
100 Buzz

100 rows selected.

Monday, February 26, 2007

You know you work at a geek company when...

Ok, we've had some snow recently here in Virginia.  Normally when it snows - you might think of people making snowmen:


or maybe even snow angels:


But no, here at Oracle, they like to make statements.  Here is the view from my window this fine morning:



On a different note, I've commented about Seth Godin's blog before - but this one just struck me this morning.  It was about preciseness in language.  I wrote about that same thing a while ago.  It is so true - preciseness in language is pretty important if you want to get your points across - or even read!

Thursday, February 22, 2007

Tools and dumbing down...

Just recently, I commented on an article "revenge of the calculators".  It talked of the dumbing down that all too easily happens when one relies far too much on their tools.  Sort of like the numerous reports of people following their builtin GPS navigation systems into rivers, dead ends, buildings, sand piles and the like.

Kathy Sierra just wrote about the same issue

I do believe tools are necessary - her analogy of tweaking postscript rather than using a word processor hit it dead on.  You sometimes do need a tool to be more efficient - the inner workings of postscript are not useful to most people (glaring exception would be the people that make the tool that generates postscript).  However, the cashier that cannot make change - or recognize when the machine is telling them to do something clearly wrong (because they plugged in the wrong numbers) is in a heap of trouble.

The hard part is finding the fine line between what you need to know and what you can remain dumb about.  I struggle with that line we all of the time with the database.  There is a lot that we don't need to know (it might be interesting to some of us - but we don't need to know some things).  It frustrates me sometimes when people insist on learning internals - prior to mastering analytics, SQL in general, transaction semantics, physical and logical design, and so on.

On an unrelated note - I was stumbling around this morning and hit this page.  For some reason I was reminded of being a kid and people would counsel you: "when someone does something bad to you, just breath for 10 seconds before responding - cool down first".  I wonder if their 30 second advice actually works.  If my experience with the typical end user is taken into consideration - there is 0% chance that it does!



The internet is just broken for me today.  Hate those "unknown errors":


At least I didn't have to count to 30 for this one.  I wonder of the advice to "please try again" is different if they encounter a "known" error :)

Monday, February 19, 2007

Sláinte mhath!

I was reading around over the weekend and saw Mark Rittman and Doug Burns talking about a Miracle Database forum happening in Scotland.  I was originally scheduled to head over there - but unfortunately cannot make it this time.  I was really looking forward to it as I never have been to Scotland before and the timing would have been excellent.  Normally, when I get to Europe, it is December, January, February  - you know, the really warm months :)

Anyway, if you are in the area of Scotland at the end of May 2007, that looks like an excellent collection of speakers and the venue cannot be beat.  Just don't forget your kilt (that is Thomas Presslie - the forum organizer - leading Mogens Nørgaard on stage at the UKOUG in 2005)



Sunday, February 18, 2007

Ok Megan and Alan, beat that...

My daughter Megan has discovered stumble upon - and stumbled upon this game. Beware, it could be addicting:


Megan and Alan have gotten to 7 balls so far, I just had to beat them. I'm sure they'll pass me again tonight :)

I'll just have to practice more.

Friday, February 16, 2007

Just Testing...

I got to meet Steven Feuerstein for the first time not too long ago.  He did two talks at that conference - one was on a new testing tool he has been working on for quite a while now.  It is all about PL/SQL (of course - what else would you expect from Steven :) and looked pretty interesting.  You can check out some information about it here.

I have on my todo list now to download it and play around with it - there is a free trial.  If you do the same - feel free to comment on it, here or on Steven's blog entry.

Tuesday, February 13, 2007

Long live the command line...

My friend Alberto Dell'Era sent me this very interesting link.  I never thought of it that way - but it is so true.  Google is the new command line!  We've come full circle back to typing commands in to get things done.

I use "define:" in Google all of the time - as well as "site:" to search this blog.  In a way, the search engine interface is the command line of the 21st century.  Sweet :)

Too Funny...

An "anti-page".

A suggested list of things not to buy your love interest for valentines day.

Now, the vacuum cleaner - obvious, the "You on a diet" book - apparent.  But some of them - funny.  The Princess Leia wig, Barbed Wire, a book entitled "He's Just Not That Into You (The Newly Expanded Edition)", Ball & Chain t-shirt, Triple Complex HaliTonic for Bad Breath and Halitosis, and my favorite (you have to see it to fully appreciate it).

Monday, February 12, 2007

I learn something new every day...

Ok, time for a geek (eg: having a smidge of technical content) post.  What I learned new today about Oracle that I don't think I knew about before.  Notice that I said "that I don't think I knew", there is a chance I did - but forgot.

In a nutshell - LOBS are always out of line in an index organized table unless you have an overflow segment defined.  And that fact may have a massive impact on your performance during inserts, retrievals and the total amount of storage used.

ops$tkyte%ORA10GR2> create table t
2 ( x int primary key,
3 y clob
4 )
5 organization index
6 lob (y) store as
7 ( enable storage in row )
8 /
create table t
ERROR at line 1:
ORA-22853: invalid LOB storage option specification

So, we cannot special enable storage in row here at all - not without an OVERFLOW clause:  

ops$tkyte%ORA10GR2> create table t
2 ( x int primary key,
3 y clob
4 )
5 organization index
6 lob (y) store as
7 ( enable storage in row )
8 overflow
9 /
Table created.

ops$tkyte%ORA10GR2> insert into t
2 select object_id,
3 object_name
4 from all_objects;
50047 rows created.
Elapsed: 00:00:03.68

ops$tkyte%ORA10GR2> select segment_name,
2 bytes
3 from user_segments;

------------------------------ ----------
SYS_LOB0000065089C00002$$ 65536
SYS_IOT_TOP_65089 4194304
SYS_IL0000065089C00002$$ 65536
SYS_IOT_OVER_65089 65536

About 3 and 1/2 seconds, about 4 MB of data - however, if we just "default" - don't specify the overflow: 

ops$tkyte%ORA10GR2> drop table t purge;
Table dropped.

ops$tkyte%ORA10GR2> create table t
2 ( x int primary key,
3 y clob
4 )
5 organization index
6 lob (y) store as
7 ( disable storage in row )
8 /
Table created.

ops$tkyte%ORA10GR2> insert into t
2 select object_id,
3 object_name
4 from all_objects;
50046 rows created.
Elapsed: 00:02:13.66

ops$tkyte%ORA10GR2> select segment_name, bytes
2 from user_segments;

------------------------------ ----------
SYS_IL0000065094C00002$$ 3145728
SYS_IOT_TOP_65094 2097152
SYS_LOB0000065094C00002$$ 419430400

As you can see - when we skip the overflow clause - the LOB will be stored out of line - regardless of size.  That means each row will touch the lob index and maintain it and each row will allocate at least a chunk of storage (even though we only need 30 characters at most in this example).  So, we go from 3 and 1/2 seconds roughly using inline LOBS to 2 and 1/4 minutes when the LOB is out of line.  Additionally - we go from 4 MB total storage (all of it in the IOT) to over 400 MB (due in part to my chunk size, 8k in this case - as small as possible) spread across the IOT, the lob segment and the lob index.

All of this came about due to a customer saying "sqlldr is really slow against tables with LOBS".  Slowly peel away the onion to find it was IOT's with LOBS (not just tables), peeling further back to recognize the default (and only) storage for a LOB in and IOT without an overflow is "disable storage in row" - and there you go.  "The reason".

Lots of layers on some onions.

Friday, February 09, 2007

It doesn't happen often...

There is nothing more freeing than.....

A totally empty inbox


Don't know what it is about that - but it is a very good feeling indeed.  I've done everything I had on my todo list of things to do!  I'm free now :)

Well, except for the questions in the asktom queue of course... Drat, not as done as I thought.  See this is what the asktom homepage looks like when I'm taking questions (proof that this view of that page actually exists)


and in the spirit of learning something new everyday - the snippet I pointed too in my last entry is not a "when others then null;", just looks like it could be one :)


It is not limited to PL/SQL!

How to do the logical equivalent of:

when others
then null;

In C#.  Brilliant :)

Thursday, February 08, 2007

It takes all kinds...

It takes all kinds of people to make everything work.  I stumbled on this short paper by Isaac Asimov this morning and really enjoyed it (again, it is something I've read in the past in one of his collections of papers).

I can relate to what he is saying.  Ask me to write a really complex SQL query - no problem.  Ask me to do some electrical wiring - forget about it (I'll have to write someday about how I blew every fuse in my apartment building years ago installing a dimmer switch).

We are all good at something, we are all expert in some area.  The trick I guess is finding out what that is.  Hopefully it is something you enjoy doing - and I think it almost always will be.

Because we enjoy doing things we do well.

Wednesday, February 07, 2007

22 Tips...

I stumbled upon this site a while ago and wrote about an article they had there.  Since then, I've subscribed to it and have mostly liked the postings.  Only wish there were more of them :)

Today - 22 tips.

#3 - Easy to say "forgive and forget".  Really hard to do.  Really really hard sometimes. 

#4 - Definitely agree with "Associate with positive, supportive people".  Another way to say it might be "be with people that like to be with you".

#5 - "Get involved in work and activities you love" - yup.  I'm always confused when people ask me "should I be a DBA or stay in development" (or vice versa).  The questioning goes along the lines of "which is a better career path".  The problem I have with that question is - it is so personal, only the person asking the question stands a chance of getting the right answer!  I would always lean towards development - since that is what I like, what I do, what makes me tick.  But - some people don't like it - but they really love being a DBA, or a Veterinarian, or a whatever. 

I laughed at #13 - "Ignore yourself".  Then I read what they meant by it.  Me overthink things?  Obsess?  Dwell on things for way too long - nah, I'd never do that.  (sarcasm there, I tend to obsess)

#16 - "start giving more".  Indeed.

Anyway - many of the other points make sense as well and depending on your attitude/situation - some more than others.  In short however, I really like that site and the articles therein.

Tuesday, February 06, 2007

Do it yourself asktom...

I was reading Scott Spendolini's blog this morning and he reminded me of something I forgot to announce.  After repeated requests over time - the application behind the asktom website is available for download.

You can read Scott's take on this here.  Basically - the APEX team is providing a set of "packaged" applications and other open source projects to anyone that wants them.

I would like to take a moment to thank two people for their help recently.  They are - Christina Cho:


and Marco Adelfio:


the team that rewrote asktom for the purpose of making the "ask the expert" software available.  They had the unenviable task of taking a bit of software that evolved from my lovingly handwritten mod-plsql first version of asktom, into the first html/db application.  Where it got "stuck" in a time warp - stuck at version 1.4.something of html/db - a release that was never actually released.  It was not really upgradable - so they took it and redid it.

I've been very pleased with the results so far...

Monday, February 05, 2007

Semantics - the meaning of words...

It is interesting (to me anyway) how the meaning of words, or the interpretation of a phrase can radically affect how something is taken by someone else.

Consider the following situation.  You are offered a chance to do something next weekend.  You don't really care one way or the other if you do this event.  You might be tempted (I would have been until recently!) to say:

I am ambivalent about doing that

Turns out that would be an entirely incorrect way to say that!  It certainly does not say what you mean.  Ambivalent means you have really strong, conflicting thoughts (like a love/hate pair of feelings) about something.  I always thought it meant "I don't care one way or the other" - because I never really looked it up, rather - I probably deduced its meaning from the way it appeared to be used.

I only discovered this in a conversation with a friend who was trying to make a tough decision.  They expressed their "ambivalence" and I said something to the effect of "wow, if it were me - I would be torn with strong reasons pulling me in two directions".  They said precisely :)  A discussion as to the meaning of the word ambivalent followed and that was when I learned what ambivalent really meant.

It makes me a bit leery of using that word in the future :)  What if I use it correctly, but the person listening to me has the wrong meaning stuck in their head?  It completely changes the meaning of what I'm saying.

I read another more subtle example of this over the weekend.  The article is Programmers Don't Like to Code.  I myself have said "coders love to write code - it is what they do".  But, after reading that, I would have to at least partially agree.  Coders don't necessarily like to code - they like to solve problems - in their own way (which necessitates writing code).  Maybe a case of false causality :)  Coders write code not because they like to, but because they have to.  Not necessarily a problem with not understanding the correct definition of a word - but how a phrase is interpreted.

I am reminded of this old entry of mine...

Saturday, February 03, 2007


I really like science fiction - if I am reading for fun, it is usually in that category (usually, not always - last book I re-read for fun was this one by Mitch Albom). 

Someone reminded me of this sci-fi fact via email yesterday referring to a recent blog entry of mine:

That's two of his older stories I've seen on the web in the last two days.  This is one of my (and Asimov's ) personal favorites.


Isaac Asimov - one of my all time favorites.  As you can see from the spines - those books have been read (and most more than once).  I first read them growing up and now that I re-read them, still enjoy the stories.  Maybe even more since I'm sure some of the adult humor didn't quite hit me as a boy.

I've recently read all of the works of a relative new comer to the sci-fi scene - Alastair Reynolds.  If your are interested in seeing if you like his style - I strongly recommend Century Rain.  I read it this summer - it is a combination "romance, sci-fi, mystery thriller" all rolled into one.

My son Alan (14, the opposite of my age 41) had exams the other week and during that week he would have some down time to fill.  So he asked me for a book to read and I gave him that one.  First day he came back - it was half read and he really liked it.  Now he is onto the rest of the series.  Sort of nice that a book like that can appeal to such a broad range of ages (either that, or I'm easily amused or Alan is really sophisticated :)

I have in my wish list on the soon to be released next book of his, Galactic North.  It'll give me something to read this summer.

 In case you are curious, I'm currently reading Palestine: Peace Not Apartheid, definitely non-fiction.

Friday, February 02, 2007

Test Cases...

A couple of days ago, Peter Scott had an interesting post on test cases.  I agree 100% with the sentiment expressed there.  If you search for "test case" on my blog here you'll get snippets like:

Give me a short test case. Something small, yet 100% complete. Concise - but self contained. Remove anything not relevant to the problem.

Tiny is good, but complete is a requirement.

999 times out of 1,000 - when I build these myself - I find my own mistake or omission.

Test cases are so very important.  And seriously - most of the times when I build them, I find my own mistake or find a workaround to the problem at hand.

And if I don't, someone else will see it - it will be digestible, small, easy enough to understand.

I see Tim Hall has "weighed in" (weighed in - get it :) on my last blog entry.  I laughed out loud at his last sentence, the conclusion - very nice.

Thursday, February 01, 2007

How to scale...

I received an email this morning from another Oracle employee and the gist was

"what percentage of the questions regarding scalability, reliability or performance you get are as a result of an 'elegantly' designed middle tier implementation that just took for granted a well tuned, well designed database"

Meaning, the presumption was made that the database will just scale and perform well without any serious thought. This question came about as a result of a discussion he was having with another internal employee who had (wisely) written (emphasis is mine)

I think some of the successes that I had in development projects as I started doing more with middle tier development always came from my early work and knowledge of the database and its capabilities. I found with Scada systems, billing systems, etc. that no matter how well your architect a system, if the database is not used effectively, then your systems will never scale or be reliable. Architects put so much time into creating what they perceive to be a perfectly architected middle tier (or SOA), without realizing that much of their success will come from the Database tier.

It has been my experience that too many of the “middle tier” experienced people now days have no knowledge of how to effectively use the DB, how to architect systems with a large middle tier component around a DB, and how to take advantage of DB features as part of a middle-tier architecture. Middle tier people have become DB illiterate.

They wanted to know what I thought about this concept. Most of you can already probably guess what my response was I am sure :) I wrote back simply:

all of them, 100%. I am not being sarcastic, just agreeing 100% with what was said. Chapter 1 of my books start with:

Developing Successful Oracle Applications

I spend the bulk of my time working with Oracle database software and, more to the point, with people who use this software. Over the last 18 years, I’ve worked on many projects—successful ones as well as complete failures—and if I were to encapsulate my experiences into a few broad statements, they would be

  • An application built around the database—dependent on the database—will succeed or fail based on how it uses the database. Additionally, in my experience, all applications are built around databases. I cannot think of a single useful application that does not store data persistently somewhere.
  • Applications come, applications go. The data, however, lives forever. In the long term, the goal is not about building applications; it really is about using the data underneath these applications.
  • A development team needs at its heart a core of database-savvy developers who are responsible for ensuring the database logic is sound and the system is built to perform from day one. Tuning after the fact (tuning after deployment) typically means you did not give serious thought to these concerns during development.

To me, the ability to scale (perform, be reliable) starts with and many time ends with the database implementation and how the application interacts with the database.