Comments on: Oracle Troubleshooting with Snapper – detecting who’s causing excessive redo generation

By: Tanel Poder

Tanel Poder — Sun, 11 Oct 2009 11:24:36 +0000

Well if you describe V$LOGMNR_CONTENTS you see there’s a session_id column in there, this gives you session info. And with something like ASH or manual v$session history you could see which dml statements these sessions did at the time. There is no direct way though to link redo generation to a SQL statement as Oracle doesn’t measure redo generation by SQL statement.

By: Dakshin

Dakshin — Sat, 10 Oct 2009 11:34:50 +0000

Thanks. But how do I know which sessions / SQLs were causing more redo? Is it that I go through the whole day’s transactions by txn id and try to gauge their impact ? (Mainly look at DML statements)

By: Tanel Poder

Tanel Poder — Fri, 09 Oct 2009 15:35:36 +0000

Yes, you need to access the old archivelogs from past with LogMiner. Read the documentation about DBMS_LOGMNR and V$LOGMNR_CONTENTS

By: Dakshin

Dakshin — Fri, 09 Oct 2009 09:48:24 +0000

Hi Tanel,

Is there a way to know why my DB was generating 3 times the ‘normal’ redo 3 days back? Want to diagnose so that I can prevent, if possible, such occurrences in the future. Thanks.

By: Oracle Session Snapper – real-time session-level performance stats for DBAs | Tanel Poder's blog: Core IT for Geeks and Pros

Tue, 11 Aug 2009 01:36:58 +0000

[...] http://blog.tanelpoder.com/2008/05/30/oracle-troubleshooting-with-snapper-detecting-whos-causing-exc... [...]

By: tanelp

tanelp — Mon, 07 Jul 2008 08:16:03 +0000

Snapper doesn’t have this functionality for two reasons:

1) i haven’t figured out an easy way to persist the snapshot information *without having to create any stored objects in db*

2) my Sesspack tool has this functionality and more..

By: CJ

CJ — Mon, 07 Jul 2008 08:08:13 +0000

Hi Tanel,

Probably my earlier post didn’t make sense. I will try to simplify the question I was asking:

Is it possible to use the snapper tool such that you generate a snapshot before starting the process, take another snapshot when the process ends and get the report on the changed stats?

By: CJ

CJ — Mon, 30 Jun 2008 17:49:54 +0000

Hi Tanel,

First of all, congrats and thanks for a brilliant weblog and website.

The snapper tool is quite good, but I am finding it a bit ‘different’. I am used to using runstats, so it might just be a case of getting familiarized.

I open 2 SQL windows. I take snap session A from session B, and the run the problematic piece of code in session A. Once the code finishes, I take another snap in session A and print the deltas. This is normally good enough for me, and only in rare cases would I require more frequent snaps.

Right I don’t think now you can get snapper to function in the above-mentioned way, but correct me if I am wrong.

By: Chen Shapira

Chen Shapira — Sun, 01 Jun 2008 04:52:40 +0000

The main design goal is the reason you are getting comments on the weekend :)

Since you don’t change anything, I feel reasonably comfortable running the new version on a production system on a weekend. I know that in worse case, I kill the session and everything is gone.

But it worked fine. Thanks again.

By: tanelp

tanelp — Sun, 01 Jun 2008 03:57:41 +0000

Yep, the main design goal of Snapper was that it should not require creating any database objects, or require any changes as matter of fact.

So, if I wanted to order in a single anonymous PL/SQL block (without having to create a TYPE object) then I’d need to do it manually with some procedural sort algorithm.

Initially it was in my TODO list but by now I’ve understood it’s not that much needed, as:

1) ordering v$sesstat stats doesnt make sense, as every statistic represents a completely different thing (you can’t compare redo size with parse count for example)

2) the number of different wait / time stats shown per session are is normally low enough for doing quick visual comparison

3) that’s why snapper has such fixed output format – that you could easily paste it to Excel for post processing and further analysis :)

But yeah – in snapper code I have implemented a manual nested loop join, with full table scans on both “tables”. So it’s not efficient at all but serves the purpose well and was simplest to implement!