Subject RE: [ib-support] Decodeing GDS Lock Print
Author Griffin, Patrick J.
Ann,

While passing lightly over the question of cause & effect, I discovered this
weekend that gfix -validate showed an index problem on that database.

Gfix output:
Summary of validation errors

Number of index page errors : 2

...pat
p.s. As a precaution I did a gbak backup and restore on all the databases
and rebooted the server.


-----Original Message-----
From: Ann W. Harrison [mailto:harrison@...]
Sent: Monday, December 18, 2000 11:38 AM
To: ib-support@egroups.com
Subject: RE: [ib-support] Decodeing GDS Lock Print


At 01:43 PM 12/15/2000 -0500, Griffin, Patrick J. wrote:

>I hadn't thought of looking there, but checking it now I see that it is
>flooded with activity from the users who weren't blocked. There were no
>records shown with that Lock Block number.

Right. The history tends to take a short view (is there a config
parameter?) and probably expanding it would waste space without
adding information.

>I took a look in the Event Log portion and saw entries like:
>
>(Occurred 5 times) DEL_OWNER: owner = 901460, lock = 901460, request
=
>0
>
>(Occurred once) DEL_OWNER: owner = 901460, lock = 1587712, request
>= 0
>(Occurred once) DEL_OWNER: owner = 901460, lock = 939412, request
=
>0
>
>[owner 901460 pointed to the task I killed to free up the system, but I
>assume these entries may represent tasks that occupied that slot earlier
and
>are not related to this challenge.]

That's likely as the various block types are kept around and reused. Those
look like transaction end messages, particularly the first one.


>You also asked "Are your various owners in different groups?"
>
>All of our users have been grouped by department, so there would be
>many users trying to read this table and all of them may have different
Unix
>Group ID's. Additionally, all users are members of the PRODUCTION group,
>and it's membership in this group that grants them access to the local
>Production Database files. None of these users actually appear in
isc4.gdb.

The normal mode of lock table failure is a signal that can't be
delivered. The symptoms are not what you are seeing (one request
will have the lock - in your printout, no one does) but I can't
resist trying to make a known solution fit an unknown problem.
The other argument against this hypothesis is that the system
generally runs.

There was a problem last year with a database on solaris that kept
hanging up - turned out to be a known bug in solaris signal handling.


Regards,

Ann
www.ibphoenix.com
We have answers.



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com