If you are familiar with Oracle optimizer hints, you have heard that they can be a way to force immediate performance improvement, but are not meant to be a long-term solution. The reason that they are not a long-term solution, in my opinion, is that a database is a constantly changing entity. These changes include data density (amount), data skew (from inserts, updates, and deletes), and the addition or subtraction of objects (tables, views, packages, and procedures). This is the same reason that performance tuning is not a ‘once and done’ process.
I recently had the opportunity to experience the use of optimizer hints as a (supposed) silver bullet and as a performance detriment months later. I was tuning a query in third-party supplied code and found through the explain plan that it was selecting vastly more records than originally thought. It was actually using index range scans to return 38 million records. This amount of data is best obtained through the multi-block access of a full table scan then a sequential index scan. The system did not have the tuning and diagnostics pack feature licensed, so SQL profiles and baselines were not an option. The vendor changing the code was also not an option. I finally used several full table scan hints in one of the sub-queries that was performing poorly. The result was improved execution time of the process. While thanks were going around, I cautioned that the use of these hints was not a long-term solution and that a code rewrite was likely the best solution overall. I had the feeling that my caution fell on deaf ears. This was confirmed when over the next couple of months, I was asked to apply the ‘fix’ to other environments where the performance problem appeared.
Last week, I was asked to review one of the environments where performance was poor, but the ‘fix’ was already present. How could this be? Wasn’t the ‘fix’ the silver bullet for this problem? I resisted the the urge to say ‘I told you so’ and started my tuning exercise. As a side note, when approaching poorly-performing code with embedded optimizer hints, you should always remove the hints to start your tuning from an unbiased perspective. After removing the ‘fix’, I asked the users to check the performance. Guess what? Performance returned to an acceptable level.
So, in the course of a couple of months, I had seen that the optimizer hints were actually a band-aid to be used to temporarily remedy a performance problem until a long-term solution can be found and not a silver bullet. Another piece of advice I might offer is that if you do indeed end up using optimizer hints, keep track of where you place them as you may need to go back again and remove them. Happy tuning.