In the previous part I explained the top part of the report. In this part I’ll continue with the actual information about database activity, what we are looking for and other important things we can find in 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.
As you know, Oracle Open World is over (for me at least), and one of the major topics there was Oracle 12cR2 (or 12.2). It looks like a really cool version, the downside is that is currently available on Oracle cloud only. We are all waiting for the on-premise release so we can install and play with it.
There are few ways to see the execution plan of a SQL statement. One of these ways is the autotrace option in sqlplus. It is a very easy-to-use feature and people use it quite often. But there is a risk here. The autotrace option doesn’t always show you the correct execution plan.
Lately I prepared a demo and had a simple case that showed the incorrect info from autotrace, so here it is.
My previous post that showed a real life troubleshooting was a hit. I guess people like to hear these kind of things, so I decided to write another post, this time a real life SQL tuning.