Locks - Significant Overhead?

Folks, OS:HPUX 11.0 ODS:7.30 FC7 Memory: Tons I'm of the opinion that increasing the locks to compensate for poor query/program design is not the best approach. Keep the value low and have the programs work within these constraints. However, I've been asked to determine the impact by increasing our current value of 400,000 to 1,000,000. The manual tells me 44 bytes per lock. Not a big deal in terms of memory. Other than an increased memory segment, what else should I be aware of. One program running for approximately 30 minutes utilizes 240,000 locks. This program may be executed by several people at one time. I have communicated that they should re-think there design, they are. However, they are in the 11th hour. Thanks in advance, Scott H.

Scott, With adequate memory, performance does not seem to be impacted at all (that's based on 'feel', - I didn't do specific tests aimed at estimating the impact). One of my clients (ha!) is currently running with 8m locks to support a badly written 3rd party process - it was far simpler than getting the dopes who wrote the process to redesign it. But, if you are going to actually test the impact, we'd love to hear the results. Rudy "Henderson, Scott" wrote: > Folks, > > OS:HPUX 11.0 > ODS:7.30 FC7 > Memory: Tons > > I'm of the opinion that increasing the locks to compensate for poor > query/program design is not the best approach. Keep the value low and have > the programs work within these constraints. However, I've been asked to > determine the impact by increasing our current value of 400,000 to > 1,000,000. The manual tells me 44 bytes per lock. Not a big deal in terms > of memory. Other than an increased memory segment, what else should I be > aware of. > One program running for approximately 30 minutes utilizes 240,000 locks. > This program may be executed by several people at one time. I have > communicated that they should re-think there design, they are. However, > they are in the 11th hour. > > Thanks in advance, > > Scott H.