Hotsos is a blast. Easily the best technical Oracle conference. The speakers are terrific, the topics are cutting edge and the audience is experienced, intelligent and engaged.
I’ve been to quiet a few conferences by now, and one of the things I noticed is that the best learning is rarely as organized as “I’ll go to this presentation about triggers and I’ll learn important things about triggers”. This works too, but often you learn more from chance comments, side conversations, something a presenter says that causes you to think more deeply about some topics.
I’m documenting the best lessons I’ve learned, so you can learn too and so I won’t forget them.
From Toon Koppelaars’ presentation, “‘Triggers considered harmful’, considered harmful”, I learned to never use triggers. Toon’s intention was the show that while triggers can be sneaky, surprising and generally a dubious coding practice in most cases, they have a legitimate use in enforcing business rules. Some business rules that involve multiple rows in the same table (“Each department with a manager must also have a clerk” was Toon’s example) are very difficult to enforce otherwise. Toon’s showed how triggers can be used safely to enforce these business rules and other constraints. So why did I decide to never use triggers? Because Toon showed what has to be done in order to implement them correctly. It turns out to be a lot of work, quiet complicated and its very easy to get things wrong and create bugs that will be very challenging to track down later on. I’ll do my best to stay away from the entire mess.
Maria Cogan gave an amazing presentation about data warehouse best practices, and I learned quiet a few things. I learned what are partition-wise joins, why they are amazing and how to give Oracle a chance to use them.
I learned that using a graphical tool like SQL Monitor is nothing to be ashamed of. I discovered SQL Monitor few month back when the customer wanted periodic updates about progress of a long running rebuild and I wanted to sleep. A script that emails the nice HTML output of SQL Monitor to the customer every 30 minutes during the night solved the problem for both of us. From that point I used SQL Monitor regularly to follow up on progress of long running queries and to communicate progress and bottlenecks to different departments in customer organizations. However, I never told anyone about it. Because I thought that using graphical tools will make me look like a non-expert. All the cool kids are querying ASH tables and so on. But if an expert like Maria Cogan can use SQL Monitor in front of a large Hotsos audience, then there is no shame in using it too.
I learned that Resource Manager is worth another look. I tried using resource manager with 10.2, and it caused so many issues that I just couldn’t deploy it on production. I’ve heard from several presenters that resource manager got a whole lot better and that using it on a database where multiple users run parallel queries is a good way to achieve balanced resource allocation. I’ll definitely keep that in mind.
From Dr. Neil Gunther I’ve re-learned the importance of models. You need to know, before you start running tests and collecting data, what you would expect to see and why. This gives you a framework. This allows detecting when the data collection phase went all wrong and gave you something meaningless, and this gives you context to interpret meaningful surprises that your data may unravel.
From an interesting conversation with Christo, I learned an important lesson about problem solving. Sometimes the problem that the customer asks you to solve is not the actual problem they need to solve, sometimes when you are drowning in problems and issues it is worthwhile to take a deep look and check if there is a common cause that could be solved, a process that could be improved, work that can be eliminated. I also learned that just because a customer is paying you to solve the problem, doesn’t mean they’ll actually cooperate in solving it. Sometimes customers can become emotionally attached to their problems and changes are always scary.
Quiet a lot for just 3 days conference. Consider this a warm recommendation to attend the next Hotsos conference.