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 (AT) liemar (DOT) 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 (AT) liemar (DOT) nl> wrote:


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:

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/doc...de2.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 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 (AT) austin (DOT) rr.com> wrote

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 (AT) liemar (DOT) nl> wrote: