E_DMA00D_TOO_MANY_LOG_LOCKS
Steve McElhinney
our batch work, however the batch work finishes successfully...
What is this 'error'?,
and what is this message actually telling me?
Env. is 1.2/01, on HPUX 10.01
>>>>> errlog.log
::[1395 , 409B92A0]: Tue Sep 14 21:45:59 1999
E_DMA00D_TOO_MANY_LOG_LOCKS This lock list cannot acquire any more
logical locks.
The lock list status is 00000000, and the lock request flags were
00000008. The lock list currently holds 1024 logical locks,
and the maximum number of locks allowed is 1024.
The configuration parameter controlling this resource is
ii.*.rcp.lock.per_tx_limit.
<<<<<
Thanks
Steve McElhinney.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Steve McDaniel
I would question whether the batch jobs are actually completing
successfully.
You will either need to increase the maxlocks or change your batch jobs to
commit more often....
Steve
Karl & Betty Schendel
>We are getting the following 'Too many Locks' message when we run
>our batch work, however the batch work finishes successfully...
>What is this 'error'?,
>and what is this message actually telling me?
>Env. is 1.2/01, on HPUX 10.01
>
> >>>>> errlog.log
>::[1395 , 409B92A0]: Tue Sep 14 21:45:59 1999
>E_DMA00D_TOO_MANY_LOG_LOCKS This lock list cannot acquire any more
>logical locks.
>The lock list status is 00000000, and the lock request flags were
>00000008. The lock list currently holds 1024 logical locks,
>and the maximum number of locks allowed is 1024.
>The configuration parameter controlling this resource is
>ii.*.rcp.lock.per_tx_limit.
It's telling you that the transaction acquired more locks than the
per-transaction limit. It will attempt to escalate some page locks to
table locks to deal with the problem. It's not a fatal error, but
lock escalation is a prime source of deadlock, which is why the warning is
(optionally) logged.
You can either a) do nothing, b) increase per_tx_limit in cbf (under the
Locking system parameters), c) decrease your maxlocks setting (assuming you've
increased it from the default setting, or d) look into how the transaction
works to see if a different algorithm or storage structure would be better.
a and b are probably the simplest; I don't recommend unless you have your
maxlocks setting way way up there; and you might want to check the tables
involved for excess overflow no matter what else you do.
Karl R. Schendel, Jr.
K/B Computer Associates sche...@kbcomputer.com
Ingres and Unix Expertise
Past President, North American Ingres Users Association
past_pr...@naiua.org
Richard Yates
Steve McElhinney <ste...@mail-express.com> wrote:
> We are getting the following 'Too many Locks' message when we run
> our batch work, however the batch work finishes successfully...
> What is this 'error'?,
> and what is this message actually telling me?
> Env. is 1.2/01, on HPUX 10.01
Hmm, look a little further down in the errlog - do you see an:
E_DM9041_LK_ESCALATE_TABLE
What what?
Richard.
--
Please e-mail copy r.j....@open.ac.uk when replying,
if you will be so kind.
Terrance Richard Boyes
> At 9:01 AM +0000 9/16/99, Steve McElhinney wrote:
>>We are getting the following 'Too many Locks' message when we run
>>our batch work, however the batch work finishes successfully...
>>What is this 'error'?,
>>and what is this message actually telling me?
[snip]
> It's telling you that the transaction acquired more locks than the
> per-transaction limit. It will attempt to escalate some page locks to
> table locks to deal with the problem. It's not a fatal error, but
> lock escalation is a prime source of deadlock, which is why the warning is
> (optionally) logged.
> You can either a) do nothing, b) increase per_tx_limit in cbf (under the
> Locking system parameters), c) decrease your maxlocks setting (assuming you've
> increased it from the default setting, or d) look into how the transaction
> works to see if a different algorithm or storage structure would be better.
> a and b are probably the simplest; I don't recommend unless you have your
I assume there was a c) missing here ?
> maxlocks setting way way up there; and you might want to check the tables
> involved for excess overflow no matter what else you do.
Except that if it's batch and there's only the one process running
it can make sense to go straight to table level locks for the
batch /only/.
--
<URL:http://www.pierrot.co.uk/> Team AMIGA
There are never any bugs you haven't found yet.
Rudy Hartanto
Try to maximise utilization of "optimizedb" (refer to your INGRES system
documentation) especially for "large" tables. Theoretically it could reduce
number of pages retrieved by DMF.
Another practical thing is re-check that QEP could utilize index table
you've declared (refer to INGRES system documentation about "set qep" to
trace how QEP execute your query). In some case you should re-organize your
index table to minimize number of pages retrieved by DMF.
Rudy Hartanto
-----------
Steve McElhinney wrote in message <7rqbl8$vdk$1...@nnrp1.deja.com>...
>We are getting the following 'Too many Locks' message when we run
>our batch work, however the batch work finishes successfully...
>What is this 'error'?,
>and what is this message actually telling me?
>Env. is 1.2/01, on HPUX 10.01
>
>>>>>> errlog.log
>::[1395 , 409B92A0]: Tue Sep 14 21:45:59 1999
>E_DMA00D_TOO_MANY_LOG_LOCKS This lock list cannot acquire any more
>logical locks.
>The lock list status is 00000000, and the lock request flags were
>00000008. The lock list currently holds 1024 logical locks,
>and the maximum number of locks allowed is 1024.
>The configuration parameter controlling this resource is
>ii.*.rcp.lock.per_tx_limit.
><<<<<
>Thanks
>Steve McElhinney.