Re: ITL deadlocks question

From: AMIT VERMA <verma.labs_at_gmail.com>
Date: Sat, 25 Jan 2014 01:57:47 +0530
Message-ID: <CAL622=BH4z4aG9gQp-MRt0TgfuKCRTvDO2oaGtdTdNXgkWMfBw_at_mail.gmail.com>

is it related with MUTEX or some other algorithm which works.

On Sat, Jan 25, 2014 at 1:30 AM, Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk
> wrote:

>
>
> No.
>
> Unless it's changed recently, a session will try each ITL slot in turn
> for a few seconds and then stop on one of them once it's gone through the
> entire list. If you're lucky the time it takes to cover the list means it
> will find a slot even if there were none when it started looking. You need
> to recreate the table with initrans set to at least 8 to be safe.
>
>
>
> Regards
> Jonathan Lewis
> http://jonathanlewis.wordpress.com
> _at_jloracle
> ------------------------------
> *From:* oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] on
> behalf of McPeak, Matt [vxsmimmcp_at_subaru.com]
> *Sent:* 24 January 2014 19:24
> *To:* Oracle Mailinglist
> *Subject:* ITL deadlocks question
>
> I have a situation where the users like to submit eight (8) copies of
> an I/O intensive job simultaneously – one job for each of our product lines.
>
>
>
> The job operates on tables that are not partitioned (or otherwise
> physically separated) by product line, so that one database block may
> contain rows for many different product lines.
>
>
>
> Occasionally, some of the processes are failing due to ITL deadlocks.
>
>
>
> My question is: suppose you have:
>
>
>
> Block 1 => ITL: txn A, txn B with txn C waiting.
>
> Block 2 => ITL: txn B, txn C with txn A waiting…
>
> Block 3 => ITL: txn C, txn **R** with txn B waiting…
>
>
>
> Is Oracle’s ITL deadlock detection smart enough to realize that, in block
> #1 for example, txn C is waiting for **either** txn A **or** txn B to
> end, but that it need not wait for both?
>
>
>
> In other words, is it smart enough to know that the situation above is *
> *not** a deadlock? (Because txn R can still end, then txn B, then both
> txn C and txn A can continue.)
>
>
>
> The two tables involved are each in their own single table hash cluster,
> if that matters.
>
>
>
> Thanks in advance for any help!
>
>
>
> Matt
>
>
>

-- 
Amit Verma
v.amit84_at_skype.com


"Winning takes talent but it takes character to keep winning"

--
http://www.freelists.org/webpage/oracle-l

Received on Fri Jan 24 2014 - 21:27:47 CET