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.
Originally posted on “Databases at CERN” blog
I’ve already mentioned on this blog very useful Consolidated Database Replay feature, for example while testing unified auditing performance impact (Unified auditing performance) or while investigating problems with hanging workload capture (Starting workload capture hangs – is it really problem with RAT?). But only recently I’ve found that along with this functionality, there was additional and again very handy capability introduced, allowing you to create a subset from already captured workload.