Conference rocks::dec_edi

2990.0. "RDB-E-LOCK_CONFLICT" by EEMELI::PLAHTEENMAKI () Wed Jan 29 1997 13:19

Hi,


In a customers site DEC/EDI is producing the following errors:

%RDB-E-LOCK_CONFLICT, request failed due to locked resource
-RDMS-F-TIMEOUT, timeout on record 50:12:1
-SYSTEM-F-ABORT, abort
-DECEDI-I-INFO, Error from SQL when opening the UIALFLIST cursor in
MSL_RESET_TRANSMISSION.
-DECEDI-I-CONDLOGGED, condition logged by _RTA2: on node HEL13:: at
28-JAN-1997 15:31:39.59


%DECEDI-W-FAILDSWRITE, failed data server write Comms Audit
-RDB-E-LOCK_CONFLICT, request failed due to locked resource
-RDMS-F-TIMEOUT, timeout on record 51:6:1
-SYSTEM-F-ABORT, abort
-DECEDI-I-INFO, Error from SQL when updating CLF in GEN_UPDATE_CALF.
-DECEDI-I-CONDLOGGED, condition logged by DECEDI$TFS on node HEL13:: at
28-JAN-1997 17:05:53.93

A%DECEDI-W-FAILTRANSREC, failed translation file recovery
-DECEDI-W-FAILTRANSREC, failed translation file recovery
-DECEDI-E-ERROR, unsuccessful completion
-RDB-E-LOCK_CONFLICT, request failed due to locked resource
-RDMS-F-TIMEOUT, timeout on record 51:6:1
-SYSTEM-F-ABORT, abort
-DECEDI-I-INFO, Error from SQL when updating CLF in GEN_MOD_AND_UPD_CALF.
-DECEDI-I-CONDLOGGED, condition logged by DECEDI$TFB on node HEL13:: at
28-JAN-1997 15:20:51.17

%DECEDI-E-TRNERRUPDTLF, Error updating record in Translation Audit Log File
-DECEDI-E-ERROR, unsuccessful completion
-RDB-E-LOCK_CONFLICT, request failed due to locked resource
-RDMS-F-TIMEOUT, timeout on record 55:546:1
-SYSTEM-W-CANCEL, operation canceled
-DECEDI-I-INFO, Error from SQL when updating TLF in GEN_UPDATE_TALF.
-DECEDI-W-FAILDSWRITE, failed data server write Audit Log File
-DECEDI-I-APPINTQ, Application Interchange Qualifier is ''
-DECEDI-I-APPINTID, Application Interchange Id is ''
-DECEDI-I-PARINTQ, Partner Interchange Qualifier is ''
-DECEDI-I-PARINTID, Partner Interchange Id is ''
-DECEDI-I-INTCNTRL, Interchange Control Number is ''
-RDB-E-LOCK_CONFLICT, request failed due to locked resource
-RDMS-F-TIMEOUT, timeout on record 55:546:1
-SYSTEM-W-CANCEL, operation canceled


Here is quotas for decedi user account:


Maxjobs:         0  Fillm:      1000  Bytlm:       200000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:       300  JTquota:       4096
Prclm:          11  DIOlm:       300  WSdef:         2048
Prio:            4  ASTlm:      2000  WSquo:         4096
Queprio:         0  TQElm:      1000  WSextent:      8192
CPU:        (none)  Enqlm:     10000  Pgflquo:      60000

DEC/EDI version 2.1 and VAX/VMS 6.1

Vax is very slow.

Could someone help me to find out, what should be done here? 

Best regards,
Pertti

Pertti,

there's some pretty good information there. 

I would get a local RDB expert to look at the customer's system.
They are getting locking problems (obviously). 

These errors are returned to DEC/EDI by RDB and so there's not a whole
lot we can do.

M

There are some things you can check such as ..

1. rmu/show locks/mode=waiting

- this will show something as follows :-

Resource: remote monitor 1

          ProcessID Process Name        Lock ID   System ID Requested Granted  
          --------- ---------------     --------- --------- --------- -------
Blocker:  00017740  DECEDI$SCHEDULE     720014B3  00000000  PR        NL
Waiting:  0002BA36  DECEDI$FS_1....     2C0014AD  00000000  PR        NL
Waiting:  0001C0C9  DECEDI$CSFS_1..     01000311  00000000  PR        NL
Waiting:  00028DC7  DECEDI$RSFS_1..     03000642  00000000  PR        NL
Waiting:  000253CA  DECEDI$SAFS_1..     24000EF7  00000000  PR        NL
Waiting:  00018A39  DECEDI$AFS_1...     450013D7  00000000  PR        NL

from which you can determine (hopefully) which process is blocking
which other processes.


2. 
the 51:xx:yy is the address of the record where the lock is occuring:
51 is the stoarage area-id within the database
(A database is divided into areas (area) and logical areas (larea)).

$ rmu/analyze decedi$audit_db/areas/larea=51/out=areaa.tmp

will show you information about the logical area (51).

(or $ rmu/analyze decedi$audit_db/areas/area=51/out=larea.tmp ).

3.
Try dumping out the database header 
($rmu/dump/header decedi$audit_dbb/out=header.tmp);
then look in header.tmp to see if the storagre areas have often been extended.
If so, it may be an idea to export then reimport the database with larger
storage sizes sizes.

4. 
as a one-off guess, I suspect it is an i/o bottleneck.

try moving the database to another (faster) disk by exporting the database,
then importing the databsae (see the sql manual for export and import).

This will defragment the database and also give you the option of where
to physically place the storage areas.

regards,
Andrew