In the previous post I talked about the order of predicate execution based on the predicate position and inline view.
As promised, in this post I’ll add statistics and see what happens.
When Oracle are adding a new feature to the database, they usually add a parameter to control it. Sometimes, after adding feature and the parameter, they realize that the parameter they chose for controlling the feature is not suitable. It might be confusing, or too general or something else. In these cases they change the parameter in the following version.
After talking a bit about the AWR report (if you haven’t read the previous posts, you can find part 1 here and part 2 here), I think one of the best ways to understand it is to talk about real examples. In this part I’ll give you a few examples and tips regarding the report.
Once in a while I get requests for some information about reading and analyzing an AWR report. I have been thinking for a long time about writing such a post, but always postponed it as it is a very tricky topic. The AWR (or statspack for that matter) report is huge and contains so much information that it’s easy to get lost. It also requires a lot of knowledge about the database and the different mechanisms so it’s very difficult to explain all of this in a blog post (or even a series of posts). In this post I’ll try to start from the beginning, explaining a little bit about the AWR report and the analysis process and we’ll see where it takes us.
The internet is full of information about indexes, and for a reason. Indexes in a database is probably the most important performance related topic. There are so many cases, properties, and different ways to use indexes that there is simply a lot to write about. In this post I’d like to talk about a specific use case that I’ve seen a few times, and is related to index scans and performance.