Subject | RE: [ib-support] Decodeing GDS Lock Print |
---|---|
Author | Griffin, Patrick J. |
Post date | 2000-12-18T16:52:11Z |
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:
parameter?) and probably expanding it would waste space without
adding information.
look like transaction end messages, particularly the first one.
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
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 isRight. The history tends to take a short view (is there a config
>flooded with activity from the users who weren't blocked. There were no
>records shown with that Lock Block number.
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
>0and
>
>[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
>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?"Unix
>
>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
>Group ID's. Additionally, all users are members of the PRODUCTION group,isc4.gdb.
>and it's membership in this group that grants them access to the local
>Production Database files. None of these users actually appear in
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