Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Use gv$session to tell if a query is hanging

I have a query running in Oracle, which may or may not be hung. It's been running for ~10 hours now, but based on the amount of data I'm loading that may not be unreasonable.

I was looking at the session in gv$session and was wondering if there's a way to translate that information to see if there's actually any activity going on, or if the query is stuck waiting for a lock or otherwise hung.

I've already read the documentation for this view here. I'm mostly looking for tips from anyone whose had experience debugging these types of issues in Oracle.

Thanks!

like image 901
Paul Avatar asked Apr 27 '12 14:04

Paul


People also ask

How do you find long running queries?

You can view any SQL statement that executes for more than 6 absolute seconds (the "long running" threshold) using the v$session_longops view. where rownum <=1; This query for long running SQL is especially useful when operations contain long running loops such as shown in the example below.

How do I find the top 10 long running queries in Oracle?

How do I find the top 10 long running queries in Oracle? Answer: You can query the v$session_longops view to find long-running queries and you can query the AWR to find historical queries (if you have purchased the AWR packs).. The Oracle data dictionary contains a little-known view called the v$session_longops.

What is the difference between V session and GV session?

V$ views contain statistics for one instance, whereas GV$ views contain information from all the active instances. Each GV$ view contains an INST_ID column of type NUMBER, which can be used to identify the instance associated with the row data.

How do you check what session is doing in Oracle?

To view sessions: In SQL Developer, click Tools, then Monitor Sessions. A Sessions tab is displayed.


2 Answers

In gv$session, the event column tells you what wait event your session is currently waiting on. If your session is waiting on some sort of lock held by another session, the event will tell you that (for example, it will be "enq: TX - row lock contention" if you are enqueued waiting to lock a row held by another session) and blocking_instance and blocking_session will be populated with the instance and session ID of the holder of the lock. You can also look at seconds_in_wait (if wait_time=0) to determine how many seconds the session has spent in the current wait event. That should at least tell you whether your session is currently "stuck" but it doesn't tell you if your query is ever really going to finish-- if there is a bad plan, it's entirely possible that you've got "good" wait events like waits for disk I/O that indicate the session is doing something but that the query is never really going to finish.

like image 75
Justin Cave Avatar answered Sep 20 '22 19:09

Justin Cave


Based on some further research and Ollie's comment I came up with these queries that help debug the issue:

select s.sid, 
       s.username,
       s.machine,
       s.osuser, 
       cpu_time,
       (elapsed_time/1000000)/60 as minutes,
       sql_text
from gv$sqlarea a, gv$session s
where s.sql_id = a.sql_id
and s.machine like '####';


select lo.*, 
       a.sql_text
from gv$sqlarea a, gv$session_longops lo
where lo.sql_id = a.sql_id
and lo.sid = ####
order by lo.start_time;
like image 41
Paul Avatar answered Sep 20 '22 19:09

Paul