Things you know
From a presentation I give about 'things you know'... I have this list
(you will have to read this list more than once to "get it", they are tongue twisters all, read them one word at a time deliberately, that helps me)
1) Things you know you know (you've used them, you've proven them)
2) Things you know that you don't know you know yet (you have the bits and pieces, just haven't put them all together)
3) Things you don't know that you know you don't know. (things you haven't used yet in real life)
4) Things you don't know that you don't know you don't know (follow on from #3, if you haven't used something, there is so much about it you don't even know you don't know yet)
5) Things you know that just ain't so
These are what I look for, categorize things into.
#2 is something I look for, like an unexplained phenomena in the database, just figured one out yesterday with read consistency and 10g. My scripts had all changed in their behavior between 9i and 10g -- the ones I've been using for a long time. I could not explain it. Yesterday, all of a sudden, in a flash of intuition, I could - and proved it (as in provided myself compelling evidence that what I thought was true was in fact the cause). It was dynamic sampling kicking in and changing the number of IO's a query would do... I had a script that in 9i and before would consistently show that after 10,000 updates of a row (followed by commit), a query opened before the updates would do 10,000 IO's to rollback the changes. In 10g, sometimes it was 3 IO's, sometimes 500, sometimes thousands - but never 10,000. Made me really nervous presenting - because I knew it would show something - but not sure what I would see. Now I know why (and I knew why, I just never put the pieces together) Dynamic sampling would query the table and sample the blocks - and do some of the rolling back I needed to have done and I would take advantage of it. Analyze the table up front and I'm back to 10,000 IO's every time. I didn't know I knew why, hadn't tied all of the bits and pieces together.
#3 is really easy. Those are the technologies I have on a list of "things to learn about". I really need to do a deep dive into ASM, but I need the project to drive it. I learn things like that by doing them for real a couple of times. Just playing with it in a lab doesn't always get me where I need to be. It might not be something I get to for a while, but it is on my list. But I do need a real project to work with it on. (streams is high on the list too but the same caveat applies, I'll need a project to learn it right).
#4 is one I don't have too much of a problem with. Anything I haven't actually used in real life. I tend not to talk about them too much. I don't know what I don't know about them so I avoid pretending I do. It is an extension of #3 in that unless and until you've used something a lot, there is a ton about it you don't even know you don't know yet. I try to learn about them as I go along, but try not to talk too much about it until I do.
#5, that is a recurring theme for me. Question Authority. Show me. Prove it (as in show me compelling evidence that you know what you say is true). Don't ask me to "trust you", because I don't trust me, why should I trust you. We are all full of #5, our backgrounds and experiences guarantee that. This paper I wrote is all about #5. We all know things that just ain't so.
Today for example, going through Expert One on One for the second edition. I am fairly impressed by what I did in 2000/2001 (although sometimes I also find myself saying "doh, did I really say THAT"). Not the book itself but rather the way the book speaks for itself. I had never written one before that but it is holding up rather well. When it is wrong about how something works in 9i/10g (because it was written for 8i and before), it tells me! It didn't know it would be wrong, but it tells me. How? The test cases. They all run, but some with different results. So the funny thing is I'm discovering new things about 10g that I didn't know before - and 10g is different in many ways from 9i I'm finding. And 9i from 8i. Just by replaying the book. Little things, big things. Little thing - test case on how triggers affect redo generation of inserts, updates, deletes. Ran it in 10g and said "wow, 8i did it differently". Ran it in 9i and said instead "wow 10g is unique". The rules changed. Many of them have. Silent array fetching in PLSQL, redo generation different, memory allocation - way way different. Big things -- even subtle differences in 10g over 9i - anyone notice that in 10g shared_pool_size the parameter equals the sum(bytes) from v$sgastat - that'll never happen in 9i and before. What does it mean to you? Well, that your shared pool is smaller than you think it is in 10g if you didn't increase the shared_pool_size when you upgraded. All of the little bits that added onto it in 9i and before, STEAL from it in 10g. For example, my shared_pool_size of 80m in 9i resulted in a 96m shared pool. In 10g, it would be rounded up to the granule size (probably 80 meg actually since that is divisible by 4, 8 and 16. Ok, so I cannot write "probably", it will be 80 meg on RHAS 3.0 32bit Oracle 10g) and would be 16 meg SMALLER than in 9i.
So, I don't really prioritize what I learn, they just keep sort of hitting me in the face from time to time. Slap slap, wake up, something new is here. And it is always nice to know. I just file it away for when I need it.