My name is Vasu Balla, and I’ve been with Pythian for about four months now. I have worked on Oracle E-Business Suite instances for over five years, and I’ve never had a moment where I felt bored. I am constantly challenged with new technologies and new issues, and my Pythian team’s clients continue to present interesting issues. Our team recently encountered an issue a client had had with Oracle Configurator for two years. They had followed up with Oracle Tech Support for over a year and had eventually learned just to live with the problem. When Pythian came in, we were shocked to learn the history of the problem. It turned out to be one of the most exciting problems we’ve resolved.
Welcome to the 89th edition of Log Buffer, the weekly review of database blogs.
I wrote this post because I feel there is a great need for it. The number of people struggling with unstable query plans due to bind peeking in Oracle 10G is enormous, to say the least. More than that, solutions like disabling bind variable peeking are driving us away from understanding the root cause of the problem and applying the right fix to it.
RDA 4.11 is out, with a couple of new features. “Oracle Database Diagnostics Collector” (ORADDC) is one of those. It allows you to easily activate all kinds of traces, dumps, or stack collections. This may become one of the most used RDA modules for Oracle Support Services and Oracle database administrators stuck in different situations. For now, let’s start with a more basic question: “How to leverage RDA in a RAC environment ?”
As of this month, Adam Machanic has been hired to lead Pythian’s global SQL Server practice and will be working out of our office in Central Square in Boston, Massachussets. Adam is in my opinion as close as it comes to a resource in the Microsoft SQL Server space that has the personality, track record and respect that Tom Kyte has in the Oracle space.
Welcome to the 88th edition of Log Buffer, the weekly review of database blogs.
No one has ever come out and formally asked me for a document that states “Best Practices to Scale Application X”. It is an unusual demand, since it’s something many of us at Pythian have implemented, but it’s been more of an ad hoc, iterative process — and rightly so, since architectures must be so organic, and so tailored to the application. What’s more, no one has ever brought us on board so early in the game that we have a hand in actually — gasp! — doing the design and data-model from the get-go. Woo hoo!
I’m amazed what people are able to do with Oracle technologies. One of the things I’ve liked the most is to spend some time (not enough!) with Kuassi Mensah. The guy is awesome! As a Product Manager at Oracle, he knows probably everything about JServer (the JVM in Oracle 11g), and he is one of the best guys on the subject of some of the key connection layer to access an Oracle database, including JDBC, OCI, and Web Services.
If you’re interested by any of those subjects, you should subscribe to his 360Â° blog and read his book.
I got to troubleshoot an amazing situation a few weeks ago. I think it is essentially inconceivable that allowing a single query to run on your system can flip another query’s plans and cause major performance issues (and in this case even downtime!). Sometimes it’s coincidence, sometimes it’s load, and sometimes it’s a single ad hoc query with a new predicate that starts the slowly-ticking time bomb. Here is how it happens and how to fix it.
Welcome the the 87th of Log Buffer, the weekly review of database blogs.