Re: Performance problem after merging db server

In article <6q4ft3$not$1@news02.btx.dtag.de>, Stephan Stresing <triple- p.sst@t-online.de> writes >Hi, >we have a heavy performance problem after 'merging' two db systems >to one. We did this because according to the Informix Performance guide >and the advices of Informix experts. >After merging we encountered a heavy performance hit on batch programs >as well as on dialogues. Now our client got additional 256 Meg of RAM >installed and it seemed that the got a little bit lighter, but it didn't >last for long. > Run your applications with SET EXPLAIN ON and make sure that they are not sequential scanning large tables or using the wrong indicies. >Addendum: onconfig >LOGFILES 6 # Number of logical log files >LOGSIZE 51200 # Logical log size (Kbytes)> 51Mb Logcial logs. ># Diagnostics > >MSGPATH /usr1/informix/papers.log # System message log file path >CONSOLE /dev/null # System console message path>ALARMPROGRAM /usr1/informix/log_full.sh # Alarm program path > ># System Archive Tape Device > >TAPEDEV /dev/rmt/0 # Tape device path >TAPEBLK 2048 # Tape block size (Kbytes) 2Mb block size here. >TAPESIZE 4096000 # Maximum amount of data to put on tape >(Kbytes)> ># Log Archive Tape Device > >LTAPEDEV /dev/null # Log tape device path >LTAPEBLK 16 # Log tape block size (Kbytes) Yet the logical log tape device is /dev/null?? >LTAPESIZE 10240 # Max amount of data to put on log tape >(Kbytes)> ># Optical > >STAGEBLOB ,1 # INFORMIX-OnLine/Optical staging area > > ># Parallel Database Queries (pdq) >MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority Set to 0 to disable PDQ. >DS_MAX_QUERIES # Maximum number of decision support>queries >DS_TOTAL_MEMORY # Decision support memory (Kbytes) >DS_MAX_SCANS 1048576 # Maximum number of decision support>scans >DATASKIP off # List of dbspaces to skip> ># OPTCOMPIND ># 0 => Nested loop joins will be preferred (where ># possible) over sortmerge joins and hash joins. ># 1 => If the transaction isolation mode is not ># "repeatable read", optimizer behaves as in (2) ># below. Otherwise it behaves as in (0) above. ># 2 => Use costs regardless of the transaction isolation ># mode. Nested loop joins are not necessarily ># preferred. Optimizer bases its decision purely ># on costs. >OPTCOMPIND 2 # To hint the optimizer> Set to 0 to enabel index usage...this si probably the problem. -- David Williams Maintainer of the Informix FAQ Primary site (Beta Version) http://www.smooth1.demon.co.uk Official site http://www.iiug.org/techinfo/faq/faq_top.html I see you standin', Standin' on your own, It's such a lonely place for you, For you to be If you need a shoulder, Or if you need a friend, I'll be here standing, Until the bitter end... So don't chastise me Or think I, I mean you harm... All I ever wanted Was for you To know that I care