CCFLAGS

CCFLAGS

Post by Simmons, Keit » Wed, 27 Nov 2002 21:02:06



Following a recent aborted upgrade to 7.31 UD4 (see other threads) we are
now back runing on 7.31 UC6. A prime reason for the upgrade was to be able
to use the onconfig parameter CCFLAGS to speed archives by eliminating the
'very old pages' bug. In all the excitment :-)) of backing out the upgrade
CCFLAGS was accidently left in the onconfig file. The archive we now have
running is going to complete in record time and does not seem to be hitting
the bug. My understanding was the CCFLAGS was only active at version UC7 and
above, can anyone confirm or deny this?

Keith

**********************************************************************************
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.
**********************************************************************************

 
 
 

CCFLAGS

Post by Madison Prue » Thu, 28 Nov 2002 00:40:58


CCFLAGS has existed (undocumented) since 5.x.
The purpose of CCFLAGS is to do additional consistancy checking.  These other checks
include things such as memory scribbeling, memory checking, etc.  Most of the setting
of CCFLAGS have a significant impact on performance.  It was a convienent way to do
set the old page archive logic, but personally, I would have prefered that some other
means besides setting a CCFLAGS bit had been chosen.  It's too easy to set a wrong
flag in CCFLAGS that can cause an adverse affect on the engine.

CCFLAGS has never been in the onconfig.std because it is undocumented.


> Following a recent aborted upgrade to 7.31 UD4 (see other threads) we are
> now back runing on 7.31 UC6. A prime reason for the upgrade was to be able
> to use the onconfig parameter CCFLAGS to speed archives by eliminating the
> 'very old pages' bug. In all the excitment :-)) of backing out the upgrade
> CCFLAGS was accidently left in the onconfig file. The archive we now have
> running is going to complete in record time and does not seem to be hitting
> the bug. My understanding was the CCFLAGS was only active at version UC7 and
> above, can anyone confirm or deny this?

> Keith

> **********************************************************************************
> 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.
> **********************************************************************************

--
---------------------------------------
Madison Pruet
Enterprise Replication Product Development
IBM Informix Dynamic Server
Dallas, Texas

 
 
 

CCFLAGS

Post by Bill Dar » Thu, 28 Nov 2002 00:07:51


I have seen pretty much the same thing.  I have installed and backed out UD4
3 times for various reasons.  I do not see as much problem with the
arc_very_old_pages problem as before, but it still does show up once in a
while.  I attributed the improvement to a change in my update statistics
rather than leaving CCFLAGS set in ONCONFIG.  
On my first upgrade to UD4 I ran an UPDATE STATISTICS LOW on all tables.
Since I only run HIGH on a regular basis, the LOW made the server start
cleaning up many thousands of deleted B-tree items that were never actually
deleted.  After a few hours of this an assert fail for a corrupt B-tree
caused a chunk to be marked down.  I restored the dbspace from tape and
backed out UD4.  Since then I have run Art Kagel's dostats once a week to
clean up these B-tree items.  
Since then I have seen much less problems with the archives.  I don't know
if it is the CCFLAGS or the UPDATE STATISTICS LOW.

Regards,
Bill

> -----Original Message-----

> Sent:      Tuesday, November 26, 2002 7:02 AM

> Subject:   CCFLAGS

> Following a recent aborted upgrade to 7.31 UD4 (see other threads) we are
> now back runing on 7.31 UC6. A prime reason for the upgrade was to be able
> to use the onconfig parameter CCFLAGS to speed archives by eliminating the
> 'very old pages' bug. In all the excitment :-)) of backing out the upgrade
> CCFLAGS was accidently left in the onconfig file. The archive we now have
> running is going to complete in record time and does not seem to be
> hitting
> the bug. My understanding was the CCFLAGS was only active at version UC7
> and
> above, can anyone confirm or deny this?

> Keith

> **************************************************************************
> ********
> 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.
> **************************************************************************
> ********

 
 
 

CCFLAGS

Post by James Latime » Thu, 28 Nov 2002 03:10:10


HP-UX 11.0
INFORMIX 7.31FD2
OMNIBACK II
Database ~200GB

I have been fighting backup times for over a year particularly on one SAP
(4.5B) systems.  The times initially range 15-16 hours.  Adding regular
update statistics scripts reduced the times to 8-9 hours.

Out of frustration and lack of finding a satisfactory solution I recently
made a change to the Informix parameter TAPEBLK.  (Yes, I know that the
Backup and Restore Guide indicates that this parameter is ignored by OnBar).
  OmniBack had been setup with 256K for blocksize and the TAPEBLK value was
64K.  Out of curiousity, I recently changed the value to 128K.  The backup
times are now 5.5 to 5.75 hours.  I wanted to change the value to 256K but
all changes are 'frozen' until after the first of the year.

Informix Tech support has no explanation and indicates the parameter is
ignored by OnBar.  This may be true but it would appear that it could be
used by OmniBack in the roll of Storage Manager.

I do not really care at this point since this systems backup times are now
less than any other system.

I was aware of CCFLAGS but my impression was that it would basically result
in treating everything as a Level 0 so I was reserving this as the last
action.

This is not a recommendation.  It did work for me and I do understand the
frustration of resolving Informix 7.31 backup times.  I just wish that I
would be allowed to change the value to match OmniBack (256K).




>Subject: RE: CCFLAGS
>Date: Tue, 26 Nov 2002 10:07:51 -0500

>I have seen pretty much the same thing.  I have installed and backed out
>UD4
>3 times for various reasons.  I do not see as much problem with the
>arc_very_old_pages problem as before, but it still does show up once in a
>while.  I attributed the improvement to a change in my update statistics
>rather than leaving CCFLAGS set in ONCONFIG.
>On my first upgrade to UD4 I ran an UPDATE STATISTICS LOW on all tables.
>Since I only run HIGH on a regular basis, the LOW made the server start
>cleaning up many thousands of deleted B-tree items that were never actually
>deleted.  After a few hours of this an assert fail for a corrupt B-tree
>caused a chunk to be marked down.  I restored the dbspace from tape and
>backed out UD4.  Since then I have run Art Kagel's dostats once a week to
>clean up these B-tree items.
>Since then I have seen much less problems with the archives.  I don't know
>if it is the CCFLAGS or the UPDATE STATISTICS LOW.

>Regards,
>Bill

> > -----Original Message-----

> > Sent: Tuesday, November 26, 2002 7:02 AM

> > Subject:      CCFLAGS

> > Following a recent aborted upgrade to 7.31 UD4 (see other threads) we
>are
> > now back runing on 7.31 UC6. A prime reason for the upgrade was to be
>able
> > to use the onconfig parameter CCFLAGS to speed archives by eliminating
>the
> > 'very old pages' bug. In all the excitment :-)) of backing out the
>upgrade
> > CCFLAGS was accidently left in the onconfig file. The archive we now
>have
> > running is going to complete in record time and does not seem to be
> > hitting
> > the bug. My understanding was the CCFLAGS was only active at version UC7
> > and
> > above, can anyone confirm or deny this?

> > Keith

>**************************************************************************
> > ********
> > 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.

>**************************************************************************
> > ********

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail
 
 
 

1. setting CCFLAGS in onconfig

This parameter takes a number of values. Set to 0x400000 will stop
foreground writes by updating pages with very old timestamps in the
buffer instead of on disk. However, I believe there is still a bug that
means every time a page is updated you get an af file dumped, so
performance is still hit.

I can't imagine how that is possible. Perhaps you need to disable it
during the actual restore.

Cheers,
--
Mark.

+----------------------------------------------------------+-----------+

| http://www.informix.com  http://www.informixhandbook.com |/////  / //|
| http://www.iiug.org  +-----------------------------------+////  / ///|
|                      |This email will self-destruct in   |///  / ////|
|                      |10 sec. If you received this email |//  / /////|
|                      |in error, sorry about the mess.    |/  ////////|
+----------------------+-----------------------------------+-----------+

2. JET function calls

3. CDaoRecordset : Strange SQL-Query Error