Hi all


At a client site we encountered the problem that a certain file grew with 
3Mb a day, the same amount of data went into the table as was deleted. When 
we recover this file, the size decreases to its original size. We then got 
the tip that we should modify the pervasive 8 setting "File Growth Factor" 
from its original value of 15% to eg. 0%. This modification helped a bit, 
the growth of this file is now 3Mb a week. Still after a recover action, the 
size decreases again to its original size. It is acceptable that the file 
growths a bit, but this size is strange (at least we think it is).

(Magic 9, Pervasive 8, Windows2000 and Windows2003).

With Pervasive 7/2000i we don't have this problem (with exactly the same 
software (Magic 9 and our application) and platforms)

Does anyone else encounter the same problem or more important, knows what to 
do about it?


Thanks in advance
-- 
Met vriendelijke groet,


Barry van den Reek
Support Manager
Liemar Automatiseringen BV

Tel.         : 0031 40 248 4041
Fax         : 0031 40 248 3771
e-mail     : barry@liemar.nl
website   : http://www.liemar.nl


De informatie in dit document heeft een vertrouwelijk karakter en is
dientengevolge uitsluitend bestemd voor de geadresseerde(n). Indien u
niet als geadresseerde bent aangeduid, dient u zich te onthouden van
kennisneming, openbaarmaking en verveelvoudiging van de informatie die
dit document bevat. Indien dit document u kennelijk onbedoeld heeft bereikt,
verzoeken wij u onverwijld contact met ons op te nemen en dit document
te vernietigen. Aan dit bericht kunnen geen rechten worden ontleend.

Barry,

When you say recover do you mean using the rebuild utility?

The problem with the rebuild utility is that it results in a table
with just about fully populated pages. Therefore almost none of the
tables that get loaded in memory will have any free slots, so the
engine has no choice but to create new pages. As a result you'll
typically see a significant filegrowth just after using the rebuild
utility. If you populate the table with Butil -load or Butil -copy
you'll end up with a file that is initially larger but will show less
file growth at start (using default settings).

You'll see similar results after using rebuild on earlier versions of
Pervasive. If diskspace is such a problem that you feel obliged to use
rebuild in order to compact the files, you should advise your customer
to invest.

Gordon


On Fri, 11 Mar 2005 11:30:56 GMT, "Barry van den Reek"
<barry@liemar.nl> wrote:

>Hi all
>
>
>At a client site we encountered the problem that a certain file grew with 
>3Mb a day, the same amount of data went into the table as was deleted. When 
>we recover this file, the size decreases to its original size. We then got 
>the tip that we should modify the pervasive 8 setting "File Growth Factor" 
>from its original value of 15% to eg. 0%. This modification helped a bit, 
>the growth of this file is now 3Mb a week. Still after a recover action, the 
>size decreases again to its original size. It is acceptable that the file 
>growths a bit, but this size is strange (at least we think it is).
>
>(Magic 9, Pervasive 8, Windows2000 and Windows2003).
>
>With Pervasive 7/2000i we don't have this problem (with exactly the same 
>software (Magic 9 and our application) and platforms)
>
>Does anyone else encounter the same problem or more important, knows what to 
>do about it?
>
>
>Thanks in advance

 
 Gordon Bos
 Q-RY Solutions
 +31-(0)15-2564035

 http://www.q-ry.nl/

Hi Barry,

I have a feeling that one of the changes in V8 was, the "preallocation" 
chosen when creating a file is now applied *every* time the file needs 
to be expanded.  Previously, I think the setting was used just once when 
the file was created... i.e. you would get a new file with lots of 
preallocated space, which would then grow slowly as required.  Now, 
it'll expand less-often, but in much larger leaps.

I kind of remember reading this back in the days of the V8 beta. 
However, I cannot find any reference to this in the current V8 
documentation.  I think it may have been in a "What's New" document that 
was an overview for the beta.

Either way, I don't think this new behaviour in V8 is necessarilly your 
problem.  I'm not even sure that you have a problem... it's well known 
that Btrieve files will continue to grow and never shrink in size.

If you routinely put 3Mb of data into a file and subsequently remove 
that data, surely this leaves you with a large 3Mb chunk of "free" space 
to be reused the next day?

Jon






Barry van den Reek wrote:
> Hi all
> 
> 
> At a client site we encountered the problem that a certain file grew with 
> 3Mb a day, the same amount of data went into the table as was deleted. When 
> we recover this file, the size decreases to its original size. We then got 
> the tip that we should modify the pervasive 8 setting "File Growth Factor" 
> from its original value of 15% to eg. 0%. This modification helped a bit, 
> the growth of this file is now 3Mb a week. Still after a recover action, the 
> size decreases again to its original size. It is acceptable that the file 
> growths a bit, but this size is strange (at least we think it is).
> 
> (Magic 9, Pervasive 8, Windows2000 and Windows2003).
> 
> With Pervasive 7/2000i we don't have this problem (with exactly the same 
> software (Magic 9 and our application) and platforms)
> 
> Does anyone else encounter the same problem or more important, knows what to 
> do about it?
> 
> 
> Thanks in advance

There is a change with the Pervasive.SQL V8 engine when used with 8.x
files.  It is called the "turbo write accelerator".  
From the V8 What's New manual:
http://www.pervasive.com/library/docs/psql/810/whatsnew/perfmkde2.html#91696
---------------
Synopsis

TWA improves performance by grouping changed file pages together in
memory, and writing them sequentially to disk as a block. This
behavior reduces the number of seeks performed by the hard drive head
during each disk write operation, and also reduces the number of
separate disk write operations performed when the database engine is
under a heavy write load.

While this release of the database engine can read and write any data
file format version 5.x and higher, TWA is only used with files stored
in the new file format available with this release, version 8.x.
Requirements

The database engine uses TWA only when writing to files stored in 8.x
file format. ...
---------------

Might as well set the create file format back to 7.x if you set the
file growth factor back to 0 as it will have the same affect.

Leonard

On Mon, 14 Mar 2005 17:34:09 +0000, Jon Grieve
<jgrieve@southdown-co-uk> wrote:

>Hi Barry,
>
>I have a feeling that one of the changes in V8 was, the "preallocation" 
>chosen when creating a file is now applied *every* time the file needs 
>to be expanded.  Previously, I think the setting was used just once when 
>the file was created... i.e. you would get a new file with lots of 
>preallocated space, which would then grow slowly as required.  Now, 
>it'll expand less-often, but in much larger leaps.
>
>I kind of remember reading this back in the days of the V8 beta. 
>However, I cannot find any reference to this in the current V8 
>documentation.  I think it may have been in a "What's New" document that 
>was an overview for the beta.
>
>Either way, I don't think this new behaviour in V8 is necessarilly your 
>problem.  I'm not even sure that you have a problem... it's well known 
>that Btrieve files will continue to grow and never shrink in size.
>
>If you routinely put 3Mb of data into a file and subsequently remove 
>that data, surely this leaves you with a large 3Mb chunk of "free" space 
>to be reused the next day?
>
>Jon
>
>
>
>
>
>
>Barry van den Reek wrote:
>> Hi all
>> 
>> 
>> At a client site we encountered the problem that a certain file grew with 
>> 3Mb a day, the same amount of data went into the table as was deleted. When 
>> we recover this file, the size decreases to its original size. We then got 
>> the tip that we should modify the pervasive 8 setting "File Growth Factor" 
>> from its original value of 15% to eg. 0%. This modification helped a bit, 
>> the growth of this file is now 3Mb a week. Still after a recover action, the 
>> size decreases again to its original size. It is acceptable that the file 
>> growths a bit, but this size is strange (at least we think it is).
>> 
>> (Magic 9, Pervasive 8, Windows2000 and Windows2003).
>> 
>> With Pervasive 7/2000i we don't have this problem (with exactly the same 
>> software (Magic 9 and our application) and platforms)
>> 
>> Does anyone else encounter the same problem or more important, knows what to 
>> do about it?
>> 
>> 
>> Thanks in advance

Hi All,

The problem with the growth of the files is that we had a file e.g. 
Allinput.^01 of 2Gb, a Allinput.^02 of 2Gb and a Allinput.fil of 600 Mb. 
When our application used the file the CPU on the server went up to 99% 
usage. So the problem is not the space on the disk but the CPU usage. When 
we recovered the file it was back to the "original" 35 Mb. In version 7 and 
2000 Pervasive reused the emptied space of the file to fill with the new 
data, but it seems to me that version 8 only adds the data without reusing 
the empty spaces in a file, while the File Growth Factor is set te 0%.
At another customer I have set the file format back to 7.x to see if the 
file also grows that hard.

I'll keep you informed

Barry



"Leonard" <lharvey@austin.rr.com> wrote in message 
news:n2vc31hhpg4bpu86g8evdbhuqshgmt858i@4ax.com...
> There is a change with the Pervasive.SQL V8 engine when used with 8.x
> files.  It is called the "turbo write accelerator".
> From the V8 What's New manual:
> http://www.pervasive.com/library/docs/psql/810/whatsnew/perfmkde2.html#91696
> ---------------
> Synopsis
>
> TWA improves performance by grouping changed file pages together in
> memory, and writing them sequentially to disk as a block. This
> behavior reduces the number of seeks performed by the hard drive head
> during each disk write operation, and also reduces the number of
> separate disk write operations performed when the database engine is
> under a heavy write load.
>
> While this release of the database engine can read and write any data
> file format version 5.x and higher, TWA is only used with files stored
> in the new file format available with this release, version 8.x.
> Requirements
>
> The database engine uses TWA only when writing to files stored in 8.x
> file format. ...
> ---------------
>
> Might as well set the create file format back to 7.x if you set the
> file growth factor back to 0 as it will have the same affect.
>
> Leonard
>
> On Mon, 14 Mar 2005 17:34:09 +0000, Jon Grieve
> <jgrieve@southdown-co-uk> wrote:
>
>>Hi Barry,
>>
>>I have a feeling that one of the changes in V8 was, the "preallocation"
>>chosen when creating a file is now applied *every* time the file needs
>>to be expanded.  Previously, I think the setting was used just once when
>>the file was created... i.e. you would get a new file with lots of
>>preallocated space, which would then grow slowly as required.  Now,
>>it'll expand less-often, but in much larger leaps.
>>
>>I kind of remember reading this back in the days of the V8 beta.
>>However, I cannot find any reference to this in the current V8
>>documentation.  I think it may have been in a "What's New" document that
>>was an overview for the beta.
>>
>>Either way, I don't think this new behaviour in V8 is necessarilly your
>>problem.  I'm not even sure that you have a problem... it's well known
>>that Btrieve files will continue to grow and never shrink in size.
>>
>>If you routinely put 3Mb of data into a file and subsequently remove
>>that data, surely this leaves you with a large 3Mb chunk of "free" space
>>to be reused the next day?
>>
>>Jon

Keep in mind that the Create File Version is just that.  It determines
the file version of any new files.  Existing files do not change
versions unless rebuilt.

Leonard

On Tue, 15 Mar 2005 12:37:53 GMT, "Barry van den Reek"
<barry@liemar.nl> wrote:

>Hi All,
>
>The problem with the growth of the files is that we had a file e.g. 
>Allinput.^01 of 2Gb, a Allinput.^02 of 2Gb and a Allinput.fil of 600 Mb. 
>When our application used the file the CPU on the server went up to 99% 
>usage. So the problem is not the space on the disk but the CPU usage. When 
>we recovered the file it was back to the "original" 35 Mb. In version 7 and 
>2000 Pervasive reused the emptied space of the file to fill with the new 
>data, but it seems to me that version 8 only adds the data without reusing 
>the empty spaces in a file, while the File Growth Factor is set te 0%.
>At another customer I have set the file format back to 7.x to see if the 
>file also grows that hard.
>
>I'll keep you informed
>
>Barry
>
>
>
>"Leonard" <lharvey@austin.rr.com> wrote in message 
>news:n2vc31hhpg4bpu86g8evdbhuqshgmt858i@4ax.com...
>> There is a change with the Pervasive.SQL V8 engine when used with 8.x
>> files.  It is called the "turbo write accelerator".
>> From the V8 What's New manual:
>> http://www.pervasive.com/library/docs/psql/810/whatsnew/perfmkde2.html#91696
>> ---------------
>> Synopsis
>>
>> TWA improves performance by grouping changed file pages together in
>> memory, and writing them sequentially to disk as a block. This
>> behavior reduces the number of seeks performed by the hard drive head
>> during each disk write operation, and also reduces the number of
>> separate disk write operations performed when the database engine is
>> under a heavy write load.
>>
>> While this release of the database engine can read and write any data
>> file format version 5.x and higher, TWA is only used with files stored
>> in the new file format available with this release, version 8.x.
>> Requirements
>>
>> The database engine uses TWA only when writing to files stored in 8.x
>> file format. ...
>> ---------------
>>
>> Might as well set the create file format back to 7.x if you set the
>> file growth factor back to 0 as it will have the same affect.
>>
>> Leonard
>>
>> On Mon, 14 Mar 2005 17:34:09 +0000, Jon Grieve
>> <jgrieve@southdown-co-uk> wrote:
>>
>>>Hi Barry,
>>>
>>>I have a feeling that one of the changes in V8 was, the "preallocation"
>>>chosen when creating a file is now applied *every* time the file needs
>>>to be expanded.  Previously, I think the setting was used just once when
>>>the file was created... i.e. you would get a new file with lots of
>>>preallocated space, which would then grow slowly as required.  Now,
>>>it'll expand less-often, but in much larger leaps.
>>>
>>>I kind of remember reading this back in the days of the V8 beta.
>>>However, I cannot find any reference to this in the current V8
>>>documentation.  I think it may have been in a "What's New" document that
>>>was an overview for the beta.
>>>
>>>Either way, I don't think this new behaviour in V8 is necessarilly your
>>>problem.  I'm not even sure that you have a problem... it's well known
>>>that Btrieve files will continue to grow and never shrink in size.
>>>
>>>If you routinely put 3Mb of data into a file and subsequently remove
>>>that data, surely this leaves you with a large 3Mb chunk of "free" space
>>>to be reused the next day?
>>>
>>>Jon
>