IDS Forum

RE: Bug arc_very_old_pages()

Posted By:
Date:

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 >>$myout
done
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

Messages In This Thread

• Bug arc_very_old_pages()
  Milena Ilieva -- Friday, 11 April 2003, at 10:39 a.m.
  • Re: Bug arc_very_old_pages()
    timothy.a.brown@marconi.com -- Friday, 11 April 2003, at 11:17 a.m.
    • RE: Bug arc_very_old_pages()
      Popova, Sylvia (CGI) -- Friday, 11 April 2003, at 3:33 p.m.
  • RE: Bug arc_very_old_pages()
    Simmons, Keith -- Monday, 14 April 2003, at 3:50 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.