Then there was a presentation on what a presentation on what a ‘hobby DBA’ can use to trouble shoot a production application. For this Quest offers different tools too, for instance Spotlight on Oracle. What is mostly done is monitoring alarms, thresholds being exceeded, for instance high CPU usage or the amount of memory available is low. Not really testing your application, but responding to issues raised by the users, like ‘The application is slow’, or (worse) ‘The application doesn’t work’ (don’t be too specific, please…). This was mainly a presentation on Firefighting performance problems in production. Chances are this will come up with a better statement than the one you wrote.
This tool rewrites the SQL statement you provide it (more times than you could do yourself in the same time) and looks for the best execution plan (it doesn’t actually execute the statements). Another tool they promote is the SQL optimizer for Oracle. But you can of course also ask the database (inspect the SGA) or, if all else fails, ask your users or your DBA. You can use the code Xpert or the profiler (and their front-end to it). Quest has a couple of tools available that can help you with solving these issues. That makes up 90% of the performance issues. Another 30% can be found in the indexes used. 60% of the performance issues can be found in the SQL statements used. It is much cheaper (time and money wise) to tune your code early in the process than when it’s all on production and when there’s lots of lines of code to check. The main issue in this presentation was that you should care about performance as early as possible in your development. Last Wednesday Quest organized a seminar in Amsterdam on the performance of the Oracle database and the programs you write for it.
0 kommentar(er)
