Comments on: Executions in v$sql http://mrothouse.wordpress.com/2007/06/04/executions-in-vsql/ Thoughts and notes about my IT and DBMS profession Fri, 06 Nov 2009 23:59:09 +0000 http://wordpress.com/ hourly 1 By: Ewan http://mrothouse.wordpress.com/2007/06/04/executions-in-vsql/#comment-4089 Ewan Tue, 05 Jun 2007 06:54:26 +0000 http://mrothouse.wordpress.com/2007/06/04/executions-in-vsql/#comment-4089 The best way to get historical data in Oracle 9i is using statspack, which can be run on a scheduled basis then you build reports on the snaps later. You can look at existing snaps by running the following command in sqlplus, it should list every existing statspack snap and let you choose to build a report between 2 times. @?/rdbms/admin/spreport.sql Otherwise, you can run this command in sqlplus to run a snap on demand, so you can run it, leave it 10 minutes, then run the same command again. exec statspack.snap(); Afterwards, you can run the spreport.sql and it will output a spool file full of details like memory usage, disk i/o usage, and includes the top SQL by executions, buffer get, and disk i/o between the times of the 2 snaps requested. The best way to get historical data in Oracle 9i is using statspack, which can be run on a scheduled basis then you build reports on the snaps later.

You can look at existing snaps by running the following command in sqlplus, it should list every existing statspack snap and let you choose to build a report between 2 times.

@?/rdbms/admin/spreport.sql

Otherwise, you can run this command in sqlplus to run a snap on demand, so you can run it, leave it 10 minutes, then run the same command again.

exec statspack.snap();

Afterwards, you can run the spreport.sql and it will output a spool file full of details like memory usage, disk i/o usage, and includes the top SQL by executions, buffer get, and disk i/o between the times of the 2 snaps requested.

]]> By: Gary http://mrothouse.wordpress.com/2007/06/04/executions-in-vsql/#comment-4065 Gary Tue, 05 Jun 2007 00:51:16 +0000 http://mrothouse.wordpress.com/2007/06/04/executions-in-vsql/#comment-4065 Well for a start, I'd be looking at ROWS_PROCESSED not executions as it is possible that you have a single update/insert/update/merge statement execution covering a lot of rows (and generating lots of redo). You could also ignore SELECT statements. Also, if you can catch it while it is happening, you can use session statistics to identify the database session generating the most redo SELECT sid,name,value FROM V$SESSTAT s, v$statname n WHERE n.statistic# = s.statistic# AND value > 1000 AND name like '%redo size%' ORDER BY sid,LOWER(name); Well for a start, I’d be looking at ROWS_PROCESSED not executions as it is possible that you have a single update/insert/update/merge statement execution covering a lot of rows (and generating lots of redo). You could also ignore SELECT statements.
Also, if you can catch it while it is happening, you can use session statistics to identify the database session generating the most redo
SELECT sid,name,value
FROM V$SESSTAT s, v$statname n
WHERE n.statistic# = s.statistic#
AND value > 1000
AND name like ‘%redo size%’
ORDER BY sid,LOWER(name);

]]>