Re: Performance. .oO(not AGAIN!)

Daniel Denes (dad@berlin.snafu.de) wrote: : Hi there, : here is another performace problem posting. I've read the FAQ but haven't : actually found something that fits. <snip> : EXECUTE IMMEDIATE SET LOCK MODE TO WAIT 10; : Did this cause the error or may there really by a deadlock? This probably was an attempt to **fix** the problem in the code. With more users you are probabably seeing serious contention problems. Some things to look for: What table's it locking on? Change that table to row-level locking. Look for tasks that get a lock and then do a lot of work during the duration of the lock. Look for things like system calls, stored procedures, and triggers that may be making system calls while inside a transaction. You want to minimize the time spent waiting. Try changing the lock mode to "wait 30" and see what happens. : And, more important: What can be done to improve performance? : I don't think there is much to do with the code, nor is it a problem of : UPDATE STATISTICS (I've tried that! only marginal improvement). If there was : some money to spend on Hardware, what would you suggest? Can Online stripe the : raw partition on several disks? (I've used glance, a performance monitor. It : shows CPU and disk as bottlenecks). Any ideas?? Look at your database layout. General rules to follow: Use as many disks as possible, Put logs and physical logs on different disks Put tables that are frequently accessed together or joined together on different spindles if the tables are big. 64 SQLTURBO's is a lot of back-ends. Look at your sar....are you swapping? Upgrading to 7.XX OnLine should help here. Look for zombie sqlturbos....you'll probably find quite a few. Good luck Joe -- --------------------------------------------------------------------------- Joe Lumbley(jlumbley@netcom.com) ---------------------------------------------------------------------------