Locking mystery summary

Morning, Ok, some details. I now have tried all sorts of things to replicate this, including copying part the table and performing the update on variations. Here we go: IDS 7.31.UC4, AIX 4.3.3, table had : 432755 row(s) inserted. 29651 row(s) updated. Type Logging Index Lock mode Locks temp none none exclusive zip temp yes none exclusive zip temp yes yes exclusive zip normal none none exclusive zip normal yes none exclusive zip normal yes yes exclusive zip normal yes yes shared zip BUT! Set the lock mode on the table to row... normal table with index, no lock, poof, 60K locks gone bye bye. Set an exclusive lock on the table, few locks grabbed. normal yes yes shared poof, 60K normal yes yes exclusive zip normal yes none shared 30K or so So, there we have it, a new paper titled lock mode row considered harmfull when updating an indexed table, hahah. Though I remember seeing a paper about why throwing excessive amounts of memory at database cache is bad. mmmm the mysteries of computing at 9am... erk thanks for the input all, so it seems that the index and the lock mode on the table was the prob. Why I got 7k locks grabbed the other day while the table was locked no idea. brett -- ----------------------------------------------------------------- Brett's 13th law of UNIX administration... The 13th sucks, we'll skip this one ----------------------------------------------------------------- Brett Geer - UNIX Admin/Analyst/Programmer - Intratex Holdings. Tel. +27 31 717 4000 Direct. +27 31 717 4146 Fax. +27 31 717 4001 ----------------------------------------------------------------- The little voices are talking to me again, telling me of a long forgotten rhyme... the Rhyme of the Ancient Sysadmin # ps -ef | kill -9 `awk '/albatross/{print $2}'` -----------------------------------------------------------------