tuning
This is the first article in a series about performance of concurrent processing. We’ll take a closer look at the internals of concurrent managers, the settings that affect their performance and the ways of diagnosing performance and configuration issues. Today we’ll start with an overview of the internal workflow of a concurrent manager process. Enjoy the reading!
When reviewing the performance of some queries, it is sometimes useful to review the sessions statistics for each execution of the query. I had a situation that required to look at these stats so I could see why one query would run fast and sometimes much slower. I wrote a simple wrapper ksh shell script for the query. It saves the session statistics in a table before and after the execution of the query and then prints out the statistics in a pivot report. This turned out to be very handy to me and therefore I chose to share it with the world :)
Have you ever heard the one about throwing hardware at a software problem? I have this nifty RAC system that supports some very public and very mission-critical apps, and one day (it was Sunday night) it starts choking. We’re getting enqueues. Slowly they start climbing. Ten nodes came to a crashing halt. I have now seen a ten-node RAC cluster come to crashing halt and completely lock up. Why, you ask? A simple SQL statement: DELETE FROM a WHERE b=c AND d=e;.
Recent Comments