Re: To mess up with data dict or not

From: joel garry <joel-garry_at_home.com>
Date: Fri, 1 Oct 2010 09:51:44 -0700 (PDT)
Message-ID: <11824d6d-b062-4402-8b35-d284a7831130_at_q40g2000prg.googlegroups.com>

On Sep 30, 8:45 pm, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:

> So, the problematic sequence is SYS.DBMS_LOCK_ID. As it turns out, the
> sequence is created with the cache size of 20 numbers, which is woefully
> inadequate, having in mind the size of the task. What would be the
> downside of changing the cache to something decent, like 8192 numbers,
> besides losing support, of course?
>

I have no idea, but idly poking about the bug database brought up 8467336, which must get at least a nomination for an award for least descriptive visible bug ever.

Searching on SQ contention comes up with a few platform dependent RAC mutex type problems, I wonder if you are close to one of those - if so, might be interesting if you speed things up with a bigger cache. Or not. Try it and see.

I guess you have to make things fail to get an obscure misconfiguration fixed. Is changing the cache on a dictionary sequence really a support nullifier?

jg

--
_at_home.com is bogus.
Darn net neutrality. http://skunkpost.com/news.sp?newsId=3291

Received on Fri Oct 01 2010 - 11:51:44 CDT