Bug arc_very_old_pages()

Hello, I have seen duscussions about bug #101062 - arc_very_old_pages(). We just faced this problem this week, even though it could have existed for a long time. IDS 7.30 UC10 UnixWare 7.1.1 Informix crashed while level 0 backup was running. I know this bug has been fixed in 7.31 and above, so we are going to upgrade Informix. But until we do that I still have to do backups. One thing I have noticed - that the first level 1 backup (after level 0) was much much bigger (we are doing the incremental backups in file) than it used to be. It is just impossible to have so much data for 1 day. My question is - Does this bug affect the volume of the incremental backups? Thanks in advance, Milena __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

Hi Milena, We also ran into this bug. Since we are running SAP (ERP), there are notes that suggest it's not a good idea to continue running incremental backups after you set the CCFLAGS parameter in your onconfig file following the upgrade. This leads me to believe that the work-around might affect incremental backups, though I really don't know. I'd suggest you talk with Informix Support about this... Good luck, -Tim "Milena Ilieva " To: ids@iiug.org <milena_ilieva@ cc: yahoo.com> Subject: Bug arc_very_old_pages() [900] Sent by: forum.subscribe r@iiug.org 04/11/2003 10:39 AM Hello, I have seen duscussions about bug #101062 - arc_very_old_pages(). We just faced this problem this week, even though it could have existed for a long time. IDS 7.30 UC10 UnixWare 7.1.1 Informix crashed while level 0 backup was running. I know this bug has been fixed in 7.31 and above, so we are going to upgrade Informix. But until we do that I still have to do backups. One thing I have noticed - that the first level 1 backup (after level 0) was much much bigger (we are doing the incremental backups in file) than it used to be. It is just impossible to have so much data for 1 day. My question is - Does this bug affect the volume of the incremental backups? Thanks in advance, Milena __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

Hi Milena, CCFLAGS will have to be set in the onconfig to CCFLAGS 0x400000. You wont have problems with the speed of level 0 or 1 anymore... Here is the workaround: ARCHIVE TIMESTAMP PROBLEM AND PERFORMANCE - Document Number: 253 Summary: This article discusses bugs 101062 as it pertains to archiving. Ways to isolate, determine risk, resolve and workarounds are given. Detail: Each online page is composed of a timestamp. The timestamp will either be in the range of plus or minus 2 gig (2147483647) or 0 to 4294967295. Each page must have a value in this range. The archive algorithm uses this to qualify pages during the backup and checks the value of the timestamp during restores. BUG: 101062 ARCHIVE PERFORMANCE DEGRADATION WHEN MANY CALLS TO ARC_VERY_OLD_PAGE() STATUS: As of 10/22/99 it is verified in all families and not fixed in any version. SYMPTOMS: An archive will run fine thru some dbspaces but will slow down on others. It will also run fine for a while and then run slow, up to 4 times as long as normal. Then it will run normally again. ANALYSIS: Run the onstat -g ath |grep arcbackup. You will find on 7.3 x/9.x an arcbackup1 and arcbackup2 thread. On 7.2x you will only find one arc* thread. Get the thread id of the arcbackup1 or arc thread and then run the following command: onstat -g stk . The tid is the thread id. Then run this command several times during the archive. You will see many stacks that show the arc_very_old_pages function. If you don't see this function then this is not likely the bug. If you see calls to kaio_... then it could be an OS bug that involves Kernal AIO (KAIO). Here is a script to watch an archive and log the backup threads stacks: #!/bin/sh #--------------------------------------------------------------------# #- This script will monitor all archive threads and log the stack -# #- traces for each. The only thread not monitored is the logbackup -# #- thread. -# #--------------------------------------------------------------------# #- 1. Set the variables if not set already. -# #- 2. Set naptime to desired sleep interval. Default is 3 sec. -# #- 3. Set myout to the log file you wish. Default is arc.sh.out -# #- 4. Exit the script by using control-c. Program will exit when -# #- backup completes. -# #--------------------------------------------------------------------# #- Set the environment here -# #INFORMIXSERVER #ONCONFIG #INFORMIXSQLHOSTS #INFORMIXDIR #PATH $INFORMIXDIR/bin:${PATH} naptime=3 notstarted=1 myout="$0.out" rm -f $myout while [ -f $0 ] do #- get the ontape threads and dump the stacks -# mytape=`onstat -g ath|grep ontape|cut -c1-7` myarc=`onstat -g ath|grep arc|cut -c1-7` tapecnt=`onstat -g ath|grep ontape|wc -l` if [ "$tapecnt" -eq 0 ] then if [ "$notstarted" -eq 0 ] then exit 0 fi else notstarted=0 fi for mytid in $mytape $myarc do onstat -g stk $mytid >>$myoutdone sleep $naptime done #-------- End of script -------# Update from Brandon Lahey on 1/11/2001: There are two fixes for this Bug. If the patch has the John Miller fix, then CCFLAGS will have to be set in the onconfig to CCFLAGS 0x400000. The following bugs will also need to be included with that patch. 144164, 134718, 144100, 144428, 145675 and a new bug not yet identified. If the customer gets the R&D patch, then all of the bugs listed above are included in the fix, except BUG 145675 and the new bug not identified. If in doubt about which fix you have, you can verify this with the DSDPA engineer that did the patch. UPDATE on 5/16/2001: The fix was in General Release 7.31.UC7 and higher and is off by default. The above patch information is involves this as the way to activiate the patch: The new functionality introduced by the fix to Bug 101062 is not turned on by default. You must enable the new functionality by setting the following ONCONFIG parameter before bringing the engine online. CCFLAGS 0x400000 To verify that the proper CCFLAGS settings are in effect: Using dbaccess, select database 'sysmaster'. Run the following query: select hex(value) from sysshmhdr where name = "ccflags"; This will return: (expression) 0x00400000 *NOTE: This assumes you don't currently run with any other CCFLAGS enabled. *NOTE: It is important that once CCFLAGS has been set for bug 101062 that it not be turned off for that instance. There are potential problems should this occur. 1. The archives would revert to being slow. 2. In the window between when the engine was brought up without CCFLAGS being set and when the next archive is taken, there would be the potential for corruption. This could only occur where there was an engine crash and then only during fast recovery. This is due to the change in the physical log. Regards, Sylvia -----Original Message----- From: timothy.a.b.... [mailto:timothy.a.brown@marconi.com] Sent: Friday, April 11, 2003 11:18 AM To: ids@iiug.org Subject: Re: Bug arc_very_old_pages() [901] Hi Milena, We also ran into this bug. Since we are running SAP (ERP), there are notes that suggest it's not a good idea to continue running incremental backups after you set the CCFLAGS parameter in your onconfig file following the upgrade. This leads me to believe that the work-around might affect incremental backups, though I really don't know. I'd suggest you talk with Informix Support about this... Good luck, -Tim "Milena Ilieva " To: ids@iiug.org <milena_ilieva@ cc: yahoo.com> Subject: Bug arc_very_old_pages() [900] Sent by: forum.subscribe r@iiug.org 04/11/2003 10:39 AM Hello, I have seen duscussions about bug #101062 - arc_very_old_pages(). We just faced this problem this week, even though it could have existed for a long time. IDS 7.30 UC10 UnixWare 7.1.1 Informix crashed while level 0 backup was running. I know this bug has been fixed in 7.31 and above, so we are going to upgrade Informix. But until we do that I still have to do backups. One thing I have noticed - that the first level 1 backup (after level 0) was much much bigger (we are doing the incremental backups in file) than it used to be. It is just impossible to have so much data for 1 day. My question is - Does this bug affect the volume of the incremental backups? Thanks in advance, Milena __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

Milena You need to go to 7.31 UD5 at least for the bug fix and then need to the ONCONFIG parameter CCFLAGS. Yes this bug will affect incremental backups (both level 1 and 2) as well as level 0. Keith -> -----Original Message----- -> From: Milena Ilieva [mailto:milena_ilieva@yahoo.com] -> Sent: Friday, April 11, 2003 3:39 PM -> To: ids@iiug.org -> Subject: Bug arc_very_old_pages() [900] -> -> -> Hello, -> -> I have seen duscussions about bug #101062 - -> arc_very_old_pages(). -> We just faced this problem this week, even though it -> could have existed for a long time. -> -> IDS 7.30 UC10 -> UnixWare 7.1.1 -> -> Informix crashed while level 0 backup was running. I -> know this bug has been fixed in 7.31 and above, so we -> are going to upgrade Informix. But until we do that I -> still have to do backups. One thing I have noticed - -> that the first level 1 backup (after level 0) was much -> much bigger (we are doing the incremental backups in -> file) than it used to be. It is just impossible to -> have so much data for 1 day. -> -> My question is - Does this bug affect the volume of -> the incremental backups? -> -> Thanks in advance, -> -> Milena -> -> __________________________________________________ -> Do you Yahoo!? -> Yahoo! Tax Center - File online, calculators, forms, and more -> http://tax.yahoo.com -> ******************************************************************************** ** This message is sent in strict confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. ******************************************************************************** **