First Major Hurdle for Volume I
We have tech edited up through chapter 9 and I have chapters 10 and 11 in my inbox to do. A couple of chapters are “finished”, as in I’ve seen the pdf proofs of them and that will be what is put onto paper. The deadline for everything is August 11th, so we are in the home stretch now. I’d really like to have the book in the store for Oracle Open World in September and in order to do that – the 11th is sort of a drop dead date.
I’ve learned a couple of new things going through this rewrite process. It has been interesting. Lots of things “technically” changed from 8i to 9i and 10g. Things you might not notice until you go looking for them. But it just drives home that being able to test and measure things leads to better understanding. The tuning advice of 8i and even 9i is not as relevant in 10g and some of the setup “rules of thumb” have just been turned upside down. The experience of the past is useful, but unless you know how to see what is going on – it’ll just be magic.
One analogy. I was just looking through Effective Oracle by Design. I was writing about scalar subqueries. While doing that I noticed I wrote this extremely ‘useful’ comment:
But somehow, the second query is more efficient.
In hindsight, I’m sort of embarrassed by writing that. I didn’t know then what I know now – I know precisely why the scalar subqueries can be more efficient in that case (and now I even know how to make some of those queries even MORE efficient than they were in the book). A feature called scalar subquery caching is involved and I knew about it vaguely (well, I don’t know if it is called that, that is what I call it) When we figured it all out – with some help from Jonathan Lewis – new opportunities to use them opened up. So, why is is important that we actually understand what is going on (going beyond the incredibly useful statements like “try this, I did once and it was great, maybe it will be for you too”)? Because now that I understand exactly what is happening, I can use this feature even better. If I just observed “hey, sometimes this thing works good” and didn’t understand it, I wouldn’t know when to apply it – or how to best apply it.
So, in the rewrite, I’ve gotten clarity on some things I knew but didn’t know why (I can safely say, there are no comments like “but somehow” in this book!). I’ve gotten my thinking readjusted on things I thought I knew (eg: the shared_pool_size init.ora parameter is always smaller than the actual shared pool size – show SGA will always show a variable size much bigger than the shared_pool_size. NOT true anymore…).
All in all, I’m feeling fairly positive about the next release of the book – sometimes second editions are superficial updates, I didn’t want to do that and I can safely say I did not do that. There is a lot of new material in there.
Now, if I can just make it to August 11th :)
On a non-related note. Has anyone else ever had a bird take out their internet connection? I did this morning. It was going along great and then all of a sudden — nothing. Looked to the sky to see if a big storm was coming (that can take it out) but it was clear. So, I haul the ladder out to the field:
and noticed a bird had left a nice present on it (it was a bit dirtier before the photo). As I’m cleaning it off, I notice this label on the long bar — which I’m sort of holding onto for balance:
It says “This device emits radio frequency energy, Keep two feet (0.6 meters) away from this point, Before servicing or upgrading, unplug indoor power connection”. I should have read the documentation first I suppose. Now I know.