Re: Index Organized table - hanging on selects
From: Robert Klemme <shortcutter_at_googlemail.com>
Date: Mon, 30 Apr 2012 22:22:54 +0200
Message-ID: <a08aldFfa6U1_at_mid.individual.net>
On 30.04.2012 19:51, Dan wrote:
> I might have misled everyone when I said "locking". The point is that
> there are no locks happening. If there were locks I could easily
> address them. The query just marches along at a very slow pace but
> nothing seems amiss while running. It seems like a lock but it
> clearly isn't - especially when this is a select query, not an update
> or insert.
Date: Mon, 30 Apr 2012 22:22:54 +0200
Message-ID: <a08aldFfa6U1_at_mid.individual.net>
On 30.04.2012 19:51, Dan wrote:
> I might have misled everyone when I said "locking". The point is that
> there are no locks happening. If there were locks I could easily
> address them. The query just marches along at a very slow pace but
> nothing seems amiss while running. It seems like a lock but it
> clearly isn't - especially when this is a select query, not an update
> or insert.
If there is a lot concurrent update activity on the table slow access to Undo might be an explanation.
> My main purpose was just to see if anyone else has had (or heard of)
> issues with IOT's in which the table occasionally performs very slowly
> on a select (I know writes/updates are slow). Another person in my
> company experienced the same problem several months ago in which a
> newly created IOT was completely inaccessible, it completely hanged on
> select (with no locks present). Very strange...
The first step would be to look at execution plans as has been suggested. What did that turn up?
Kind regards
robert
-- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/Received on Mon Apr 30 2012 - 15:22:54 CDT