1. for the blocking session column,
I have a handy script to release the system to end user promptly. my copyright
your advice, please.

set pages 80 lines 125
rem v$lock.block = 1 — blocking
rem v$lock.request > 0 — blocked
prompt Where the blocking user’s Session:
select ‘alter system kill session ”’|| s1.sid ||’, ‘|| s1.serial# ||”’;’ “Kill Command”
, to_char(s1.logon_time, ‘ddMon hh24:mi’) ||’ ‘|| s1.username ||’ => ‘|| s1.osuser ||’ ‘||
regexp_substr(s1.machine, ‘\\\\.*’) ||’ ‘|| s1.program ||’ ‘|| s1.module ||’ ‘||
s1.action ||’ ‘|| s1.client_info ||’ ‘|| s1.status ||’ ‘|| s1.seconds_in_wait “blocking user”
, substr(sqlt1.sql_text, 1, 120) “blocking SQL”
, to_char(s2.logon_time, ‘ddMon hh24:mi’) ||’ ‘|| s2.username ||’ => ‘|| s2.osuser ||’ ‘||
regexp_substr(s2.machine, ‘\\\\.*’) ||’ ‘|| s2.program ||’ ‘|| s2.module ||’ ‘||
s2.action ||’ ‘|| s2.client_info ||’ ‘|| s2.status ||’ ‘|| s2.seconds_in_wait “blocked user”
, substr(sqlt2.sql_text, 1, 120) “blocked SQL”
from v$session s1, v$session s2, v$sql sqlt1, v$sql sqlt2
where s1.sid = s2.blocking_session
and sqlt1.sql_id = s1.prev_sql_id
and sqlt2.sql_id = s2.sql_id
/

2). for SQL text, for me, it is the first thing to look into it. as it is very common that server performance issue is caused by bad SQL application, such as not use index properly.

thank you.

about the script homes yes you are right again from your point of view but at least blocking column of v$session could be good on sw for versions over 10G

Thank you for your comment Tanel

I enjoyed delivering the seminar as well (and that’s again why I ran out of time in the end). If attendees are staying focused and “with me” I get additional energy out of it and try to give even more out on the topics people seem to be interested in the most.

Some context for any readers who haven’t seen mu work – you mentioned the spin_count autotuner. To avoid someone thinking that I spoke about it in a positive fashion, I mentioned it in a context that spin_count is usually misused & abused parameter. In 99.9% cases you don’t need to touch it, the root causes of your problems need to be fixed (like parsing,executing too often or too many logical IOs against same blocks due bad exec plan/physical design etc).

Regarding the 2 things you don’t agree with

1) The SQL text doesn’t need to be the FIRST thing to check in my approach. It’s all about narrowing down the things to look up the most efficient way. Running sw takes only a second or two and gives evidence about what the session is doing right now. Execution plan can give only remote clues at best about what’s the session doing/waiting on right now. But again, my approach comes from my experience – you use whatever order suits you best.

2) Regarding different versions of scripts to take advantage of new columns etc. First, if there’s a new column in a view in newer oracle version – it doesn’t automatically mean that this column is actually useful and should be displayed at all
It’s again about looking into minimum amount of RELEVANT data, not looking into all possible numbers you can see.
So, as my scripts are living ones, I frequently improve them, then in order to avoid the discrepancies between the same script in different directories I have single universal versions – which are dynamic based on the version you run on. For example both snapper and latchprofX scripts are dynamic, they show the columns/views which exist on 10g+ but the same scripts don’t show these columns in 9i. That way I can have a single script, avoid versioning problems/overhead and still have dynamic output where it matters.

Thanks once more for your feedback!