Christian Antognini published a handy list of currently available levels.Comments Off | Filed in Oracle | Tags: debugging
If you are on 10g, or if on 11g but ACS (Adaptive Cursor Sharing) is not an option, then deleting column Histograms may be your best option to improve your plan stability. Like any other change, you rather test first on a non-production environment. Even in such test environment, you may want to restrict your test to only those tables accessed by your SQL. On 11g, DBMS_STATS.DELETE_COLUMN_STATS provides an option to delete just the Histograms while preserving all other column statistics. This is by using parameter COL_STAT_TYPE with value HISTOGRAM. If you want to do the same on 10g, you may want to use the SQLT HGRM module. In any case you can always restore column statistics using DBMS_STATS.RESTORE_TABLE_STATS.
Carlos gives us a tip on how to disable the use of Histograms with a hidden parameter:
If you are considering deleting Histograms to test the effect on an execution plan and the performance of your SQL, you may want to test first asking the CBO to simply ignore them. If patch for bug 9550277 has been applied in your system then you can command below.
ALTER SESSION SET “_FIX_CONTROL”=’9550277:1′;
Worth noting that Jonathan Lewis was very successful in tuning a customer’s query by simply deleting histograms:
The most critical piece of advice I had given them was to get rid of ALL the histograms they had on their system, and then watch very carefully for any signs that they might need to re-introduce a handful of histograms over the next few weeks. One of their critical queries completed in less that 2 seconds when histograms were removed, but took 33 seconds to complete when histograms were in place.Comments Off | Filed in Oracle | Tags: performance
SQL injection attacks are becoming significantly more popular amongst hackers, according to recent data. Between Q1 2012 and Q2 2012, there has been an estimated 69 percent increase of this attack type.
SQL injection can be easily avoided. How? Just use bind variables. Here is a quote from Tom Kyte:
If you use bind variables, you cannot be SQL Injected – this is true for PL/SQL, for Java, for any and all languages. If you use bind variables you cannot be SQL Injected – period. It is that simple, really and truly.
Tom also links to an excellent paper on this subject written by Bryn Llewellyn: How to write SQL injection proof PL/SQL [PDF].
It baffles me how such a simple and easy solution to such a big security problem is not implemented in the code base of all of these big companies that have recently been hacked.Comments Off | Filed in Oracle, Security | Tags: sql