Today I want to share with you another interesting example of solving performance problem which happened in the database used for Business Intelligence purposes. Users were complaining that the performance in kind of staging database (STGDB) was much better than the production one (PRDDB), even though the dataset was exactly the same.
How often did you have the situation when performance problem disappeared just after refreshing object statistics? Of course it is nice to solve the problem quickly and simply, but is always better to understand what has exactly happened.
The last blog post of Jeff Smith (18.1 Features: SQL Injection Detection) about little, but nice feature of SQL Developer detecting if your PL/SQL code might be vulnerable for SQL Injection, reminded me about the presentation I’ve delivered during Oracle Tutorials at CERN in 2013.
If you have performance problems after migrating your BI databases from 188.8.131.52 to 184.108.40.206 or any other performance issue, you should not underestimate SQL Plan Notes, which can point you to the right direction or just let you understand what exactly is going on with your queries. Please check below how SQL Plan Notes helped me to investigate problem I recently encountered.
Having a need to run the same set of commands on many machines is a very common task for IT engineers of all kind. If you want to do it efficiently and in a smart way (e.g. to run it only on machines with specific set of conditions), I have an example, that could be added to your toolbox.
Proper monitoring of backup jobs is one of the crucial elements in ensuring that your databases are well-enough protected against data loss. You can for example grep your backup logs, put some kind of alerting inside your backup scripts, but the most obvious method is just to use Oracle dictionary views.
Dealing with query performance degradation coming from suboptimal execution plans is a task every DBA knows. Thanks to very good Oracle instrumentation, we have several options to deal with the problem, both in terms of analysis, as well as introducing the correct solution. If you are able to get the proper plan for example from
DBA_HIST_SQL_PLAN or from different “versions” of the same database available in various types of environments (DEV, TEST, etc.), your life should be much easier.