Analysis of activities during checkpoint.

Hi, Env : IBM Informix Dynamic Server Version 9.40.FC5XF SunOS DB10 5.9 Generic_118558-28 sun4u sparc SUNW,Sun-Fire I would like to know the activities being done by IDS when the engine is blocked for checkpoint. I know it is basically chunk writes but what else other than that? how can i diagnose the long checkpoints? btree cleaner/scanner setting is - BTSCANNER num=6,priority=high,threshold=600000,rangesize=500. In general my checkpoints range between 20-30 sec, but i am observing some high figures suddenly. There is no job in critical write section during chkpnt. Please help me understand. vartika.

Hi, for a start you may want to look at the output of "onstat -F". After that I think there are many other people that can give you more detailed advice ... :) Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Herbert Kircher Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 02.07.2008 10:01:46: > Hi, > > Env : > IBM Informix Dynamic Server Version 9.40.FC5XF > SunOS DB10 5.9 Generic_118558-28 sun4u sparc SUNW,Sun-Fire > > I would like to know the activities being done by IDS when the engine is > blocked for checkpoint. I know it is basically chunk writes but what else > other than that? how can i diagnose the long checkpoints? > > btree cleaner/scanner setting is - > BTSCANNER num=6,priority=high,threshold=600000,rangesize=500. > > In general my checkpoints range between 20-30 sec, but i am observing some > high figures suddenly. There is no job in critical write section during > chkpnt. > Please help me understand. > > vartika. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Hi, in general checkpoint times between 20-30 seconds are quite bad. Please post your onconfig + do you use KAIO ? + do you use raw devices ? For analysis of an activ checkpoint check two things: 1) onstat -R (or onstat -R |tail) several times Is the number of dirty pages going down all the time? If yes, the server needs that much time for writing the dirty pages to disk! If not, go to 2) 2) onstat -g ses 0 > <session_file> onstat -u | grep X You get all user threads/sessions in critical sections If you have threads/sessions with long critical sections look at the individual session in your <session_file> (session ID is column 3 of onstat -u|grep X ) Maybe you can see, what the session is doing ?! The most common cause for long checkpoints on our site are INSERT operations on tables with degenerated indexes. If you see INSERTs in critical sections during checkpoint look at the indexes of the table and reorganize them. Regards, Andreas Kutsche > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von > VARTIKA AGRAWAL > Gesendet: Mittwoch, 02. Juli 2008 10:02 > An: ids@iiug.org > Betreff: Analysis of activities during checkpoint. [12542] > > Hi, > > Env : > IBM Informix Dynamic Server Version 9.40.FC5XF > SunOS DB10 5.9 Generic_118558-28 sun4u sparc SUNW,Sun-Fire > > I would like to know the activities being done by IDS when the engine is > blocked for checkpoint. I know it is basically chunk writes but what else > other than that? how can i diagnose the long checkpoints? > > btree cleaner/scanner setting is - > BTSCANNER num=6,priority=high,threshold=600000,rangesize=500. > > In general my checkpoints range between 20-30 sec, but i am observing some > high figures suddenly. There is no job in critical write section during > chkpnt. > Please help me understand. > > vartika. > > > ************************************************************************** > ***** > Forum Note: Use "Reply" to post a response in the discussion forum.

Thank you andreas, Please have a look at the onconfig entries - ROOTNAME rootdbs # Root dbspace name ROOTPATH /informix/P10/sapdata/physdev1/data01 ROOTOFFSET 16 # Offset of root dbspace into device (Kbytes) ROOTSIZE 200000 # Size of root dbspace (Kbytes) MIRROR 1 # Mirroring flag (Yes = 1, No = 0) MIRRORPATH # Path for device containing mirrored root MIRROROFFSET 0 # Offset into mirrored device (Kbytes)PHYSDBS physdbs # Location (dbspace) of physical log PHYSFILE 800000 # Physical log file size (Kbytes) LOGFILES 600 # Number of logical log files 20/09/99 LOGSIZE 500 # initial (!) Logical log size (Kbytes)MSGPATH /informix/P10/online.db10.p10.log # System message log file path CONSOLE /informix/P10/console.db10.p10.log # System console message path ALARMPROGRAM /informix/P10/etc/infodb_check.sh # Alarm program path TAPEDEV /dev/rmt/dbbkp # Tape device path TAPEBLK 1024 # Tape block size (Kbytes) TAPESIZE 208666624 # Maximum amount of data to put on tape (Kbytes)LTAPEDEV /dev/rmt/logbkp # Log tape device path LTAPEBLK 256 # Log tape block size (Kbytes) LTAPESIZE 30000000 # Max amount of data to put on log tape (Kbytes)STAGEBLOB # INFORMIX-OnLine/Optical staging area SERVERNUM 0 # Unique id corresponding to a OnLine instance DBSERVERNAME db10p10tcp # Name of default database server DBSERVERALIASES db10p10shm # List of alternate dbservernames NETTYPE ipcshm,,, # Override sqlhosts nettype parameters NETTYPE tlitcp,2,190,CPU # Override sqlhosts nettype parameters DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. RESIDENT 0 # Forced residency flag (Yes = 1, No = 0) MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor NUMCPUVPS 39 # Number of User (cpu) vps SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to oneMUTEX_WAIT_LISTS 0 # If non-zero, force use of mutex wait lists NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 0 # Affinity number of processors LOCKS 8000000 # Maximum number of locks BUFFERS 1900000 # Maximum number of shared buffers NUMAIOVPS 2 # Number of IO vps PHYSBUFF 1024 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 625 # Maximum number of logical log files CLEANERS 125 # Number of buffer cleaner processes SHMBASE 0x10a000000 # Shared memory base address SHMVIRTSIZE 16777216 # initial virtual shared memory segment size SHMADD 500000 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 900 # Check point interval (in sec)[changed on 13-10-2002] LRUS 110 # Numbe2 of LRU queues LRU_MAX_DIRTY 2 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit LTXHWM 45 # Long transaction high water mark percentage LTXEHWM 70 # Long transaction high water mark (exclusive) TXTIMEOUT 0x12c # Transaction timeout (in sec) STACKSIZE 256 # Stack size (Kbytes) OFF_RECVRY_THREADS 10 # Default number of offline worker threads ON_RECVRY_THREADS 10 # Default number of online worker threads BAR_BSALIB_PATH /usr/lib/sparcv9/ibsad001.so BAR_ACT_LOG /tmp/bar_act.log BAR_MAX_BACKUP 0 BAR_RETRY 3 BAR_NB_XPORT_COUNT 50 BAR_XFER_BUF_SIZE 31 RA_PAGES 32 # Number of pages to attempt to read ahead RA_THRESHOLD 30 # Number of pages left before next groupDBSPACETEMP tmpdbs1,tmpdbs2,tmpdbs3 # Default temp dbspaces DUMPDIR /tmp # Preserve diagnostics in this directory DUMPSHMEM 0 # Dump a copy of shared memory DUMPGCORE 0 # Dump a core image using 'gcore' DUMPCORE 0 # Dump a core image (Warning:this aborts OnLine) DUMPCNT 1 # Number of shared memory or gcore dumps for FILLFACTOR 90 # Fill factor for building indexes USEOSTIME 0 # 0: use internal time(fast), 1: get time from OS(slow) MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority 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 OPTCOMPIND 2 # To hint the optimizer ONDBSPACEDOWN 1 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAITLBU_PRESERVE 1 # Preserve last log for log backup OPCACHEMAX 128 # Maximum optical cache size (Kbytes) HETERO_COMMIT 0 DD_HASHSIZE 613 # Length of DD Hash; 03-Nov-94 DD_HASHMAX 30 # Width of DD Hash; 03-Nov-94CDR_LOGBUFFERS 2048 # size of log reading buffer pool (Kbytes) CDR_EVALTHREADS 1,1 # evaluator threads (per-cpu-vp,additional) CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds) CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue SYSALARMPROGRAM /informix/P10/etc/evidence.sh # System Alarm program path TBLSPACE_STATS 1CDR_LOGDELTA 30 # % of log space allowed in queue memory CDR_NUMCONNECT 16 # Expected connections per server CDR_NIFRETRY 300 # Connection retry (seconds) CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0 none, 9 max)ISM_DATA_POOL ISMData # If the data pool name is changed, be sure to ISM_LOG_POOL ISMLogs OPT_GOAL -1 DIRECTIVES 1 RESTARTABLE_RESTORE off BTSCANNER num=6,priority=high,threshold=600000,rangesize=500 DYNAMIC_LOGS 2 CDR_SERIAL 0,0 # Serial Column Sequence CDR_DBSPACE # dbspace for syscdr database CDR_QHDR_DBSPACE # CDR queue dbspace (default same as catalog) CDR_QDATA_SBSPACE # List of CDR queue smart blob spaces CDR_MAX_DYNAMIC_LOGS 0 # Dynamic log addition disabled by default BAR_DEBUG_LOG /tmp/bar_dbug.log # ON-Bar Debug Log - not in /tmp please BAR_PROGRESS_FREQ 0 SBSPACENAME # Default smartblob space name - this is where blobs SYSSBSPACENAME # Default smartblob space for use by the Informix BLOCKTIMEOUT 3600 # Default timeout for system block ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or anything but 1) The no of dirty buffers in onstat -R keeps on changing ( going up and down without any specific pattern).We do not use KAIO. we do use raw devices for chunks. This time onstat -u | grep X gave one entry which was an INSERT operation. This query was inserting data into a table thru a view. The underlying table has got 8 index but the same job runs fine for most of the time. how can i find the state of an index ie degenerated or healthy. ?? pl. explain. regards, vartika.

Hello, you should change NUMAIOVPS 2 # Number of IO vpsto something like NUMAIOVPS 100 That should give you a performance boost - not only at checkpoint times. You can add AIO-VPs online with onmode -p +<number> aio You can watch IO processes with onstat -g iovIf io/wup is high (2 or higher) you should add even more AIO-VPs. If that doesn't reduce checkpoint times dramatically, you could try to lower LRU_MIN_DIRTY and LRU_MAX_DIRTY to smaller (fractional) values: LRU_MAX_DIRTY 1 (or 0.5) LRU_MIN_DIRTY 0.5 (or 0.3) For the INSERT operations: Monitor several checkpoints - do you see critical INSERTs on that table? If the Indices are detached (dbschema -ss -d <database> -t <table>) - check size of the index fragments with: oncheck -pt <database>:<table> If one/many indexes are larger than the table an index recreation could be worth the effort. If you habe attached indexes: oncheck -pt gives the usage of table pages (data, other) - if you don't have binary data in the table (text, raw fields), the other pages are index pages. If other is much higher than data, an index recreation .... Attention: The DROP of attached indexes can need a lot of time! Index creation should be done with PDQ_PRIORITY and PSORT_NPROCS set (for a quick start 50 , 8 ) - I'm not sure if MAX_PDQPRIORITY must be set to 100 , could be done with an onmode option. Regards, Andreas > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von > VARTIKA AGRAWAL > Gesendet: Mittwoch, 02. Juli 2008 13:23 > An: ids@iiug.org > Betreff: Re: AW: Analysis of activities during checkpoint. [12547] > > Thank you andreas, > > Please have a look at the onconfig entries - > ROOTNAME rootdbs # Root dbspace name > ROOTPATH /informix/P10/sapdata/physdev1/data01 > ROOTOFFSET 16 # Offset of root dbspace into device (Kbytes) > ROOTSIZE 200000 # Size of root dbspace (Kbytes) > MIRROR 1 # Mirroring flag (Yes = 1, No = 0) > MIRRORPATH # Path for device containing mirrored root > MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> PHYSDBS physdbs # Location (dbspace) of physical log > PHYSFILE 800000 # Physical log file size (Kbytes) > LOGFILES 600 # Number of logical log files 20/09/99 > LOGSIZE 500 # initial (!) Logical log size (Kbytes)> MSGPATH /informix/P10/online.db10.p10.log # System message log file path > CONSOLE /informix/P10/console.db10.p10.log # System console message path > ALARMPROGRAM /informix/P10/etc/infodb_check.sh # Alarm program path > TAPEDEV /dev/rmt/dbbkp # Tape device path > TAPEBLK 1024 # Tape block size (Kbytes) > TAPESIZE 208666624 # Maximum amount of data to put on tape (Kbytes)> LTAPEDEV /dev/rmt/logbkp # Log tape device path > LTAPEBLK 256 # Log tape block size (Kbytes) > LTAPESIZE 30000000 # Max amount of data to put on log tape (Kbytes)> STAGEBLOB # INFORMIX-OnLine/Optical staging area > SERVERNUM 0 # Unique id corresponding to a OnLine instance > DBSERVERNAME db10p10tcp # Name of default database server > DBSERVERALIASES db10p10shm # List of alternate dbservernames > NETTYPE ipcshm,,, # Override sqlhosts nettype parameters > NETTYPE tlitcp,2,190,CPU # Override sqlhosts nettype parameters > DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. > RESIDENT 0 # Forced residency flag (Yes = 1, No = 0) > MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor > NUMCPUVPS 39 # Number of User (cpu) vps > SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one> MUTEX_WAIT_LISTS 0 # If non-zero, force use of mutex wait lists > NOAGE 0 # Process aging > AFF_SPROC 0 # Affinity start processor > AFF_NPROCS 0 # Affinity number of processors > LOCKS 8000000 # Maximum number of locks > BUFFERS 1900000 # Maximum number of shared buffers > NUMAIOVPS 2 # Number of IO vps > PHYSBUFF 1024 # Physical log buffer size (Kbytes) > LOGBUFF 32 # Logical log buffer size (Kbytes)> LOGSMAX 625 # Maximum number of logical log files > CLEANERS 125 # Number of buffer cleaner processes > SHMBASE 0x10a000000 # Shared memory base address > SHMVIRTSIZE 16777216 # initial virtual shared memory segment size > SHMADD 500000 # Size of new shared memory segments (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited > CKPTINTVL 900 # Check point interval (in sec)[changed on 13-10-2002] > LRUS 110 # Numbe2 of LRU queues > LRU_MAX_DIRTY 2 # LRU percent dirty begin cleaning limit > LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit > LTXHWM 45 # Long transaction high water mark percentage > LTXEHWM 70 # Long transaction high water mark (exclusive) > TXTIMEOUT 0x12c # Transaction timeout (in sec) > STACKSIZE 256 # Stack size (Kbytes) > OFF_RECVRY_THREADS 10 # Default number of offline worker threads > ON_RECVRY_THREADS 10 # Default number of online worker threads > BAR_BSALIB_PATH /usr/lib/sparc

BTSCANNER does not affect checkpointing at all, it controls the performance of the Btree Scanner threads which run in the background almost constantly removing keys marked for deletion and compressing index nodes that have emptied to keep the indexes efficient. The ONCONFIG parameters that affect checkpoint duration are: CKPTINTVL - the time between the end of one checkpoint and the beginning of the next. PHYSFILE - the larger the physical log, the more data has to be cleared out at the end of the checkpoint. Also the physical log can be triggering your checkpoints if you have CKPTINTVL set too high and PHYSFILE too low. LRUS - more LRUs will flush more quickly during LRU flush time leaving less chance that there will be more dirty buffers than LRU_MIN_DIRTY at checkpoint time. LRU_MAX_DIRTY - the % of dirty buffers in an LRU queue that triggers an LRU write. LRU_MIN_DIRTY - the % of dirty buffers left in an LRU queue when an LRU write completes. NUMAIOVPS - if your chunks are COOKED files or devices then AIO VPS are used to flush dirty buffers to disk, both at LRU flush time and at chunk write time during a checkpoint. If you chunks are not all RAW devices, then you need the greater of the number of LRU queues or 1.5 times the number of COOKED chunks in order for dirty page flushing to be time efficient. If you are using a few large chunks instead of a larger number of smaller chunks, you will have only one flush thread per chunk running at checkpoint time. More chunks means more flush threads means less time to flush. Finally, how many disk spindles are involved with flushing your chunks? If it's all going to partitions on a single HUGE spindle or even several spindles attached to a single controller channel, then you may be hitting the IO limits of your subsystems. More spindles and/or more controller channels involved means lower flush times. Art On Wed, Jul 2, 2008 at 4:01 AM, VARTIKA AGRAWAL <vartika_agrawal@ril.com> wrote: > Hi, > > Env : > IBM Informix Dynamic Server Version 9.40.FC5XF > SunOS DB10 5.9 Generic_118558-28 sun4u sparc SUNW,Sun-Fire > > I would like to know the activities being done by IDS when the engine is > blocked for checkpoint. I know it is basically chunk writes but what else > other than that? how can i diagnose the long checkpoints? > > btree cleaner/scanner setting is - > BTSCANNER num=6,priority=high,threshold=600000,rangesize=500. > > In general my checkpoints range between 20-30 sec, but i am observing some > high figures suddenly. There is no job in critical write section during > chkpnt. > Please help me understand. > > vartika. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Art wrote: > BTSCANNER does not affect checkpointing at all, it controls the > performance > of the Btree Scanner threads which run in the background almost constantly > removing keys marked for deletion and compressing index nodes that have > emptied to keep the indexes efficient. BTSCANNER may influence checkpoints significantly. In IDS9.40xC5 or higher it happens that the btscanner cannot keep up with deletion and therefore causes sessions that remain in critical section for very long times (up to hours). May be it is a bug in 9.40. It happens when the btscanner works with leaf scans. You can change this in onconfig, e.g.: BTSCANNER num=2,priority=low,threshold=50000,rangesize=500 or with command online: onmode -C rangesize 500 onmode -C threshold 50000 onmode -C stop onmode -C stop onmode -C start onmode -C start In the case of the Informix Server here all problems with long checkpoints vanished after those measures. -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

In this version I would start analysis with setting up environment varibale TRACECKPT when starting IDS to identify what is taking so long... if dskflush() or wait4critex() the next steps depends on it...

please tell me more about setting up environment varibale TRACECKPT. Can it be enabled while engine is on-line? if not , what is the alternative ? I am not very confortable with writing scipts so if you have any ready ref, kindly let me share. thanks.

It is environment variable which has to enabled when IDS starts, unfortunately it is not dynamic... I see no other way how to get the information, in latest IDS versions, there is onstat -g ckp which shows the advanced checkpoint info... put to your environment file > TRACECKPT=1 or TRACEFUZZYCKPT=1 when implemented you can see in the online.log something like > 09:49:12 13472 buffers dirty 09:49:12 oldest lsn loguniq 8411, logpos 0x130e62cc 09:49:12 12735 dirty pages are to be flushed 09:49:14 dskflush() took 1 seconds 09:49:14 wait4critex() took 0 seconds 09:49:14 724 buffers dirty 09:49:14 oldest lsn loguniq 8411, logpos 0x130e62cc 09:49:14 safe_dskflush() took 0 seconds 09:49:14 Checkpoint Completed: duration was 1 seconds. 09:49:14 Checkpoint loguniq 8412, logpos 0x17ff018, timestamp: important are the functions dskflush & wait4critex...

From my understanding, enabling this env. variable is ok for debugging purpose only. It may have some significant overhead. As other said, 20-30 sec checkpoint is bad, I would explore as advised by Andra and other. --- On Thu, 3/7/08, JAN VIRT <j.virt@centrum.cz> wrote: From: JAN VIRT <j.virt@centrum.cz> Subject: Re: Analysis of activities during checkpoint. [12562] To: ids@iiug.org Received: Thursday, 3 July, 2008, 8:04 PM It is environment variable which has to enabled when IDS starts, unfortunately it is not dynamic... I see no other way how to get the information, in latest IDS versions, there is onstat -g ckp which shows the advanced checkpoint info... put to your environment file > TRACECKPT=1 or TRACEFUZZYCKPT=1 when implemented you can see in the online.log something like > 09:49:12 13472 buffers dirty 09:49:12 oldest lsn loguniq 8411, logpos 0x130e62cc 09:49:12 12735 dirty pages are to be flushed 09:49:14 dskflush() took 1 seconds 09:49:14 wait4critex() took 0 seconds 09:49:14 724 buffers dirty 09:49:14 oldest lsn loguniq 8411, logpos 0x130e62cc 09:49:14 safe_dskflush() took 0 seconds 09:49:14 Checkpoint Completed: duration was 1 seconds. 09:49:14 Checkpoint loguniq 8412, logpos 0x17ff018, timestamp: important are the functions dskflush & wait4critex... ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/mail

Hi Andreas, It seems that the INSERT operation is the reason for long chkpnt. But this is happening only for a particular category of location. It goes thru for all other loactions (withing fractions) and stuck up only for one. I simulated two diff jobs at the same time and one went thru but other one( the culprit loc) again took very long to finish. Both loc have got almost equal no count in the table. The under lying table is fragmented in 8 dbspaces using round-robin having 9 detached indices and 6 index are larger than the table fragment size. onstat -g iov always gives io/wup between 0.8 to 1.2. What may be going wrong and where ? Thanking you all. vartika.

Hi, I think that a recreation of the indices could solve the problem - if possible you should do that. Index drop/creation in IDS9 needs an exclusive lock of the table - therefore you need an application downtime (or at least some 'quiet' times). How big is your table (oncheck -pt <db>:<table>) ? For index creation you should set the environment variables PDQPRIORITY, PSORT_NPROCS and change the IDS parameters MAX_PDQPRIORITY , DS_TOTAL_MEMORY with onmode . You can have a look at SAP Note 85067 ! It would be a good idea to test index recreation on a test system to get some idea about runtimes required. The update statistics after the index recreation might take more time than the index creation itself. If you don't want (or can't) recreate the indices you might try to lower the threshold of the BTREESCANNER configuration (onmode -C) - perhaps your problematic indexes don't get cleaned. As I can see from your onconfig the database supports a SAP system - which table is affected and which type of SAP system do you run? Did you change the number of NUMAIOVPS ? Did that have an impact on performance? I would be interested in one sample output of onstat -g iov . Regards, Andreas Kutsche > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von > VARTIKA AGRAWAL > Gesendet: Freitag, 04. Juli 2008 08:37 > An: ids@iiug.org > Betreff: Re: AW: AW: Analysis of activities during chec.... [12577] > > Hi Andreas, > > It seems that the INSERT operation is the reason for long chkpnt. But this > is > happening only for a particular category of location. It goes thru for all > other loactions (withing fractions) and stuck up only for one. > > I simulated two diff jobs at the same time and one went thru but other > one( > the culprit loc) again took very long to finish. Both loc have got almost > equal no count in the table. > > The under lying table is fragmented in 8 dbspaces using round-robin having > 9 > detached indices and 6 index are larger than the table fragment size. > > onstat -g iov always gives io/wup between 0.8 to 1.2.> > What may be going wrong and where ? > > Thanking you all. > vartika. > > > ************************************************************************** > ***** > Forum Note: Use "Reply" to post a response in the discussion forum.

Hi Andreas, I am very comfortable with index creation and re-org and as you've suggested we always carry out this activity in a replica system but the main problem is down-time. It is very difficult to get. So far I have not changed the number of NUMAIOVPS ('coz response time is ok). I remember doing (adding more aio vp) it some time back but if we bounce the engine then does the onconfig value take effect? Here IDS is supporting a 46B sap system and the table is 'AUSP' and the view thru which the data is being inserted in 'AUSPC_V' and the tx is 'COR1'(Create Process Order) and I am getting this error(hang INSERTS) for a particular plant only. DB10:informix 7% onstat -g iov IBM Informix Dynamic Server Version 9.40.FC5XF -- On-Line -- Up 18 days 16:18:27 -- 22365184 Kbytes AIO I/O vps:class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors kio 0 s 238.7 2404808 2354239 50569 0 2589362 0.9 0 kio 1 i 254.4 2562937 2500563 62374 0 2408117 1.1 0 kio 2 i 496.3 4999949 4914595 85354 0 4089601 1.2 0 kio 3 s 439.2 4425182 4346452 78730 0 3666591 1.2 0 kio 4 i 477.3 4809050 4724907 84143 0 3962964 1.2 0 kio 5 i 435.2 4384475 4305841 78634 0 3652704 1.2 0 kio 6 i 482.2 4858517 4774440 84077 0 4041864 1.2 0 kio 7 s 462.8 4662417 4577347 85070 0 3878042 1.2 0 kio 8 i 477.1 4806317 4720109 86208 0 4005377 1.2 0 kio 9 s 467.5 4710228 4624100 86128 0 3925564 1.2 0 kio 10 i 495.7 4994114 4904213 89901 0 4144201 1.2 0 kio 11 i 465.4 4689265 4606013 83252 0 3941849 1.2 0 kio 12 i 490.5 4942005 4854413 87592 0 4145739 1.2 0 kio 13 i 476.3 4799193 4712997 86196 0 4019736 1.2 0 kio 14 i 492.9 4965623 4878046 87577 0 4176744 1.2 0 kio 15 s 455.3 4587474 4506650 80824 0 3873520 1.2 0 kio 16 i 487.9 4915399 4825349 90050 0 4130260 1.2 0 kio 17 s 465.6 4691319 4604464 86855 0 3964030 1.2 0 kio 18 i 478.0 4815681 4729854 85827 0 4067140 1.2 0 kio 19 i 487.2 4908883 4820755 88128 0 4131455 1.2 0 kio 20 i 512.3 5161707 5068993 92714 0 4350075 1.2 0 kio 21 i 477.1 4806284 4722302 83982 0 4087566 1.2 0 kio 22 i 475.8 4793793 4704636 89157 0 4118026 1.2 0 kio 23 i 510.3 5141346 5048785 92561 0 4342563 1.2 0 kio 24 i 517.3 5211428 5118536 92892 0 4404450 1.2 0 kio 25 i 479.3 4829143 4741694 87449 0 4135415 1.2 0 kio 26 i 522.1 5259664 5166589 93075 0 4464259 1.2 0 kio 27 i 472.7 4762246 4675624 86622 0 4058204 1.2 0 kio 28 i 493.8 4975240 4887793 87447 0 4231049 1.2 0 kio 29 i 540.7 5447501 5348881 98620 0 4663363 1.2 0 kio 30 i 519.7 5236453 5146948 89505 0 4477662 1.2 0 kio 31 s 470.1 4736726 4651697 85029 0 4083221 1.2 0 kio 32 i 486.8 4904118 4817193 86925 0 4248903 1.2 0 kio 33 i 494.6 4983023 4893916 89107 0 4265053 1.2 0 kio 34 i 521.9 5258301 5163651 94650 0 4475629 1.2 0 kio 35 i 526.2 5301896 5208327 93569 0 4541526 1.2 0 kio 36 i 496.1 4998220 4909563 88657 0 4257202 1.2 0 kio 37 i 489.4 4930951 4843299 87652 0 4257872 1.2 0 kio 38 i 514.6 5184693 5094258 90435 0 4448206 1.2 0 msc 0 i 0.1 1326 0 0 0 1323 1.0 0 aio 0 i 0.0 330 110 0 0 330 1.0 0 aio 1 i 0.0 0 0 0 0 0 0.0 0 pio 0 i 0.0 0 0 0 0 0 0.0 0 lio 0 i 0.0 0 0 0 0 0 0.0 0 Regards, Vartika Agrawal

Hi, you are using KAIO !!! You see the kio rows in the onstat -g iov output only when using KAIO. Therefore NUMAIOVPS = 2 is Okay (and you won't see any performance impacts when changing it). As I suggested you can try to lower the threshold value for the BTREESCANNERS - but it is not sure if it helps. AUSP looks like an ever changing table - I think you have to recreate the indexes to avoid the long checkpoints. We don't use table AUSP (only a few rows) - but if you want you can send me your dbschema -ss and oncheck -pt for your AUSP and I will compare it to some of our problem tables (BDCPS in SAP or some special tables in non-SAP applications). Regards, Andreas > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von > VARTIKA AGRAWAL > Gesendet: Freitag, 04. Juli 2008 11:56 > An: ids@iiug.org > Betreff: Re: AW: AW: AW: Analysis of activities during .... [12580] > > Hi Andreas, > > I am very comfortable with index creation and re-org and as you've > suggested > we always carry out this activity in a replica system but the main problem > is > down-time. It is very difficult to get. > > So far I have not changed the number of NUMAIOVPS ('coz response time is > ok). > I remember doing (adding more aio vp) it some time back but if we bounce > the > engine then does the onconfig value take effect? > > Here IDS is supporting a 46B sap system and the table is 'AUSP' and the > view > thru which the data is being inserted in 'AUSPC_V' and the tx is > 'COR1'(Create > Process Order) and I am getting this error(hang INSERTS) for a particular > plant only. > > DB10:informix 7% onstat -g iov > > IBM Informix Dynamic Server Version 9.40.FC5XF -- On-Line -- Up 18 days > 16:18:27 -- 22365184 Kbytes > > AIO I/O vps:> class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup errors > kio 0 s 238.7 2404808 2354239 50569 0 2589362 0.9 0 > kio 1 i 254.4 2562937 2500563 62374 0 2408117 1.1 0 > kio 2 i 496.3 4999949 4914595 85354 0 4089601 1.2 0 > kio 3 s 439.2 4425182 4346452 78730 0 3666591 1.2 0 > kio 4 i 477.3 4809050 4724907 84143 0 3962964 1.2 0 > kio 5 i 435.2 4384475 4305841 78634 0 3652704 1.2 0 > kio 6 i 482.2 4858517 4774440 84077 0 4041864 1.2 0 > kio 7 s 462.8 4662417 4577347 85070 0 3878042 1.2 0 > kio 8 i 477.1 4806317 4720109 86208 0 4005377 1.2 0 > kio 9 s 467.5 4710228 4624100 86128 0 3925564 1.2 0 > kio 10 i 495.7 4994114 4904213 89901 0 4144201 1.2 0 > kio 11 i 465.4 4689265 4606013 83252 0 3941849 1.2 0 > kio 12 i 490.5 4942005 4854413 87592 0 4145739 1.2 0 > kio 13 i 476.3 4799193 4712997 86196 0 4019736 1.2 0 > kio 14 i 492.9 4965623 4878046 87577 0 4176744 1.2 0 > kio 15 s 455.3 4587474 4506650 80824 0 3873520 1.2 0 > kio 16 i 487.9 4915399 4825349 90050 0 4130260 1.2 0 > kio 17 s 465.6 4691319 4604464 86855 0 3964030 1.2 0 > kio 18 i 478.0 4815681 4729854 85827 0 4067140 1.2 0 > kio 19 i 487.2 4908883 4820755 88128 0 4131455 1.2 0 > kio 20 i 512.3 5161707 5068993 92714 0 4350075 1.2 0 > kio 21 i 477.1 4806284 4722302 83982 0 4087566 1.2 0 > kio 22 i 475.8 4793793 4704636 89157 0 4118026 1.2 0 > kio 23 i 510.3 5141346 5048785 92561 0 4342563 1.2 0 > kio 24 i 517.3 5211428 5118536 92892 0 4404450 1.2 0 > kio 25 i 479.3 4829143 4741694 87449 0 4135415 1.2 0 > kio 26 i 522.1 5259664 5166589 93075 0 4464259 1.2 0 > kio 27 i 472.7 4762246 4675624 86622 0 4058204 1.2 0 > kio 28 i 493.8 4975240 4887793 87447 0 4231049 1.2 0 > kio 29 i 540.7 5447501 5348881 98620 0 4663363 1.2 0 > kio 30 i 519.7 5236453 5146948 89505 0 4477662 1.2 0 > kio 31 s 470.1 4736726 4651697 85029 0 4083221 1.2 0 > kio 32 i 486.8 4904118 4817193 86925 0 4248903 1.2 0 > kio 33 i 494.6 4983023 4893916 89107 0 4265053 1.2 0 > kio 34 i 521.9 5258301 5163651 94650 0 4475629 1.2 0 > kio 35 i 526.2 5301896 5208327 93569 0 4541526 1.2 0 > kio 36 i 496.1 4998220 4909563 88657 0 4257202 1.2 0 > kio 37 i 489.4 4930951 4843299 87652 0 4257872 1.2 0 > kio 38 i 514.6 5184693 5094258 90435 0 4448206 1.2 0 > msc 0 i 0.1 1326 0 0 0 1323 1.0 0 > aio 0 i 0.0 330 110 0 0 330 1.0 0 > aio 1 i 0.0 0 0 0 0 0 0.0 0 > pio 0 i 0.0 0 0 0 0 0 0.0 0 > lio 0 i 0.0 0 0 0 0 0 0.0 0 > > Regards, > Vartika Agrawal > > > ************************************************************************** > ***** > Forum Note: Use "Reply" to post a response in the discussion forum.

"If you are using a few large chunks instead of a larger number of smaller chunks, you will have only one flush thread per chunk running at checkpoint time. More chunks means more flush threads means less time to flush." Dang, is this still true as of 10? We may have caused our demise by using a few large chunks like 20gig chunks. (not my idea I wanted 5 gig chunks but I let it happen.)

Yes, still true. Art On Tue, Jul 8, 2008 at 11:29 AM, CURTIS CROWSON <curtis@crowson1.com> wrote: > "If you are using a few large chunks instead of a larger number of smaller > chunks, you will have only one flush thread per chunk running at checkpoint > time. More chunks means more flush threads means less time to flush." > > Dang, is this still true as of 10? We may have caused our demise by using a > few large chunks like 20gig chunks. (not my idea I wanted 5 gig chunks but > I > let it happen.) > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

Is it still true for IDS 11.5 as well? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Tuesday, July 08, 2008 1:08 PM To: ids@iiug.org Subject: Re: Analysis of activities during checkpoint. [12599] Yes, still true. Art On Tue, Jul 8, 2008 at 11:29 AM, CURTIS CROWSON <curtis@crowson1.com> wrote: > "If you are using a few large chunks instead of a larger number of smaller > chunks, you will have only one flush thread per chunk running at checkpoint > time. More chunks means more flush threads means less time to flush." > > Dang, is this still true as of 10? We may have caused our demise by using a > few large chunks like 20gig chunks. (not my idea I wanted 5 gig chunks but > I > let it happen.) > > > > **************************************************************************** *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

In version 11 there are non-blocking checkpoints. So the time to flush data from the bufferpool to disk is generally not done while blocking users. John = "Larry Sorensen" = <lsorensen25@msn. = com> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect RE: Analysis of activities durin= g 07/08/2008 02:52 checkpoint. [12604] = PM = = = Please respond to = ids@iiug.org = = = Is it still true for IDS 11.5 as well? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of A= rt Kagel Sent: Tuesday, July 08, 2008 1:08 PM To: ids@iiug.org Subject: Re: Analysis of activities during checkpoint. [12599] Yes, still true. Art On Tue, Jul 8, 2008 at 11:29 AM, CURTIS CROWSON <curtis@crowson1.com> wrote: > "If you are using a few large chunks instead of a larger number of smaller > chunks, you will have only one flush thread per chunk running at checkpoint > time. More chunks means more flush threads means less time to flush."= > > Dang, is this still true as of 10? We may have caused our demise by u= sing a > few large chunks like 20gig chunks. (not my idea I wanted 5 gig chunk= s but > I > let it happen.) > > > > ***********************************************************************= ***** *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinion= s and do not reflect on my employer, Oninit, the IIUG, nor any other organiza= tion with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. ***********************************************************************= ***** *** Forum Note: Use "Reply" to post a response in the discussion forum. ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =

I don't believe this has been changed, but there is at least another important factor to consider: amount of data change.... You can have very large chunks, full of static data... Regards, On Tue, Jul 8, 2008 at 10:52 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > Is it still true for IDS 11.5 as well? > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Tuesday, July 08, 2008 1:08 PM > To: ids@iiug.org > Subject: Re: Analysis of activities during checkpoint. [12599] > > Yes, still true. > > Art > > On Tue, Jul 8, 2008 at 11:29 AM, CURTIS CROWSON <curtis@crowson1.com> > wrote: > > > "If you are using a few large chunks instead of a larger number of > smaller > > > chunks, you will have only one flush thread per chunk running at > checkpoint > > time. More chunks means more flush threads means less time to flush." > > > > Dang, is this still true as of 10? We may have caused our demise by using > a > > few large chunks like 20gig chunks. (not my idea I wanted 5 gig chunks > but > > > I > > let it happen.) > > > > > > > > > > **************************************************************************** > *** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > > do not reflect on my employer, Oninit, the IIUG, nor any other organization > with which I am associated either explicitly or implicitly. Neither do > those opinions reflect those of other individuals affiliated with any > entity > > with which I am affiliated nor those of the entities themselves. > > > **************************************************************************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

Yes, and likely for 12.00 also when it comes out. ;-) Art On Tue, Jul 8, 2008 at 5:52 PM, Larry Sorensen <lsorensen25@msn.com> wrote: > Is it still true for IDS 11.5 as well? > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Tuesday, July 08, 2008 1:08 PM > To: ids@iiug.org > Subject: Re: Analysis of activities during checkpoint. [12599] > > Yes, still true. > > Art > > On Tue, Jul 8, 2008 at 11:29 AM, CURTIS CROWSON <curtis@crowson1.com> > wrote: > > > "If you are using a few large chunks instead of a larger number of > smaller > > > chunks, you will have only one flush thread per chunk running at > checkpoint > > time. More chunks means more flush threads means less time to flush." > > > > Dang, is this still true as of 10? We may have caused our demise by using > a > > few large chunks like 20gig chunks. (not my idea I wanted 5 gig chunks > but > > > I > > let it happen.) > > > > > > > > > > **************************************************************************** > *** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > > do not reflect on my employer, Oninit, the IIUG, nor any other organization > with which I am associated either explicitly or implicitly. Neither do > those opinions reflect those of other individuals affiliated with any > entity > > with which I am affiliated nor those of the entities themselves. > > > **************************************************************************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

So you are saying it is fixed in 13? ;-)

John, I like that word "generally" :-) IF something was to be blocked I suspect it would be a write and only if in the same chunk as the checkpoint? Or is this even less likely than I think. I have a 30GB dbspace that mainly occasional inserts to the end and sooner or later we will need to delete from the beginning (SEQ # wise). LOTS of queries in between. Tim Ertl 413-442-9000 x6211 -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of John Miller iii Sent: Tuesday, July 08, 2008 6:17 PM To: ids@iiug.org Subject: RE: Analysis of activities during checkpoint. [12605] In version 11 there are non-blocking checkpoints. So the time to flush data from the bufferpool to disk is generally not done while blocking users. John = "Larry Sorensen" = <lsorensen25@msn. = com> = To Sent by: ids@iiug.org = ids-bounces@iiug. = cc org = Subj= ect RE: Analysis of activities durin= g 07/08/2008 02:52 checkpoint. [12604] = PM = = = Please respond to = ids@iiug.org = = = Is it still true for IDS 11.5 as well? -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of A= rt Kagel Sent: Tuesday, July 08, 2008 1:08 PM To: ids@iiug.org Subject: Re: Analysis of activities during checkpoint. [12599] Yes, still true. Art On Tue, Jul 8, 2008 at 11:29 AM, CURTIS CROWSON <curtis@crowson1.com> wrote: > "If you are using a few large chunks instead of a larger number of smaller > chunks, you will have only one flush thread per chunk running at checkpoint > time. More chunks means more flush threads means less time to flush."= > > Dang, is this still true as of 10? We may have caused our demise by u= sing a > few large chunks like 20gig chunks. (not my idea I wanted 5 gig chunk= s but > I > let it happen.) > > > > ***********************************************************************= ***** *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinion= s and do not reflect on my employer, Oninit, the IIUG, nor any other organiza= tion with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. ***********************************************************************= ***** *** Forum Note: Use "Reply" to post a response in the discussion forum. ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. = **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

Hi Andreas, I did get some performance improvement after adding few(10) AIO vps for last 2 days with rest of the setting intact. But now when I do onstat -g iov, I find that except 2 aio ,io/wup for rest of the aio is 1.0. Whether these aios are being used ? Should I remove 10 & 11? pl refer the following stat. kio 36 i 243.0 68120889 66661550 1459339 0 63846178 1.1 0 kio 37 b 233.5 65444359 64075472 1368887 0 60868980 1.1 0 kio 38 i 241.7 67742292 66355169 1387123 0 62165395 1.1 0 msc 0 i 0.1 20552 0 0 0 20537 1.0 0 aio 0 i 0.0 5175 1718 0 0 5175 1.0 0 aio 1 i 0.0 1 0 0 0 1 1.0 0 aio 2 i 0.0 1 0 0 0 1 1.0 0 aio 3 i 0.0 1 0 0 0 1 1.0 0 aio 4 i 0.0 1 0 0 0 1 1.0 0 aio 5 i 0.0 1 0 0 0 1 1.0 0 aio 6 i 0.0 1 0 0 0 1 1.0 0 aio 7 i 0.0 1 0 0 0 1 1.0 0 aio 8 i 0.0 1 0 0 0 1 1.0 0 aio 9 i 0.0 1 0 0 0 1 1.0 0 aio 10 i 0.0 0 0 0 0 1 0.0 0 aio 11 i 0.0 0 0 0 0 1 0.0 0 pio 0 i 0.0 0 0 0 0 0 0.0 0 lio 0 i 0.0 0 0 0 0 0 0.0 0 How long does the effect of dynamically added vps last? What are the other settings which can be done to boost system performance while IDS is on-line? I do not have any formal training in ids dba so pl. ignore any dumb question? Regards, Vartika.

Hi, when using KAIO (kio-threads in onstat -g iov) AIO handles only some special operations - I don't remember exactly which, but not really important. In case of KAIO (and raw devices) 2 (or maximum 4) AIO VPS are enough. But more don't hurt performance unless memory is very very tight. Dynamically added VPs are active until reconfiguration (with onmode again) or until IDS restart. Regards, Andreas > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von > VARTIKA AGRAWAL > Gesendet: Donnerstag, 10. Juli 2008 13:44 > An: ids@iiug.org > Betreff: Re: AW: AW: AW: AW: Analysis of activities dur.... [12625] > > Hi Andreas, > > I did get some performance improvement after adding few(10) AIO vps for > last 2 > days with rest of the setting intact. But now when I do onstat -g iov, I > find > that except 2 aio ,io/wup for rest of the aio is 1.0. Whether these aios > are > being used ? > Should I remove 10 & 11? pl refer the following stat. > > kio 36 i 243.0 68120889 66661550 1459339 0 63846178 1.1 0 > kio 37 b 233.5 65444359 64075472 1368887 0 60868980 1.1 0 > kio 38 i 241.7 67742292 66355169 1387123 0 62165395 1.1 0 > msc 0 i 0.1 20552 0 0 0 20537 1.0 0 > aio 0 i 0.0 5175 1718 0 0 5175 1.0 0 > aio 1 i 0.0 1 0 0 0 1 1.0 0 > aio 2 i 0.0 1 0 0 0 1 1.0 0 > aio 3 i 0.0 1 0 0 0 1 1.0 0 > aio 4 i 0.0 1 0 0 0 1 1.0 0 > aio 5 i 0.0 1 0 0 0 1 1.0 0 > aio 6 i 0.0 1 0 0 0 1 1.0 0 > aio 7 i 0.0 1 0 0 0 1 1.0 0 > aio 8 i 0.0 1 0 0 0 1 1.0 0 > aio 9 i 0.0 1 0 0 0 1 1.0 0 > aio 10 i 0.0 0 0 0 0 1 0.0 0 > aio 11 i 0.0 0 0 0 0 1 0.0 0 > pio 0 i 0.0 0 0 0 0 0 0.0 0 > lio 0 i 0.0 0 0 0 0 0 0.0 0 > > How long does the effect of dynamically added vps last? What are the other > settings which can be done to boost system performance while IDS is on- > line? > I do not have any formal training in ids dba so pl. ignore any dumb > question? > > Regards, > Vartika. > > > ************************************************************************** > ***** > Forum Note: Use "Reply" to post a response in the discussion forum.

2008/7/10 Andreas.KUTSCHE@spar.at <andreas.kutsche@spar.at>: > Hi, > > when using KAIO (kio-threads in onstat -g iov) AIO handles only some special > operations - I don't remember exactly which, but not really important. No , just unimportant things like message log, console log and (possibly) archives if sent to disk !! > In case of KAIO (and raw devices) 2 (or maximum 4) AIO VPS are enough. > But more don't hurt performance unless memory is very very tight. > > Dynamically added VPs are active until reconfiguration (with onmode again) > or until IDS restart. > > Regards, > Andreas > >> > ------------------------------------------- > SPAR Österreichische Warenhandels-AG > Hauptzentrale > A - 5015 Salzburg, Europastrasse 3 > FN 34170 a > > Tel: +43 662 4470 24223 > Mobile: +43 664 6259575 > E-Mail: Andreas.KUTSCHE@spar.at > Internet: http://www.spar.at > > Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich > geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, > enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die > Informationen in dieser E-Mail sind ausschließlich für den Adressaten > bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir > Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung > zu setzen. > Über das Internet versandte E-Mails können leicht manipuliert oder unter > fremdem Namen erstellt werden. Daher schließen wir die rechtliche > Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der > Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich > bestätigt und gezeichnet wird. > Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung > von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. > hieraus entstehende Schäden. > Wir danken für Ihr Verständnis. > > Important notice: The contents of this e-mail may contain confidential and > legally protected information that is in particular related to operational and > trade secrets, which the recipient is obliged to treat as confidential. The > information in this e-mail is made available exclusively for use by the > addressee. In the event that the e-mail may have been sent to you in error, we > would ask you to kindly delete this communication from your system and to > contact us. > E-mails sent via the Internet can be easily manipulated or sent out under > someone else's name. We therefore do not accept legal liability for the > information contained in this communication. The contents of the e-mail are > only legally binding if they have been confirmed and signed by us in writing. > If, in spite of our using Antivirus protection software, a virus may have > penetrated your system through the sending of this e-mail, we do not accept > liability for any damage that may possibly arise as a result of this. > We trust that you appreciate our position. > > ------------------------------------------- > -----Ursprüngliche Nachricht----- > >> Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von >> VARTIKA AGRAWAL >> Gesendet: Donnerstag, 10. Juli 2008 13:44 >> An: ids@iiug.org >> Betreff: Re: AW: AW: AW: AW: Analysis of activities dur.... [12625] >> >> Hi Andreas, >> >> I did get some performance improvement after adding few(10) AIO vps for >> last 2 >> days with rest of the setting intact. But now when I do onstat -g iov, I >> find >> that except 2 aio ,io/wup for rest of the aio is 1.0. Whether these aios >> are >> being used ? >> Should I remove 10 & 11? pl refer the following stat. >> >> kio 36 i 243.0 68120889 66661550 1459339 0 63846178 1.1 0 >> kio 37 b 233.5 65444359 64075472 1368887 0 60868980 1.1 0 >> kio 38 i 241.7 67742292 66355169 1387123 0 62165395 1.1 0 >> msc 0 i 0.1 20552 0 0 0 20537 1.0 0 >> aio 0 i 0.0 5175 1718 0 0 5175 1.0 0 >> aio 1 i 0.0 1 0 0 0 1 1.0 0 >> aio 2 i 0.0 1 0 0 0 1 1.0 0 >> aio 3 i 0.0 1 0 0 0 1 1.0 0 >> aio 4 i 0.0 1 0 0 0 1 1.0 0 >> aio 5 i 0.0 1 0 0 0 1 1.0 0 >> aio 6 i 0.0 1 0 0 0 1 1.0 0 >> aio 7 i 0.0 1 0 0 0 1 1.0 0 >> aio 8 i 0.0 1 0 0 0 1 1.0 0 >> aio 9 i 0.0 1 0 0 0 1 1.0 0 >> aio 10 i 0.0 0 0 0 0 1 0.0 0 >> aio 11 i 0.0 0 0 0 0 1 0.0 0 >> pio 0 i 0.0 0 0 0 0 0 0.0 0 >> lio 0 i 0.0 0 0 0 0 0 0.0 0 >> >> How long does the effect of dynamically added vps last? What are the other >> settings which can be done to boost system performance while IDS is on- >> line? >> I do not have any formal training in ids dba so pl. ignore any dumb >> question? >> >> Regards, >> Vartika. >> >> >> ************************************************************************** >> ***** >> Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

You're fine. The output is telling you that all but 2 AIO VPs are being actively used, so you needed them. You can probably reduce by one or even 2 with no ill effect. Dynamic VPS live only until the server is brought down. You have to modify the ONCCONFIG file to make the change take effect when the server next comes online. Art On Thu, Jul 10, 2008 at 7:44 AM, VARTIKA AGRAWAL <vartika_agrawal@ril.com> wrote: > Hi Andreas, > > I did get some performance improvement after adding few(10) AIO vps for > last 2 > days with rest of the setting intact. But now when I do onstat -g iov, I > find > that except 2 aio ,io/wup for rest of the aio is 1.0. Whether these aios > are > being used ? > Should I remove 10 & 11? pl refer the following stat. > > kio 36 i 243.0 68120889 66661550 1459339 0 63846178 1.1 0 > kio 37 b 233.5 65444359 64075472 1368887 0 60868980 1.1 0 > kio 38 i 241.7 67742292 66355169 1387123 0 62165395 1.1 0 > msc 0 i 0.1 20552 0 0 0 20537 1.0 0 > aio 0 i 0.0 5175 1718 0 0 5175 1.0 0 > aio 1 i 0.0 1 0 0 0 1 1.0 0 > aio 2 i 0.0 1 0 0 0 1 1.0 0 > aio 3 i 0.0 1 0 0 0 1 1.0 0 > aio 4 i 0.0 1 0 0 0 1 1.0 0 > aio 5 i 0.0 1 0 0 0 1 1.0 0 > aio 6 i 0.0 1 0 0 0 1 1.0 0 > aio 7 i 0.0 1 0 0 0 1 1.0 0 > aio 8 i 0.0 1 0 0 0 1 1.0 0 > aio 9 i 0.0 1 0 0 0 1 1.0 0 > aio 10 i 0.0 0 0 0 0 1 0.0 0 > aio 11 i 0.0 0 0 0 0 1 0.0 0 > pio 0 i 0.0 0 0 0 0 0 0.0 0 > lio 0 i 0.0 0 0 0 0 0 0.0 0 > > How long does the effect of dynamically added vps last? What are the other > settings which can be done to boost system performance while IDS is > on-line? > I do not have any formal training in ids dba so pl. ignore any dumb > question? > > Regards, > Vartika. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

How to remove unwanted aio vps? I m getting following error - DB10:informix 19% onmode -p -1 aio onmode: error when trying to change the number of aio virtual processor by -1. :( vartika.

Hi Vartika, Please check this link. You can add but not drop virtual processors of the AIO, PIO, LIO, TLI, SHM, SOC, and STR classes. http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.ad ref.doc/adref308.htm Thanks.. Amitava E - id : amitacha@in.ibm.com "VARTIKA AGRAWAL" <vartika_agrawal@ ril.com> To Sent by: ids@iiug.org ids-bounces@iiug. cc org Subject Re: AW: AW: AW: AW: Analysis of 11/07/2008 13:16 activities dur.... [12657] Please respond to ids@iiug.org How to remove unwanted aio vps? I m getting following error - DB10:informix 19% onmode -p -1 aio onmode: error when trying to change the number of aio virtual processor by -1. :( vartika. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Ok, Thank you. But is there any workaround or shall i wait till engine re-starts ? vartika.

Hello, to get rid of the additional AIO VPs you must wait until engine restart. But the additional AIO VPs don't hurt your performance. Regards, Andreas > ------------------------------------------- SPAR Österreichische Warenhandels-AG Hauptzentrale A - 5015 Salzburg, Europastrasse 3 FN 34170 a Tel: +43 662 4470 24223 Mobile: +43 664 6259575 E-Mail: Andreas.KUTSCHE@spar.at Internet: http://www.spar.at Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse, enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die Informationen in dieser E-Mail sind ausschließlich für den Adressaten bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung zu setzen. Über das Internet versandte E-Mails können leicht manipuliert oder unter fremdem Namen erstellt werden. Daher schließen wir die rechtliche Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich bestätigt und gezeichnet wird. Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl. hieraus entstehende Schäden. Wir danken für Ihr Verständnis. Important notice: The contents of this e-mail may contain confidential and legally protected information that is in particular related to operational and trade secrets, which the recipient is obliged to treat as confidential. The information in this e-mail is made available exclusively for use by the addressee. In the event that the e-mail may have been sent to you in error, we would ask you to kindly delete this communication from your system and to contact us. E-mails sent via the Internet can be easily manipulated or sent out under someone else's name. We therefore do not accept legal liability for the information contained in this communication. The contents of the e-mail are only legally binding if they have been confirmed and signed by us in writing. If, in spite of our using Antivirus protection software, a virus may have penetrated your system through the sending of this e-mail, we do not accept liability for any damage that may possibly arise as a result of this. We trust that you appreciate our position. ------------------------------------------- -----Ursprüngliche Nachricht----- > Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] Im Auftrag von > VARTIKA AGRAWAL > Gesendet: Freitag, 11. Juli 2008 11:20 > An: ids@iiug.org > Betreff: Re: AW: AW: AW: AW: Analysis of activities dur.... [12660] > > Ok, Thank you. > > But is there any workaround or shall i wait till engine re-starts ? > > vartika. > > > ************************************************************************** > ***** > Forum Note: Use "Reply" to post a response in the discussion forum.

Restart IS the workaround. Oh, PLEASE do not strip the post you are replying to from your reply. Many of us follow the forums and CDI using the email gateways and we don't keep hundreds of threads in our inboxes just to we will know what post you are replying to. It's not just you, Vartika this is becoming an epidemic. Please everyone, snip the posts if you think they're getting long or irrellevant, but leave enough so we all know what you are replying to. Art On Fri, Jul 11, 2008 at 5:19 AM, VARTIKA AGRAWAL <vartika_agrawal@ril.com> wrote: > Ok, Thank you. > > But is there any workaround or shall i wait till engine re-starts ? > > vartika. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

You can only remove AIO VPS with onmode if this was added dinamicaly, else, you need to reduce the number in the onconfig param and stop/start your server. -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of VARTIKA AGRAWAL Sent: Viernes, 11 de Julio de 2008 02:46 a.m. To: ids@iiug.org Subject: Re: AW: AW: AW: AW: Analysis of activities dur.... [12657] How to remove unwanted aio vps? I m getting following error - DB10:informix 19% onmode -p -1 aio onmode: error when trying to change the number of aio virtual processor by -1. :( vartika. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.