Are Deadlocks function of extents number ?

Hi, I have just a little question : I am wondering if the Deadlocks is linked to the number of extents ? I am asking this question because some developers of a third application told me that the deadlock we have on the database and some slowness problems were due to our number of extent on some specific tables. Tables that they had designed. Btw, we have a 7.31.FC6 on Hp-ux11. So, could you help me to know if it is effectivly correct. Thanks in advance. Best Regards Fred

On 6 Jun 2004 23:51:54 -0700, oxow@yahoo.com (Oxow) wrote: Number of extents can decrease performance in accessing data. It can produce problems with dead locks because system is work very slow. If your rebuild tables with good extent size you could resolve this problem >Hi, > >I have just a little question : > >I am wondering if the Deadlocks is linked to the number of extents ? > >I am asking this question because some developers of a third >application told me that the deadlock we have on the database and some >slowness problems were due to our number of extent on some specific >tables. Tables that they had designed. > >Btw, we have a 7.31.FC6 on Hp-ux11. > >So, could you help me to know if it is effectivly correct. >Thanks in advance. > >Best Regards >Fred

"Oxow" <oxow@yahoo.com> wrote in message news:d169ee4.0406062251.538542d3@posting.google.com... > Hi, > > I have just a little question : > > I am wondering if the Deadlocks is linked to the number of extents ? > > I am asking this question because some developers of a third > application told me that the deadlock we have on the database and some > slowness problems were due to our number of extent on some specific > tables. Tables that they had designed. > > Btw, we have a 7.31.FC6 on Hp-ux11. > > So, could you help me to know if it is effectivly correct. > Thanks in advance. I would say that it is almost certainly incorrect, and sounds like a classic from "The Developer's Book of Excuses" to deflect the blame away from where it truly lies. In OnLine v5 an extra i/o was required to access every table with more than 8 extents, but the problems are less acute in v7 onwards. Indexes in particular can become very skewed and end up with pages on avaerage half, or less full, which may be somewhat inefficient. I doubt that this would be enough to account for deadlock issues, and I have not heard that actually exceeding the maximum number of extents, which should produce a straightforward error, is ever masked by other symptoms. The main way in which a DBA can compromise an application's transaction logic is through inappropriate setting of the lock mode for a table or tables - usually by mistakenly setting Lock Mode Parge rather than Row. Otherwise such problems are squarely the responsibility of the database and application designers. For confirmation, perhaps you could send an onstat -d, and the output from something like Lester Knutsen's extents.sql sql (available from the IIUG website) to show the number of extents in each table?

Deadlocks are a result of accessing data from opposite directions. If the application accesses table-1 and then table-2 in one spot and then in another spot is accessing table-2 prior to table-1, you will get a deadlock. This can be aggravated by retaining locks longer than necessary - as in the case where repeatable reads are used. But the fundamental cause of the deadlock is accessing two data objects in opposite order. Another thing that can aggravate the probability of a deadlock is when different queries access the same data in opposite directions. For instance if scans are being mixed with index accesses. "Oxow" <oxow@yahoo.com> wrote in message news:d169ee4.0406062251.538542d3@posting.google.com... > Hi, > > I have just a little question : > > I am wondering if the Deadlocks is linked to the number of extents ? > > I am asking this question because some developers of a third > application told me that the deadlock we have on the database and some > slowness problems were due to our number of extent on some specific > tables. Tables that they had designed. > > Btw, we have a 7.31.FC6 on Hp-ux11. > > So, could you help me to know if it is effectivly correct. > Thanks in advance. > > Best Regards > Fred

Dear Neil, > For confirmation, perhaps you could send an onstat -d, and the output from > something like Lester Knutsen's extents.sql sql (available from the IIUG > website) to show the number of extents in each table? This is the output of the onstat -d nonetheless I do not understand what you will find out in this one. Informix Dynamic Server Version 7.31.FC6 -- On-Line -- Up 1 days 09:54:06 --s Dbspaces address number flags fchunk nchunks flags owner name c0000000123a51c8 1 1 1 1 N informix rootdbs c0000000123a6cb0 2 1 2 1 N informix physlog c0000000123a6d98 3 1 3 3 N informix logfiles c0000000123a6e80 4 2001 6 1 N T informix tempdb1 c0000000123dd450 5 2001 7 1 N T informix tempdb2 c0000000123dd538 6 2001 8 1 N T informix tempdb3 c0000000123dd620 7 2001 9 1 N T informix tempdb4 c0000000123dd708 8 1 10 3 N informix db0 c0000000123dd7f0 9 1 11 2 N informix db1 c0000000123dd8d8 10 1 12 1 N informix db2 c0000000123dd9c0 11 1 13 1 N informix db3 c0000000123ddaa8 12 1 14 1 N informix db4 c0000000123ddb90 13 1 15 2 N informix db5 c0000000123ddc78 14 1 16 2 N informix gbspec c0000000123ddd60 15 1 17 1 N informix db6 15 active, 2047 maximum Chunks address chk/dbs offset size free bpages flags pathname c0000000123a52b0 1 1 0 66000 49659 PO- /informix/liS c0000000123a5858 2 2 0 100000 447 PO- /informix/liG c0000000123a5950 3 3 0 160000 4947 PO- /informix/li0 c0000000123a5a48 4 3 0 200000 4997 PO- /informix/li1 c0000000123a5b40 5 3 0 650000 4997 PO- /informix/li2 c0000000123a5c38 6 4 0 100000 99461 PO- /informix/li1 c0000000123a5d30 7 5 0 100000 99513 PO- /informix/li2 c0000000123a5e28 8 6 0 100000 99624 PO- /informix/li3 c0000000123a5f20 9 7 0 100000 99393 PO- /informix/li4 c0000000123a6018 10 8 0 400000 130996 PO- /informix/li0 c0000000123a6110 11 9 0 200000 63 PO- /informix/li1 c0000000123a6208 12 10 0 200000 34626 PO- /informix/li2 c0000000123a6300 13 11 0 200000 155598 PO- /informix/li3 c0000000123a63f8 14 12 0 200000 49807 PO- /informix/li4 c0000000123a64f0 15 13 0 200000 13282 PO- /informix/li5 c0000000123a65e8 16 14 0 250000 499 PO- /informix/li0 c0000000123a66e0 17 15 0 256000 117286 PO- /informix/li1 c0000000123a67d8 18 14 0 256000 141181 PO- /informix/li2 c0000000123a68d0 19 9 0 1024000 920684 PO- /informix/lia c0000000123a69c8 20 8 0 100000 98931 PO- /informix/lib c0000000123a6ac0 21 8 0 400000 399997 PO- /informix/lia c0000000123a6bb8 22 13 0 200000 199997 PO- /informix/lia 22 active, 2047 maximum In addition, all the table do not have more than 10 extents. Tell me what is your opinion ? Thanks anyway for your help. Best Regards Fred