• September 30, 2014

Urban "Best Practice" Myths....

Guest Author

I had a situation today where someone was insisting that "x" was a "best practice". I asked them to show me where Oracle had defined "x" to be a best practice, and after some searching there was no best practice "x" defined by Oracle. It really interesting how we have actual best practices and what I call cultural best practices and then there are the Urban best practices.

In every case, the only true best practice is one that is defined by Oracle as a best practice. OFA is a best practice. MAA is a collection of best practices.

Cultural best practices are those that get their start in our culture. These cultural best practices tend to grow, because they offer a solution to problems we think we are facing or, more often, that we might face in the future. The solutions sound reasonable. The problem is that the expected results of these cultural best practices often is never really validated. For example, rebuilding indexes on a regular basis is, in my mind, a cultural best practice. It is NOT a best practice in reality. While using the best practice might demonstrate some positive results, as time goes on the same problem that caused the index to have performance and growth issues comes back. So, this is a best practice that really isn't one because it does not really solve the problem. It does not address the root cause of the problem which is probably something like sparse deletion on indexes that use some kind of surrogate key... The real best practice for this problem lies in the domain of data modeling. Because some people can't data model even the simplest things, then they have to rely on this problem inherent in B*Tree indexes.

Then there are the  Urban Myth best practices. This is one I caught today. The DBA said "I was told that X is a best practice!". This database is weeks away from going to production. Implementing this X best practice would involve a lot of risk, and the customer is in a panic because he thinks he "had" to implement this best practice.

That the DBA simply didn't understand two very important things about best practices. First of all, just because someone else said it does not make it so. There are many urban myths in the DBA world designed to save your database. People will tell you this, suggest that and insist that xy and z are best practices - because it's what they do every day. This is simply a best practice myth - and so often when I dive into these urban best practices, they have unintended consequences that the DBA never considered. So, in the end, the lack of understanding that cause the problem that the DBA had and that they developed their "best practice" with the same lack of education - not understanding their folly. Then, thinking they have done something amazing, they spread their newly found best practice, finding an audience.

The other best practice myth, and perhaps the biggest one, is if you see it on the internet it must be true. How many times have you copy and pasted some long bit of SQL or PL/SQL code from a web page because the resulting output sounds very helpful. Then, the web page tries to guide you to interpreting the output. So often, I've seen these pages analyzing data completely wrong, and thus leading to totally incorrect solutions.

Another like situation is when someone posts a problem in user groups. All of a sudden, there is this rush to provide answers - change this, alter that, and configure this all rush out from the internet from well meaning (usually) people who want to help you solve your problem.

The problem here is that usually the problem statement is woefully lacking needed detail. People tend to fill in the blanks in one way or another and spit out solutions ... sometimes the solutions are bad, sometimes really bad and sometimes downright dangerous. Running around changing 13 things that 13 different people tell you to do is not proper problem diagnosis and resolution. 

The bottom line is that there is a lot of misinformation out there. Make sure, before you change anything on your database - understand the implications of that change. For example, when adding an index remember that index might be used by the query you are now tuning - but it's presence might well change other execution plans - for the better in some cases and for the worse in others.

If you want to apply best practices, look to Oracle as the source for those best practices if your own experience does not provide that source of information. If you wonder how to approach a problem, and what the best practice is to deal with that problem, shoot support a SR and ask them if Oracle has any guidance. Also, look to experienced Oracle sources for the information you need - the likes of Tom Kyte - you can also ask your sales rep and he or she might well be able to find you someone inside of Oracle that can answer your questions.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.